As part of this are you considering only multiple Java runtimes or can this proposal embrace a C++/Python/Ruby component implementation deployed on the C++ runtime?
Cheers, On 13/01/07, Jim Marino <[EMAIL PROTECTED]> wrote:
On Jan 13, 2007, at 1:26 PM, Meeraj Kunnumpurath wrote: > Jeremy, > > Based on the discussion we had earlier I have started putting the > basic shell around the domain physical model and discovery service. > > 1. Both physical model discovery and service interfaces are hosted > in SPI. > 2. Under services I have started on couple of implementations for > the discovery service. > 3. I guess the physical model realisation would go into core. > 3. In standalone assembly, I have created the home for the admin > rutnime SCDL, that will host the client facing assembly service and > also manage the domain wide singleton assembly model. Once we get > this working we can look into moving this from a cerntalized model > to a more federated peer-to-peer model. > > The admin runtime uses the discovery service to listen for > federated runtimes, participating in the domain managed by the > admin runtime, coming alive. The runtimes publish their presence > using the discovery service when they come alive. The admin runtime > will use the current topology of the domain to send artifacts that > are deployed in the domain using the assembly service to > participating runtimes. I am still unclear on how the admin runtime > would make a decision on deploy component X in runtime X and > component Y in runtime Y. > > Anyway, I will keep the discovery and the domain physical model > service going. > Cool. I've been looking at the discover service in some detail (both zeroconf and JXTA) and when I have some more time, I'll post some thoughts as well. Jim > Ta > Meeraj > > >> From: Jeremy Boynes <[EMAIL PROTECTED]> >> Reply-To: tuscany-dev@ws.apache.org >> To: tuscany-dev@ws.apache.org >> Subject: Distributed assemblies >> Date: Sat, 13 Jan 2007 12:26:12 -0800 >> >> Meeraj and I were chatting this morning about an approach for >> supporting an SCA Domain that is broader than a single runtime. >> >> So far we have been focusing on the wiring and component models >> within a single address space (runtime) allowing us to hook up >> user and system components according to the principles of SCA >> assembly. This has provided us a foundation for expanding >> functionality to the more interesting distributed case where we >> are managing an assembly that spans multiple runtimes. To do >> that, we identified a set of system services that would support >> this: >> >> 1) a global assembly model which represents the logical assembly >> of application components in the domain >> 2) a global physical model which represents the online physical >> structure of the domain (primarily which runtimes are participating) >> 3) a discovery service which would abstract the protocols used to >> discover/track the physical structure (a layering over protocols >> such as UPNP, Bonjour or JXTA) >> 4) a user-facing assembly service that allows them to manipulate >> the logical assembly >> 5) a "run this" (need a better name) service that allows the >> assembly service to control which logical components are actually >> running on a physical runtime (this may include bindings to >> support inter-runtime connections) >> >> The first use-case we want to support is one that allows a user >> to add a component to the assembly that is implemented by a >> composite that contains two components (X and Y) that are wired >> to each other but which need to be executed on two different >> physical runtimes (A and B). The assembly service will direct >> runtime A to run component X and runtime B to run component Y. It >> will also direct runtime A to bind the reference and runtime B to >> bind the service for the connecting wire so that X is able to >> invoke Y. >> >> This will take quite a bit of work so is probably best tackled in >> stages. The first priorities will be to get implementations of >> the user-facing assembly service and internal "run this" services >> running in a manner that supports distribution. We can do this >> locally by running two runtimes in a single server. At the same >> time we can be implementing a version of the discovery service >> that uses one of the standard protocols (which one is TBD) to >> build up the physical model. >> >> With this in place we can add the algorithms that determine how >> components get allocated to runtimes, starting with a basic form >> where the user provides the information and advancing to forms >> where it is configured by the global controller. The second phase >> will probably work in a master-slave mode where the controller >> runs on a single runtime (possibly with failover). A third phase >> will tackle the more complex problem of distributing the assembly >> model in a multi-master or pure-peer mode. >> >> -- >> Jeremy >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > _________________________________________________________________ > MSN Hotmail is evolving – check out the new Windows Live Mail > http://ideas.live.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Pete
