Sorry, you have been talking about section 10 of the SCA assembly spec.  

IMO, the names don't matter too much here. Having a layer that handles domain 
level deployment is good in addition to the node that is used to execute the 
components out of the domain.

Thanks,
Raymond
________________________________________________________________ 
Raymond Feng
[email protected]
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________

On Jun 9, 2010, at 12:08 AM, ant elder wrote:

> I think this is a misunderstanding of what this is for, I'm not trying
> to implement a new domain manger type of thing, so using the module
> name domain is likely confusing things. I'll move this somewhere else
> and continue it there.
> 
>   ...ant
> 
> On Sun, Jun 6, 2010 at 5:52 PM, Raymond Feng <[email protected]> wrote:
>> Hi,
>> Let the SCA spec speaks then :-). The following is the TOC of section 10
>> excerpted from the SCA assembly spec.
>> 10 Packaging and Deployment
>> ...............................................................................................................88
>> 10.1
>> Domains.........................................................................................................................................88
>> 10.2
>> Contributions..................................................................................................................................88
>> 10.2.1 SCA Artifact
>> Resolution...........................................................................................................89
>> 10.2.2 SCA Contribution Metadata
>> Document...................................................................................91
>> 10.2.3 Contribution Packaging using
>> ZIP...........................................................................................93
>> 10.3 States of Artifacts in the Domain
>> ....................................................................................................93
>> 10.4 Installed Contribution
>> ......................................................................................................................94
>> 10.4.1 Installed Artifact
>> URIs..............................................................................................................94
>> 10.5 Operations for
>> Contributions...........................................................................................................94
>> 10.5.1 install Contribution & update
>> Contribution...............................................................................94
>> 10.5.2 add Deployment Composite & update Deployment
>> Composite..............................................95
>> 10.5.3 remove Contribution
>> ................................................................................................................95
>> 10.6 Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
>> ....................................................95
>> 10.7 Domain-Level Composite
>> ...............................................................................................................96
>> 10.7.1 add To Domain-Level
>> Composite............................................................................................96
>> 10.7.2 remove From Domain-Level Composite
>> .................................................................................96
>> 10.7.3 get Domain-Level
>> Composite..................................................................................................96
>> 10.7.4 get QName Definition
>> ..............................................................................................................96
>> 10.8 Dynamic Behaviour of Wires in the SCA
>> Domain...........................................................................97
>> 10.9 Dynamic Behaviour of Component Property Values
>> ......................................................................97
>> 
>> I would like to make a few points based on what the spec says:
>> 1) Section 10 is really about Packaging and Deployment as the title clearly
>> states. IMO, that's consistent with my argument in the previous e-mail.
>> "3574 This section describes the SCA Domain and the packaging and deployment
>> of artifacts contributed to the
>> 3575 Domain."
>> 2) Section 10 doesn't contain any runtime operations such as
>> getService(...).
>> Once we fully implement the functions in Section 10, I do see opportunities
>> that the domain can configure the nodes and launch them locally for
>> "testing".
>> +1 to keep the "domain" module separate from the "node".
>> -1 to merge the "domain" module with the "node" modules at this point.
>> Thanks,
>> Raymond
>> 
>> ________________________________________________________________
>> Raymond Feng
>> [email protected]
>> Apache Tuscany PMC member and committer: tuscany.apache.org
>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>> Personal Web Site: www.enjoyjava.com
>> ________________________________________________________________
>> 
>> On Jun 6, 2010, at 2:23 AM, ant elder wrote:
>> 
>> Thats a quite particular view of the domain Raymond. The naming is
>> like this to try to avoid any initial misconceptions about what should
>> or should not be done, and the Javadoc is exactly as from the spec to
>> make it harder to deviate from the spec defined functions. I expect
>> theses will be changed as it becomes more "done". I'd suggested
>> merging this with the Node APIS, and in my view that would be best for
>> Tuscany, but an alternative that could also work well is to instead
>> merge the Node APIs into this. So thats what I'll do for now, which
>> will give room to innovate around the spec while leaving the old APIs
>> stable.
>> 
>>   ...ant
>> 
>> On Sat, Jun 5, 2010 at 5:33 PM, Raymond Feng <[email protected]> wrote:
>> 
>> A few comments:
>> 
>> 1) Can we rename the package and class names? "something" and "Section10"
>> 
>> seems to be strange :-).
>> 
>> 2) The javadoc is difficult to read too with the line numbers copied from
>> 
>> the spec.
>> 
>> 3) I don't think the domain module should have any overlapping again the
>> 
>> node modules. The domain provides functions to "manage"  the SCA domain
>> 
>> metadata through "deployment". The node is the execution environment for a
>> 
>> group of top-level components from the SCA domain. IMO, Section10.java
>> 
>> should NOT contain the getService() method. We could add methods to it so
>> 
>> that it can be used to create NodeConfiguration though.
>> 
>> An SCA domain has both metadata and runtime views.
>> 
>> a. The SCA domain is the registry for contributions, composites, policy
>> 
>> definitions and node configurations. The domain composite represents the
>> 
>> overall composition of all the services that share the same boundary
>> 
>> (wirings based on the SCA address) and vocabulary (policies).
>> 
>> b. At runtime, the domain metadata is used by the nodes to execute the
>> 
>> top-level components. The metadata can be made available to a node via a
>> 
>> live domain registry (either centralized or distributed) or a set of offline
>> 
>> configuration files.
>> 
>> Thanks,
>> 
>> Raymond
>> 
>> ________________________________________________________________
>> 
>> Raymond Feng
>> 
>> [email protected]
>> 
>> Apache Tuscany PMC member and committer: tuscany.apache.org
>> 
>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>> 
>> Personal Web Site: www.enjoyjava.com
>> 
>> ________________________________________________________________
>> 
>> On Jun 5, 2010, at 12:20 AM, ant elder wrote:
>> 
>> Ok I've moved this to trunk now -
>> 
>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain/.
>> 
>> I really like these spec defined APIs, they make the use of
>> 
>> domains/contributions/composites much more explicit and seem more
>> 
>> intuitive than what we've currently got. We could carry on developing
>> 
>> them separately but that will result in some duplication with existing
>> 
>> code so it would be good to merge them with the existing Node code.
>> 
>>   ...ant
>> 
>> 
>> 
>> 

Reply via email to