You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/03/12 12:28:36 UTC
[PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
I like the look of the workspace code Sebastien has been writing and I
propose to try it out on samples/calculator-distributed.
In particular I'd like to help Felix who is hitting the common filesystem
restriction of the current domain implementation .
Let me know if anyone has any concerns.
I'll report back with what I learn. There are other modules that rely on
distributed support
itest/callable-references
itest/domain
itest/osgi-tuscany/tuscany-3rdparty
itest/osgi-tuscay/tuscany-runtime
samples/calculator-distributed
tools/eclipse/plugins/runtime
I'm happy to think about those if the sample/calculator-distributed goes ok.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg02610.html
On Mon, Mar 10, 2008 at 6:07 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
> > Simon Laws wrote:
> >> On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <si...@googlemail.com>
> >> wrote:
> >>
> >>>
> >>> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
> >>> jsdelfino@apache.org> wrote:
> >>>
> >>>> Jean-Sebastien Delfino wrote:
> >>>>> Simon Laws wrote:
> >>>>>> I've been running the workspace code today with a view to
> integrating
> >>>> the
> >>>>>> new code in assembly which calculates service endpoints i.e. point4
> >>>>>> above.
> >>>>>>
> >>>>>> I think we need to amend point 4 to make this work properly..
> >>>>>>
> >>>>>> 4. Point my Web browser to the various ATOM collections to get:
> >>>>>> - lists of contributions, composites and nodes
> >>>>>> - list of contributions that are required by a given contribution
> >>>>>> - the source of a particular composite
> >>>>>> - the output of a composite after the domain composite has been
> built
> >>>> by
> >>>>>> CompositeBuilder
> >>>>>>
> >>>>>> Looking at the code in DeployableCompositeCollectionImpl I see that
> >>>> on
> >>>>>> doGet() it builds the request composite. What the last point needs
> >>>> to
> >>>>>> do is
> >>>>>>
> >>>>>> - read the whole domain
> >>>>>> - set up all of the service URIs for each of the included
> composites
> >>>>>> taking
> >>>>>> into account the node to which each composite is assigned
> >>>>>> - build the whole domain using CompositeBuilder
> >>>>>> - extract the required composite from the domain and serialize it
> >>>> out.
> >>>>> Yes, exactly!
> >>>>>
> >>>>>> Are you changing this code or can I put this in?
> >>>>> Just go ahead, I'll update and merge if I have any other changes in
> >>>> the
> >>>>> same classes.
> >>>>>
> >>>> Simon, a quick update: I've done an initial bring-up of node2-impl.
> >>>> It's
> >>>> still a little rough but you can give it a try if you want.
> >>>>
> >>>> The steps to run the store app for example with node2 are as follows:
> >>>>
> >>>> 1) use workspace-admin to add the store and assets contributions to
> the
> >>>> domain;
> >>>>
> >>>> 2) add the store composite to the domain composite using the admin as
> >>>> well;
> >>>>
> >>>> 3) start the StoreLauncher2 class that I just added to the store
> >>>> module;
> >>>>
> >>>> 4) that will start an instance of node2 with all the node config
> served
> >>>> from the admin app.
> >>>>
> >>>> So the next step is to integrate your node allocation code with
> >>>> workspace-admin and that will complete the story. Then we'll be able
> to
> >>>> remove all the currently hardcoded endpoint URIs from the composites.
> >>>>
> >>>> I'll send a more detailed description and steps to run more scenarios
> >>>> later on Friday.
> >>>>
> >>>> --
> >>>> Jean-Sebastien
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>> Ok, sounds good. I've done the uri integration although there are
> some
> >>> issues we need to discuss. First I'll update with your code, commit my
> >>> changes and then post here about the issues.
> >>>
> >>> Regards
> >>>
> >>> Simon
> >>>
> >> I've now checked in my changes (last commit was 634762) to integrate
> >> the URI
> >> calculation code with the workspace. I've run the new store launcher
> >> following Sebastien's instructions from a previous post to this thread.
> I
> >> don't seem to have broken it too much although I'm not seeing any
> >> prices for
> >> the catalog items.
> >
> > I was seeing that issue too before, it's a minor bug in the property
> > writing code, which is not writing property values correctly.
> >
> >> Issues with the URI generation code....
> >>
> >> I have to turn model resolution back on by uncommenting a line in
> >> ContributionContentProcessor.resolve. Otherwise the JavaImplementation
> >> types
> >> are not read and
> >> compositeConfiguationBuilder.calculateBindingURIs(defaultBindings,
> >> composite, null); can't generate default services. I then had to tun
> >> it back
> >> off to make the store sample work. I need some help on this one.
> >
> > I'm investigating now.
> >
> >>
> >> If you hand craft services it seems to be OK although I have noticed,
> >> looking at the generated SCDL, that it seems to be assuming that all
> >> generated service names will be based on the implementation classname
> >> regardless of whether the interface is marked as @Remotable or not.
> Feels
> >> like a bug somewhere so am going to look at that next.
> >
> > OK
> >
> >>
> >> To get Java implementation resolution to work I needed to hack in the
> >> Java
> >> factories setup in the DeployableCompositeCollectionImpl.initialize()
> >> method. This is not very good and raises the bigger question about
> >> the set
> >> up in here. It's creating a set of extension points in parallel to
> those
> >> created by the runtime running this component. Can we either use the
> >> registry created by the underlying runtime or do similar generic setup.
> >
> > Yes, I'd like to keep the infrastructure used by the admin decoupled
> > from the infrastructure of the runtime hosting the admin, but I'll try
> > to simplify the setup by creating an instance of runtime for the admin
> > and getting the necessary objects out of it, instead of assembling it
> > from scratch as it is now.
> >
> >> The code doesn't currently distinguish between those services that are
> >> @Remotable and those that aren't
> >>
> >> Simon
> >>
> >
> >
>
> Simon,
>
> After a few more changes, the domain / node allocation, default URI
> calculation and resolution of references across nodes now works OK.
>
> I was able to remove all the hardcoded URIs in the tutorial composites
> as they now get determined from the configuration of the nodes that the
> composites are deployed to.
>
> You can use the latest tutorial modules to see the end to end
> integration, with the following steps:
>
> 1. Start tutorial/domain/.../LaunchTutorialAdmin.
>
> 2. Open http://localhost:9990/ui/composite in your Web browser. You
> should see all the tutorial contributions and deployables that I've
> added to that domain.
>
> 3. Click the feeds in the "composite install image" to see the resolved
> composites.
>
> 4. Start all the launch programs in tutorial/nodes, you can start them
> in any order you want.
>
> 5. Open tutorial/assets/tutorial.html in your Web browser, follow the
> links to the various store implementations.
>
> Hope this helps.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Using new admin and nodes in the tutorial, was: [PROPOSAL] Using
new Workspace in samples/calculator-distributed
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Simon Laws wrote:
>> I got the code done last week but I'm only just now finishing up the
>> build.xml file. So, as promised, here's what I did (a bit of a long
>> post but
>> I think I got it all)
>>
>> Firstly to get more familiar with the workspace I followed Sebastien's
>> instructions from the Domain/Contribution repository thread [1] and
>> ran up
>> the workspace to have a play.
>>
>> "You can use the latest tutorial modules to see the end to end
>> integration,
>> with the following steps:
>>
>> 1. Start tutorial/domain/.../LaunchTutorialAdmin.
>>
>> 2. Open http://localhost:9990/ui/composite in your Web browser. You
>> should
>> see all the tutorial contributions and deployables that I've added to
>> that
>> domain.
>>
>> 3. Click the feeds in the "composite install image" to see the resolved
>> composites.
>>
>> 4. Start all the launch programs in tutorial/nodes, you can start them in
>> any order you want.
>>
>> 5. Open tutorial/assets/tutorial.html in your Web browser, follow the
>> links
>> to the various store implementations."
>>
>> The workspace is allowing you to organize the relationships between
>> contributions/composites, the domain composite that describes the whole
>> application and the nodes that will run the composites. It processes
>> all of
>> the contributions that have been provided, the composites they
>> contain, the
>> association of composite with the domain and with nodes and produces
>> fully
>> resolved composites in terms of the contributions that are require to run
>> them and the service and reference URIs that they will use.
>>
>> This resolved composite information is available from the workspace
>> through
>> composite specific feeds. From this feed you can get URLs to the required
>> contributions and the composite. In fact what happens each time you do
>> a GET
>> on the composite URL is that all of the composites assigned to the domain
>> are read and the domain composite is "built" in full using the composite
>> builder. The individual composite that was requested is then extracted
>> and
>> returned. In this way policy matching, cross domain wiring, autowiring
>> etc
>> is manged at the domain level using the same code used by the nodes to
>> build
>> individual composites.
>>
>> This is very similar in layout with what is happening with our current
>> domain/node implementation where you add contributions to the domain and
>> nodes run the resulting composites. However there is a big difference
>> here
>> in that there is now an implication that the domain is fully configured
>> before you start the nodes as the workspace is responsible for
>> configuring
>> service / reference URIs based on prior knowledge of node configurations.
>> Previously you could start nodes and have them register with the domain
>> without having to provide this knowledge manually to the domain. I guess
>> automatic node registration could be rolled into this if we want.
>>
>> In making the calculator-distributed sample work I wanted to be able
>> to test
>> the sample in our maven build so having a set of HTTP forms (which the
>> workspace does provide) to fill in is interesting but not that useful. So
>> immediately I went looking for the files that the workspace writes to
>> see if
>> I could create those and install them pre-configured ready for the
>> test to
>> run. I used the tutorial files as templates and made the following to
>> match
>> the calculator-distributed scenario.
>>
>> Firstly there is a file (workspace.xml) [2] that describes all each
>> contribution's location and URI
>>
>> <workspace xmlns="http://tuscany.apache.org/xmlns/sca/1.0" xmlns:ns1="
>> http://tuscany.apache.org/xmlns/sca/1.0">
>> <contribution location="file:./target/classes/nodeA" uri="nodeA"/>
>> <contribution location="file:./target/classes/nodeB" uri="nodeB"/>
>> <contribution location="file:./target/classes/nodeC" uri="nodeC"/>
>> <contribution location="file:./target/classes/cloud" uri="
>> http://tuscany.apache.org/xmlns/sca/1.0/cloud"/>
>> </workspace>
>>
>> Then there is a file (domain.composite) [3] that is a serialized
>> version of
>> the domain composite, i.e. what you would get from the specs
>> getDomainLevelComposite() method. This shows which composites are
>> deployed
>> at the domain level.
>>
>> <composite name="domain.composite"
>> targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
>> xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="
>> http://www.osoa.org/xmlns/sca/1.0">
>> <include name="ns2:CalculatorA" uri="nodeA" xmlns:ns2="http://sample"/>
>> <include name="ns2:CalculatorB" uri="nodeB" xmlns:ns2="http://sample"/>
>> <include name="ns2:CalculatorC" uri="nodeC" xmlns:ns2="http://sample"/>
>> </composite>
>>
>> Lastly there is a file (cloud.composite) [4] that is another SCA
>> composite
>> that describes the nodes that are going to run composites.
>>
>> <composite name="cloud.composite"
>> targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
>> xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="
>> http://www.osoa.org/xmlns/sca/1.0">
>> <include name="ns2:NodeA" uri="
>> http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
>> http://sample/cloud"/>
>> <include name="ns2:NodeB" uri="
>> http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
>> http://sample/cloud"/>
>> <include name="ns2:NodeC" uri="
>> http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
>> http://sample/cloud"/>
>> </composite>
>>
>> Each included node composite looks something like
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>> xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
>> targetNamespace="http://sample/cloud"
>> xmlns:s="http://sample"
>> name="NodeA">
>>
>> <component name="NodeA">
>> <t:implementation.node uri="nodeA" composite="s:CalculatorA"/>
>> <service name="Node">
>> <binding.sca uri="http://localhost:8100"/>
>> </service>
>> </component>
>>
>> </composite>
>>
>> You will note that the node holds default binding URI information.
>>
>> With these files the workspace can produce the fully configured
>> composites
>> that will run on each node.
>>
>> Having done this I rewrote the code in the "node" package to create a
>> set of
>> launchers for the various parts of the sample.
>>
>> node.LaunchDomain [5] was the first and simply calls the
>> DomainAdminLauncher
>> from the workspace-admin package. This starts an SCA application,
>> reads all
>> these files, makes some web pages available and more importantly make the
>> resolved composite information available at URLs starting
>> http://host:9990/.
>> ..
>>
>> node.LaunchCalculatorNodeA, B, C [6] allows each node to be started. You
>> will note that in each of these a node gets started with a line something
>> like
>>
>> node =
>> nodeFactory.createSCANode("http://localhost:9990/node-image/NodeA");
>>
>> This is a slightly different take on the node creation process we had
>> before
>> (this new node code is in the node2-* packages). It lets you create a
>> node
>> given a composite information. This is derived from the helper method
>> Simon
>> Nash put on the factory and in this case is the URI of an Atom feed that
>> provides a link to a composite and the contributions required to run that
>> composite. The node runs, pulls down this information. Based on this
>> information it pulls down each of the contributions and the composite and
>> starts up the composite.
>>
>> As all the composites are fully configured the nodes simply build,
>> activate
>> and start them. They don't need to go looking for service endpoints.
>>
>> The actual distributed calculator application is the same as it was
>> before.
>>
>> I hope this makes some kind of sense. Please ask if you want more
>> details.
>>
>> Regards
>>
>> Simon
>>
>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28711.html
>> [2]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/workspace.xml
>>
>> [3]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/domain.composite
>>
>> [4]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/cloud.composite
>>
>> [5]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchDomain.java
>>
>> [6]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchCalculatorNodeA.java
>>
>>
>
> Simon,
>
> Thanks a lot for that nice description!
>
> The last few days I've been busy with the bring-up of java/sca/tutorial
> on top of this, the last part of the tutorial that's not running now is
> the catalog-webapp (running into JAX-B issues I think I need to add the
> jaxb JARs to my JRE endorsed directory).
>
> Once that's running I'll try to post an update of the scenario
> description [1] with more details and screencaps of the admin pages.
>
With SVN revision r638721 the webapp part (in the catalog-webapp module
works as well).
Here are more details describing how to run the tutorial application,
and what you can do with the admin pages:
1. From sca/tutorial/domain (this is where the pre-defined tutorial
domain configuration is), start the admin application:
java -jar <install>/modules/tuscany-workspace-admin-1.2-incubating.jar
2. Open http://localhost:9990/ui/workspace in your web browser to work
with SCA Contributions. On that page you can list, add and delete
contributions.
A contribution has a URI and is located at an address. You can specify a
local JAR, a local folder, or an HTTP location.
You should see the SCA contributions from the tutorial (assets, cloud,
and different versions of the online store), their dependencies, and the
deployable composites that they contain. Here's a screencap:
http://people.apache.org/~jsdelfino/tuscany/admin/workspace.png
3. Open http://localhost:9990/ui/composite in your web browser to work
with the Composites included in the SCA domain composite. On that page
you can list the composites included in the domain composite, add and
delete composites.
A composite is identified by a namespace, a name and the URI of the
contribution that contains it. Only deployable composites can be
included in the domain composite (the list of deployables in each
contribution is shown on the Contributions page).
You should see the various SCA composites developed in the tutorial and
the components that they contain. Here's a screencap:
http://people.apache.org/~jsdelfino/tuscany/admin/composite.png
4. Open http://localhost:9990/ui/cloud in your web browser to work with
SCA nodes. On that page you can list, add and delete SCA nodes that will
run your SCA composites.
A node has a name, a URI (the HTTP address at which the service
components running on it will be available), and is configured to run a
composite, identified by its namespace, name and contribution URI.
At some point we'll need to implement popup lists on these pages to
select all these names instead of having to type them :)
You should see the nodes configured to run the various parts of the
tutorial. Here's a screencap:
http://people.apache.org/~jsdelfino/tuscany/admin/cloud.png
5. Click the Composite Install Image feeds to see the configuration of
the nodes. Each node is configured with an ATOM feed containing the
following links:
- the composite that you've configured to run on it
- the list of contributions required by that composite (the contribution
that contributed it and its dependencies).
6. The Start/Stop buttons are temporarily broken in revision r638721 at
least (I think it's a simple fix which I'll try to make tomorrow), but
to start a node you can just run the following from a command prompt:
java -jar <install>/modules/tuscany-node2-launcher-1.2-incubating.jar
http://localhost:9990/node-image/<node name>
The node identified by <node-name> will start, get its configuration
from that URL, get the composite to run and the required contributions
and start the service components in the composite as usual.
7. SCA contributions can also be packaged as WARs for deployment to
Tomcat for example. Module tutorial/nodes-jee/catalog-webapp shows an
example of that.
To run it, you can do the following:
- The catalog component will need the currency converter component to be
running to perform currency conversions. First, start the CurrencyNode
node as follows
java -jar <install>/modules/tuscany-node2-launcher-1.2-incubating.jar
http://localhost:9990/node-image/CurrencyNode
- Export environment variable TUSCANY_HOME=<tuscany install>, then start
Tomcat.
- Install tutorial-catalog-webapp.war on Tomcat as CatalogWebAppNode.war
then open http://localhost:9990/CatalogWebAppNode in your Web browser.
You should see the catalog with a few items in it.
Hope this helps. I'm thinking that we should probably start putting some
of this info on a Wiki page at some point.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [PROPOSAL] Using new Workspace in samples/calculator-distributed
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes:
was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> I got the code done last week but I'm only just now finishing up the
> build.xml file. So, as promised, here's what I did (a bit of a long post but
> I think I got it all)
>
> Firstly to get more familiar with the workspace I followed Sebastien's
> instructions from the Domain/Contribution repository thread [1] and ran up
> the workspace to have a play.
>
> "You can use the latest tutorial modules to see the end to end integration,
> with the following steps:
>
> 1. Start tutorial/domain/.../LaunchTutorialAdmin.
>
> 2. Open http://localhost:9990/ui/composite in your Web browser. You should
> see all the tutorial contributions and deployables that I've added to that
> domain.
>
> 3. Click the feeds in the "composite install image" to see the resolved
> composites.
>
> 4. Start all the launch programs in tutorial/nodes, you can start them in
> any order you want.
>
> 5. Open tutorial/assets/tutorial.html in your Web browser, follow the links
> to the various store implementations."
>
> The workspace is allowing you to organize the relationships between
> contributions/composites, the domain composite that describes the whole
> application and the nodes that will run the composites. It processes all of
> the contributions that have been provided, the composites they contain, the
> association of composite with the domain and with nodes and produces fully
> resolved composites in terms of the contributions that are require to run
> them and the service and reference URIs that they will use.
>
> This resolved composite information is available from the workspace through
> composite specific feeds. From this feed you can get URLs to the required
> contributions and the composite. In fact what happens each time you do a GET
> on the composite URL is that all of the composites assigned to the domain
> are read and the domain composite is "built" in full using the composite
> builder. The individual composite that was requested is then extracted and
> returned. In this way policy matching, cross domain wiring, autowiring etc
> is manged at the domain level using the same code used by the nodes to build
> individual composites.
>
> This is very similar in layout with what is happening with our current
> domain/node implementation where you add contributions to the domain and
> nodes run the resulting composites. However there is a big difference here
> in that there is now an implication that the domain is fully configured
> before you start the nodes as the workspace is responsible for configuring
> service / reference URIs based on prior knowledge of node configurations.
> Previously you could start nodes and have them register with the domain
> without having to provide this knowledge manually to the domain. I guess
> automatic node registration could be rolled into this if we want.
>
> In making the calculator-distributed sample work I wanted to be able to test
> the sample in our maven build so having a set of HTTP forms (which the
> workspace does provide) to fill in is interesting but not that useful. So
> immediately I went looking for the files that the workspace writes to see if
> I could create those and install them pre-configured ready for the test to
> run. I used the tutorial files as templates and made the following to match
> the calculator-distributed scenario.
>
> Firstly there is a file (workspace.xml) [2] that describes all each
> contribution's location and URI
>
> <workspace xmlns="http://tuscany.apache.org/xmlns/sca/1.0" xmlns:ns1="
> http://tuscany.apache.org/xmlns/sca/1.0">
> <contribution location="file:./target/classes/nodeA" uri="nodeA"/>
> <contribution location="file:./target/classes/nodeB" uri="nodeB"/>
> <contribution location="file:./target/classes/nodeC" uri="nodeC"/>
> <contribution location="file:./target/classes/cloud" uri="
> http://tuscany.apache.org/xmlns/sca/1.0/cloud"/>
> </workspace>
>
> Then there is a file (domain.composite) [3] that is a serialized version of
> the domain composite, i.e. what you would get from the specs
> getDomainLevelComposite() method. This shows which composites are deployed
> at the domain level.
>
> <composite name="domain.composite"
> targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
> xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="
> http://www.osoa.org/xmlns/sca/1.0">
> <include name="ns2:CalculatorA" uri="nodeA" xmlns:ns2="http://sample"/>
> <include name="ns2:CalculatorB" uri="nodeB" xmlns:ns2="http://sample"/>
> <include name="ns2:CalculatorC" uri="nodeC" xmlns:ns2="http://sample"/>
> </composite>
>
> Lastly there is a file (cloud.composite) [4] that is another SCA composite
> that describes the nodes that are going to run composites.
>
> <composite name="cloud.composite"
> targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
> xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="
> http://www.osoa.org/xmlns/sca/1.0">
> <include name="ns2:NodeA" uri="
> http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
> http://sample/cloud"/>
> <include name="ns2:NodeB" uri="
> http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
> http://sample/cloud"/>
> <include name="ns2:NodeC" uri="
> http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
> http://sample/cloud"/>
> </composite>
>
> Each included node composite looks something like
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
> targetNamespace="http://sample/cloud"
> xmlns:s="http://sample"
> name="NodeA">
>
> <component name="NodeA">
> <t:implementation.node uri="nodeA" composite="s:CalculatorA"/>
> <service name="Node">
> <binding.sca uri="http://localhost:8100"/>
> </service>
> </component>
>
> </composite>
>
> You will note that the node holds default binding URI information.
>
> With these files the workspace can produce the fully configured composites
> that will run on each node.
>
> Having done this I rewrote the code in the "node" package to create a set of
> launchers for the various parts of the sample.
>
> node.LaunchDomain [5] was the first and simply calls the DomainAdminLauncher
> from the workspace-admin package. This starts an SCA application, reads all
> these files, makes some web pages available and more importantly make the
> resolved composite information available at URLs starting http://host:9990/.
> ..
>
> node.LaunchCalculatorNodeA, B, C [6] allows each node to be started. You
> will note that in each of these a node gets started with a line something
> like
>
> node = nodeFactory.createSCANode("http://localhost:9990/node-image/NodeA");
>
> This is a slightly different take on the node creation process we had before
> (this new node code is in the node2-* packages). It lets you create a node
> given a composite information. This is derived from the helper method Simon
> Nash put on the factory and in this case is the URI of an Atom feed that
> provides a link to a composite and the contributions required to run that
> composite. The node runs, pulls down this information. Based on this
> information it pulls down each of the contributions and the composite and
> starts up the composite.
>
> As all the composites are fully configured the nodes simply build, activate
> and start them. They don't need to go looking for service endpoints.
>
> The actual distributed calculator application is the same as it was before.
>
> I hope this makes some kind of sense. Please ask if you want more details.
>
> Regards
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28711.html
> [2]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/workspace.xml
> [3]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/domain.composite
> [4]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/cloud.composite
> [5]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchDomain.java
> [6]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchCalculatorNodeA.java
>
Simon,
Thanks a lot for that nice description!
The last few days I've been busy with the bring-up of java/sca/tutorial
on top of this, the last part of the tutorial that's not running now is
the catalog-webapp (running into JAX-B issues I think I need to add the
jaxb JARs to my JRE endorsed directory).
Once that's running I'll try to post an update of the scenario
description [1] with more details and screencaps of the admin pages.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
I got the code done last week but I'm only just now finishing up the
build.xml file. So, as promised, here's what I did (a bit of a long post but
I think I got it all)
Firstly to get more familiar with the workspace I followed Sebastien's
instructions from the Domain/Contribution repository thread [1] and ran up
the workspace to have a play.
"You can use the latest tutorial modules to see the end to end integration,
with the following steps:
1. Start tutorial/domain/.../LaunchTutorialAdmin.
2. Open http://localhost:9990/ui/composite in your Web browser. You should
see all the tutorial contributions and deployables that I've added to that
domain.
3. Click the feeds in the "composite install image" to see the resolved
composites.
4. Start all the launch programs in tutorial/nodes, you can start them in
any order you want.
5. Open tutorial/assets/tutorial.html in your Web browser, follow the links
to the various store implementations."
The workspace is allowing you to organize the relationships between
contributions/composites, the domain composite that describes the whole
application and the nodes that will run the composites. It processes all of
the contributions that have been provided, the composites they contain, the
association of composite with the domain and with nodes and produces fully
resolved composites in terms of the contributions that are require to run
them and the service and reference URIs that they will use.
This resolved composite information is available from the workspace through
composite specific feeds. From this feed you can get URLs to the required
contributions and the composite. In fact what happens each time you do a GET
on the composite URL is that all of the composites assigned to the domain
are read and the domain composite is "built" in full using the composite
builder. The individual composite that was requested is then extracted and
returned. In this way policy matching, cross domain wiring, autowiring etc
is manged at the domain level using the same code used by the nodes to build
individual composites.
This is very similar in layout with what is happening with our current
domain/node implementation where you add contributions to the domain and
nodes run the resulting composites. However there is a big difference here
in that there is now an implication that the domain is fully configured
before you start the nodes as the workspace is responsible for configuring
service / reference URIs based on prior knowledge of node configurations.
Previously you could start nodes and have them register with the domain
without having to provide this knowledge manually to the domain. I guess
automatic node registration could be rolled into this if we want.
In making the calculator-distributed sample work I wanted to be able to test
the sample in our maven build so having a set of HTTP forms (which the
workspace does provide) to fill in is interesting but not that useful. So
immediately I went looking for the files that the workspace writes to see if
I could create those and install them pre-configured ready for the test to
run. I used the tutorial files as templates and made the following to match
the calculator-distributed scenario.
Firstly there is a file (workspace.xml) [2] that describes all each
contribution's location and URI
<workspace xmlns="http://tuscany.apache.org/xmlns/sca/1.0" xmlns:ns1="
http://tuscany.apache.org/xmlns/sca/1.0">
<contribution location="file:./target/classes/nodeA" uri="nodeA"/>
<contribution location="file:./target/classes/nodeB" uri="nodeB"/>
<contribution location="file:./target/classes/nodeC" uri="nodeC"/>
<contribution location="file:./target/classes/cloud" uri="
http://tuscany.apache.org/xmlns/sca/1.0/cloud"/>
</workspace>
Then there is a file (domain.composite) [3] that is a serialized version of
the domain composite, i.e. what you would get from the specs
getDomainLevelComposite() method. This shows which composites are deployed
at the domain level.
<composite name="domain.composite"
targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="
http://www.osoa.org/xmlns/sca/1.0">
<include name="ns2:CalculatorA" uri="nodeA" xmlns:ns2="http://sample"/>
<include name="ns2:CalculatorB" uri="nodeB" xmlns:ns2="http://sample"/>
<include name="ns2:CalculatorC" uri="nodeC" xmlns:ns2="http://sample"/>
</composite>
Lastly there is a file (cloud.composite) [4] that is another SCA composite
that describes the nodes that are going to run composites.
<composite name="cloud.composite"
targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="
http://www.osoa.org/xmlns/sca/1.0">
<include name="ns2:NodeA" uri="
http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
http://sample/cloud"/>
<include name="ns2:NodeB" uri="
http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
http://sample/cloud"/>
<include name="ns2:NodeC" uri="
http://tuscany.apache.org/xmlns/sca/1.0/cloud" xmlns:ns2="
http://sample/cloud"/>
</composite>
Each included node composite looks something like
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://sample/cloud"
xmlns:s="http://sample"
name="NodeA">
<component name="NodeA">
<t:implementation.node uri="nodeA" composite="s:CalculatorA"/>
<service name="Node">
<binding.sca uri="http://localhost:8100"/>
</service>
</component>
</composite>
You will note that the node holds default binding URI information.
With these files the workspace can produce the fully configured composites
that will run on each node.
Having done this I rewrote the code in the "node" package to create a set of
launchers for the various parts of the sample.
node.LaunchDomain [5] was the first and simply calls the DomainAdminLauncher
from the workspace-admin package. This starts an SCA application, reads all
these files, makes some web pages available and more importantly make the
resolved composite information available at URLs starting http://host:9990/.
..
node.LaunchCalculatorNodeA, B, C [6] allows each node to be started. You
will note that in each of these a node gets started with a line something
like
node = nodeFactory.createSCANode("http://localhost:9990/node-image/NodeA");
This is a slightly different take on the node creation process we had before
(this new node code is in the node2-* packages). It lets you create a node
given a composite information. This is derived from the helper method Simon
Nash put on the factory and in this case is the URI of an Atom feed that
provides a link to a composite and the contributions required to run that
composite. The node runs, pulls down this information. Based on this
information it pulls down each of the contributions and the composite and
starts up the composite.
As all the composites are fully configured the nodes simply build, activate
and start them. They don't need to go looking for service endpoints.
The actual distributed calculator application is the same as it was before.
I hope this makes some kind of sense. Please ask if you want more details.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28711.html
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/workspace.xml
[3]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/domain.composite
[4]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/cloud.composite
[5]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchDomain.java
[6]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/src/main/java/node/LaunchCalculatorNodeA.java
Re: [PROPOSAL] Using new Workspace in samples/calculator-distributed Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
+1.
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Wednesday, March 12, 2008 4:28 AM
To: <tu...@ws.apache.org>
Subject: [PROPOSAL] Using new Workspace in samples/calculator-distributed
Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
> I like the look of the workspace code Sebastien has been writing and I
> propose to try it out on samples/calculator-distributed.
>
> In particular I'd like to help Felix who is hitting the common filesystem
> restriction of the current domain implementation .
>
> Let me know if anyone has any concerns.
>
> I'll report back with what I learn. There are other modules that rely on
> distributed support
>
> itest/callable-references
> itest/domain
> itest/osgi-tuscany/tuscany-3rdparty
> itest/osgi-tuscay/tuscany-runtime
> samples/calculator-distributed
> tools/eclipse/plugins/runtime
>
> I'm happy to think about those if the sample/calculator-distributed goes
> ok.
>
>
> Regards
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg02610.html
>
> On Mon, Mar 10, 2008 at 6:07 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Jean-Sebastien Delfino wrote:
>> > Simon Laws wrote:
>> >> On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <si...@googlemail.com>
>> >> wrote:
>> >>
>> >>>
>> >>> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
>> >>> jsdelfino@apache.org> wrote:
>> >>>
>> >>>> Jean-Sebastien Delfino wrote:
>> >>>>> Simon Laws wrote:
>> >>>>>> I've been running the workspace code today with a view to
>> integrating
>> >>>> the
>> >>>>>> new code in assembly which calculates service endpoints i.e.
>> >>>>>> point4
>> >>>>>> above.
>> >>>>>>
>> >>>>>> I think we need to amend point 4 to make this work properly..
>> >>>>>>
>> >>>>>> 4. Point my Web browser to the various ATOM collections to get:
>> >>>>>> - lists of contributions, composites and nodes
>> >>>>>> - list of contributions that are required by a given contribution
>> >>>>>> - the source of a particular composite
>> >>>>>> - the output of a composite after the domain composite has been
>> built
>> >>>> by
>> >>>>>> CompositeBuilder
>> >>>>>>
>> >>>>>> Looking at the code in DeployableCompositeCollectionImpl I see
>> >>>>>> that
>> >>>> on
>> >>>>>> doGet() it builds the request composite. What the last point
>> >>>>>> needs
>> >>>> to
>> >>>>>> do is
>> >>>>>>
>> >>>>>> - read the whole domain
>> >>>>>> - set up all of the service URIs for each of the included
>> composites
>> >>>>>> taking
>> >>>>>> into account the node to which each composite is assigned
>> >>>>>> - build the whole domain using CompositeBuilder
>> >>>>>> - extract the required composite from the domain and serialize it
>> >>>> out.
>> >>>>> Yes, exactly!
>> >>>>>
>> >>>>>> Are you changing this code or can I put this in?
>> >>>>> Just go ahead, I'll update and merge if I have any other changes in
>> >>>> the
>> >>>>> same classes.
>> >>>>>
>> >>>> Simon, a quick update: I've done an initial bring-up of node2-impl.
>> >>>> It's
>> >>>> still a little rough but you can give it a try if you want.
>> >>>>
>> >>>> The steps to run the store app for example with node2 are as
>> >>>> follows:
>> >>>>
>> >>>> 1) use workspace-admin to add the store and assets contributions to
>> the
>> >>>> domain;
>> >>>>
>> >>>> 2) add the store composite to the domain composite using the admin
>> >>>> as
>> >>>> well;
>> >>>>
>> >>>> 3) start the StoreLauncher2 class that I just added to the store
>> >>>> module;
>> >>>>
>> >>>> 4) that will start an instance of node2 with all the node config
>> served
>> >>>> from the admin app.
>> >>>>
>> >>>> So the next step is to integrate your node allocation code with
>> >>>> workspace-admin and that will complete the story. Then we'll be able
>> to
>> >>>> remove all the currently hardcoded endpoint URIs from the
>> >>>> composites.
>> >>>>
>> >>>> I'll send a more detailed description and steps to run more
>> >>>> scenarios
>> >>>> later on Friday.
>> >>>>
>> >>>> --
>> >>>> Jean-Sebastien
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>>
>> >>>> Ok, sounds good. I've done the uri integration although there are
>> some
>> >>> issues we need to discuss. First I'll update with your code, commit
>> >>> my
>> >>> changes and then post here about the issues.
>> >>>
>> >>> Regards
>> >>>
>> >>> Simon
>> >>>
>> >> I've now checked in my changes (last commit was 634762) to integrate
>> >> the URI
>> >> calculation code with the workspace. I've run the new store launcher
>> >> following Sebastien's instructions from a previous post to this
>> >> thread.
>> I
>> >> don't seem to have broken it too much although I'm not seeing any
>> >> prices for
>> >> the catalog items.
>> >
>> > I was seeing that issue too before, it's a minor bug in the property
>> > writing code, which is not writing property values correctly.
>> >
>> >> Issues with the URI generation code....
>> >>
>> >> I have to turn model resolution back on by uncommenting a line in
>> >> ContributionContentProcessor.resolve. Otherwise the JavaImplementation
>> >> types
>> >> are not read and
>> >> compositeConfiguationBuilder.calculateBindingURIs(defaultBindings,
>> >> composite, null); can't generate default services. I then had to tun
>> >> it back
>> >> off to make the store sample work. I need some help on this one.
>> >
>> > I'm investigating now.
>> >
>> >>
>> >> If you hand craft services it seems to be OK although I have noticed,
>> >> looking at the generated SCDL, that it seems to be assuming that all
>> >> generated service names will be based on the implementation classname
>> >> regardless of whether the interface is marked as @Remotable or not.
>> Feels
>> >> like a bug somewhere so am going to look at that next.
>> >
>> > OK
>> >
>> >>
>> >> To get Java implementation resolution to work I needed to hack in the
>> >> Java
>> >> factories setup in the DeployableCompositeCollectionImpl.initialize()
>> >> method. This is not very good and raises the bigger question about
>> >> the set
>> >> up in here. It's creating a set of extension points in parallel to
>> those
>> >> created by the runtime running this component. Can we either use the
>> >> registry created by the underlying runtime or do similar generic
>> >> setup.
>> >
>> > Yes, I'd like to keep the infrastructure used by the admin decoupled
>> > from the infrastructure of the runtime hosting the admin, but I'll try
>> > to simplify the setup by creating an instance of runtime for the admin
>> > and getting the necessary objects out of it, instead of assembling it
>> > from scratch as it is now.
>> >
>> >> The code doesn't currently distinguish between those services that are
>> >> @Remotable and those that aren't
>> >>
>> >> Simon
>> >>
>> >
>> >
>>
>> Simon,
>>
>> After a few more changes, the domain / node allocation, default URI
>> calculation and resolution of references across nodes now works OK.
>>
>> I was able to remove all the hardcoded URIs in the tutorial composites
>> as they now get determined from the configuration of the nodes that the
>> composites are deployed to.
>>
>> You can use the latest tutorial modules to see the end to end
>> integration, with the following steps:
>>
>> 1. Start tutorial/domain/.../LaunchTutorialAdmin.
>>
>> 2. Open http://localhost:9990/ui/composite in your Web browser. You
>> should see all the tutorial contributions and deployables that I've
>> added to that domain.
>>
>> 3. Click the feeds in the "composite install image" to see the resolved
>> composites.
>>
>> 4. Start all the launch programs in tutorial/nodes, you can start them
>> in any order you want.
>>
>> 5. Open tutorial/assets/tutorial.html in your Web browser, follow the
>> links to the various store implementations.
>>
>> Hope this helps.
>> --
>> Jean-Sebastien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org