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.
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]