You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/02/01 02:23:36 UTC
Chat summary on the SCA deployment story in Tuscany
Hi,
I had an offline chat with Jeremy to help myself glue a few pieces
(basically a sequence of actions and participants) together so that I can
see the whole picture of the SCA deployment story in Tuscany.
We feel it's useful to share the information with the community. I put
together a summary at
http://cwiki.apache.org/confluence/display/TUSCANY/Deployment. Please review
and comment.
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Chat summary on the SCA deployment story in Tuscany
Posted by Raymond Feng <en...@gmail.com>.
OK, I have added your comments to the wiki page:
http://cwiki.apache.org/confluence/display/TUSCANY/Deployment
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, January 31, 2007 6:50 PM
Subject: Re: Chat summary on the SCA deployment story in Tuscany
> Couple of comments.
>
> I'd say they're not really phases - contributing something is independent
> of making changes to the assembly. The contribution process is about
> adding Types to the domain (composites, classes, XSD complexTypes, etc.)
> whereas the assembly is about creating/modifying/ removing instances of
> things (primarily components).
>
> Contributions are not just about SCA applications themselves but about
> anything that contributes function to the domain.
>
> The caching is about storing the introspection results for "production"
> artifacts that are basically versioned and immutable. This is similar in
> concept to the way Maven caches artifacts locally and never needs to go
> back to an online repo once they have been downloaded. Given some
> introspections are likely to be expensive (e.g. scanning an EAR to look
> for EJBs and then processsing the class files for annotations) it would
> be good to avoid redoing that when its not necessary.
>
> The idea of "portable builders" is about separating the node responsible
> for domain assembly from the nodes running component implementations. In
> a heterogeneous federation, it could be the assembly node(s) are running
> C++ but the user wants to add a Java component that will actually run on
> a Java node. If the introspection results for the Java contribution are
> portable, it would be possible for the C++ to set up the physical
> configuration for the Java builder; alternatively, it could delegate that
> to a service running in a native Java environment. Similarly, if the
> component was in some portable language (like Ruby or XSLT), then the
> configuration could be done on a Java node and passed to a C++ runtime
> node.
>
> --
> Jeremy
>
> On Jan 31, 2007, at 5:23 PM, Raymond Feng wrote:
>
>> Hi,
>>
>> I had an offline chat with Jeremy to help myself glue a few pieces
>> (basically a sequence of actions and participants) together so that I
>> can see the whole picture of the SCA deployment story in Tuscany.
>>
>> We feel it's useful to share the information with the community. I put
>> together a summary at http://cwiki.apache.org/confluence/
>> display/TUSCANY/Deployment. Please review and comment.
>>
>> Thanks,
>> Raymond
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Chat summary on the SCA deployment story in Tuscany
Posted by Jeremy Boynes <jb...@apache.org>.
Couple of comments.
I'd say they're not really phases - contributing something is
independent of making changes to the assembly. The contribution
process is about adding Types to the domain (composites, classes, XSD
complexTypes, etc.) whereas the assembly is about creating/modifying/
removing instances of things (primarily components).
Contributions are not just about SCA applications themselves but
about anything that contributes function to the domain.
The caching is about storing the introspection results for
"production" artifacts that are basically versioned and immutable.
This is similar in concept to the way Maven caches artifacts locally
and never needs to go back to an online repo once they have been
downloaded. Given some introspections are likely to be expensive
(e.g. scanning an EAR to look for EJBs and then processsing the class
files for annotations) it would be good to avoid redoing that when
its not necessary.
The idea of "portable builders" is about separating the node
responsible for domain assembly from the nodes running component
implementations. In a heterogeneous federation, it could be the
assembly node(s) are running C++ but the user wants to add a Java
component that will actually run on a Java node. If the introspection
results for the Java contribution are portable, it would be possible
for the C++ to set up the physical configuration for the Java
builder; alternatively, it could delegate that to a service running
in a native Java environment. Similarly, if the component was in some
portable language (like Ruby or XSLT), then the configuration could
be done on a Java node and passed to a C++ runtime node.
--
Jeremy
On Jan 31, 2007, at 5:23 PM, Raymond Feng wrote:
> Hi,
>
> I had an offline chat with Jeremy to help myself glue a few pieces
> (basically a sequence of actions and participants) together so that
> I can see the whole picture of the SCA deployment story in Tuscany.
>
> We feel it's useful to share the information with the community. I
> put together a summary at http://cwiki.apache.org/confluence/
> display/TUSCANY/Deployment. Please review and comment.
>
> Thanks,
> Raymond
>
> ---------------------------------------------------------------------
> 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