[snip]
Simon Laws wrote:
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.
This is a pretty nice starting point.
I would suggest to try to separate the topology description information
from the logical SCA domain composition:
- what runtimes are available
- for each runtime:
- the (logical) addresses at which it can be reached for each SCA
binding type
- the components allocated to that runtime
Here are two suggestions for doing this:
A topology.config file, something like that:
runtimeA:
binding.ws: http://localhost:8080/acbd
binding.sca: http://localhost:1234
binding.jsonrpc: http://localhost:8085/jsonxyz
components: CalculatorServiceComponent, AddServiceComponent
runtimeB:
binding.ws: http:myotherhost:6060/tuvw
binding.sca: http://myotherhost:5678
components: MultiplyServiceComponent, SubtractServiceComponent,
DivideServiceComponent
or a topology.xml file, where we would actually describe the SCA
runtimes, their configuration and how they are assembled on a network
using an SCA assembly:
topology.xml
<composite>
<component name="runtimeA>
<service>
<binding.ws uri="http://localhost:8080/acbd"/>
<binding.jsonrpc uri="http://localhost:8085/jsonxyz"/>
<binding.sca uri="http://localhost:1234"/>
</service>
<implementation.container>
<component name="CalculatorServiceComponent"/>
<component name="AddServiceComponent"/>
</implementation.container>
</component>
<component name="runtimeB">
<service>
<binding.ws uri="http://myotherhost:6060/tuvw"/>
<binding.sca uri="http://myotherhost:5678"/>
</service>
<implementation.container>
<component name="MultiplyServiceComponent"/>
<component name="SubtractServiceComponent"/>
<component name="DivideServiceComponent"/>
</implementation.container>
</component>
</composite>
What I find interesting with that second form - apart from the fact that
the user won't have to learn another configuration language if he
already knows SCA - is that we could use the <binding.*> configurations
in that topology file to host default configuration for the bindings
described in the SCA domain.
Then the notation that you're proposing with the runtime ID inlined in
the SCA domain logical assembly could be supported as well, but as a
progressive/shortcut option for want to inline the runtime allocation in
their SCA domain composite. However, we would have the capability, in
our underlying configuration model and runtime implementation to
completely separate the logical SCA domain composition and the topology
description, which are really two different dimensions of the
configuration of a service network.
Thoughts?
[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/tuscany-dev@ws.apache.org/msg18242.html
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
