Re: Distributed assemblies
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed assemblies
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]
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
Re: Distributed assemblies
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed assemblies
On 15/01/07, Jeremy Boynes [EMAIL PROTECTED] 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
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]
Re: Distributed assemblies
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
