You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2010/05/25 09:25:32 UTC
APIs described in section 10 of the SCA Assembly spec
Last week I started having a look at what implementing the APIs that
are described in section 10 of the SCA Assembly spec would look like.
As the commit comment said [1] there wasn't a clear idea where it
would go, a user had asked me about it, and I just wanted to see if
Tuscany provided everything needed to support the APIs. It turns out
Tuscany has already pretty much everything needed and it was quite
easy to get to work. I quite like these APIs so now I'd like to move
it from contrib to trunk and start seeing how it can be more
integrated with the main Tuscany code.
...ant
[1] http://mail-archives.apache.org/mod_mbox/tuscany-commits/201005.mbox/%3C20100520114512.D15802388900@eris.apache.org%3E
Re: APIs described in section 10 of the SCA Assembly spec
Posted by Raymond Feng <en...@gmail.com>.
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
rfeng@apache.org
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 <en...@gmail.com> 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
>> rfeng@apache.org
>> 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 <en...@gmail.com> 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
>>
>> rfeng@apache.org
>>
>> 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
>>
>>
>>
>>
Re: APIs described in section 10 of the SCA Assembly spec
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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
> rfeng@apache.org
> 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 <en...@gmail.com> 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
>
> rfeng@apache.org
>
> 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
>
>
>
>
Re: APIs described in section 10 of the SCA Assembly spec
Posted by Raymond Feng <en...@gmail.com>.
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
rfeng@apache.org
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 <en...@gmail.com> 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
>> rfeng@apache.org
>> 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
>>
>>
Re: APIs described in section 10 of the SCA Assembly spec
Posted by ant elder <an...@apache.org>.
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 <en...@gmail.com> 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
> rfeng@apache.org
> 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
>
>
Re: APIs described in section 10 of the SCA Assembly spec
Posted by Raymond Feng <en...@gmail.com>.
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
rfeng@apache.org
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
Re: APIs described in section 10 of the SCA Assembly spec
Posted by ant elder <an...@apache.org>.
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
Re: APIs described in section 10 of the SCA Assembly spec
Posted by ant elder <an...@apache.org>.
Alright naming the module tuscany-domain sounds ok for now and I'm
fine with keeping it out of the NodeFactory/Node APIs.
...ant
On Tue, May 25, 2010 at 5:41 PM, Raymond Feng <en...@gmail.com> wrote:
> If I understand correctly, section 10 of the SCA assembly spec defines a set
> of "logical" operations that be performed against an SCA domain. It's a
> deployment view of the SCA domain (i.e, the metadata of the domain). We
> should not mix it with the Tuscany NodeFactory/Node APIs that provides a
> runtime view of the Tuscany implementation of SCA.
> IMO, we can use the APIs described in section 10 as the base to build up the
> SCA domain manager. As we have discussed before, we have different ways to
> "form" and SCA domain:
> * static vs dynamic
> * discovery vs central-registry
> For different schemes, the implementation of the SCA domain operations can
> be different too.
> Having said this, I suggest that we check it in under a module such as
> tuscany-domain. I'm not sure if we should expose them to the runtime node
> which already uses the EndpointRegistry (DomainRegistry) to access the
> metadata of an SCA domain.
> [1]
> https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
> [2] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Domain
>
> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> 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 May 25, 2010, at 8:18 AM, Simon Laws wrote:
>
> On Tue, May 25, 2010 at 8:25 AM, ant elder <an...@gmail.com> wrote:
>
> Last week I started having a look at what implementing the APIs that
>
> are described in section 10 of the SCA Assembly spec would look like.
>
> As the commit comment said [1] there wasn't a clear idea where it
>
> would go, a user had asked me about it, and I just wanted to see if
>
> Tuscany provided everything needed to support the APIs. It turns out
>
> Tuscany has already pretty much everything needed and it was quite
>
> easy to get to work. I quite like these APIs so now I'd like to move
>
> it from contrib to trunk and start seeing how it can be more
>
> integrated with the main Tuscany code.
>
> ...ant
>
> [1]
> http://mail-archives.apache.org/mod_mbox/tuscany-commits/201005.mbox/%3C20100520114512.D15802388900@eris.apache.org%3E
>
>
> I'd certainly like to have a go with them so +1 from me.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
>
Re: APIs described in section 10 of the SCA Assembly spec
Posted by Raymond Feng <en...@gmail.com>.
If I understand correctly, section 10 of the SCA assembly spec defines a set of "logical" operations that be performed against an SCA domain. It's a deployment view of the SCA domain (i.e, the metadata of the domain). We should not mix it with the Tuscany NodeFactory/Node APIs that provides a runtime view of the Tuscany implementation of SCA.
IMO, we can use the APIs described in section 10 as the base to build up the SCA domain manager. As we have discussed before, we have different ways to "form" and SCA domain:
* static vs dynamic
* discovery vs central-registry
For different schemes, the implementation of the SCA domain operations can be different too.
Having said this, I suggest that we check it in under a module such as tuscany-domain. I'm not sure if we should expose them to the runtime node which already uses the EndpointRegistry (DomainRegistry) to access the metadata of an SCA domain.
[1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
[2] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Domain
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
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 May 25, 2010, at 8:18 AM, Simon Laws wrote:
> On Tue, May 25, 2010 at 8:25 AM, ant elder <an...@gmail.com> wrote:
>> Last week I started having a look at what implementing the APIs that
>> are described in section 10 of the SCA Assembly spec would look like.
>> As the commit comment said [1] there wasn't a clear idea where it
>> would go, a user had asked me about it, and I just wanted to see if
>> Tuscany provided everything needed to support the APIs. It turns out
>> Tuscany has already pretty much everything needed and it was quite
>> easy to get to work. I quite like these APIs so now I'd like to move
>> it from contrib to trunk and start seeing how it can be more
>> integrated with the main Tuscany code.
>>
>> ...ant
>>
>> [1] http://mail-archives.apache.org/mod_mbox/tuscany-commits/201005.mbox/%3C20100520114512.D15802388900@eris.apache.org%3E
>>
>
> I'd certainly like to have a go with them so +1 from me.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: APIs described in section 10 of the SCA Assembly spec
Posted by Simon Laws <si...@googlemail.com>.
On Tue, May 25, 2010 at 8:25 AM, ant elder <an...@gmail.com> wrote:
> Last week I started having a look at what implementing the APIs that
> are described in section 10 of the SCA Assembly spec would look like.
> As the commit comment said [1] there wasn't a clear idea where it
> would go, a user had asked me about it, and I just wanted to see if
> Tuscany provided everything needed to support the APIs. It turns out
> Tuscany has already pretty much everything needed and it was quite
> easy to get to work. I quite like these APIs so now I'd like to move
> it from contrib to trunk and start seeing how it can be more
> integrated with the main Tuscany code.
>
> ...ant
>
> [1] http://mail-archives.apache.org/mod_mbox/tuscany-commits/201005.mbox/%3C20100520114512.D15802388900@eris.apache.org%3E
>
I'd certainly like to have a go with them so +1 from me.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com