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 2008/01/21 22:31:58 UTC
SCA contribution packaging schemes: was: SCA runtimes
Simon Nash wrote:
>> Jean-Sebastien Delfino wrote:
>> - Under which circumstances does the app packager want to package the
>> Tuscany and dependency JARs with the application artifacts.
[snip]
> With a big topic like this, dividing it into separate threads makes it
> easier for people to follow and participate in the discussions. The
> split you are suggesting looks good to me.
[snip]
Trying to address "Under which circumstances does the app packager want
to package the Tuscany and dependency JARs with the application artifacts?"
My (maybe simplistic) view is:
A) We can package in a WAR:
- several SCA contributions JARs
- any SCA deployment composites
- the required API JARs
- the required Tuscany JARs and runtime dependency JARs
This allows deployment of an SCA/Tuscany based solution to JEE Web
containers without requiring any system configuration or software
installation besides the Webapp.
There are some basic architectural limitations to that scheme:
- no good support for other bindings than HTTP based bindings
- footprint issue with every Webapp packaging the whole runtime
Also we're not quite there yet as I don't think we support:
- several SCA contributions in the packaged solution
- SCA deployment composites
B) Package SCA contributions as simple JARs, containing only the
application artifacts (no API JARs, no runtime dependency JARs).
Packaging SCA contributions as OSGi bundles is a variation of the same
scheme.
Any thoughts?
What other packaging schemes do people want to support and when?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I view the WAR (a single web module) is a simplified deployment of EAR
(might contain multiple modules). I meant to say that we can embed SCA
assembly in a JEE application, for example, a bunch of java components wired
together to provide some services to the EJB, JSP or Servlet. It's probably
related to the "Use Recursive SCA Assembly in Enterprise Applications"
scenario in [1]. I guess it's the degenerated case of the
META-INF/application.composite without the capability of
<implementation.ejb> or <implementation.web>.
[1] http://www.osoa.org:80/pages/viewpage.action?pageId=3980
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, January 23, 2008 9:57 AM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
> Raymond Feng wrote:
>> A & B seem to be the two primary schemes. A variation of option A is that
>> we package all the jars (as utility jars) into an EAR so that JEE
>> applications can use Tuscany/SCA.
>>
>
> Can you help me understand what you meant by: "so that JEE applications
> can use Tuscany/SCA"?
>
> Are you talking about the "SCA assembly of JEE applications" described in
> http://www.osoa.org/pages/viewpage.action?pageId=3980 using something like
> META-INF/application.composite?
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> A & B seem to be the two primary schemes. A variation of option A is
> that we package all the jars (as utility jars) into an EAR so that JEE
> applications can use Tuscany/SCA.
>
Can you help me understand what you meant by: "so that JEE applications
can use Tuscany/SCA"?
Are you talking about the "SCA assembly of JEE applications" described
in http://www.osoa.org/pages/viewpage.action?pageId=3980 using something
like META-INF/application.composite?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
A & B seem to be the two primary schemes. A variation of option A is that we
package all the jars (as utility jars) into an EAR so that JEE applications
can use Tuscany/SCA.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, January 21, 2008 1:31 PM
Subject: SCA contribution packaging schemes: was: SCA runtimes
> Simon Nash wrote:
> >> Jean-Sebastien Delfino wrote:
>>> - Under which circumstances does the app packager want to package the
>>> Tuscany and dependency JARs with the application artifacts.
> [snip]
>> With a big topic like this, dividing it into separate threads makes it
>> easier for people to follow and participate in the discussions. The
>> split you are suggesting looks good to me.
> [snip]
>
> Trying to address "Under which circumstances does the app packager want to
> package the Tuscany and dependency JARs with the application artifacts?"
>
> My (maybe simplistic) view is:
>
> A) We can package in a WAR:
> - several SCA contributions JARs
> - any SCA deployment composites
> - the required API JARs
> - the required Tuscany JARs and runtime dependency JARs
>
> This allows deployment of an SCA/Tuscany based solution to JEE Web
> containers without requiring any system configuration or software
> installation besides the Webapp.
>
> There are some basic architectural limitations to that scheme:
> - no good support for other bindings than HTTP based bindings
> - footprint issue with every Webapp packaging the whole runtime
>
> Also we're not quite there yet as I don't think we support:
> - several SCA contributions in the packaged solution
> - SCA deployment composites
>
> B) Package SCA contributions as simple JARs, containing only the
> application artifacts (no API JARs, no runtime dependency JARs).
>
> Packaging SCA contributions as OSGi bundles is a variation of the same
> scheme.
>
> Any thoughts?
> What other packaging schemes do people want to support and when?
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Jan 28, 2008 5:34 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
<snip>
I don't think that a Webapp is the right architecture but I may be wrong
> or missing something, so you should probably just try and see for
> yourself if this is what you want to do.
>
Can you explain more about why what you mean by not the right architecture?
There has been confusion and disagreement around what Tuscany should be
doing with webapps for a long time, years even, so maybe its time we tried
to get some consensus on this.
...ant
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Starting with the J2SE based runtime sounds like a balanced approach. I
think the embedded HTTP support (Tomcat or Jetty) will provide us the
web-based UI capability to install/uninstall/list contributions and
deploy/undeploy composites. I also see great similarity with the
Tuscany/Geronimo deep integration (Tuscany as a Geronimo plugin) where the
GUI can be an extension to the Geronimo admin console.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Sunday, January 27, 2008 9:34 PM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
> ant elder wrote:
>> On Jan 24, 2008 7:47 PM, Jean-Sebastien Delfino <js...@apache.org>
>> wrote:
>>
>>> ant elder wrote:
>>> [snip]
>>>> The (F), (G) and (H) would use the packaging in your (B). For your (B)
>>>> how/where were you expecting those sca contribution jars to get used?
>>> Ah I'm happy to see that there are not so many packaging schemes after
>>> all :)
>>>
>>> We've already started to discuss contribution usage scenarios in [1].
>>>
>>> Here's a longer scenario, showing how I want to use contributions and
>>> composites in a domain for the store tutorial I've been working on.
>>>
>>> There are three contributions in the tutorial:
>>> - assets.jar containing most implementation artifacts
>>> - store.jar containing the main store components
>>> - cloud.jar containing utility components in the service "cloud"
>>>
>>> Both store.jar and cloud.jar import artifacts from assets.jar.
>>>
>>> 1. Create assets.jar and store.jar (using scheme B).
>>>
>>> 2. Open my tutorial domain in my Web browser, upload store.jar to the
>>> domain.
>>>
>>> 3. List the contributions in the domain, store.jar shows a red-x error
>>> as some of its imports are not resolvable.
>>>
>>> 4. Upload assets.jar. Both assets.jar and store.jar show in the list
>>> with no red-x.
>>>
>>> 5. List the deployable composites, find http://store#store under
>>> store.jar. Open it in my browser to check it's what I want.
>>>
>>> 6. Mark http://store#store as deployed. Store has a reference to a
>>> CurrencyConverter service (from composite http://cloud#cloud which is
>>> not in my domain yet) so it shows a red-x and appears disabled.
>>>
>>> 7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
>>> mark it deployed. The red-x on deployed composite http://store#store is
>>> now gone.
>>>
>>> 8. Assuming I have 2 machines for running SCA in my network and have
>>> already declared these 2 machines to my domain, allocate composites to
>>> them. Select http://store#store and associate it with machine1.
>>> Store.jar and assets.jar are downloaded to machine1 and machine1
>>> configured with http://store#store.
>>>
>>> 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
>>> and assets.jar are downloaded to machine2 and machine2 is configured
>>> with http://cloud#cloud.
>>>
>>> 10. Display the list of deployed composites, select http://store#store,
>>> click the start button, select http://cloud#cloud, click start.
>>>
>>> Hope this helps.
>>>
>>> [1] http://marc.info/?l=tuscany-dev&m=119952302226006
>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>> That all sounds wonderful, will be really good when we get to there.
>> There's
>> a lot to do for all that to work
>
> There's not a lot to do. Most of the necessary work is to decouple all the
> code that's implementing too much runtime magic getting in the way of the
> simple scenario I've described here.
>
> though so as a stepping stone how about
>> getting this to work on a single node first without the gui and
>> individual
>> deployment steps and then add those things once we have something basic
>> working?
>
> Sorry to disagree, I'm approaching this the other way around:
>
> 1. Get the user experience and the UI right first.
>
> 2. Work through the individual steps and make sure they make sense.
>
> 3. Clean up all the magic code currently tying all the steps together, and
> make the individual functions (add/remove a contribution, validate a
> contribution, get a contribution closure) usable.
>
> 4. Lastly, implement minimal code to bootstrap a runtime node from a
> deployed composite (for the last step in the scenario).
>
> The basic idea is to drive the development of the underlying plumbing from
> the scenario and user experience and not the other way around.
>
>>
>> Where do we want this to run? - I'd quite like at least one of the
>> options
>> to be as a regular webapp in Tomcat.
>>
>
> I don't think that a Webapp is the right architecture but I may be wrong
> or missing something, so you should probably just try and see for yourself
> if this is what you want to do.
>
> I'm more interested in getting the above scenario working well with one
> option for now: the J2SE based runtime. That's what I've started to work
> on.
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Jan 24, 2008 7:47 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
>> ant elder wrote:
>> [snip]
>>> The (F), (G) and (H) would use the packaging in your (B). For your (B)
>>> how/where were you expecting those sca contribution jars to get used?
>> Ah I'm happy to see that there are not so many packaging schemes after
>> all :)
>>
>> We've already started to discuss contribution usage scenarios in [1].
>>
>> Here's a longer scenario, showing how I want to use contributions and
>> composites in a domain for the store tutorial I've been working on.
>>
>> There are three contributions in the tutorial:
>> - assets.jar containing most implementation artifacts
>> - store.jar containing the main store components
>> - cloud.jar containing utility components in the service "cloud"
>>
>> Both store.jar and cloud.jar import artifacts from assets.jar.
>>
>> 1. Create assets.jar and store.jar (using scheme B).
>>
>> 2. Open my tutorial domain in my Web browser, upload store.jar to the
>> domain.
>>
>> 3. List the contributions in the domain, store.jar shows a red-x error
>> as some of its imports are not resolvable.
>>
>> 4. Upload assets.jar. Both assets.jar and store.jar show in the list
>> with no red-x.
>>
>> 5. List the deployable composites, find http://store#store under
>> store.jar. Open it in my browser to check it's what I want.
>>
>> 6. Mark http://store#store as deployed. Store has a reference to a
>> CurrencyConverter service (from composite http://cloud#cloud which is
>> not in my domain yet) so it shows a red-x and appears disabled.
>>
>> 7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
>> mark it deployed. The red-x on deployed composite http://store#store is
>> now gone.
>>
>> 8. Assuming I have 2 machines for running SCA in my network and have
>> already declared these 2 machines to my domain, allocate composites to
>> them. Select http://store#store and associate it with machine1.
>> Store.jar and assets.jar are downloaded to machine1 and machine1
>> configured with http://store#store.
>>
>> 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
>> and assets.jar are downloaded to machine2 and machine2 is configured
>> with http://cloud#cloud.
>>
>> 10. Display the list of deployed composites, select http://store#store,
>> click the start button, select http://cloud#cloud, click start.
>>
>> Hope this helps.
>>
>> [1] http://marc.info/?l=tuscany-dev&m=119952302226006
>>
>> --
>> Jean-Sebastien
>>
>>
> That all sounds wonderful, will be really good when we get to there. There's
> a lot to do for all that to work
There's not a lot to do. Most of the necessary work is to decouple all
the code that's implementing too much runtime magic getting in the way
of the simple scenario I've described here.
though so as a stepping stone how about
> getting this to work on a single node first without the gui and individual
> deployment steps and then add those things once we have something basic
> working?
Sorry to disagree, I'm approaching this the other way around:
1. Get the user experience and the UI right first.
2. Work through the individual steps and make sure they make sense.
3. Clean up all the magic code currently tying all the steps together,
and make the individual functions (add/remove a contribution, validate a
contribution, get a contribution closure) usable.
4. Lastly, implement minimal code to bootstrap a runtime node from a
deployed composite (for the last step in the scenario).
The basic idea is to drive the development of the underlying plumbing
from the scenario and user experience and not the other way around.
>
> Where do we want this to run? - I'd quite like at least one of the options
> to be as a regular webapp in Tomcat.
>
I don't think that a Webapp is the right architecture but I may be wrong
or missing something, so you should probably just try and see for
yourself if this is what you want to do.
I'm more interested in getting the above scenario working well with one
option for now: the J2SE based runtime. That's what I've started to work on.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
>
>
> Add the
> > code that loads all contributions that are available from the file
> system.
> > Ant already has this code in various forms
>
> We can do simpler than load "all contributions that are available from
> the file system" as the list of contributions to be loaded in a node is
> determined from the composite allocated to it.
I was thinking specifically here about how the node is told which composite
to load and subsequently how it physically locates the artifacts that are
required. As we have disconnected nodes from the domain there is no service
interface to call to pass this information. So my suggestion was to wrap the
node with the code that can load information deployed via the file system in
lieu of a service interface that tells the node what to do.
>
> > 3. As an experiment make a Domain that takes as input
> > a - Contributions from disc (again can re-use Ant's contribution
> loading
> > code)
>
> I'm not too keen on scanning a disk directory as it doesn't apply to a
> distributed environment, I'd prefer to:
> - define a model representing a contribution repository
> - persist it in some XML form
> - provide a service to add/remove/update contributions
>
> Once we have that basic service in place, it'll be easy to develop a
> program that watches a directory and drives the add/remove/update calls.
This was just a step on the way suggestion to get the "repository" up and
running quickly. We need to be able to read the model and the contributions
themselves. In the spirit of keeping functions separate the mechanism by
which the model and the contributions get to the repository is not connected
to the way that they are read and processed.
Regards
Simon
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
snip...
> I'm not too keen on scanning a disk directory as it doesn't apply to a
> distributed environment, I'd prefer to:
> - define a model representing a contribution repository
> - persist it in some XML form
>
I've started on some model code in my sandbox [1]. Feel free to use and
abuse.
Regards
Simon
[1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
[snip]
> How about the following as some first steps.
>
> 1. Disengage the Node from the domain in the way that it is connected at the
> moment leaving the Node able to load Contributions and start composites as
> it does currently in stand alone mode. Doing this we remove the sca
> application that is used to connect the node to the domain and the need to
> pull in WS, JSON etc that came up on another thread.
+1 to disengage all the magic domain/node connections.
>
> 2. Wrap the Node in the first run options we want to test with (standalone
> and tomcat webapp would give us enough to try most of the samples).
I'd like to focus on the J2SE standalone option as trying to tackle many
options before having the simple one really figured out will create a mess.
Add the
> code that loads all contributions that are available from the file system.
> Ant already has this code in various forms
We can do simpler than load "all contributions that are available from
the file system" as the list of contributions to be loaded in a node is
determined from the composite allocated to it.
>
> 3. As an experiment make a Domain that takes as input
> a - Contributions from disc (again can re-use Ant's contribution loading
> code)
I'm not too keen on scanning a disk directory as it doesn't apply to a
distributed environment, I'd prefer to:
- define a model representing a contribution repository
- persist it in some XML form
- provide a service to add/remove/update contributions
Once we have that basic service in place, it'll be easy to develop a
program that watches a directory and drives the add/remove/update calls.
> b - a topology file something like [1]
>
> and produces as output
>
> c - a list of which contributions need to be copied to which node and
> appropriate warnings about missing dependencies
> d - updated contributions/composites so that references that refer to
> services in remote nodes have absolute URLs written in to appropriate
> bindings.
+1 to the general ideas but I really want to decouple b, c, d as they
are independent steps.
> We also have most of the code already to do a-d in various places. d is
> the trickiest bit but provides the ideal opportunity to tidy up the binding
> URL calculation story.
The less code the better... We may be able to reuse a little bit but we
can cover the scenario I've tried to describe with much less code than
we currently have :)
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26561.html
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by ant elder <an...@apache.org>.
On Jan 25, 2008 1:16 PM, Simon Laws <si...@googlemail.com> wrote:
> Sebastien/Ant
>
> >
> > > Here's a longer scenario, showing how I want to use contributions and
> > > composites in a domain for the store tutorial I've been working on.
> >
> A real eye opener. Thank you for this.
>
> snip...
>
> >
> > getting this to work on a single node first without the gui and
> individual
> >
> > deployment steps and then add those things once we have something basic
> > working?
>
> How about the following as some first steps.
>
> 1. Disengage the Node from the domain in the way that it is connected at
> the
> moment leaving the Node able to load Contributions and start composites
> as
> it does currently in stand alone mode. Doing this we remove the sca
> application that is used to connect the node to the domain and the need to
> pull in WS, JSON etc that came up on another thread.
>
> 2. Wrap the Node in the first run options we want to test with (standalone
> and tomcat webapp would give us enough to try most of the samples). Add
> the
> code that loads all contributions that are available from the file system.
> Ant already has this code in various forms
>
> 3. As an experiment make a Domain that takes as input
> a - Contributions from disc (again can re-use Ant's contribution loading
> code)
> b - a topology file something like [1]
>
> and produces as output
>
> c - a list of which contributions need to be copied to which node and
> appropriate warnings about missing dependencies
> d - updated contributions/composites so that references that refer to
> services in remote nodes have absolute URLs written in to appropriate
> bindings.
>
> We also have most of the code already to do a-d in various places. d is
> the trickiest bit but provides the ideal opportunity to tidy up the
> binding
> URL calculation story.
>
> Thoughts?
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26561.html
>
Sounds fine to me, and to try and progress things along unless there's
alternative suggestions I'd like to make a start at this. Any help welcomed,
first for me will be to get the store tutorial contributions running in a
single node.
...ant
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
Sebastien/Ant
>
> > Here's a longer scenario, showing how I want to use contributions and
> > composites in a domain for the store tutorial I've been working on.
>
A real eye opener. Thank you for this.
snip...
>
> getting this to work on a single node first without the gui and individual
>
> deployment steps and then add those things once we have something basic
> working?
How about the following as some first steps.
1. Disengage the Node from the domain in the way that it is connected at the
moment leaving the Node able to load Contributions and start composites as
it does currently in stand alone mode. Doing this we remove the sca
application that is used to connect the node to the domain and the need to
pull in WS, JSON etc that came up on another thread.
2. Wrap the Node in the first run options we want to test with (standalone
and tomcat webapp would give us enough to try most of the samples). Add the
code that loads all contributions that are available from the file system.
Ant already has this code in various forms
3. As an experiment make a Domain that takes as input
a - Contributions from disc (again can re-use Ant's contribution loading
code)
b - a topology file something like [1]
and produces as output
c - a list of which contributions need to be copied to which node and
appropriate warnings about missing dependencies
d - updated contributions/composites so that references that refer to
services in remote nodes have absolute URLs written in to appropriate
bindings.
We also have most of the code already to do a-d in various places. d is
the trickiest bit but provides the ideal opportunity to tidy up the binding
URL calculation story.
Thoughts?
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26561.html
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Jan 24, 2008 7:47 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> ant elder wrote:
> [snip]
> >
> > The (F), (G) and (H) would use the packaging in your (B). For your (B)
> > how/where were you expecting those sca contribution jars to get used?
>
> Ah I'm happy to see that there are not so many packaging schemes after
> all :)
>
> We've already started to discuss contribution usage scenarios in [1].
>
> Here's a longer scenario, showing how I want to use contributions and
> composites in a domain for the store tutorial I've been working on.
>
> There are three contributions in the tutorial:
> - assets.jar containing most implementation artifacts
> - store.jar containing the main store components
> - cloud.jar containing utility components in the service "cloud"
>
> Both store.jar and cloud.jar import artifacts from assets.jar.
>
> 1. Create assets.jar and store.jar (using scheme B).
>
> 2. Open my tutorial domain in my Web browser, upload store.jar to the
> domain.
>
> 3. List the contributions in the domain, store.jar shows a red-x error
> as some of its imports are not resolvable.
>
> 4. Upload assets.jar. Both assets.jar and store.jar show in the list
> with no red-x.
>
> 5. List the deployable composites, find http://store#store under
> store.jar. Open it in my browser to check it's what I want.
>
> 6. Mark http://store#store as deployed. Store has a reference to a
> CurrencyConverter service (from composite http://cloud#cloud which is
> not in my domain yet) so it shows a red-x and appears disabled.
>
> 7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
> mark it deployed. The red-x on deployed composite http://store#store is
> now gone.
>
> 8. Assuming I have 2 machines for running SCA in my network and have
> already declared these 2 machines to my domain, allocate composites to
> them. Select http://store#store and associate it with machine1.
> Store.jar and assets.jar are downloaded to machine1 and machine1
> configured with http://store#store.
>
> 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
> and assets.jar are downloaded to machine2 and machine2 is configured
> with http://cloud#cloud.
>
> 10. Display the list of deployed composites, select http://store#store,
> click the start button, select http://cloud#cloud, click start.
>
> Hope this helps.
>
> [1] http://marc.info/?l=tuscany-dev&m=119952302226006
>
> --
> Jean-Sebastien
>
>
That all sounds wonderful, will be really good when we get to there. There's
a lot to do for all that to work though so as a stepping stone how about
getting this to work on a single node first without the gui and individual
deployment steps and then add those things once we have something basic
working?
Where do we want this to run? - I'd quite like at least one of the options
to be as a regular webapp in Tomcat.
...ant
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
More comments inline :)
Raymond Feng wrote:
> I'm a bit confused by that your statement in :
>
> 6. Mark http://store#store as deployed. Store has a reference to a
> CurrencyConverter service (from composite http://cloud#cloud which is
> not in my domain yet) so it shows a red-x and appears disabled.
>
> In this case, the target service is not in my domain yet, but it
> shouldn't prevent http://store#store from being assigned to a node to
> start the composite.
My view is that this case should prevent assigning http://store#store to
a machine, in the next few months at least.
Having a reference is the expression of a requirement (i.e. I need the
function behind the reference to be available to perform my job).
Assigning a component with a dangling reference to a processor and
starting it is just violating that requirement, like trying to run a
Java class with compile errors.
I'm not saying that we'll never have to look into that kind of dream
dynamic scenario, but I'd like to start with reality before attacking
that dream.
The relationship between the reference and service
> is loosely-coupled, right?
Can you help me understand your definition of loosely coupled?
It could be a warning though.
>
> I assume when we select a deployable composite from a contribution, we
> just have to create a collection of contributions required to deploy the
> composite. Let's say let have two deployable composites
> http//store#store and http://cloud#cloud. It could end up with two
> downloadable zips: store.jar & assets.jar for store composite and
> cloud.jar & asset.jar for cloud composite. One zip can be downloaded to
> machine 1 and the other goes to machine 2.
Yes. We could also put some of the pieces of runtime required to run the
composite in that zip.
There is no need to check if
> a reference in store composite can be fulfilled by a service in cloud
> composite.
>
If somebody has declared a reference, that was for a reason: express the
requirement to have a service wired to that reference so I'd prefer to
check for now.
Also until the reference is satisfied you may not know which binding to
use, thereby preventing you to select the correct machine equipped with
the necessary software to support that binding.
>
>> Or the GUI could select the required
>>> contributions/composites as we mark one deployable composite.
>>>
>>
>> We could do that, except that the required composites might not be
>> available in the domain yet.
>
> I should say required contrbutions.
Yes, when you select a composite, the UI could highlight the
contributions required by the contribution containing that composite.
>
>>
>> [snip]
>>>> 9. Select http://cloud#cloud and associate it with machine2.
>>>> Cloud.jar and assets.jar are downloaded to machine2 and machine2 is
>>>> configured with http://cloud#cloud.
>>>
>>> Who initiates the download? Is it a pull or push model?
>>
>> I was thinking about push: the domain triggers the download.
>>
>> To avoid over-engineering this too quickly, how about starting simple
>> and just generating a zip of the artifacts and let the administrator
>> FTP and unzip it on the target machine?
>>
>> In other words I think we need to be comfortable with executing the
>> install / resolve / deploy / configure / distribute steps manually
>> before trying to automate them.
>
> It's import to keep all these steps separate and manually operatable.
Exactly.
> For example, we could expose management services over JMX, and the
> control be invoked from any JMX-enabled consolse/command line.
Not sure about JMX yet, I'd like to understand what the individual steps
are before picking a specific technology to implement them.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, January 24, 2008 2:11 PM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
> Some more input on steps 7 and 9.
>
> I agree with your other comments (snipped out to keep this short).
>
> Raymond Feng wrote:
> [snip]
>>> 7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
>>> mark it deployed. The red-x on deployed composite http://store#store is
>>> now gone.
>>
>> We should be able to deploy multiple composites in one shot as they might
>> have cross-references.
>
> Yes, but the simple "one composite at a time" deployment scheme that I
> described still supports your cross-reference case, or am I missing
> something?
>
I'm a bit confused by that your statement in :
6. Mark http://store#store as deployed. Store has a reference to a
CurrencyConverter service (from composite http://cloud#cloud which is
not in my domain yet) so it shows a red-x and appears disabled.
In this case, the target service is not in my domain yet, but it shouldn't
prevent http://store#store from being assigned to a node to start the
composite. The relationship between the reference and service is
loosely-coupled, right? It could be a warning though.
I assume when we select a deployable composite from a contribution, we just
have to create a collection of contributions required to deploy the
composite. Let's say let have two deployable composites http//store#store
and http://cloud#cloud. It could end up with two downloadable zips:
store.jar & assets.jar for store composite and cloud.jar & asset.jar for
cloud composite. One zip can be downloaded to machine 1 and the other goes
to machine 2. There is no need to check if a reference in store composite
can be fulfilled by a service in cloud composite.
> Or the GUI could select the required
>> contributions/composites as we mark one deployable composite.
>>
>
> We could do that, except that the required composites might not be
> available in the domain yet.
I should say required contrbutions.
>
> [snip]
>>> 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
>>> and assets.jar are downloaded to machine2 and machine2 is configured
>>> with http://cloud#cloud.
>>
>> Who initiates the download? Is it a pull or push model?
>
> I was thinking about push: the domain triggers the download.
>
> To avoid over-engineering this too quickly, how about starting simple and
> just generating a zip of the artifacts and let the administrator FTP and
> unzip it on the target machine?
>
> In other words I think we need to be comfortable with executing the
> install / resolve / deploy / configure / distribute steps manually before
> trying to automate them.
It's import to keep all these steps separate and manually operatable. For
example, we could expose management services over JMX, and the control be
invoked from any JMX-enabled consolse/command line.
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Some more input on steps 7 and 9.
I agree with your other comments (snipped out to keep this short).
Raymond Feng wrote:
[snip]
>> 7. Upload cloud.jar, find deployable composite http://cloud#cloud in
>> it, mark it deployed. The red-x on deployed composite
>> http://store#store is now gone.
>
> We should be able to deploy multiple composites in one shot as they
> might have cross-references.
Yes, but the simple "one composite at a time" deployment scheme that I
described still supports your cross-reference case, or am I missing
something?
Or the GUI could select the required
> contributions/composites as we mark one deployable composite.
>
We could do that, except that the required composites might not be
available in the domain yet.
[snip]
>> 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
>> and assets.jar are downloaded to machine2 and machine2 is configured
>> with http://cloud#cloud.
>
> Who initiates the download? Is it a pull or push model?
I was thinking about push: the domain triggers the download.
To avoid over-engineering this too quickly, how about starting simple
and just generating a zip of the artifacts and let the administrator FTP
and unzip it on the target machine?
In other words I think we need to be comfortable with executing the
install / resolve / deploy / configure / distribute steps manually
before trying to automate them.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Thank you for describing the scenario. It's really helpful to understand how
all the pieces work together from a user perspective.
I have a few comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, January 24, 2008 11:47 AM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
> ant elder wrote:
> [snip]
>>
>> The (F), (G) and (H) would use the packaging in your (B). For your (B)
>> how/where were you expecting those sca contribution jars to get used?
>
> Ah I'm happy to see that there are not so many packaging schemes after all
> :)
>
> We've already started to discuss contribution usage scenarios in [1].
>
> Here's a longer scenario, showing how I want to use contributions and
> composites in a domain for the store tutorial I've been working on.
>
> There are three contributions in the tutorial:
> - assets.jar containing most implementation artifacts
> - store.jar containing the main store components
> - cloud.jar containing utility components in the service "cloud"
>
> Both store.jar and cloud.jar import artifacts from assets.jar.
>
> 1. Create assets.jar and store.jar (using scheme B).
>
> 2. Open my tutorial domain in my Web browser, upload store.jar to the
> domain.
A degenerated case is to copy store.jar to a folder containing the
contributions for a given SCA domain. But the web-based management is better
suitable for a distributed env.
>
> 3. List the contributions in the domain, store.jar shows a red-x error as
> some of its imports are not resolvable.
>
We could have something similar to the OSGi console to show the status of
each contribution (such as INSTALLED, RESOLVED). For those that cannot be
fully resolved, we should be able to tell which "import" is not satisfied.
> 4. Upload assets.jar. Both assets.jar and store.jar show in the list with
> no red-x.
>
> 5. List the deployable composites, find http://store#store under
> store.jar. Open it in my browser to check it's what I want.
>
> 6. Mark http://store#store as deployed. Store has a reference to a
> CurrencyConverter service (from composite http://cloud#cloud which is not
> in my domain yet) so it shows a red-x and appears disabled.
>
> 7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
> mark it deployed. The red-x on deployed composite http://store#store is
> now gone.
We should be able to deploy multiple composites in one shot as they might
have cross-references. Or the GUI could select the required
contributions/composites as we mark one deployable composite.
>
> 8. Assuming I have 2 machines for running SCA in my network and have
> already declared these 2 machines to my domain, allocate composites to
> them. Select http://store#store and associate it with machine1. Store.jar
> and assets.jar are downloaded to machine1 and machine1 configured with
> http://store#store.
I assume the closure (a set of contributions required by the deployable
composite) should be downloaded.
>
> 9. Select http://cloud#cloud and associate it with machine2. Cloud.jar and
> assets.jar are downloaded to machine2 and machine2 is configured with
> http://cloud#cloud.
Who initiates the download? Is it a pull or push model?
>
> 10. Display the list of deployed composites, select http://store#store,
> click the start button, select http://cloud#cloud, click start.
>
> Hope this helps.
>
> [1] http://marc.info/?l=tuscany-dev&m=119952302226006
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
[snip]
>
> The (F), (G) and (H) would use the packaging in your (B). For your (B)
> how/where were you expecting those sca contribution jars to get used?
Ah I'm happy to see that there are not so many packaging schemes after
all :)
We've already started to discuss contribution usage scenarios in [1].
Here's a longer scenario, showing how I want to use contributions and
composites in a domain for the store tutorial I've been working on.
There are three contributions in the tutorial:
- assets.jar containing most implementation artifacts
- store.jar containing the main store components
- cloud.jar containing utility components in the service "cloud"
Both store.jar and cloud.jar import artifacts from assets.jar.
1. Create assets.jar and store.jar (using scheme B).
2. Open my tutorial domain in my Web browser, upload store.jar to the
domain.
3. List the contributions in the domain, store.jar shows a red-x error
as some of its imports are not resolvable.
4. Upload assets.jar. Both assets.jar and store.jar show in the list
with no red-x.
5. List the deployable composites, find http://store#store under
store.jar. Open it in my browser to check it's what I want.
6. Mark http://store#store as deployed. Store has a reference to a
CurrencyConverter service (from composite http://cloud#cloud which is
not in my domain yet) so it shows a red-x and appears disabled.
7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
mark it deployed. The red-x on deployed composite http://store#store is
now gone.
8. Assuming I have 2 machines for running SCA in my network and have
already declared these 2 machines to my domain, allocate composites to
them. Select http://store#store and associate it with machine1.
Store.jar and assets.jar are downloaded to machine1 and machine1
configured with http://store#store.
9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
and assets.jar are downloaded to machine2 and machine2 is configured
with http://cloud#cloud.
10. Display the list of deployed composites, select http://store#store,
click the start button, select http://cloud#cloud, click start.
Hope this helps.
[1] http://marc.info/?l=tuscany-dev&m=119952302226006
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Jan 23, 2008 6:24 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> ant elder wrote:
> > On Jan 21, 2008 9:31 PM, Jean-Sebastien Delfino <js...@apache.org>
> > wrote:
> >
> >> Simon Nash wrote:
> >> >> Jean-Sebastien Delfino wrote:
> >>>> - Under which circumstances does the app packager want to package the
> >>>> Tuscany and dependency JARs with the application artifacts.
> >> [snip]
> >>> With a big topic like this, dividing it into separate threads makes it
> >>> easier for people to follow and participate in the discussions. The
> >>> split you are suggesting looks good to me.
> >> [snip]
> >>
> >> Trying to address "Under which circumstances does the app packager want
> >> to package the Tuscany and dependency JARs with the application
> >> artifacts?"
> >>
> >> My (maybe simplistic) view is:
> >>
> >> A) We can package in a WAR:
> >> - several SCA contributions JARs
> >> - any SCA deployment composites
> >> - the required API JARs
> >> - the required Tuscany JARs and runtime dependency JARs
> >>
> >> This allows deployment of an SCA/Tuscany based solution to JEE Web
> >> containers without requiring any system configuration or software
> >> installation besides the Webapp.
> >>
> >> There are some basic architectural limitations to that scheme:
> >> - no good support for other bindings than HTTP based bindings
> >> - footprint issue with every Webapp packaging the whole runtime
> >>
> >> Also we're not quite there yet as I don't think we support:
> >> - several SCA contributions in the packaged solution
> >> - SCA deployment composites
> >>
> >> B) Package SCA contributions as simple JARs, containing only the
> >> application artifacts (no API JARs, no runtime dependency JARs).
> >>
> >> Packaging SCA contributions as OSGi bundles is a variation of the same
> >> scheme.
> >>
> >> Any thoughts?
> >> What other packaging schemes do people want to support and when?
> >> --
> >> Jean-Sebastien
> >>
> >>
> > Here's all the options I can think of:
> >
> > A) - app dependencies and tuscany and its dependencies in web-inf/lib
> > B) - app dependencies in web-inf/lib, tuscany and its dependencies in
> > container shared library (geronimo/websphere/..)
> > C) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany
> and
> > its dependencies in web-inf/tuscany (to issolate tuscany from app CL)
> > D) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany
> and
> > its dependencies in folder outside of webapp ie c:/Tuscany/lib
> > E) - app dependencies in web-inf/lib, tuscany using deep integration in
> > container (tomcat/geronimo/...)
> > F) - all tuscany and its dependencies in web-inf/lib, app (sca
> > contributions) in web-inf/sca-contributions
> > G) - all tuscany and its dependencies in web-inf/lib, app (sca
> > contributions) outside of webapp ie c:/MySCAContributions
> > H) - tuscany using deep integration in container (tomcat/geronimo/...),
> > app's (sca contributions) in folder in container, ie c:/apache-
> tomcat-6.0.10
> > /SCAContributions
> >
> > Are there any other configurations anyone can think of?
> >
> > Most of our webapp samples today use (A) but we've code scattered about
> SVN
> > and SVN history that do most of the others.
> > (C) and (D) is what i think was being suggested by Simon Nash in [1].
> > The app can see the Tuscany classes and dependencies with (A) and (B)
> which
> > we were trying to avoid at one point.
> > (B) (D) (E) and (H) reduce the size of the application as Tuscany is
> outside
> > of the webapp but that requires an extra install step
> > (G) (and F) is what I think users were interested in doing in
> TUSCANY-1884
> > and [2]
> >
> > So its just a matter of deciding which we want to support and distribute
> :)
> > As everyone seems to have different ideas about whats important I'm
> tempted
> > to say lets try to support all of these for now so we play around and
> see
> > which we think are really useful. How to distribute each option could be
> > left to another thread.
> >
> > ...ant
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200801.mbox/%3c4786A694.1030609@hursley.ibm.com%3e
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200710.mbox/%3c562382.53461.qm@web45509.mail.sp1.yahoo.com%3e
> >
>
> I don't think that "support all of these" is such a good idea as it will
> create complexity, but people are welcome to work on them if they want
> to spend the time.
>
> I'm interested in working on providing simple and usable support for:
>
> - (A) as it's a simple scheme that'll work with all Web containers
>
> - (B from your list) as it's a lighter variation of (A) that'll work
> with Web containers that support shared libraries.
>
> - (B from my list) as it's in line with the SCA spec and keeps runtime
> specifics out of the application package.
>
> I'm not quite sure how to map my option (B) to your options (F), (G),
> (H). What will the packaging of an SCA contribution look like in your
> options (F), (G), (H)?
>
> --
> Jean-Sebastien
>
The (F), (G) and (H) would use the packaging in your (B). For your (B)
how/where were you expecting those sca contribution jars to get used?
...ant
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, January 23, 2008 10:24 AM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
> ant elder wrote:
>> On Jan 21, 2008 9:31 PM, Jean-Sebastien Delfino <js...@apache.org>
>> wrote:
>>
>>> Simon Nash wrote:
>>> >> Jean-Sebastien Delfino wrote:
>>>>> - Under which circumstances does the app packager want to package the
>>>>> Tuscany and dependency JARs with the application artifacts.
>>> [snip]
>>>> With a big topic like this, dividing it into separate threads makes it
>>>> easier for people to follow and participate in the discussions. The
>>>> split you are suggesting looks good to me.
>>> [snip]
>>>
>>> Trying to address "Under which circumstances does the app packager want
>>> to package the Tuscany and dependency JARs with the application
>>> artifacts?"
>>>
>>> My (maybe simplistic) view is:
>>>
>>> A) We can package in a WAR:
>>> - several SCA contributions JARs
>>> - any SCA deployment composites
>>> - the required API JARs
>>> - the required Tuscany JARs and runtime dependency JARs
>>>
>>> This allows deployment of an SCA/Tuscany based solution to JEE Web
>>> containers without requiring any system configuration or software
>>> installation besides the Webapp.
>>>
>>> There are some basic architectural limitations to that scheme:
>>> - no good support for other bindings than HTTP based bindings
>>> - footprint issue with every Webapp packaging the whole runtime
>>>
>>> Also we're not quite there yet as I don't think we support:
>>> - several SCA contributions in the packaged solution
>>> - SCA deployment composites
>>>
>>> B) Package SCA contributions as simple JARs, containing only the
>>> application artifacts (no API JARs, no runtime dependency JARs).
>>>
>>> Packaging SCA contributions as OSGi bundles is a variation of the same
>>> scheme.
>>>
>>> Any thoughts?
>>> What other packaging schemes do people want to support and when?
>>> --
>>> Jean-Sebastien
>>>
>>>
>> Here's all the options I can think of:
>>
>> A) - app dependencies and tuscany and its dependencies in web-inf/lib
>> B) - app dependencies in web-inf/lib, tuscany and its dependencies in
>> container shared library (geronimo/websphere/..)
>> C) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany
>> and
>> its dependencies in web-inf/tuscany (to issolate tuscany from app CL)
>> D) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany
>> and
>> its dependencies in folder outside of webapp ie c:/Tuscany/lib
>> E) - app dependencies in web-inf/lib, tuscany using deep integration in
>> container (tomcat/geronimo/...)
>> F) - all tuscany and its dependencies in web-inf/lib, app (sca
>> contributions) in web-inf/sca-contributions
>> G) - all tuscany and its dependencies in web-inf/lib, app (sca
>> contributions) outside of webapp ie c:/MySCAContributions
>> H) - tuscany using deep integration in container (tomcat/geronimo/...),
>> app's (sca contributions) in folder in container, ie
>> c:/apache-tomcat-6.0.10
>> /SCAContributions
>>
>> Are there any other configurations anyone can think of?
>>
>> Most of our webapp samples today use (A) but we've code scattered about
>> SVN
>> and SVN history that do most of the others.
>> (C) and (D) is what i think was being suggested by Simon Nash in [1].
>> The app can see the Tuscany classes and dependencies with (A) and (B)
>> which
>> we were trying to avoid at one point.
>> (B) (D) (E) and (H) reduce the size of the application as Tuscany is
>> outside
>> of the webapp but that requires an extra install step
>> (G) (and F) is what I think users were interested in doing in
>> TUSCANY-1884
>> and [2]
>>
>> So its just a matter of deciding which we want to support and distribute
>> :)
>> As everyone seems to have different ideas about whats important I'm
>> tempted
>> to say lets try to support all of these for now so we play around and see
>> which we think are really useful. How to distribute each option could be
>> left to another thread.
>>
>> ...ant
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200801.mbox/%3c4786A694.1030609@hursley.ibm.com%3e
>> [2]
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200710.mbox/%3c562382.53461.qm@web45509.mail.sp1.yahoo.com%3e
>>
>
> I don't think that "support all of these" is such a good idea as it will
> create complexity, but people are welcome to work on them if they want to
> spend the time.
+1 to start with only a few options. I have to admit that I will be
overhelmed by so many choices.
>
> I'm interested in working on providing simple and usable support for:
>
> - (A) as it's a simple scheme that'll work with all Web containers
+1.
>
> - (B from your list) as it's a lighter variation of (A) that'll work with
> Web containers that support shared libraries.
+1. I already experimented it with Geronimo and it works fine.
>
> - (B from my list) as it's in line with the SCA spec and keeps runtime
> specifics out of the application package.
>
> I'm not quite sure how to map my option (B) to your options (F), (G), (H).
> What will the packaging of an SCA contribution look like in your options
> (F), (G), (H)?
My understanding is that F/G/H have the same packaging scheme as Sebstien's
B, i.e., a place to get a list of installed contributions. What's left is
how the hosting environment manage the contributions and composites to form
a SCA domain (list/install/uninstall contributions, list/start/stop
deployable composites).
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Jan 21, 2008 9:31 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
>> Simon Nash wrote:
>> >> Jean-Sebastien Delfino wrote:
>>>> - Under which circumstances does the app packager want to package the
>>>> Tuscany and dependency JARs with the application artifacts.
>> [snip]
>>> With a big topic like this, dividing it into separate threads makes it
>>> easier for people to follow and participate in the discussions. The
>>> split you are suggesting looks good to me.
>> [snip]
>>
>> Trying to address "Under which circumstances does the app packager want
>> to package the Tuscany and dependency JARs with the application
>> artifacts?"
>>
>> My (maybe simplistic) view is:
>>
>> A) We can package in a WAR:
>> - several SCA contributions JARs
>> - any SCA deployment composites
>> - the required API JARs
>> - the required Tuscany JARs and runtime dependency JARs
>>
>> This allows deployment of an SCA/Tuscany based solution to JEE Web
>> containers without requiring any system configuration or software
>> installation besides the Webapp.
>>
>> There are some basic architectural limitations to that scheme:
>> - no good support for other bindings than HTTP based bindings
>> - footprint issue with every Webapp packaging the whole runtime
>>
>> Also we're not quite there yet as I don't think we support:
>> - several SCA contributions in the packaged solution
>> - SCA deployment composites
>>
>> B) Package SCA contributions as simple JARs, containing only the
>> application artifacts (no API JARs, no runtime dependency JARs).
>>
>> Packaging SCA contributions as OSGi bundles is a variation of the same
>> scheme.
>>
>> Any thoughts?
>> What other packaging schemes do people want to support and when?
>> --
>> Jean-Sebastien
>>
>>
> Here's all the options I can think of:
>
> A) - app dependencies and tuscany and its dependencies in web-inf/lib
> B) - app dependencies in web-inf/lib, tuscany and its dependencies in
> container shared library (geronimo/websphere/..)
> C) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany and
> its dependencies in web-inf/tuscany (to issolate tuscany from app CL)
> D) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany and
> its dependencies in folder outside of webapp ie c:/Tuscany/lib
> E) - app dependencies in web-inf/lib, tuscany using deep integration in
> container (tomcat/geronimo/...)
> F) - all tuscany and its dependencies in web-inf/lib, app (sca
> contributions) in web-inf/sca-contributions
> G) - all tuscany and its dependencies in web-inf/lib, app (sca
> contributions) outside of webapp ie c:/MySCAContributions
> H) - tuscany using deep integration in container (tomcat/geronimo/...),
> app's (sca contributions) in folder in container, ie c:/apache-tomcat-6.0.10
> /SCAContributions
>
> Are there any other configurations anyone can think of?
>
> Most of our webapp samples today use (A) but we've code scattered about SVN
> and SVN history that do most of the others.
> (C) and (D) is what i think was being suggested by Simon Nash in [1].
> The app can see the Tuscany classes and dependencies with (A) and (B) which
> we were trying to avoid at one point.
> (B) (D) (E) and (H) reduce the size of the application as Tuscany is outside
> of the webapp but that requires an extra install step
> (G) (and F) is what I think users were interested in doing in TUSCANY-1884
> and [2]
>
> So its just a matter of deciding which we want to support and distribute :)
> As everyone seems to have different ideas about whats important I'm tempted
> to say lets try to support all of these for now so we play around and see
> which we think are really useful. How to distribute each option could be
> left to another thread.
>
> ...ant
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200801.mbox/%3c4786A694.1030609@hursley.ibm.com%3e
> [2]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200710.mbox/%3c562382.53461.qm@web45509.mail.sp1.yahoo.com%3e
>
I don't think that "support all of these" is such a good idea as it will
create complexity, but people are welcome to work on them if they want
to spend the time.
I'm interested in working on providing simple and usable support for:
- (A) as it's a simple scheme that'll work with all Web containers
- (B from your list) as it's a lighter variation of (A) that'll work
with Web containers that support shared libraries.
- (B from my list) as it's in line with the SCA spec and keeps runtime
specifics out of the application package.
I'm not quite sure how to map my option (B) to your options (F), (G),
(H). What will the packaging of an SCA contribution look like in your
options (F), (G), (H)?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Jan 21, 2008 9:31 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Simon Nash wrote:
> >> Jean-Sebastien Delfino wrote:
> >> - Under which circumstances does the app packager want to package the
> >> Tuscany and dependency JARs with the application artifacts.
> [snip]
> > With a big topic like this, dividing it into separate threads makes it
> > easier for people to follow and participate in the discussions. The
> > split you are suggesting looks good to me.
> [snip]
>
> Trying to address "Under which circumstances does the app packager want
> to package the Tuscany and dependency JARs with the application
> artifacts?"
>
> My (maybe simplistic) view is:
>
> A) We can package in a WAR:
> - several SCA contributions JARs
> - any SCA deployment composites
> - the required API JARs
> - the required Tuscany JARs and runtime dependency JARs
>
> This allows deployment of an SCA/Tuscany based solution to JEE Web
> containers without requiring any system configuration or software
> installation besides the Webapp.
>
> There are some basic architectural limitations to that scheme:
> - no good support for other bindings than HTTP based bindings
> - footprint issue with every Webapp packaging the whole runtime
>
> Also we're not quite there yet as I don't think we support:
> - several SCA contributions in the packaged solution
> - SCA deployment composites
>
> B) Package SCA contributions as simple JARs, containing only the
> application artifacts (no API JARs, no runtime dependency JARs).
>
> Packaging SCA contributions as OSGi bundles is a variation of the same
> scheme.
>
> Any thoughts?
> What other packaging schemes do people want to support and when?
> --
> Jean-Sebastien
>
>
Here's all the options I can think of:
A) - app dependencies and tuscany and its dependencies in web-inf/lib
B) - app dependencies in web-inf/lib, tuscany and its dependencies in
container shared library (geronimo/websphere/..)
C) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany and
its dependencies in web-inf/tuscany (to issolate tuscany from app CL)
D) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany and
its dependencies in folder outside of webapp ie c:/Tuscany/lib
E) - app dependencies in web-inf/lib, tuscany using deep integration in
container (tomcat/geronimo/...)
F) - all tuscany and its dependencies in web-inf/lib, app (sca
contributions) in web-inf/sca-contributions
G) - all tuscany and its dependencies in web-inf/lib, app (sca
contributions) outside of webapp ie c:/MySCAContributions
H) - tuscany using deep integration in container (tomcat/geronimo/...),
app's (sca contributions) in folder in container, ie c:/apache-tomcat-6.0.10
/SCAContributions
Are there any other configurations anyone can think of?
Most of our webapp samples today use (A) but we've code scattered about SVN
and SVN history that do most of the others.
(C) and (D) is what i think was being suggested by Simon Nash in [1].
The app can see the Tuscany classes and dependencies with (A) and (B) which
we were trying to avoid at one point.
(B) (D) (E) and (H) reduce the size of the application as Tuscany is outside
of the webapp but that requires an extra install step
(G) (and F) is what I think users were interested in doing in TUSCANY-1884
and [2]
So its just a matter of deciding which we want to support and distribute :)
As everyone seems to have different ideas about whats important I'm tempted
to say lets try to support all of these for now so we play around and see
which we think are really useful. How to distribute each option could be
left to another thread.
...ant
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200801.mbox/%3c4786A694.1030609@hursley.ibm.com%3e
[2]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200710.mbox/%3c562382.53461.qm@web45509.mail.sp1.yahoo.com%3e