Ultimately I think some of us would like to support federated
runtimes. In the Java runtime, we will be using a pluggable mechanism
for service discovery and some of the implementations have both Java
and C++ variants. For example, Bonjour and JXTA.
Jim
On Jan 15, 2007, at 6:44 AM, Pete Robbins wrote:
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: [email protected]
>> To: [email protected]
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
