+1 to decouple the SCAClient from NodeImpl. Some of the related issues were
discussed on [1]
I also showed in [2] that we can potentially just model the SCAClient as a
Node with a single top-level ClientComponent that has references to all the
public services in the SCA domain. The client implementation can just
retrieve the SCA Domain Composite (or a subset view) to build a "client"
composite in memory and use our Node capability to set up the proxies to
services.
[1] http://www.mail-archive.com/[email protected]/msg06447.html
[2] http://www.mail-archive.com/[email protected]/msg06689.html
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Thursday, May 07, 2009 11:51 PM
To: <[email protected]>
Subject: Re: SCAClient API spec proposal
ant elder wrote:
On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <[email protected]>
wrote:
So a long way of saying +1 to creating a new and separate SCAClient.
Two thoughts...
- a first step could just be to interact with a local node and note
any restrictions
Lots of interesting things said in the thread, to move things along in
r772115 I've created a separate client module and updated to use that.
A testcase using this now looks like:
public class SCAClientTestCase extends TestCase {
private Node node;
@Override
protected void setUp() throws Exception {
node = NodeFactory.newInstance().createNode();
node.start();
}
public void testInvoke() throws Exception {
HelloworldService service =
SCAClientFactory.newInstance().getService(HelloworldService.class,
"HelloworldComponent", URI.create("default"));
assertEquals("Hello petra", service.sayHello("petra"));
}
@Override
protected void tearDown() throws Exception {
node.stop();
}
}
One thing to note is that currently the Tuscany Node has no mention of
a domain URI so this just works using the Node name as the domain uri.
...ant
Ant,
I am happy and supportive of the creation of the SCAClient.
However, I am not happy with some aspects of the current design and I
would like to see them changed.
I am most surprised to find references to SCAClient turning up in NodeImpl
class. I don't think that this is the right design.
I can appreciate that SCAClient may need access to information which is
currently held in NodeImpl. However, I think that the right design is for
NodeImpl to have a new interface to provide access to this information,
which SCAClient and others can call when required. One big reason for
this is that in the eventual design of SCAClient, the client is likely to
be running remotely from the Node. The idea of NodeImpl feeding the
necessary metadata to the SCAClient implementation "under the covers" just
isn't going to fly.
So I think that adding the new interface to NodeImpl now and then working
on a design for remoting is likely to be the right approach.
Yours, Mike.
