On Fri, May 8, 2009 at 7:51 AM, Mike Edwards
<mike.edwards.inglen...@gmail.com> wrote:
> ant elder wrote:
>>
>> On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <simonsl...@googlemail.com>
>> 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.
>

I agree with all that, this current code is just a tentitive first
step to demonstrate the *user application code* using Tuscany and
SCAClient, now we can expand on that and work out what a good
implementation is.

I would like to try to avoid engineering a more complex design than
necessary though so think we should pick specific use cases and do
just enough to make them work. To start I've picked this common case
of a single standalone node being used within a single JVM by a
testcase/sample. Next use case could be separate JVMs for the Node and
testcase/sample, or a testcase/sample using two Nodes within the one
JVM. Both of those have complications though so its seems easier to
focus on the simple case for now.

Happy to add an interface, could you say more about what it could look like?

   ...ant

Reply via email to