On 6/6/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I like the topology.xml approach. For the topology composite, I suggest
that
we use a syntax something like the following:
<composite>
<component name="runtimeA>
<implementation.runtime host="hostname or ip-address">
<mappings>
<binding name="binding.ws">
<scheme name="http" baseURI="http://$host:8080/acbd";> <!--
$host
points to the host attr of the implementation.runtime -->
<scheme name="https" baseURI="https://$host:8090/acbd";>
</binding>
<binding name="binding.jsonrpc">
<scheme name="http" baseURI="http://$host:8085/jsonxyz";>
</binding>
<binding name="binding.sca">
<scheme name="http" baseURI=http://$host:1234/>
</binding>
<component name="CalculatorServiceComponent"/>
<component name="AddServiceComponent"/>
</mappings>
</component>
...
</composite>
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, June 06, 2007 7:20 AM
Subject: Re: SCA Binding and Disitribution was: Distributed Composites
> [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/[email protected]/msg18242.html
>>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thinking about the proposals that have been made in this thread. I like
the idea of using the SCA concept of "component" to describe the services
that the runtime must implement to allow the distributed behaviour to be
managed. I think we can take it even further at that level but I still
think it's confusing to represent the runtime level as a composite.
Here's another shot:
<domain name="domainA">
<runtime name="runtimeA">
<scheme name="http" baseURI="http://$host:8080/acbd";>
<scheme name="https" baseURI="https://$host:8090/acbd";>
<component name="topology"/>
<implementation.java class="???"/>
<reference name="registry">
<binding.inline>
<assignedComponents>
<component name="CalculatorServiceComponent"/>
<component name="AddServiceComponent"/>
</assignedComponents>
</binding.inline>
</reference>
<component>
<component name="management"/>
<component name="scabinding"/>
</component>
</runtime>
<runtime name="runtimeB">
<scheme name="http" baseURI="http://$host:8081/acbd";>
<scheme name="https" baseURI="https://$host:8091/acbd";>
<component name="topology"/>
<implementation.java class="???"/>
<reference name="registry">
<binding.inline>
<assignedComponents>
<component name="AddServiceComponent"/>
</assignedComponents>
</binding.inline>
</reference>
<component>
<component name="management"/>
<component name="scabinding"/>
</runtime>
</domain>
Here I've invented some top level elements to represent the runtime itself
and concentrated on representing the various components of the runtime as
SCA components which can then expose services as appropriate. In this
example I'm implying that the component assignments come inline with the
file the intention being that this could be replaced with a binding that
gets them from a separate file or from across the network.
Alternatively we could define a service on the "topology" component that
allows the runtime to be notified of assignemnts. We could take the same
approach with components tagetted at managing the runtime, controlling the
SCA binding, manageing contributions etc.
Not sure about the "scheme" elements they could belong in some component
definition also but they seem more fundamental as without then you can't
really start up services.
Is this workable?
Simon
