On 4/30/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 4/24/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > Following on from the release content thread [1] I'd like to kick off a > discussion on how we resurrect support for a distributed runtime. We had > this feature before the core modularization and I think it would be good to > bring it back again. For me this is about working out how the tuscany > runtime can be successfully hosted in a distributed environment without > having to recreate what is done very well by existing distributed computing > technologies. > > The assembly model specification [3] deals briefly with this in its > discussion of SCA Domains > > "An SCA Domain represents a complete runtime configuration, potentially > distributed over a series of interconnected runtime nodes." > > Here is my quick sketch of the main structures described by the SCA > Domain section of the assembly spec. > > SCA Domain > Logical Services - service to control the domain > InstalledContribution (1 or more) > Base URI > Installed artifact URIs > Contribution - SCA and non-SCA artefacts contributed to the > runtime > /META_INF/sca-contribution.xml > deployable (composites) > import > export > Dependent Contributions - references to installed contributions > on which this one depends > Deployment Time Composites - composites added into an installed > contribution > Virtual Domain Level Composite - the running set of SCA artefacts. > Top level services are visible outside domain > Component, Service, Reference > Derived from notionally included installed composites > > The assembly spec says that "A goal of SCA's approach to deployment is > that the contents of a contribution should not need to be modified in order > to install and use the contents of the contribution in a domain.". This > seems sensible in that we don't want to have to rewrite composite files > every time we alter the physical set of nodes on which they are to run. > Typically in a distributed environment there is some automation of the > assignment of applications to nodes to cater for resilience, load balancing, > throughput etc. > > The assembly spec is not prescriptive about how an SCA Domain should be > mapped and supported across multiple runtime nodes but I guess the starting > point is to consider the set of components a system has, i.e. the set of > (top level?) components that populate the Virtual Domain Composite and > consider them as likely candidates for distributing across runtimes. > > So I would expect a manager of a distributed SCA runtime to go through a > number of stages in getting the system up and running. > > Define an SCA Domain (Looking at the mailing list Luciano is think these > thoughts also) > - domain definition > - as simple as a file structure (based on hierarchy from assembly > spec) in a shared file system. > - could implement more complex registry based system > - allocate nodes to the domain > - As simple as running up SCA runtime on each node in the domain. > > - For more complex scenarios might want to use a > scheduling/management system > > Add contributions to the domain > - Identify contributions required to form running service network > (developers will build/define contributions) > - Contribution these contributions to the domain > - in the simple shared file system scenario I would image they > just end up in on this file system available to all nodes in > the domain. > > Add contributions to the Virtual Domain Level Composite > - At this point it think we have to know where artifacts are > physically going to run > - It could be that all runtimes load all contributions and only expose > those destined for them or, I.e. each node has the full model loaded but > knows which bits it's running. > - Alternatively we could target each node specifically and ask it to > load a particular installed contribution and define > a distributed model. > > Manage the Domain > - Need to be able to target the logical service provided by the domain > at the appropriate runtime node > > In order to make this work the sca default binding has to be able to > work remotely across distributed runtimes so we need to select an existing > binding, or create a new one, to do this. > > I think in the first instance we should set the bar fairly low. I.e have > the target be running a sample application across two SCA runtimes > supporting java component implementations. This pretty much picks up where > we were with the distribution support before the core modularization effort. > > > I'm not sure what the target scenario should be but we could take one of > the samples we already have, e.g. SimpleBigBank which happens to have > two simple java components in its implementations, but we could go with any > of them. > > Thoughts > > Simon > > > [1] http://www.mail-archive.com/[email protected]/msg16898.html > [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16831.html > > [3] http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications > > > > Hi I've transferred this information over the the project wiki (http://cwiki.apache.org/confluence/display/TUSCANY/Distributed+Runtime ) and I've added a few more thoughts about how we can start off with quite a simplistic approach. I'm keen to get some input on this so feel free to comment here and add notes to the wiki. I hope that we can start to cut some code asap (well at least once the release activity has died down this week) to help us understand the problem so if any of this takes your fancy fell free to roll up your sleves etc. Regards Simon
Ok, so the release activity has finally started to die down so I'm bringing the disitributed runtime to the top of my pile of interesting things to look at. The notes made before are here [1]. I've been thinking about this a bit and started making baby steps toward a first example. I set up a calculator sample where, using exactly the same approach as M2, I marked components as belonging to nodes [2]. Now here I just chose this approach from the list we made before so the subject of how we map components to particular runtime is very much open and I welcome suggestions, for example, we may like to support external configurations that map component URIs to runtimes rather than adding info to the SCDL. Whatever infrastructure we are using underneath us to manage our disitributed domain (and there are plenty to choose from) has to be able to route messages to the right service. What the right service means depends on how we define and scope individual components. So we want to leverage the SCA extension mechanism to support bindings (possibly a bit fatter than the bindings that we already have) that can plug us into any suitable disitributed infrastructure solution and allow us to * Bring up all the runtimes in a domain. This may involve some registration/discovery activity but primarily relies on us being ably to identify the name of the domain, the name of the runtime in it and any active components. * Dispatch messages into the disitributed domain. We should leave message routing decisions to the underlying infrastructure as it may be providing load balancing etc. but we should be able to reach a specific component instance if we really have to. * Recieve messages from the disitributed domain. * Notify the sca runtime of important events like start, stop, move etc. What I'm doing now is looking at how to replace the SCABinding with something else when the runtime detects that a wire crosses a VM boundary (this is all VM to VM stuff at the moment). I've put some more code up in my sandbox which just prints out when it detect this situation, based on the runtimeIds not matching, and does nothing else. At the moment its a case of "stand back there's nothing to see" but what I want to do by way of a mock up is instigate a JMS binding so that all runtimes listen to a common pool of messages and just read those for which they are the target. Quite a common and straighforward approach to get us a running example we can prod and play with. Of course this doesn;t have to be a messaging solution we could use anything that allow Does this sound like a usful way to move the design on? Point to point protocols generally need access to physical addressing information so that strickes me as a step further on. I'lll continue to update the wiki page [1] with any thoughts and discussions that happen here. Regards Simon [1] http://cwiki.apache.org/confluence/display/TUSCANY/Distributed+Runtime [2] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/calculator-distributed/src/main/resources/Calculator.composite
