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

Reply via email to