Ok yes i agree with all that, it is the purpose of the SCAClient. And that reinforces the point that the impl should be separate from the Node. I know the current code has NodeImpl implementing SCAClient but that was just a easy way to demonstrate SCAClient working, so i'll create a new SCAClient impl for this.
...ant On Tue, Apr 21, 2009 at 4:29 PM, Raymond Feng <enjoyj...@gmail.com> wrote: > What I was trying to say is that SCAClient should be a client which is not > responsible for "adding/activating" a deployable composite to the SCA > domain. It should just "connects" to the SCA domain. The domain URI from the > client can be used to create a "remote" or "in-vm" connection to some > objects that know about the SCA domain to get information for the > domain-level component service. We probably will start with the "in-vm" case > where the Node seems to be a good bridge to an SCA domain. > > Thanks, > Raymond > > From: ant elder > Sent: Tuesday, April 21, 2009 5:43 AM > To: dev@tuscany.apache.org > Subject: Re: SCAClient API spec proposal > > > This is going a bit slow as i've more pressing things to do so taking it a > bit at a time, in line below... > > ...ant > > > On Tue, Apr 14, 2009 at 6:22 PM, Raymond Feng <enjoyj...@gmail.com> wrote: > > > node = NodeFactory.newInstance().createNode(config); // Create a > standalone node > > > SCAClient client = SCAClienfFactory.newInstance(); // The SCAClient can > be implemented by NodeImpl as well > > > HelloworldService service = client.getService(HelloworldService.class, > "HelloworldComponent", "urn:someDomainUri"); > > > > Do we really want SCAClient to be implemented by NodeImpl? You can pass in > a domain uri on the SCAClient getService call but a Node is tied to a single > domain, so how about, at least for now, having a separate SCAClient impl, > and we could revisit later on when we've made a bit more progress. > > ...ant >
