Ok, I've taken the next step here and have a distributed runtime example
running in my sandbox. A sample calculator application [1] showing the
disitributed runtime in action and a module containing the changes I had to
make to the runtime to get this to work [2]. The changes are actually
trivial but getting them in the appropriate place was a bit of a challenge.
Looking at the sample first I have, for the purposes of this example, chosen
to extend the SCDL model with extra attributes to indicate which runtime a
component will run in.
<component name="CalculatorServiceComponent" runtimeId="sca://mydomain/A">
This information could have been conveyed in many other ways so alternative
suggestions are welcome. I'm using a URI based scheme here as I also use the
domain uri to hold the runtimeId. So when I start up a domain I do the
following...
SCADomain scaDomain = SCADomain.newInstance("sca://mydomain/A", "/", "
Calculator.composite");
Not convinced this is the correct use of this URI but it was convenient.
Would welcome comments on what this URI is going to be used for. I note that
there is a connect() method in the domain currently which implies there is
some though about creating connections between domains that hasn't been
resolved yet.
Basically what happens is that every domain that is started in this example
loads the complete composite and then identifies those components which it's
responsible for running by comparing the components runtimeId with the
domain URI. So every domain has all the information available to it and
filters the information based on what it knows about itself. There is not
exchange of change sets between the different parts of the domain.
If the domain encounters references to services that are not running in the
domain it replaces the local SCABinding with a JMS binding. All of the hard
work goes on in the localize() method of the CompositeActivatorImpl in [2].
I chose JMS in this case as I don't have to worry too much about the
physical location of the other runtimes. I.e. We can bring the runtimes up
anywhere and as long as they can connect to the JMS broker the disitributed
domain should work. The intention is however that it could be replaced by
any suitable binding or distribution infrastructure and we can't guarantee
that the physical endpoint information is not required. Looking at the other
bindings there seems to be some variability on how end points are
determined. I note that Raymond has already started to talk about this
variability [3] and I think it would be worth summarizing (on the wiki) what
information can potentially contribute to creating endpoints and the
scenarios which use the information. I'll have a go at this assuming someone
hasn't already got this list.
So, what's next? Well it would be good to get this running in HEAD so we
need to agree if this is on the right track. There are of course some
questions...
- How should components be allocated to runtimes.
- How should runtimes be identified - currently using URIs
- How best to hook into the runtime. I'm currently letting the model get
built from all contributions and then detecting cross VM operations during
CompositeActivation.
I think we need to look at generating an API for hooking into the
distributed runtime more generally. For example, we could replace the JMS
binding with a DistributedRuntimeBinding which could provide a more
comprehensive API to between the Tuscany runtime and the distribution
technology. This could, in turn, use JMS or any other technology.
Looking forward we also need an interface through which the runtimes
themselves can share information (start, stop, locate component for
example).
If you want to try out the code (not suggesting you should but feel free)
you need to get the two modules [1] and [2] and compile them using maven.
The calculator-distributed module has an ant script that is configured to
allow you to run the two parts of the disitributed domain with a classpath
set to include the changed files before the rest of the required tuscany
files. The thing you need to fix in build.xml is the location of your local
repository. So once you have this...
Open a terminal and run up ActiveMQ to provide a JMS broker. I'm using 4.1.1
.
Open a terminal and run the part of the domain that has the
AddServiceComponent in
cd calculator-distributed
ant run-classesB
Open a terminal and run the part of the domain that has the
CalculatorServiceComponent in
cd calculator-distributed
ant run-classesA
You should see the result of the add operation. I've not included the
subtract, multiple, divide components to this sample as currently the JMS
binding struggles with it's default settings when there is more that two
components trying to use it. Fixing this is a separate issue.
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/calculator-distributed/
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/disitributed-changes/
[3] http://www.mail-archive.com/[email protected]/msg18242.html
