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