Hi Raymond

  Very good summary, and the diagram is in sync with my understanding. I'll
try to get something started on the implementation side based on you
documentation.

--
Luciano Resende
http://people.apache.org/~lresende

On 2/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

I added a diagram and the interface for the ContributionService @
http://cwiki.apache.org/confluence/display/TUSCANY/Deployment. I would
like
to hear your opinions.

Thanks,
Raymond

----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, January 31, 2007 9:18 PM
Subject: Re: Chat summary on the SCA deployment story in Tuscany


> 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" <[EMAIL PROTECTED]>
> To: <[email protected]>
> 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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to