Raymond, For the most part this approach works fine although, the travelsample's web widget runtime, the JSON-rpc connectivity are pretty critical to the core operation of the travelcatalog and its search functions not to mention the web front end.
-a- On 3/19/10 5:03 PM, "Albert Tsang" <[email protected]> wrote: > Will try to build the individual contributions that we're using as our > Tuscany reference implementation and see how far we go using that approach, > thanks! > > -a- > > > On 3/19/10 4:44 PM, "Raymond Feng" <[email protected]> wrote: > >> Don't try fullapp now. There are still dependencies to be flushed out (also >> some of the implementation/binding types to be ported from 1.x to 2.x). You >> can start to run: >> >> 1. mvn clean install -fn -Dmaven.test.skip=true >> 2. mvn eclipse:eclipse -fn >> >> Load the projects into Eclipse and try the ones that don't have compilation >> errors. >> >> We still need to add implementation.script and binding.corba into 2.x build. >> For now, you can try to build them locally from the individual projects. >> >> Thanks, >> Raymond >> -------------------------------------------------- >> From: "Albert Tsang" <[email protected]> >> Sent: Friday, March 19, 2010 4:16 PM >> To: <[email protected]> >> Subject: Re: Travel sample README questions/suggestions >> >>> I tried building and running the fullapp launcher, there's seems to be >>> some >>> missing snapshots... >>> >>> Missing: >>> ---------- >>> 1) >>> org.apache.tuscany.sca:tuscany-implementation-widget-runtime-tuscany:jar:2.0 >>> -SNAPSHOT >>> 2) org.apache.tuscany.sca:tuscany-binding-jsonrpc-js:jar:2.0-SNAPSHOT >>> 3) org.apache.tuscany.sca:tuscany-binding-sca-axis2:jar:2.0-SNAPSHOT >>> 4) org.apache.tuscany.sca:tuscany-implementation-ejb:jar:2.0-SNAPSHOT >>> 5) org.apache.tuscany.sca:tuscany-implementation-bpel-ode:jar:2.0-SNAPSHOT >>> 6) >>> org.apache.tuscany.sca:tuscany-implementation-spring-runtime:jar:2.0-SNAPSHO >>> T >>> ---------- >>> 6 required artifacts are missing. >>> >>> for artifact: >>> org.apache.tuscany.sca:scatours-launcher-fullapp:jar:2.0-SNAPSHOT >>> >>> from the specified remote repositories: >>> apache.snapshots (http://repository.apache.org/snapshots), >>> central (http://repo1.maven.org/maven2), >>> indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/), >>> java.net (http://download.java.net/maven/1), >>> intalio.org (http://www.intalio.org/public/maven2), >>> tuscany.repo (http://svn.apache.org/repos/asf/tuscany/maven), >>> maven.central (http://repo2.maven.org/maven2), >>> apache.incubator >>> (http://people.apache.org/repo/m2-incubating-repository), >>> java.net2 (http://download.java.net/maven/2), >>> apache.ws.zone (http://ws.zones.apache.org/repository2), >>> osuosl.org (http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2) >>> >>> >>> I could overcome this with our local repo but was hoping they could be >>> properly rebuilt and installed on the ASF repo >>> >>> -a- >>> >>> >>> On 3/19/10 10:07 AM, "Albert Tsang" <[email protected]> wrote: >>> >>>> Raymond, >>>> >>>> Thanks for your help! I've checked out the project and will be trying to >>>> the composites that we used for our testing. Will let you know how it >>>> goes >>>> and hopefully begin the same profiling. >>>> >>>> -a- >>>> >>>> On 3/17/10 8:42 AM, "Raymond Feng" <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I have made some progress here: >>>>> >>>>> 1) The travel sample is copied to >>>>> >>> http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/tutorials/travels>>> a >>>>> >>> m >>>>> ple/. I >>>>> updated the pom.xml, MANIFEST.MF. I also migrated the SCA xml files such >>>>> as >>>>> composite. The java package names are corrected too. There are still >>>>> compilation errors in some projects, but I can run the basic ones now. >>>>> >>>>> 2) I have ported implementation.script and binding.corba into 2.x. They >>>>> are >>>>> used by the travel sample. >>>>> >>>>> What's left? >>>>> >>>>> 1. The dependency on binding.rss. >>>>> 2. Conversational usage to be cleaned up (I commented out some of the >>>>> code) >>>>> 3. SCA domain manager dependency >>>>> 4. Bring up the whole scenario ... >>>>> >>>>> Helps are welcome! >>>>> >>>>> Thanks, >>>>> Raymond >>>>> -------------------------------------------------- >>>>> From: "Albert Tsang" <[email protected]> >>>>> Sent: Wednesday, March 17, 2010 12:19 AM >>>>> To: <[email protected]> >>>>> Subject: RE: Travel sample README questions/suggestions >>>>> >>>>>> Sounds great Raymond! I can take a tally of the contributions that I >>>>>> lumped together but it would be great to get all parts of the app >>>>>> working >>>>>> because we'll be using it to benchmark and profile. Thanks! >>>>>> >>>>>> Will put a summary of findings using NeoLoad when I get back into the >>>>>> office >>>>>> >>>>>> -a- >>>>>> ________________________________________ >>>>>> From: Raymond Feng [[email protected]] >>>>>> Sent: Monday, March 15, 2010 9:53 PM >>>>>> To: tuscany-dev >>>>>> Subject: Re: Travel sample README questions/suggestions >>>>>> >>>>>> Hi, >>>>>> >>>>>> FYI: I started to port travelsample to 2.x to cover #1 and #2. I'll let >>>>>> you >>>>>> know when I get something basic working. >>>>>> >>>>>> Thanks, >>>>>> Raymond >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Raymond Feng" <[email protected]> >>>>>> Sent: Monday, March 15, 2010 4:38 PM >>>>>> To: <[email protected]> >>>>>> Cc: "George Baxter" <[email protected]>; "Chase Garber" >>>>>> <[email protected]> >>>>>> Subject: Re: Travel sample README questions/suggestions >>>>>> >>>>>>> Here is my estimate: >>>>>>> >>>>>>> #1 and #2 should be trivial: 1-2 days >>>>>>> #3: 1 week? >>>>>>> >>>>>>> For those interaction styles or extensions >>>>>>> (implementation/binding/databinding/policy types) supported by 2.x, >>>>>>> the >>>>>>> migration should be fairly straightforward. We can try to port as much >>>>>>> as >>>>>>> we can. >>>>>>> >>>>>>> Thanks, >>>>>>> Raymond >>>>>>> -------------------------------------------------- >>>>>>> From: "Albert Tsang" <[email protected]> >>>>>>> Sent: Monday, March 15, 2010 4:22 PM >>>>>>> To: <[email protected]> >>>>>>> Cc: "George Baxter" <[email protected]>; "Chase Garber" >>>>>>> <[email protected]> >>>>>>> Subject: RE: Travel sample README questions/suggestions >>>>>>> >>>>>>>> Raymond, >>>>>>>> >>>>>>>> We're very green on this front however, that being said are >>>>>>>> interested >>>>>>>> in >>>>>>>> moving this forward for our own purposes as well as contributing back >>>>>>>> to >>>>>>>> the community to help build momentum. Can you provide an estimate of >>>>>>>> just how much work this would be line by line? There are some things >>>>>>>> that I think can be prioritized later like #4, but critically >>>>>>>> speaking >>>>>>>> it >>>>>>>> sounds like #1-2 and possibly #3 would need to be done to get the >>>>>>>> travelsample operational. Thoughts? >>>>>>>> >>>>>>>> George - the "fix" that Simon provided regarding getting the context >>>>>>>> back >>>>>>>> from the callback - does this work and does it eliminate the >>>>>>>> workaround >>>>>>>> need of having to default to conversations? >>>>>>>> >>>>>>>> -a- >>>>>>>> ________________________________________ >>>>>>>> From: Raymond Feng [[email protected]] >>>>>>>> Sent: Monday, March 15, 2010 8:57 AM >>>>>>>> To: tuscany-dev >>>>>>>> Subject: Re: Travel sample README questions/suggestions >>>>>>>> >>>>>>>> Hi, Albert. >>>>>>>> >>>>>>>> Would you like to share the profiling result with us? We can work >>>>>>>> together >>>>>>>> to remove the bottlenecks to Tuscany more performed and scalable. >>>>>>>> >>>>>>>> The travelsample won't run with Tuscany 2.x as-is. There are some >>>>>>>> migration >>>>>>>> efforts needed: >>>>>>>> >>>>>>>> 1) Port the composite and sca-contribution.xml files into OASIS SCA >>>>>>>> XML >>>>>>>> syntax. Most of them can be just the namespace changes >>>>>>>> 2) Port the java apis and annotations >>>>>>>> 3) The conversational features are removed in OASIS SCA. We need to >>>>>>>> decide >>>>>>>> what could replace them. >>>>>>>> 4) The SCA domain manager is yet to be ported from 1.x to 2.x. But we >>>>>>>> can >>>>>>>> probably use the EndpointRegistry to achieve the distributed domain. >>>>>>>> 5) We can introduce new things such as OSGi integration in 2.x. >>>>>>>> >>>>>>>> If you are interested in helping this out, I can start to copy the >>>>>>>> code >>>>>>>> from >>>>>>>> 1.x into 2.x with basic porting, such as pom.xml and namespace >>>>>>>> changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Raymond >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Albert Tsang" <[email protected]> >>>>>>>> Sent: Sunday, March 14, 2010 4:36 PM >>>>>>>> To: <[email protected]> >>>>>>>> Cc: <[email protected]> >>>>>>>> Subject: Re: Travel sample README questions/suggestions >>>>>>>> >>>>>>>>> We completed profiling of Tuscany 1.6 on Tomcat 6 and JDK 1.6. >>>>>>>>> Would >>>>>>>>> like to perform the same profile testing with 2.x using the >>>>>>>>> travelsample app again on tc6/jdk1.6. >>>>>>>>> >>>>>>>>> -a- >>>>>>>>> >>>>>>>>> On Mar 14, 2010, at 4:32 PM, "Simon Nash" <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Simon Laws wrote: >>>>>>>>>>> Haven't looked at the travel sample README for a little while. >>>>>>>>>>> Anyone >>>>>>>>>>> know how up to date it is? >>>>>>>>>> It should be fully up to date and in sync with the current svn >>>>>>>>>> code. >>>>>>>>>> >>>>>>>>>>> For example, the run commands are mostly given as "ant run" but >>>>>>>>>>> this >>>>>>>>>>> doesn't seem to be the case in the binary distribution. For >>>>>>>>>>> example, >>>>>>>>>>> from the binary distribution the interaction samples are run using >>>>>>>>>>> "ant run-interaction". So maybe it's just that we need to spell >>>>>>>>>>> out >>>>>>>>>>> the different types of releases we will have and how to use them. >>>>>>>>>>> In >>>>>>>>>>> the src distro launchers and contributions will be directories >>>>>>>>>>> while >>>>>>>>>>> in the bin distro they will be jars. >>>>>>>>>> The "ant run" commands are listed in the section titled "Running >>>>>>>>>> the >>>>>>>>>> travel >>>>>>>>>> sample from the build directories" and are correct when running >>>>>>>>>> from >>>>>>>>>> the >>>>>>>>>> build directories. For running from the binary distribution, there >>>>>>>>>> is a >>>>>>>>>> later section titled "Running the travel sample from the >>>>>>>>>> distribution >>>>>>>>>> directories" which explains the commands needed in this case. Here >>>>>>>>>> is the >>>>>>>>>> paragraph from this section that describes this: >>>>>>>>>> >>>>>>>>>> To run a jar, you need to used the command "ant run-jarsuffix" >>>>>>>>>> where >>>>>>>>>> "jarsuffix" is the last part of the jar file name omitting the >>>>>>>>>> standard prefix >>>>>>>>>> "scatours-client", "scatours-launcher" or "scatours-service". For >>>>>>>>>> example, >>>>>>>>>> to run the "jumpstart" scenario, you would set your current >>>>>>>>>> directory to the >>>>>>>>>> binary distribution "launchers" directory and run the command >>>>>>>>>> ant run-jumpstart >>>>>>>>>> This runs the travel sample jar file >>>>>>>>>> scatours-launcher-jumpstart.jar >>>>>>>>>> using a >>>>>>>>>> classpath with the required runtime dependencies from the Tuscany >>>>>>>>>> SCA binary >>>>>>>>>> distribution. The location of the Tuscany SCA binary distribution >>>>>>>>>> is specified >>>>>>>>>> by the TUSCANY_HOME environment variable). >>>>>>>>>> >>>>>>>>>>> Looking at the sample descriptions I'd like to add a little more >>>>>>>>>>> meat. >>>>>>>>>>> For example. currently the description of the interaction sample >>>>>>>>>>> is >>>>>>>>>>> as >>>>>>>>>>> follows: >>>>>>>>>>> 4) Interaction - Different SCA interaction styles >>>>>>>>>>> Command: ant run >>>>>>>>>>> Directory: launchers/interaction >>>>>>>>>>> Contributions: calendar, common, currency, flight, hotel, >>>>>>>>>>> interaction-client, >>>>>>>>>>> interaction-service-remote, shoppingcart >>>>>>>>>>> I'd like to flip the Directory and Command lines and then add a >>>>>>>>>>> description section as follows. >>>>>>>>>>> >>>>>>>>>> The Directory and Command lines were originally in the other other, >>>>>>>>>> with Directory first. I changed the order of these when I added >>>>>>>>>> descriptions of the .war samples because these start with a Webapp >>>>>>>>>> line which I thought was more analogous to Command than to >>>>>>>>>> Directory. >>>>>>>>>> However, on further reflection it seems that Webapp could equally >>>>>>>>>> well >>>>>>>>>> be considered to be analogous to Directory, so I would be fine with >>>>>>>>>> reverting to the previous order and putting Directory first. >>>>>>>>>> >>>>>>>>>>> I also added the directory/run >>>>>>>>>>> command to for the binary distro but open to suggest about >>>>>>>>>>> whether/ >>>>>>>>>>> how >>>>>>>>>>> to do this. >>>>>>>>>>> 4) Interaction - Shows different SCA interaction styles >>>>>>>>>>> Directory src(bin): launchers/interaction (launchers) >>>>>>>>>>> Command src(bin): ant run (ant run-interaction) >>>>>>>>>>> >>>>>>>>>> This would need a reorganisation of the structure of the README so >>>>>>>>>> that >>>>>>>>>> the sections titled "Running the travel sample from the build >>>>>>>>>> directories" >>>>>>>>>> and "Running the travel sample from the distribution directories" >>>>>>>>>> are >>>>>>>>>> merged together into a single section. I'm concerned that doing >>>>>>>>>> this >>>>>>>>>> would be more confusing because of the mix of information appearing >>>>>>>>>> together, where some of it only applies to one case or the other. >>>>>>>>>> >>>>>>>>>> An alternative would be to keep the present structure of sections >>>>>>>>>> but add cross-references between them and perhaps also flesh out >>>>>>>>>> the >>>>>>>>>> section "Running the travel sample from the distribution >>>>>>>>>> directories" >>>>>>>>>> to be more explicit about all the commands that are needed. >>>>>>>>>> >>>>>>>>>> Another alternative would be to have a new section called something >>>>>>>>>> like >>>>>>>>>> "The travel sample scenarios" which describes the scenarios and >>>>>>>>>> lists the >>>>>>>>>> contributions/launchers/services/clients/webapps/URLs that they >>>>>>>>>> use, >>>>>>>>>> but >>>>>>>>>> doesn't go into full details of how to run them. These details >>>>>>>>>> would be >>>>>>>>>> provided in separate later sections, one for running from the build >>>>>>>>>> directories and one for running from the binary distribution. This >>>>>>>>>> is >>>>>>>>>> probably the best and clearest approach, and I'm happy to make the >>>>>>>>>> edits >>>>>>>>>> for this if others agree with this structure. >>>>>>>>>> >>>>>>>>>>> Contributions: calendar, common, currency, flight, >>>>>>>>>>> hotel, >>>>>>>>>>> interaction-client, >>>>>>>>>>> interaction-service-remote, shoppingcart >>>>>>>>>>> Description: Each SCA interaction pattern is >>>>>>>>>>> demonstrated >>>>>>>>>>> using a component from the travel booking application. >>>>>>>>>>> We¹re going to see the Hotel, Calendar, CurrencyConverter and >>>>>>>>>>> ShoppingCart components used here. These components >>>>>>>>>>> don't work in isolation so for each interaction pattern we've >>>>>>>>>>> written a simple client component. For example, the >>>>>>>>>>> InteractionLocalClient component demonstrates local >>>>>>>>>>> interactions >>>>>>>>>>> by sending a local message to the Calendar >>>>>>>>>>> component. The sample launcher will run samples for all of the >>>>>>>>>>> interaction patterns automatically.The launcher starts two >>>>>>>>>>> nodes. Node1 loads the contributions common, currency, >>>>>>>>>>> calendar, >>>>>>>>>>> shoppingcart and interaction-client and runs the >>>>>>>>>>> client.composite from the interaction-client contribution. All >>>>>>>>>>> local interaction patterns are demonstrate by clients calling >>>>>>>>>>> currency, calendar, and shoppingcart components locally, within >>>>>>>>>>> node1. Node2 loads the contributions common, hotel, >>>>>>>>>>> and interaction-service-remote, and runs the service.composite >>>>>>>>>>> from the interaction-service-remote contribution. This node >>>>>>>>>>> provides the hotel component that client components in node1 >>>>>>>>>>> can >>>>>>>>>>> send messages to remotely to demonstrate the >>>>>>>>>>> remote interaction pattern. >>>>>>>>>> +1 for adding more detailed descriptions of all the scenarios. >>>>>>>>>> >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> Received: from cas-hts01-sc.corp.shutterfly.com (172.16.200.215) by >>>>>>>>>> CAS-HTS03-SC.corp.shutterfly.com (172.16.200.113) with Microsoft >>>>>>>>>> SMTP Server >>>>>>>>>> (TLS) id 14.0.682.1; Sun, 14 Mar 2010 16:32:31 -0700 >>>>>>>>>> Received: from sms-sc03-sc.shutterfly.com (172.16.200.225) by >>>>>>>>>> cas-hts01-sc.corp.shutterfly.com (172.16.200.215) with Microsoft >>>>>>>>>> SMTP Server >>>>>>>>>> id 8.2.213.0; Sun, 14 Mar 2010 16:32:30 -0700 >>>>>>>>>> X-AuditID: ac10c8e0-b7c54ae00000414b-90-4b9d71b8dfd6 >>>>>>>>>> Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) >>>>>>>>>> by >>>>>>>>>> sms-sc03-sc.shutterfly.com (Symantec Mail Security) with SMTP id >>>>>>>>>> 1A.C8.16715.8B17D9B4; Sun, 14 Mar 2010 16:31:04 -0700 (PDT) >>>>>>>>>> Received: (qmail 17522 invoked by uid 500); 14 Mar 2010 >>>>>>>>>> 23:32:29 -0000 >>>>>>>>>> Mailing-List: contact [email protected]; run by ezmlm >>>>>>>>>> Precedence: bulk >>>>>>>>>> List-Help: <mailto:[email protected]> >>>>>>>>>> List-Unsubscribe: <mailto:[email protected]> >>>>>>>>>> List-Post: <mailto:[email protected]> >>>>>>>>>> List-Id: <dev.tuscany.apache.org> >>>>>>>>>> Reply-To: <[email protected]> >>>>>>>>>> Delivered-To: mailing list [email protected] >>>>>>>>>> Received: (qmail 17515 invoked by uid 99); 14 Mar 2010 >>>>>>>>>> 23:32:29 -0000 >>>>>>>>>> Received: from nike.apache.org (HELO nike.apache.org) >>>>>>>>>> (192.87.106.230) by >>>>>>>>>> apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Mar 2010 23:32:29 >>>>>>>>>> +0000 >>>>>>>>>> X-ASF-Spam-Status: No, hits=0.7 required=10.0 >>>>>>>>>> tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL >>>>>>>>>> X-Spam-Check-By: apache.org >>>>>>>>>> Received-SPF: neutral (nike.apache.org: local policy) >>>>>>>>>> Received: from [212.227.126.186] (HELO moutng.kundenserver.de) >>>>>>>>>> (212.227.126.186) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, >>>>>>>>>> 14 Mar >>>>>>>>>> 2010 23:32:19 +0000 >>>>>>>>>> Received: from [115.189.182.54] >>>>>>>>>> (115-189-182-54.mobile.telecom.co.nz >>>>>>>>>> [115.189.182.54]) by mrelayeu.kundenserver.de (node=mrbap0) with >>>>>>>>>> ESMTP >>>>>>>>>> (Nemesis) id 0M96Lt-1Nw9o12mlR-00D5xL; Mon, 15 Mar 2010 00:31:59 >>>>>>>>>> +0100 >>>>>>>>>> Message-ID: <[email protected]> >>>>>>>>>> Date: Sun, 14 Mar 2010 23:31:58 +0000 >>>>>>>>>> From: Simon Nash <[email protected]> >>>>>>>>>> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) >>>>>>>>>> To: <[email protected]> >>>>>>>>>> Subject: Re: Travel sample README questions/suggestions >>>>>>>>>> References: >>>>>>>>>> <[email protected] >>>>>>>>>>> >>>>>>>>>> In-Reply-To: >>>>>>>>>> <[email protected] >>>>>>>>>>> >>>>>>>>>> Content-Type: text/plain; charset="windows-1252"; format=flowed >>>>>>>>>> Content-Transfer-Encoding: 8bit >>>>>>>>>> X-Provags-ID: V01U2FsdGVkX1+OwXLVH8WLcyecjVjFMhoo8rRm2RDW73Z6Uat >>>>>>>>>> xLJAkzJPFC0pmpa9vvCPJZNRFRW5GR9ETt+r8XjIyBeclBN879 >>>>>>>>>> 85Cqcx4xZeY2cSZL0IlPQ== >>>>>>>>>> X-Virus-Checked: Checked by ClamAV on apache.org >>>>>>>>>> X-Brightmail-Tracker: AAAAARM9rGc= >>>>>>>>>> Return-Path: >>>>>>>>>> [email protected] >>>>>>>>>> X-MS-Exchange-Organization-AVStamp-Mailbox: SMEX_Ka=;691700;0;This >>>>>>>>>> mail has >>>>>>>>>> been scanned by Trend Micro ScanMail for Microsoft Exchange; >>>>>>>>>> X-MS-Exchange-Organization-SCL: 0 >>>>>>>>>> X-MS-Exchange-Organization-AuthSource: cas-hts01- >>>>>>>>>> sc.corp.shutterfly.com >>>>>>>>>> X-MS-Exchange-Organization-AuthAs: Anonymous >>>>>>>>>> MIME-Version: 1.0 >>>>>>>>>> >>>>>>>>>> Simon Laws wrote: >>>>>>>>>>> Haven't looked at the travel sample README for a little while. >>>>>>>>>>> Anyone >>>>>>>>>>> know how up to date it is? >>>>>>>>>> It should be fully up to date and in sync with the current svn >>>>>>>>>> code. >>>>>>>>>> >>>>>>>>>>> For example, the run commands are mostly given as "ant run" but >>>>>>>>>>> this >>>>>>>>>>> doesn't seem to be the case in the binary distribution. For >>>>>>>>>>> example, >>>>>>>>>>> from the binary distribution the interaction samples are run using >>>>>>>>>>> "ant run-interaction". So maybe it's just that we need to spell >>>>>>>>>>> out >>>>>>>>>>> the different types of releases we will have and how to use them. >>>>>>>>>>> In >>>>>>>>>>> the src distro launchers and contributions will be directories >>>>>>>>>>> while >>>>>>>>>>> in the bin distro they will be jars. >>>>>>>>>> The "ant run" commands are listed in the section titled "Running >>>>>>>>>> the >>>>>>>>>> travel >>>>>>>>>> sample from the build directories" and are correct when running >>>>>>>>>> from >>>>>>>>>> the >>>>>>>>>> build directories. For running from the binary distribution, there >>>>>>>>>> is a >>>>>>>>>> later section titled "Running the travel sample from the >>>>>>>>>> distribution >>>>>>>>>> directories" which explains the commands needed in this case. Here >>>>>>>>>> is the >>>>>>>>>> paragraph from this section that describes this: >>>>>>>>>> >>>>>>>>>> To run a jar, you need to used the command "ant run-jarsuffix" >>>>>>>>>> where >>>>>>>>>> "jarsuffix" is the last part of the jar file name omitting the >>>>>>>>>> standard prefix >>>>>>>>>> "scatours-client", "scatours-launcher" or "scatours-service". For >>>>>>>>>> example, >>>>>>>>>> to run the "jumpstart" scenario, you would set your current >>>>>>>>>> directory to the >>>>>>>>>> binary distribution "launchers" directory and run the command >>>>>>>>>> ant run-jumpstart >>>>>>>>>> This runs the travel sample jar file >>>>>>>>>> scatours-launcher-jumpstart.jar >>>>>>>>>> using a >>>>>>>>>> classpath with the required runtime dependencies from the Tuscany >>>>>>>>>> SCA binary >>>>>>>>>> distribution. The location of the Tuscany SCA binary distribution >>>>>>>>>> is specified >>>>>>>>>> by the TUSCANY_HOME environment variable). >>>>>>>>>> >>>>>>>>>>> Looking at the sample descriptions I'd like to add a little more >>>>>>>>>>> meat. >>>>>>>>>>> For example. currently the description of the interaction sample >>>>>>>>>>> is >>>>>>>>>>> as >>>>>>>>>>> follows: >>>>>>>>>>> 4) Interaction - Different SCA interaction styles >>>>>>>>>>> Command: ant run >>>>>>>>>>> Directory: launchers/interaction >>>>>>>>>>> Contributions: calendar, common, currency, flight, hotel, >>>>>>>>>>> interaction-client, >>>>>>>>>>> interaction-service-remote, shoppingcart >>>>>>>>>>> I'd like to flip the Directory and Command lines and then add a >>>>>>>>>>> description section as follows. >>>>>>>>>>> >>>>>>>>>> The Directory and Command lines were originally in the other other, >>>>>>>>>> with Directory first. I changed the order of these when I added >>>>>>>>>> descriptions of the .war samples because these start with a Webapp >>>>>>>>>> line which I thought was more analogous to Command than to >>>>>>>>>> Directory. >>>>>>>>>> However, on further reflection it seems that Webapp could equally >>>>>>>>>> well >>>>>>>>>> be considered to be analogous to Directory, so I would be fine with >>>>>>>>>> reverting to the previous order and putting Directory first. >>>>>>>>>> >>>>>>>>>>> I also added the directory/run >>>>>>>>>>> command to for the binary distro but open to suggest about >>>>>>>>>>> whether/ >>>>>>>>>>> how >>>>>>>>>>> to do this. >>>>>>>>>>> 4) Interaction - Shows different SCA interaction styles >>>>>>>>>>> Directory src(bin): launchers/interaction (launchers) >>>>>>>>>>> Command src(bin): ant run (ant run-interaction) >>>>>>>>>>> >>>>>>>>>> This would need a reorganisation of the structure of the README so >>>>>>>>>> that >>>>>>>>>> the sections titled "Running the travel sample from the build >>>>>>>>>> directories" >>>>>>>>>> and "Running the travel sample from the distribution directories" >>>>>>>>>> are >>>>>>>>>> merged together into a single section. I'm concerned that doing >>>>>>>>>> this >>>>>>>>>> would be more confusing because of the mix of information appearing >>>>>>>>>> together, where some of it only applies to one case or the other. >>>>>>>>>> >>>>>>>>>> An alternative would be to keep the present structure of sections >>>>>>>>>> but add cross-references between them and perhaps also flesh out >>>>>>>>>> the >>>>>>>>>> section "Running the travel sample from the distribution >>>>>>>>>> directories" >>>>>>>>>> to be more explicit about all the commands that are needed. >>>>>>>>>> >>>>>>>>>> Another alternative would be to have a new section called something >>>>>>>>>> like >>>>>>>>>> "The travel sample scenarios" which describes the scenarios and >>>>>>>>>> lists the >>>>>>>>>> contributions/launchers/services/clients/webapps/URLs that they >>>>>>>>>> use, >>>>>>>>>> but >>>>>>>>>> doesn't go into full details of how to run them. These details >>>>>>>>>> would be >>>>>>>>>> provided in separate later sections, one for running from the build >>>>>>>>>> directories and one for running from the binary distribution. This >>>>>>>>>> is >>>>>>>>>> probably the best and clearest approach, and I'm happy to make the >>>>>>>>>> edits >>>>>>>>>> for this if others agree with this structure. >>>>>>>>>> >>>>>>>>>>> Contributions: calendar, common, currency, flight, >>>>>>>>>>> hotel, >>>>>>>>>>> interaction-client, >>>>>>>>>>> interaction-service-remote, shoppingcart >>>>>>>>>>> Description: Each SCA interaction pattern is >>>>>>>>>>> demonstrated >>>>>>>>>>> using a component from the travel booking application. >>>>>>>>>>> We¹re going to see the Hotel, Calendar, CurrencyConverter and >>>>>>>>>>> ShoppingCart components used here. These components >>>>>>>>>>> don't work in isolation so for each interaction pattern we've >>>>>>>>>>> written a simple client component. For example, the >>>>>>>>>>> InteractionLocalClient component demonstrates local >>>>>>>>>>> interactions >>>>>>>>>>> by sending a local message to the Calendar >>>>>>>>>>> component. The sample launcher will run samples for all of the >>>>>>>>>>> interaction patterns automatically.The launcher starts two >>>>>>>>>>> nodes. Node1 loads the contributions common, currency, >>>>>>>>>>> calendar, >>>>>>>>>>> shoppingcart and interaction-client and runs the >>>>>>>>>>> client.composite from the interaction-client contribution. All >>>>>>>>>>> local interaction patterns are demonstrate by clients calling >>>>>>>>>>> currency, calendar, and shoppingcart components locally, within >>>>>>>>>>> node1. Node2 loads the contributions common, hotel, >>>>>>>>>>> and interaction-service-remote, and runs the service.composite >>>>>>>>>>> from the interaction-service-remote contribution. This node >>>>>>>>>>> provides the hotel component that client components in node1 >>>>>>>>>>> can >>>>>>>>>>> send messages to remotely to demonstrate the >>>>>>>>>>> remote interaction pattern. >>>>>>>>>> +1 for adding more detailed descriptions of all the scenarios. >>>>>>>>>> >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> Simon >>>>>>>>>> >>>> >>> >
