I'm coming in a little late to Jeremy's post, and trying
not to create too many email chains....
It seems to me that there's a simpler scenario that you
might want to start with. Two atomic components in the
SCA domain, communicating over the default binding
where each component is hosted on different JVMs.
There are fewer moving parts.
just an idea
Dave
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, January 15, 2007 9:54 AM
Subject: Re: Distributed assemblies
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: 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
---------------------------------------------------------------------
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]