You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/03/19 10:30:06 UTC

Using new admin and nodes in the tutorial, was: [PROPOSAL] Using new Workspace in samples/calculator-distributed

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