You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/01/13 21:26:12 UTC
Distributed assemblies
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed assemblies
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/01/07, Jeremy Boynes <jb...@apache.org> wrote:
> 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?
>
> This is really about runtime-to-runtime cooperation - which
> implementation types a runtime can support would be something that
> was input to the decision making process (about what to run where).
> So, for example, a Ruby component could be allocated any C++ or Java
> runtime that supported that implementation type.
>
> I think we should use standard protocols for this communication, such
> as Bonjour, UPNP, JXTA etc. so that they can easily be supported by
> runtimes implemented in different languages. I.e we don't want a
> protocol that relies on synchronizing native Java/C++/... objects.
> Different domains may prefer different protocols (for networking
> reasons) so we want this to be plugable.
>
> Having said that, I wasn't planning on working on a non-Java version
> but if you see something that would be hard/impossible to implement
> in the C++ runtime please shout :-)
>
> --
> Jeremy
Hey! everything is hard/impossible to implement in C++ ;-)
I need to do some homework on this first but it's certainly an area I'm
interested in.
Cheers,
--
Pete
Re: Distributed assemblies
Posted by Jeremy Boynes <jb...@apache.org>.
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?
This is really about runtime-to-runtime cooperation - which
implementation types a runtime can support would be something that
was input to the decision making process (about what to run where).
So, for example, a Ruby component could be allocated any C++ or Java
runtime that supported that implementation type.
I think we should use standard protocols for this communication, such
as Bonjour, UPNP, JXTA etc. so that they can easily be supported by
runtimes implemented in different languages. I.e we don't want a
protocol that relies on synchronizing native Java/C++/... objects.
Different domains may prefer different protocols (for networking
reasons) so we want this to be plugable.
Having said that, I wasn't planning on working on a non-Java version
but if you see something that would be hard/impossible to implement
in the C++ runtime please shout :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed assemblies
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 15, 2007, at 10:32 AM, scabooz wrote:
> 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
A good one :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed assemblies
Posted by scabooz <sc...@gmail.com>.
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" <jm...@myromatours.com>
To: <tu...@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 <jm...@myromatours.com> 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 <jb...@apache.org>
>> >> 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: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >
>> > _________________________________________________________________
>> > MSN Hotmail is evolving – check out the new Windows Live Mail
>> > http://ideas.live.com
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed assemblies
Posted by Jim Marino <jm...@myromatours.com>.
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 <jm...@myromatours.com> 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 <jb...@apache.org>
>> >> 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: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >
>> > _________________________________________________________________
>> > MSN Hotmail is evolving – check out the new Windows Live Mail
>> > http://ideas.live.com
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed assemblies
Posted by Pete Robbins <ro...@googlemail.com>.
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 <jm...@myromatours.com> 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 <jb...@apache.org>
> >> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> > _________________________________________________________________
> > MSN Hotmail is evolving – check out the new Windows Live Mail
> > http://ideas.live.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete
Re: Distributed assemblies
Posted by Jim Marino <jm...@myromatours.com>.
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 <jb...@apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> _________________________________________________________________
> MSN Hotmail is evolving – check out the new Windows Live Mail
> http://ideas.live.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Distributed assemblies
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
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 <jb...@apache.org>
>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: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org