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 >>
