On Thu, Apr 9, 2009 at 7:01 PM, Raymond Feng <enjoyj...@gmail.com> wrote: > Please see my comments inline. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <ant.el...@gmail.com> > Sent: Thursday, April 09, 2009 5:55 AM > To: <dev@tuscany.apache.org> > Subject: Re: SCAClient API spec proposal > > [[snip]] >> >> So lets explore this a bit using the testcase below as an example of >> what we might want to do. It uses the tests setup and tearDown methods >> to createand stop a Tuscany Node and then the in a test method uses an >> SCAClient to get a service so that would need someway to find the >> already created Node. >> >> Some things are: >> - the Tuscany Node doesn't have a domain URI so there isn't any way to >> create or match existing Nodes to match the URI passed in on the >> SCAClient getService call. > > IMO, a Tuscany SCA Node can be running in two modes: > > * offline: not connecting to an SCA domain 'manager' > * online: connecting to an SCA domain 'manager' > > Please note 'manager' is either a central controller or a distributed group. > > In the offline mode, the Node gets its configuration from a document which > would include the URI for the SCA domain. > In the online mode, the Node connects an SCA domain and the URI of the > domain is available to the Node. > >> - there's no link between the Node and SCAClient instances for the >> SCAClient to find the Node so it will probably have to use some static >> in the factories > > The SCAClient can be instantiated independent of the Node. So the SCAClient > can be run without an active Node. Again, there are different options to > provide > configuration to the SCAClient, such as: > * An XML document (which can list more than one SCA domains) > * An instance of the Node which has knowledge of a subset or the whole of an > SCA domain. > > If the domain URI passed from the SCAClient API cannot be resolved to a > known SCA domain, then we should report with NoSuchDomainException. > >> - we probably want to think about supporting multiple Nodes in a >> domain so i'm wondering if we need to have an SCADomain again and have >> the SCADomain know about multiple Nodes. >> > > We need to be a bit careful here. The SCA domain is a virtual collection. If > we create a java model for the domain, then it should be able to get all the > metadata for the domain, such as the contributions, domain composite. > Typically, what a Node sees is a portion/fragment of the SCA domain. > >
heh, I expected this would be an interesting topic ;-) I'll leave a more detailed reply to next week but in the meantime here is all i can find in the SCA Assembly spec (1.1 cd03) directly related to how the SCA domain works, its not very precisely defined, do say if i've missed anything or if theres other spec docs mentioning something. So for things not specifically mentioned here i guess we have a lot of flexibility to do whatever we like: 3381 An SCA Domain represents a complete runtime configuration, potentially distributed over a series 3382 of interconnected runtime nodes. 3397 An SCA Domain has the following: 3398 • A virtual domain-level composite whose components are deployed and running 3399 • A set of installed contributions that contain implementations, interfaces and other artifacts 3400 necessary to execute components 3401 • A set of logical services for manipulating the set of contributions and the virtual domain 3402 level composite. 3683 SCA Runtimes provide the following conceptual functionality associated with contributions to the 3684 Domain (meaning the function might not be represented as addressable services and also 3685 meaning that equivalent functionality might be provided in other ways). An SCA runtime MAY 3686 provide the contribution operation functions (install Contribution, update Contribution, add 3687 Deployment Composite, update Deployment Composite, remove Contribution).[ASM12008] 3742 11.6 Domain-Level Composite 3743 The domain-level composite is a virtual composite, in that it is not defined by a composite 3744 definition document. Rather, it is built up and modified through operations on the Domain. 3745 However, in other respects it is very much like a composite, since it contains components, wires, 3746 services and references. 3760 The abstract domain-level functionality for modifying the domain-level composite is as follows, 3761 although a runtime can supply equivalent functionality in a different form: 3762 11.6.1 add To Domain-Level Composite 3773 11.6.2 remove From Domain-Level Composite 3778 11.6.3 get Domain-Level Composite 3782 11.6.4 get QName Definition 3789 Note that this, like all the other domain-level operations, is a conceptual operation. Its capabilities 3790 need to exist in some form, but not necessarily as a service operation with exactly this signature. ...ant