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 2007/11/28 01:26:42 UTC
Updated online store tutorial
The online store tutorial application is now pretty much working.
It shows how SCA allows a business to create an online store composite
application and recompose and evolve it as the business changes and expands.
1. How to build an online store to sell fruits online with an SCA
composite, a few java components (a shopping cart, a catalog, a currency
converter), and a Web 2.0 AJAX UI.
2. How to recompose/rewire the store application after a merger with a
vegetables company and offer a merged catalog of fruits and vegetables.
3. How to evolve the store's infrastructure by integrating the shopping
cart service component with a database.
4. How to configure the store composite to start offering Web services
to other online stores.
5. How to expand to another geography, with a slightly different UI,
currency, and wiring to different online services.
Slides showing these steps are available there:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/Tutorial.pdf
The code is there:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/
(the amazon and www-cloud modules are work in progress, not yet
integrated with what I just described)
If anybody is interested in contributing documentation, I think we could
use some help to document the above steps and how to develop the online
store using Tuscany in more details.
On a different note, the tutorial does not yet show how to distribute
the application across different containers like Tomcat or Geronimo. I
think we should add that aspect too, I'll post some ideas on that in a
different email.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Dec 6, 2007 3:26 PM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Dec 5, 2007 6:54 PM, Simon Laws <si...@googlemail.com> wrote:
>
> >
> >
> > On Dec 5, 2007 8:29 AM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > Hi
> > >
> > > An update of where I'm up to...
> > >
> > > Simon
> > >
> > > On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino < jsdelfino@apache.org>
> > > wrote:
> > >
> > > > [snip]
> > > > Simon Laws wrote:
> > > > >>
> > > > >
> > > > > To get me going on this I've experimented with moving the
> > > > FruitsCatalog out
> > > > > of the cloud and into a webapp. The web app relies on the evolving
> > > > deep
> > > > > tomcat integration so starting the scenario requires the following
> > > > steps....
> > > > >
> > > > > Unzip the distribution/tomcat zip over your tomcat installation
> > > > > Set the tomcat/sca-contributions/tuscany.properties file to
> > > > include node and
> > > > > domain URLs that are to your liking.
> > > > > Copy tutorial-catalog-jse.war to tomcat/webapps
> > > > > Run LaunchCloud
> > > > > Run LaunchStoreDistributed
> > > > >
> > > > > And you are set.
> > > >
> > > > Thanks a lot, I'll update and will try it.
> > > >
> > > > >
> > > > > It's all a bit fragile at the moment so lots of things to do, for
> > > > example,
> > > > > the domain is a pain as it doesn't track when things go away so it
> > > > can get
> > > > > confusing. However lets try and get the majority of the scenario
> > > > working and
> > > > > we can then look back and see where the holes are.
> > > > >
> > > > > I haven't done anything with the EJB code you made yet other than
> > > > look at
> > > > > it. I could start building the EJB for the vegetable catalog if
> > > > you like.
> > > >
> > > > Yes, here are the steps I was thinking about:
> > > > 1. develop the EJB code
> > > > 2. deploy it to Geronimo
> > > > 3. come up with a version of store.composite with the
> > > > vegetablesCatalog
> > > > reference configured with the proper EJB binding
> > > > 4. figure what the business interface for that reference looks like
> > > > (I'm
> > > > hoping that this will help shed some light on the "POJO and
> > > > databindings" discussion)
> > > > 5. get that working end to end
> > >
> > >
> > > I've done 1-5 but with very little thought about 4 other than take the
> > > VegetablesCatalog interface as it. There is a catalog-ejb project now under
> > > tutorial. This deploys to Geronimo and I've updated the distributed store to
> > > use a specifically configured binding. I had to change the domain to 9998 as
> > > Geronimo uses 9999 so some of the other bits of the tutorial may not work at
> > > the moment.
> > >
> > > >
> > > >
> > > > and in a second step:
> > > > 6. add a description of the EJB app to the domain
> > > > 7. on the vegetablesCatalog reference, replace the <binding.ejb
> > > > uri="..."/> by a wire with target="VegetableCatalog"
> > > > 8. get that working end to end
> > > >
> > > > >
> > > > > I'm assuming from what you say that we will deploy the EJB app to
> > > > Geronimo
> > > > > standalone as if it had existed before we came along with SCA.
> > > >
> > > > Yes
> > > >
> > > > Where will
> > > > > the composite that references this EJB be deployed to? I'm
> > > > struggling with
> > > > > how to satisfy "The idea is to be able to develop the scenario and
> > > > explore
> > > > > how to work with existing JEE apps and different containers in an
> > > > SCA domain
> > > > > without piling more runtime code into Tuscany." as it seems that
> > > > we will
> > > > > need to deploy the composite that references the EJB to Geronimo
> > > > which, in
> > > > > turn, means bringing up the Geronimo/Tuscany integration code
> > > > again.
> > > >
> > > > I think that "adding a composite to the domain" does not necessarily
> > > > imply "download that composite to the Tuscany-enabled container that
> > > >
> > > > runs the components it describes".
> > > >
> > > > In other words I'm hoping that we can add to the domain a composite
> > > > that
> > > > describes an application without having to install the Tuscany Java
> > > > runtime to the container that runs it.
> > > >
> > > > That's one of the reasons why I brought up that scenario: To help us
> > > > explore what a domain really is and the idea that an SCA domain is
> > > > more
> > > > than a bunch of Tuscany-Java runtimes that use a Tuscany-specific
> > > > protocol to advertise/discover their services.
> > >
> > > I have been working on bringing the Geronimo plugin back up again with
> > > the code in trunk and that is almost done now so we have some options about
> > > how we want to ply this.
> > >
> > > We could add the ability to introduce service descriptions to the
> > > domain regardless of whether the service is running on a Tuscany enabled
> > > endpoint although I haven't done this yet. We need to agree how this would
> > > be achieved from the users point of view. For example, is this a specific
> > > interface for associating the domain with existing services or is it to use
> > > the existing contribution interfaces with composites marked in some way that
> > > indicates that they are not to be deployed for real but simply added to the
> > > domain.
> > >
> > > Generally we need the ability on the domain to view and manipulate
> > > component definitions so that the deployment process is more flexible for
> > > situations when the domain level composite is modified. The deployment of
> > > "virtual" components could be part of this. I'll have a play this morning
> > > and see if any inspiration comes.
> > >
> > > I have spent time bringing up the Geronimo plugin to work with the
> > > code in trunk so we can play with a number of different scenarios.
> > >
> > > >
> > > >
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > >
> > > > --
> > > > Jean-Sebastien
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > I've made a bit more progress on this. I'm taking the approach that
> > the contribution describing the EJB will be imported into the domain on the
> > understanding that it shouldn't be deployed but, as we don't really have EJB
> > implementation support yet, will just provide the information to the domain
> > about where to find the EJB that is known to be running in Geronimo.
> >
> > To support this I added an importContribution method to the domain impl
> > (I haven't commited to putting it in the API yet while we play with it). The
> > method parses the contribution and associates it with a special kind of node
> > model (and IMPORTED node) and then registers any service information it
> > finds in the domain for other references to find.
> >
> > I haven't checked the code in yet as I have to fix some code to allow
> > binding.ejb to be wired.
> >
> > Implementing this scenario has highlighted that It's also getting to the
> > stage with the domain that I can't put off implementing component updates
> > any longer. Giorgio has also been doing some work on this (TUSCANY-1907) so
> > I'll start a separate thread on this.
> >
> > Regards
> >
> > Simon
> >
> Ok So, I have the scenario running using the following services....
>
> 1/ tutorial/catalog-ejb. A jar containing an VegetablesCatalog EJB which
> is deployed to Geronimo. It happens to contain a composite file that
> describes the EJB but this is not read by Geronimo (see 2)
>
> 2/ tutorial/cloud/lauch.LaunchCloud . The SCA cloud application extended
> to load the jar from 1/ as a contribution. The composite file from the jar
> is as follows.
>
> <composite xmlns=" http://www.osoa.org/xmlns/sca/1.0"
> targetNamespace="http://store"
> name="catalog-jee">
>
> <component name="JEEVegetablesCatalog">
> <implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
> <service name="Catalog">
> <binding.ejb uri="java:VegetablesCatalogImplRemote"/>
> </service>
> </component>
>
> </composite>
>
> Only the component names and the binding URI are processed at the moment.
> They provide enough information to find the EJB.
>
> 3. tutorial/store/launch.LaunchStoreDistributed. The SCA store application
> modified to talk to the EJB at 1/ given the information registered in the
> domain at 2/. This is what the catalog part of the composite looks like (all
> else remains the same).
>
> <component name="Catalog">
> <implementation.java class="services.merger.MergedCatalogImpl"/>
> <property name="currencyCode">USD</property>
> <service name="Catalog">
> <t:binding.jsonrpc/>
> <binding.ws uri="/CatalogWebService"/>
> </service>
> <reference name="fruitsCatalog" target="CloudFruitsCatalog"/>
>
> <!--reference name="fruitsCatalog" target="JSEFruitsCatalog"-->
>
> <!--reference name="vegetablesCatalog"
> target="CloudVegetablesCatalog"-->
> <reference name="vegetablesCatalog" target="JEEVegetablesCatalog">
> <!--binding.ejb uri="VegetablesCatalogImplRemote"-->
> <binding.ejb/>
> </reference>
> <reference name="currencyConverter"
> target="CurrencyConverter"/>
> </component>
>
> Note. I've left lines in but commented out so I can vary the scenario as
> I'm testing (the full scenario that we are going for has both Tomcat and
> Geronimo at the same time). The important lines here are
>
> <reference name="vegetablesCatalog" target="JEEVegetablesCatalog">
> <binding.ejb/>
>
> Which causes the node running this component to ask the domain for the
> service called JEEVegetablesCatalog. This has previously been registered as
> we imported the composite at 2/ into the domain. The JEEVegetablesCatalog
> component has been carefully crafted with the following binding
>
> <binding.ejb uri="java:VegetablesCatalogImplRemote"/>
>
> This ensures that the uri of the ejb binding is absolute and hence is not
> reset by SCA uri generation rules. This URI matches the JNDI name of the EJB
> defined by the EJB implementation class as follows.
>
> @Stateless(name="VegetablesCatalogImpl")
> //@Stateless
> public class VegetablesCatalogImpl implements Catalog {
> ...
> }
>
> The @Stateless with the explicit name is not actually required (I was
> interested in what I could do with it). The result is that the catalog
> component in the store application gets the correct reference to the EJB.
>
> Anyhow I'm writing this as a full build runs with a view to checking this
> in. I have lots of refworking and tidying to do but I want to get the code
> checked in as a baseline so I can move on to fixing all the things that I
> know are wrong. The main things that I need to fix are as follows. Not
> specific to this scenario but will make running the scenario a more reliable
> experience.
>
> A/ The nodes are still working in a mode where they go and ask for
> information from the domain so the demo has to be brought up in the correct
> order. I want to flip this so that the domain notifies nodes as service
> information comes and goes. This also makes domain level wiring possible
> because as wires are added the domain can notify affected nodes. I will
> start a separate thread on this as promised yesterday.
>
> B/ The messages used to pass service information about need improving to
> include more information about a service/binding. e.g. required intents.
> The domain level wiring process takes no account of policy at the moment.
>
> C/ I've implemented an import method on the domain to get the EJB
> information in while not making the composite available for deployment. We
> need to review this.
>
> D/ Multiplicites for non SCA bindings don't look like they will work to
> me. In general the binding resolution process during the build and activate
> phases needs a review. I will raise a JIRA. Looking at how to apply the
> reference updates required as service details change will be a good
> opportunity to do this.
>
> Regards
>
> Simon
>
>
> I've started to do a little bit of tidying on the distributed store
sample. I've taken the catalog-jee.composite and the associated type file
out of the EJB jar as they are not processed by Geronimo which is running
the jar. For now I've put them in the cloud so that when the cloud is run
the catalog-jee.compoiste is started on one of the nodes. The only affect of
this is that the domain is notified of the location of the EJB running on
Geronimo. SCA has no ability to try and run the EJB itself. I've removed the
ImportComposite method from the Domain for now as now the EJB composite is
just added along with all the other composites. The tutorial relies on the
fact that implementation.ejb doesn't actually do anything yet other than
contribute the meta data. It maybe that a better thing to do is having a
way of deploying specific composites to nodes rather than having different
mechanisms for adding composites. Anyhow not sure about this point yet so
more on this later. In the vein of creating scenarios we need management
user scenarios (I'll have a stab at making some).
I've changed the port number for Tomcat so that it doesn't clash with
Geronimo so that the tutorial can use both at once. I added the
tuscany.properties file that I'm using to the cloud module as an example. I
also added a very brief README about the distributed sample to the top level
tutorial. There should be a PDF like the standard store tutorial PDF but I
want to finish my doman changes before getting onto that.
Regards
Simon
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Dec 5, 2007 6:54 PM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Dec 5, 2007 8:29 AM, Simon Laws <si...@googlemail.com> wrote:
>
> > Hi
> >
> > An update of where I'm up to...
> >
> > Simon
> >
> > On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino < jsdelfino@apache.org>
> > wrote:
> >
> > > [snip]
> > > Simon Laws wrote:
> > > >>
> > > >
> > > > To get me going on this I've experimented with moving the
> > > FruitsCatalog out
> > > > of the cloud and into a webapp. The web app relies on the evolving
> > > deep
> > > > tomcat integration so starting the scenario requires the following
> > > steps....
> > > >
> > > > Unzip the distribution/tomcat zip over your tomcat installation
> > > > Set the tomcat/sca-contributions/tuscany.properties file to include
> > > node and
> > > > domain URLs that are to your liking.
> > > > Copy tutorial-catalog-jse.war to tomcat/webapps
> > > > Run LaunchCloud
> > > > Run LaunchStoreDistributed
> > > >
> > > > And you are set.
> > >
> > > Thanks a lot, I'll update and will try it.
> > >
> > > >
> > > > It's all a bit fragile at the moment so lots of things to do, for
> > > example,
> > > > the domain is a pain as it doesn't track when things go away so it
> > > can get
> > > > confusing. However lets try and get the majority of the scenario
> > > working and
> > > > we can then look back and see where the holes are.
> > > >
> > > > I haven't done anything with the EJB code you made yet other than
> > > look at
> > > > it. I could start building the EJB for the vegetable catalog if you
> > > like.
> > >
> > > Yes, here are the steps I was thinking about:
> > > 1. develop the EJB code
> > > 2. deploy it to Geronimo
> > > 3. come up with a version of store.composite with the
> > > vegetablesCatalog
> > > reference configured with the proper EJB binding
> > > 4. figure what the business interface for that reference looks like
> > > (I'm
> > > hoping that this will help shed some light on the "POJO and
> > > databindings" discussion)
> > > 5. get that working end to end
> >
> >
> > I've done 1-5 but with very little thought about 4 other than take the
> > VegetablesCatalog interface as it. There is a catalog-ejb project now under
> > tutorial. This deploys to Geronimo and I've updated the distributed store to
> > use a specifically configured binding. I had to change the domain to 9998 as
> > Geronimo uses 9999 so some of the other bits of the tutorial may not work at
> > the moment.
> >
> > >
> > >
> > > and in a second step:
> > > 6. add a description of the EJB app to the domain
> > > 7. on the vegetablesCatalog reference, replace the <binding.ejb
> > > uri="..."/> by a wire with target="VegetableCatalog"
> > > 8. get that working end to end
> > >
> > > >
> > > > I'm assuming from what you say that we will deploy the EJB app to
> > > Geronimo
> > > > standalone as if it had existed before we came along with SCA.
> > >
> > > Yes
> > >
> > > Where will
> > > > the composite that references this EJB be deployed to? I'm
> > > struggling with
> > > > how to satisfy "The idea is to be able to develop the scenario and
> > > explore
> > > > how to work with existing JEE apps and different containers in an
> > > SCA domain
> > > > without piling more runtime code into Tuscany." as it seems that we
> > > will
> > > > need to deploy the composite that references the EJB to Geronimo
> > > which, in
> > > > turn, means bringing up the Geronimo/Tuscany integration code again.
> > >
> > > I think that "adding a composite to the domain" does not necessarily
> > > imply "download that composite to the Tuscany-enabled container that
> > > runs the components it describes".
> > >
> > > In other words I'm hoping that we can add to the domain a composite
> > > that
> > > describes an application without having to install the Tuscany Java
> > > runtime to the container that runs it.
> > >
> > > That's one of the reasons why I brought up that scenario: To help us
> > > explore what a domain really is and the idea that an SCA domain is
> > > more
> > > than a bunch of Tuscany-Java runtimes that use a Tuscany-specific
> > > protocol to advertise/discover their services.
> >
> > I have been working on bringing the Geronimo plugin back up again with
> > the code in trunk and that is almost done now so we have some options about
> > how we want to ply this.
> >
> > We could add the ability to introduce service descriptions to the domain
> > regardless of whether the service is running on a Tuscany enabled endpoint
> > although I haven't done this yet. We need to agree how this would be
> > achieved from the users point of view. For example, is this a specific
> > interface for associating the domain with existing services or is it to use
> > the existing contribution interfaces with composites marked in some way that
> > indicates that they are not to be deployed for real but simply added to the
> > domain.
> >
> > Generally we need the ability on the domain to view and manipulate
> > component definitions so that the deployment process is more flexible for
> > situations when the domain level composite is modified. The deployment of
> > "virtual" components could be part of this. I'll have a play this morning
> > and see if any inspiration comes.
> >
> > I have spent time bringing up the Geronimo plugin to work with the code
> > in trunk so we can play with a number of different scenarios.
> >
> > >
> > >
> > > >
> > > > Simon
> > > >
> > >
> > >
> > > --
> > > Jean-Sebastien
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > I've made a bit more progress on this. I'm taking the approach that the
> contribution describing the EJB will be imported into the domain on the
> understanding that it shouldn't be deployed but, as we don't really have EJB
> implementation support yet, will just provide the information to the domain
> about where to find the EJB that is known to be running in Geronimo.
>
> To support this I added an importContribution method to the domain impl (I
> haven't commited to putting it in the API yet while we play with it). The
> method parses the contribution and associates it with a special kind of node
> model (and IMPORTED node) and then registers any service information it
> finds in the domain for other references to find.
>
> I haven't checked the code in yet as I have to fix some code to allow
> binding.ejb to be wired.
>
> Implementing this scenario has highlighted that It's also getting to the
> stage with the domain that I can't put off implementing component updates
> any longer. Giorgio has also been doing some work on this (TUSCANY-1907) so
> I'll start a separate thread on this.
>
> Regards
>
> Simon
>
Ok So, I have the scenario running using the following services....
1/ tutorial/catalog-ejb. A jar containing an VegetablesCatalog EJB which is
deployed to Geronimo. It happens to contain a composite file that describes
the EJB but this is not read by Geronimo (see 2)
2/ tutorial/cloud/lauch.LaunchCloud . The SCA cloud application extended to
load the jar from 1/ as a contribution. The composite file from the jar is
as follows.
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://store"
name="catalog-jee">
<component name="JEEVegetablesCatalog">
<implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
<service name="Catalog">
<binding.ejb uri="java:VegetablesCatalogImplRemote"/>
</service>
</component>
</composite>
Only the component names and the binding URI are processed at the moment.
They provide enough information to find the EJB.
3. tutorial/store/launch.LaunchStoreDistributed. The SCA store application
modified to talk to the EJB at 1/ given the information registered in the
domain at 2/. This is what the catalog part of the composite looks like (all
else remains the same).
<component name="Catalog">
<implementation.java class="services.merger.MergedCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<t:binding.jsonrpc/>
<binding.ws uri="/CatalogWebService"/>
</service>
<reference name="fruitsCatalog" target="CloudFruitsCatalog"/>
<!--reference name="fruitsCatalog" target="JSEFruitsCatalog"-->
<!--reference name="vegetablesCatalog"
target="CloudVegetablesCatalog"-->
<reference name="vegetablesCatalog" target="JEEVegetablesCatalog">
<!--binding.ejb uri="VegetablesCatalogImplRemote"-->
<binding.ejb/>
</reference>
<reference name="currencyConverter" target="CurrencyConverter"/>
</component>
Note. I've left lines in but commented out so I can vary the scenario as I'm
testing (the full scenario that we are going for has both Tomcat and
Geronimo at the same time). The important lines here are
<reference name="vegetablesCatalog" target="JEEVegetablesCatalog">
<binding.ejb/>
Which causes the node running this component to ask the domain for the
service called JEEVegetablesCatalog. This has previously been registered as
we imported the composite at 2/ into the domain. The JEEVegetablesCatalog
component has been carefully crafted with the following binding
<binding.ejb uri="java:VegetablesCatalogImplRemote"/>
This ensures that the uri of the ejb binding is absolute and hence is not
reset by SCA uri generation rules. This URI matches the JNDI name of the EJB
defined by the EJB implementation class as follows.
@Stateless(name="VegetablesCatalogImpl")
//@Stateless
public class VegetablesCatalogImpl implements Catalog {
...
}
The @Stateless with the explicit name is not actually required (I was
interested in what I could do with it). The result is that the catalog
component in the store application gets the correct reference to the EJB.
Anyhow I'm writing this as a full build runs with a view to checking this
in. I have lots of refworking and tidying to do but I want to get the code
checked in as a baseline so I can move on to fixing all the things that I
know are wrong. The main things that I need to fix are as follows. Not
specific to this scenario but will make running the scenario a more reliable
experience.
A/ The nodes are still working in a mode where they go and ask for
information from the domain so the demo has to be brought up in the correct
order. I want to flip this so that the domain notifies nodes as service
information comes and goes. This also makes domain level wiring possible
because as wires are added the domain can notify affected nodes. I will
start a separate thread on this as promised yesterday.
B/ The messages used to pass service information about need improving to
include more information about a service/binding. e.g. required intents. The
domain level wiring process takes no account of policy at the moment.
C/ I've implemented an import method on the domain to get the EJB
information in while not making the composite available for deployment. We
need to review this.
D/ Multiplicites for non SCA bindings don't look like they will work to me.
In general the binding resolution process during the build and activate
phases needs a review. I will raise a JIRA. Looking at how to apply the
reference updates required as service details change will be a good
opportunity to do this.
Regards
Simon
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Dec 5, 2007 8:29 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi
>
> An update of where I'm up to...
>
> Simon
>
> On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
> > [snip]
> > Simon Laws wrote:
> > >>
> > >
> > > To get me going on this I've experimented with moving the
> > FruitsCatalog out
> > > of the cloud and into a webapp. The web app relies on the evolving
> > deep
> > > tomcat integration so starting the scenario requires the following
> > steps....
> > >
> > > Unzip the distribution/tomcat zip over your tomcat installation
> > > Set the tomcat/sca-contributions/tuscany.properties file to include
> > node and
> > > domain URLs that are to your liking.
> > > Copy tutorial-catalog-jse.war to tomcat/webapps
> > > Run LaunchCloud
> > > Run LaunchStoreDistributed
> > >
> > > And you are set.
> >
> > Thanks a lot, I'll update and will try it.
> >
> > >
> > > It's all a bit fragile at the moment so lots of things to do, for
> > example,
> > > the domain is a pain as it doesn't track when things go away so it can
> > get
> > > confusing. However lets try and get the majority of the scenario
> > working and
> > > we can then look back and see where the holes are.
> > >
> > > I haven't done anything with the EJB code you made yet other than look
> > at
> > > it. I could start building the EJB for the vegetable catalog if you
> > like.
> >
> > Yes, here are the steps I was thinking about:
> > 1. develop the EJB code
> > 2. deploy it to Geronimo
> > 3. come up with a version of store.composite with the vegetablesCatalog
> > reference configured with the proper EJB binding
> > 4. figure what the business interface for that reference looks like (I'm
> > hoping that this will help shed some light on the "POJO and
> > databindings" discussion)
> > 5. get that working end to end
>
>
> I've done 1-5 but with very little thought about 4 other than take the
> VegetablesCatalog interface as it. There is a catalog-ejb project now under
> tutorial. This deploys to Geronimo and I've updated the distributed store to
> use a specifically configured binding. I had to change the domain to 9998 as
> Geronimo uses 9999 so some of the other bits of the tutorial may not work at
> the moment.
>
> >
> >
> > and in a second step:
> > 6. add a description of the EJB app to the domain
> > 7. on the vegetablesCatalog reference, replace the <binding.ejb
> > uri="..."/> by a wire with target="VegetableCatalog"
> > 8. get that working end to end
> >
> > >
> > > I'm assuming from what you say that we will deploy the EJB app to
> > Geronimo
> > > standalone as if it had existed before we came along with SCA.
> >
> > Yes
> >
> > Where will
> > > the composite that references this EJB be deployed to? I'm struggling
> > with
> > > how to satisfy "The idea is to be able to develop the scenario and
> > explore
> > > how to work with existing JEE apps and different containers in an SCA
> > domain
> > > without piling more runtime code into Tuscany." as it seems that we
> > will
> > > need to deploy the composite that references the EJB to Geronimo
> > which, in
> > > turn, means bringing up the Geronimo/Tuscany integration code again.
> >
> > I think that "adding a composite to the domain" does not necessarily
> > imply "download that composite to the Tuscany-enabled container that
> > runs the components it describes".
> >
> > In other words I'm hoping that we can add to the domain a composite that
> > describes an application without having to install the Tuscany Java
> > runtime to the container that runs it.
> >
> > That's one of the reasons why I brought up that scenario: To help us
> > explore what a domain really is and the idea that an SCA domain is more
> > than a bunch of Tuscany-Java runtimes that use a Tuscany-specific
> > protocol to advertise/discover their services.
>
> I have been working on bringing the Geronimo plugin back up again with the
> code in trunk and that is almost done now so we have some options about how
> we want to ply this.
>
> We could add the ability to introduce service descriptions to the domain
> regardless of whether the service is running on a Tuscany enabled endpoint
> although I haven't done this yet. We need to agree how this would be
> achieved from the users point of view. For example, is this a specific
> interface for associating the domain with existing services or is it to use
> the existing contribution interfaces with composites marked in some way that
> indicates that they are not to be deployed for real but simply added to the
> domain.
>
> Generally we need the ability on the domain to view and manipulate
> component definitions so that the deployment process is more flexible for
> situations when the domain level composite is modified. The deployment of
> "virtual" components could be part of this. I'll have a play this morning
> and see if any inspiration comes.
>
> I have spent time bringing up the Geronimo plugin to work with the code in
> trunk so we can play with a number of different scenarios.
>
> >
> >
> > >
> > > Simon
> > >
> >
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> I've made a bit more progress on this. I'm taking the approach that the
contribution describing the EJB will be imported into the domain on the
understanding that it shouldn't be deployed but, as we don't really have EJB
implementation support yet, will just provide the information to the domain
about where to find the EJB that is known to be running in Geronimo.
To support this I added an importContribution method to the domain impl (I
haven't commited to putting it in the API yet while we play with it). The
method parses the contribution and associates it with a special kind of node
model (and IMPORTED node) and then registers any service information it
finds in the domain for other references to find.
I haven't checked the code in yet as I have to fix some code to allow
binding.ejb to be wired.
Implementing this scenario has highlighted that It's also getting to the
stage with the domain that I can't put off implementing component updates
any longer. Giorgio has also been doing some work on this (TUSCANY-1907) so
I'll start a separate thread on this.
Regards
Simon
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
Hi
An update of where I'm up to...
Simon
On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> [snip]
> Simon Laws wrote:
> >>
> >
> > To get me going on this I've experimented with moving the FruitsCatalog
> out
> > of the cloud and into a webapp. The web app relies on the evolving deep
> > tomcat integration so starting the scenario requires the following
> steps....
> >
> > Unzip the distribution/tomcat zip over your tomcat installation
> > Set the tomcat/sca-contributions/tuscany.properties file to include node
> and
> > domain URLs that are to your liking.
> > Copy tutorial-catalog-jse.war to tomcat/webapps
> > Run LaunchCloud
> > Run LaunchStoreDistributed
> >
> > And you are set.
>
> Thanks a lot, I'll update and will try it.
>
> >
> > It's all a bit fragile at the moment so lots of things to do, for
> example,
> > the domain is a pain as it doesn't track when things go away so it can
> get
> > confusing. However lets try and get the majority of the scenario working
> and
> > we can then look back and see where the holes are.
> >
> > I haven't done anything with the EJB code you made yet other than look
> at
> > it. I could start building the EJB for the vegetable catalog if you
> like.
>
> Yes, here are the steps I was thinking about:
> 1. develop the EJB code
> 2. deploy it to Geronimo
> 3. come up with a version of store.composite with the vegetablesCatalog
> reference configured with the proper EJB binding
> 4. figure what the business interface for that reference looks like (I'm
> hoping that this will help shed some light on the "POJO and
> databindings" discussion)
> 5. get that working end to end
I've done 1-5 but with very little thought about 4 other than take the
VegetablesCatalog interface as it. There is a catalog-ejb project now under
tutorial. This deploys to Geronimo and I've updated the distributed store to
use a specifically configured binding. I had to change the domain to 9998 as
Geronimo uses 9999 so some of the other bits of the tutorial may not work at
the moment.
>
>
> and in a second step:
> 6. add a description of the EJB app to the domain
> 7. on the vegetablesCatalog reference, replace the <binding.ejb
> uri="..."/> by a wire with target="VegetableCatalog"
> 8. get that working end to end
>
> >
> > I'm assuming from what you say that we will deploy the EJB app to
> Geronimo
> > standalone as if it had existed before we came along with SCA.
>
> Yes
>
> Where will
> > the composite that references this EJB be deployed to? I'm struggling
> with
> > how to satisfy "The idea is to be able to develop the scenario and
> explore
> > how to work with existing JEE apps and different containers in an SCA
> domain
> > without piling more runtime code into Tuscany." as it seems that we will
> > need to deploy the composite that references the EJB to Geronimo which,
> in
> > turn, means bringing up the Geronimo/Tuscany integration code again.
>
> I think that "adding a composite to the domain" does not necessarily
> imply "download that composite to the Tuscany-enabled container that
> runs the components it describes".
>
> In other words I'm hoping that we can add to the domain a composite that
> describes an application without having to install the Tuscany Java
> runtime to the container that runs it.
>
> That's one of the reasons why I brought up that scenario: To help us
> explore what a domain really is and the idea that an SCA domain is more
> than a bunch of Tuscany-Java runtimes that use a Tuscany-specific
> protocol to advertise/discover their services.
I have been working on bringing the Geronimo plugin back up again with the
code in trunk and that is almost done now so we have some options about how
we want to ply this.
We could add the ability to introduce service descriptions to the domain
regardless of whether the service is running on a Tuscany enabled endpoint
although I haven't done this yet. We need to agree how this would be
achieved from the users point of view. For example, is this a specific
interface for associating the domain with existing services or is it to use
the existing contribution interfaces with composites marked in some way that
indicates that they are not to be deployed for real but simply added to the
domain.
Generally we need the ability on the domain to view and manipulate component
definitions so that the deployment process is more flexible for situations
when the domain level composite is modified. The deployment of "virtual"
components could be part of this. I'll have a play this morning and see if
any inspiration comes.
I have spent time bringing up the Geronimo plugin to work with the code in
trunk so we can play with a number of different scenarios.
>
>
> >
> > Simon
> >
>
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Distributed online store scenario, was: Updated online store
tutorial
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
>>
>
> To get me going on this I've experimented with moving the FruitsCatalog out
> of the cloud and into a webapp. The web app relies on the evolving deep
> tomcat integration so starting the scenario requires the following steps....
>
> Unzip the distribution/tomcat zip over your tomcat installation
> Set the tomcat/sca-contributions/tuscany.properties file to include node and
> domain URLs that are to your liking.
> Copy tutorial-catalog-jse.war to tomcat/webapps
> Run LaunchCloud
> Run LaunchStoreDistributed
>
> And you are set.
Thanks a lot, I'll update and will try it.
>
> It's all a bit fragile at the moment so lots of things to do, for example,
> the domain is a pain as it doesn't track when things go away so it can get
> confusing. However lets try and get the majority of the scenario working and
> we can then look back and see where the holes are.
>
> I haven't done anything with the EJB code you made yet other than look at
> it. I could start building the EJB for the vegetable catalog if you like.
Yes, here are the steps I was thinking about:
1. develop the EJB code
2. deploy it to Geronimo
3. come up with a version of store.composite with the vegetablesCatalog
reference configured with the proper EJB binding
4. figure what the business interface for that reference looks like (I'm
hoping that this will help shed some light on the "POJO and
databindings" discussion)
5. get that working end to end
and in a second step:
6. add a description of the EJB app to the domain
7. on the vegetablesCatalog reference, replace the <binding.ejb
uri="..."/> by a wire with target="VegetableCatalog"
8. get that working end to end
>
> I'm assuming from what you say that we will deploy the EJB app to Geronimo
> standalone as if it had existed before we came along with SCA.
Yes
Where will
> the composite that references this EJB be deployed to? I'm struggling with
> how to satisfy "The idea is to be able to develop the scenario and explore
> how to work with existing JEE apps and different containers in an SCA domain
> without piling more runtime code into Tuscany." as it seems that we will
> need to deploy the composite that references the EJB to Geronimo which, in
> turn, means bringing up the Geronimo/Tuscany integration code again.
I think that "adding a composite to the domain" does not necessarily
imply "download that composite to the Tuscany-enabled container that
runs the components it describes".
In other words I'm hoping that we can add to the domain a composite that
describes an application without having to install the Tuscany Java
runtime to the container that runs it.
That's one of the reasons why I brought up that scenario: To help us
explore what a domain really is and the idea that an SCA domain is more
than a bunch of Tuscany-Java runtimes that use a Tuscany-specific
protocol to advertise/discover their services.
>
> Simon
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Nov 29, 2007 5:39 PM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Nov 28, 2007 11:25 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
> > Simon Laws wrote:
> > > On Nov 28, 2007 4:11 PM, Jean-Sebastien Delfino <js...@apache.org>
> > > wrote:
> > >
> > >> Simon Laws wrote:
> > >> [snip]
> > >>> If I understand this correctly it looks like a reasonable way to
> > extend
> > >> the
> > >>> Fruit&Veg scenario. In the current scenario I believe that the
> > catalog
> > >>> services, when run from the "cloud" module are running as part of
> > the
> > >>> distributed domain but rely on the embedded Jetty support .
> > >> Correct
> > >>
> > >> So let me
> > >>> confirm that you are suggesting three new things
> > >>>
> > >>> 1. creating implementation.ejb to support the Vegetable catalog
> > >>> 2. choosing a different hosting option in order to deploy SCA
> > >> applications
> > >>> to a Geronimo server such that they take part in the SCA domain
> > >>> 3. choosing a different hosting option in order to deploy SCA
> > >> applications
> > >>> to a Tomcat server such that they take part in the SCA domain
> > >> Yes to 1 and 3.
> > >>
> > >> With (2), the vegetable catalog is an existing JEE application. So
> > we're
> > >> not going to deploy it to Geronimo as a new SCA
> > contribution/application
> > >> etc, it is already there running on Geronimo, and the point of the
> > >> merger is to not have to rewrite it in SCA form, but instead model
> > its
> > >> presence in the domain with an SCA composite, then wire to it.
> > >
> > >
> > > Ah. I see. Ok I like that.
> > >
> >
> > Cool, since you're still busy with the service discovery thing, I
> > thought I could help by putting together the model and XML support for
> > implementation.ejb. It's available under sca/modules in
> > implementation-ejb and implementation-ejb-xml.
> >
> > This will allow us to describe the existing catalog EJB like that:
> >
> > <composite name="veggie-catalog">
> > <component name="VeggieCatalog">
> > <implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
> > </component>
> > </composite>
> >
> > Some day in the future we'll probably want to have more code to
> > introspect the EJB module and derive its services and bindings, but for
> > now we should be able to build an interesting scenario with just the
> > model and no more code than what I just checked in. The idea is to be
> > able to develop the scenario and explore how to work with existing JEE
> > apps and different containers in an SCA domain without piling more
> > runtime code into Tuscany.
> >
> > For now, we just need to write the description of the service and
> > binding by hand, something like that:
> >
> > <componentType>
> > <service name="Catalog">
> > <interface.java interface="catalog.Catalog"/>
> > </service>
> > </componentType>
> >
> > and back to the composite:
> > <composite name="veggie-catalog">
> > <component name="VeggieCatalog">
> > <implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
> > <service name="Catalog">
> > <binding.ejb uri="CatalogEJB"/>
> > </service>
> > </component>
> > </composite>
> >
> > I'll start to add a module to the store tutorial to host the composite
> > and componentType.
> >
> > Let me know when you're done with the service discovery thing and want
> > to jump in, there's a lot to do, including developing the EJB session
> > bean itself, getting Geronimo in the picture etc.
> >
> > 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
> >
> > Ok, sounds interesting. I'm going to start looking now. I still have
> some domain things ongoing but they will be illuminated by the scenario
> anyhow. The first thing I'm going to do is get the tutorial up and running
> on my PC. It's at this point I admit that I haven't done that yet:-) The I'd
> like to run up the scenario using the technology we have already, i.e. not
> trying to do Geronimo integration in the first instance. I want to see what
> the scenario looks like before working on any new features that may be
> required.
>
> Regards
>
> Simon
>
To get me going on this I've experimented with moving the FruitsCatalog out
of the cloud and into a webapp. The web app relies on the evolving deep
tomcat integration so starting the scenario requires the following steps....
Unzip the distribution/tomcat zip over your tomcat installation
Set the tomcat/sca-contributions/tuscany.properties file to include node and
domain URLs that are to your liking.
Copy tutorial-catalog-jse.war to tomcat/webapps
Run LaunchCloud
Run LaunchStoreDistributed
And you are set.
It's all a bit fragile at the moment so lots of things to do, for example,
the domain is a pain as it doesn't track when things go away so it can get
confusing. However lets try and get the majority of the scenario working and
we can then look back and see where the holes are.
I haven't done anything with the EJB code you made yet other than look at
it. I could start building the EJB for the vegetable catalog if you like.
I'm assuming from what you say that we will deploy the EJB app to Geronimo
standalone as if it had existed before we came along with SCA. Where will
the composite that references this EJB be deployed to? I'm struggling with
how to satisfy "The idea is to be able to develop the scenario and explore
how to work with existing JEE apps and different containers in an SCA domain
without piling more runtime code into Tuscany." as it seems that we will
need to deploy the composite that references the EJB to Geronimo which, in
turn, means bringing up the Geronimo/Tuscany integration code again.
Simon
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Nov 28, 2007 11:25 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Simon Laws wrote:
> > On Nov 28, 2007 4:11 PM, Jean-Sebastien Delfino <js...@apache.org>
> > wrote:
> >
> >> Simon Laws wrote:
> >> [snip]
> >>> If I understand this correctly it looks like a reasonable way to
> extend
> >> the
> >>> Fruit&Veg scenario. In the current scenario I believe that the catalog
> >>> services, when run from the "cloud" module are running as part of the
> >>> distributed domain but rely on the embedded Jetty support .
> >> Correct
> >>
> >> So let me
> >>> confirm that you are suggesting three new things
> >>>
> >>> 1. creating implementation.ejb to support the Vegetable catalog
> >>> 2. choosing a different hosting option in order to deploy SCA
> >> applications
> >>> to a Geronimo server such that they take part in the SCA domain
> >>> 3. choosing a different hosting option in order to deploy SCA
> >> applications
> >>> to a Tomcat server such that they take part in the SCA domain
> >> Yes to 1 and 3.
> >>
> >> With (2), the vegetable catalog is an existing JEE application. So
> we're
> >> not going to deploy it to Geronimo as a new SCA
> contribution/application
> >> etc, it is already there running on Geronimo, and the point of the
> >> merger is to not have to rewrite it in SCA form, but instead model its
> >> presence in the domain with an SCA composite, then wire to it.
> >
> >
> > Ah. I see. Ok I like that.
> >
>
> Cool, since you're still busy with the service discovery thing, I
> thought I could help by putting together the model and XML support for
> implementation.ejb. It's available under sca/modules in
> implementation-ejb and implementation-ejb-xml.
>
> This will allow us to describe the existing catalog EJB like that:
>
> <composite name="veggie-catalog">
> <component name="VeggieCatalog">
> <implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
> </component>
> </composite>
>
> Some day in the future we'll probably want to have more code to
> introspect the EJB module and derive its services and bindings, but for
> now we should be able to build an interesting scenario with just the
> model and no more code than what I just checked in. The idea is to be
> able to develop the scenario and explore how to work with existing JEE
> apps and different containers in an SCA domain without piling more
> runtime code into Tuscany.
>
> For now, we just need to write the description of the service and
> binding by hand, something like that:
>
> <componentType>
> <service name="Catalog">
> <interface.java interface="catalog.Catalog"/>
> </service>
> </componentType>
>
> and back to the composite:
> <composite name="veggie-catalog">
> <component name="VeggieCatalog">
> <implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
> <service name="Catalog">
> <binding.ejb uri="CatalogEJB"/>
> </service>
> </component>
> </composite>
>
> I'll start to add a module to the store tutorial to host the composite
> and componentType.
>
> Let me know when you're done with the service discovery thing and want
> to jump in, there's a lot to do, including developing the EJB session
> bean itself, getting Geronimo in the picture etc.
>
> 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
>
> Ok, sounds interesting. I'm going to start looking now. I still have some
domain things ongoing but they will be illuminated by the scenario anyhow.
The first thing I'm going to do is get the tutorial up and running on my PC.
It's at this point I admit that I haven't done that yet:-) The I'd like to
run up the scenario using the technology we have already, i.e. not trying to
do Geronimo integration in the first instance. I want to see what the
scenario looks like before working on any new features that may be required.
Regards
Simon
Re: Distributed online store scenario, was: Updated online store
tutorial
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Nov 28, 2007 4:11 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
>> Simon Laws wrote:
>> [snip]
>>> If I understand this correctly it looks like a reasonable way to extend
>> the
>>> Fruit&Veg scenario. In the current scenario I believe that the catalog
>>> services, when run from the "cloud" module are running as part of the
>>> distributed domain but rely on the embedded Jetty support .
>> Correct
>>
>> So let me
>>> confirm that you are suggesting three new things
>>>
>>> 1. creating implementation.ejb to support the Vegetable catalog
>>> 2. choosing a different hosting option in order to deploy SCA
>> applications
>>> to a Geronimo server such that they take part in the SCA domain
>>> 3. choosing a different hosting option in order to deploy SCA
>> applications
>>> to a Tomcat server such that they take part in the SCA domain
>> Yes to 1 and 3.
>>
>> With (2), the vegetable catalog is an existing JEE application. So we're
>> not going to deploy it to Geronimo as a new SCA contribution/application
>> etc, it is already there running on Geronimo, and the point of the
>> merger is to not have to rewrite it in SCA form, but instead model its
>> presence in the domain with an SCA composite, then wire to it.
>
>
> Ah. I see. Ok I like that.
>
Cool, since you're still busy with the service discovery thing, I
thought I could help by putting together the model and XML support for
implementation.ejb. It's available under sca/modules in
implementation-ejb and implementation-ejb-xml.
This will allow us to describe the existing catalog EJB like that:
<composite name="veggie-catalog">
<component name="VeggieCatalog">
<implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
</component>
</composite>
Some day in the future we'll probably want to have more code to
introspect the EJB module and derive its services and bindings, but for
now we should be able to build an interesting scenario with just the
model and no more code than what I just checked in. The idea is to be
able to develop the scenario and explore how to work with existing JEE
apps and different containers in an SCA domain without piling more
runtime code into Tuscany.
For now, we just need to write the description of the service and
binding by hand, something like that:
<componentType>
<service name="Catalog">
<interface.java interface="catalog.Catalog"/>
</service>
</componentType>
and back to the composite:
<composite name="veggie-catalog">
<component name="VeggieCatalog">
<implementation.ejb ejb-link="catalog-ejb.jar#CatalogEJB"/>
<service name="Catalog">
<binding.ejb uri="CatalogEJB"/>
</service>
</component>
</composite>
I'll start to add a module to the store tutorial to host the composite
and componentType.
Let me know when you're done with the service discovery thing and want
to jump in, there's a lot to do, including developing the EJB session
bean itself, getting Geronimo in the picture etc.
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
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Nov 28, 2007 4:11 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Simon Laws wrote:
> [snip]
> >
> > If I understand this correctly it looks like a reasonable way to extend
> the
> > Fruit&Veg scenario. In the current scenario I believe that the catalog
> > services, when run from the "cloud" module are running as part of the
> > distributed domain but rely on the embedded Jetty support .
>
> Correct
>
> So let me
> > confirm that you are suggesting three new things
> >
> > 1. creating implementation.ejb to support the Vegetable catalog
> > 2. choosing a different hosting option in order to deploy SCA
> applications
> > to a Geronimo server such that they take part in the SCA domain
> > 3. choosing a different hosting option in order to deploy SCA
> applications
> > to a Tomcat server such that they take part in the SCA domain
>
> Yes to 1 and 3.
>
> With (2), the vegetable catalog is an existing JEE application. So we're
> not going to deploy it to Geronimo as a new SCA contribution/application
> etc, it is already there running on Geronimo, and the point of the
> merger is to not have to rewrite it in SCA form, but instead model its
> presence in the domain with an SCA composite, then wire to it.
Ah. I see. Ok I like that.
>
>
> >
> > At the moment I'm in the middle of the domain enhancements to tidy the
> > service discovery mechanisms we have already discussed but am keen to
> help
> > get this up and running when I'm done (hopefully I'll finish by current
> > changes today).
>
> Great!
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Distributed online store scenario, was: Updated online store
tutorial
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
[snip]
>
> If I understand this correctly it looks like a reasonable way to extend the
> Fruit&Veg scenario. In the current scenario I believe that the catalog
> services, when run from the "cloud" module are running as part of the
> distributed domain but rely on the embedded Jetty support .
Correct
So let me
> confirm that you are suggesting three new things
>
> 1. creating implementation.ejb to support the Vegetable catalog
> 2. choosing a different hosting option in order to deploy SCA applications
> to a Geronimo server such that they take part in the SCA domain
> 3. choosing a different hosting option in order to deploy SCA applications
> to a Tomcat server such that they take part in the SCA domain
Yes to 1 and 3.
With (2), the vegetable catalog is an existing JEE application. So we're
not going to deploy it to Geronimo as a new SCA contribution/application
etc, it is already there running on Geronimo, and the point of the
merger is to not have to rewrite it in SCA form, but instead model its
presence in the domain with an SCA composite, then wire to it.
>
> At the moment I'm in the middle of the domain enhancements to tidy the
> service discovery mechanisms we have already discussed but am keen to help
> get this up and running when I'm done (hopefully I'll finish by current
> changes today).
Great!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distributed online store scenario, was: Updated online store tutorial
Posted by Simon Laws <si...@googlemail.com>.
On Nov 28, 2007 2:18 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Jean-Sebastien Delfino wrote:
> [snip]
> > The online store tutorial application is now pretty much working.
> >
>
> [snip]
> > the tutorial does not yet show how to distribute
> > the application across different containers like Tomcat or Geronimo. I
> > think we should add that aspect too, I'll post some ideas on that in a
> > different email.
>
> I'm thinking of the following scenario to explore the distribution of a
> composition across multiple containers working together in an SCA domain.
>
> Our online store fruit business is going to merge with a company that
> sells vegetables, same as in the original tutorial scenario.
>
> But instead of providing the vegetable catalog as a Web Service in the
> Internet "service cloud", the vegetable company has implemented the
> catalog as an EJB session bean, in a JEE EAR running on Geronimo.
>
> So we're going to have to represent the vegetable catalog EJB component
> in our store SCA domain and wire to it. We can probably follow what's
> described in http://www.osoa.org/pages/viewpage.action?pageId=3980 for
> now.
>
> Also, since we're re-composing the application anyway with this merger,
> we're going to offload our main server and push the fruit catalog
> component out to its own application server, a Tomcat server.
>
> I put slides showing the original store merger and that new variation
> there:
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/Tutorial-distributed-scenario.pdf
>
> I think it will be interesting to walk through that scenario, understand
> the concrete steps to recompose the application and implement the
> merger, and... get it working :)
>
> Thoughts?
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Hi Sebastien
If I understand this correctly it looks like a reasonable way to extend the
Fruit&Veg scenario. In the current scenario I believe that the catalog
services, when run from the "cloud" module are running as part of the
distributed domain but rely on the embedded Jetty support . So let me
confirm that you are suggesting three new things
1. creating implementation.ejb to support the Vegetable catalog
2. choosing a different hosting option in order to deploy SCA applications
to a Geronimo server such that they take part in the SCA domain
3. choosing a different hosting option in order to deploy SCA applications
to a Tomcat server such that they take part in the SCA domain
At the moment I'm in the middle of the domain enhancements to tidy the
service discovery mechanisms we have already discussed but am keen to help
get this up and running when I'm done (hopefully I'll finish by current
changes today).
Regards
Simon
Distributed online store scenario, was: Updated online store tutorial
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
[snip]
> The online store tutorial application is now pretty much working.
>
[snip]
> the tutorial does not yet show how to distribute
> the application across different containers like Tomcat or Geronimo. I
> think we should add that aspect too, I'll post some ideas on that in a
> different email.
I'm thinking of the following scenario to explore the distribution of a
composition across multiple containers working together in an SCA domain.
Our online store fruit business is going to merge with a company that
sells vegetables, same as in the original tutorial scenario.
But instead of providing the vegetable catalog as a Web Service in the
Internet "service cloud", the vegetable company has implemented the
catalog as an EJB session bean, in a JEE EAR running on Geronimo.
So we're going to have to represent the vegetable catalog EJB component
in our store SCA domain and wire to it. We can probably follow what's
described in http://www.osoa.org/pages/viewpage.action?pageId=3980 for now.
Also, since we're re-composing the application anyway with this merger,
we're going to offload our main server and push the fruit catalog
component out to its own application server, a Tomcat server.
I put slides showing the original store merger and that new variation there:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/Tutorial-distributed-scenario.pdf
I think it will be interesting to walk through that scenario, understand
the concrete steps to recompose the application and implement the
merger, and... get it working :)
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org