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 2009/04/07 15:27:44 UTC

SCAClient API spec proposal

I think the SCACLient API proposal going on in the spec group looks
interesting so i've started adding support for that code to the
Tuscany 2.x trunk, see r762759/762760 and an itest at:
https://svn.apache.org/repos/asf/tuscany/java/sca/itest/scaclient-api/src/test/java/SCAClientTestCase.java

There's a thread in the spec mailing list about it:
http://lists.oasis-open.org/archives/sca-j/200903/msg00121.html

 ...ant

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Thu, Apr 9, 2009 at 7:01 PM, Raymond Feng <en...@gmail.com> wrote:
> Please see my comments inline.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@gmail.com>
> Sent: Thursday, April 09, 2009 5:55 AM
> To: <de...@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

Re: SCAClient API spec proposal

Posted by Scott Kurz <sc...@gmail.com>.
On Wed, Apr 22, 2009 at 10:10 AM, ant elder <an...@gmail.com> wrote:
....
> would not be invokeable via SCAClient as the service isn't exposed with the
> SCA binding.

I'd also assume the service would need to be exposed over binding.sca.

Continuing my line of thought... if there is any variability in
wireFormat for the binding.sca impl, then the runtime needs to provide
the actual wire format behavior established for the service to the
user of SCAClient (rather than only the default wire format behavior).

Scott

Re: SCAClient API spec proposal

Posted by Simon Laws <si...@googlemail.com>.
On Thu, Apr 23, 2009 at 3:51 PM, Scott Kurz <sc...@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 3:55 PM, Raymond Feng <en...@gmail.com> wrote:
>> 2892 If a reference does not have a binding, then the binding used can be
>> any of the bindings
>> 2893 specified by the service provider, as long as the intents attached to
>> the reference and
>> 2894 the service are all honoured.
>
> That's interesting.  So this is the OASIS Assembly Spec Sec. 8.5.
>
> I see a number of problems with this section:
>
> 1. By "reference does not have a binding" it is not clear if they are
> talking about the lack of a binding element (in which case the
> <binding.sca> might be set to be implicitly present) or the lack of a
> binding, period (in the case of this SCAClient-created proxy), or
> both.   I'm guessing they mean both.   This is a significant change
> from OSOA.   But this is only a minor clarification needed.

I'm not an expert but as I understand it it means that when there is
no binding element explicitly provided on the reference then the
binding is selected from the bindings listed on the services. Note
also the following...

904 • If a reference has a value specified for one or more target
services in its @target attribute,
905 there MUST NOT be any child <binding/> elements declared for that reference.

>
> 2.
> 2876   .....   If the interface of the service or reference is
> remotable, then either
> 2877  the local or remote variant of the SCA binding will be used
> depending on whether source
> 2878  and target are co-located or not.
>
> This is confusing.  It almost sounds like for a co-located service
> with a remotable interface, you would expect PBR instead of PBV.
> Though there must be a local vs. remotable variant of the SCA binding
> impl, there may or may not be a co-located vs. non-co-located variant.
>  This text should probably just be deleted.

Yep, I don't see that the spec defines different semantics for
binding.sca depending on whether a target is local or remote. Although
there are likely to be implications for resource used, performance etc
between the different versions of binding.sca.

>
> 3.  organization - This specification of a behavior about references
> shouldn't be buried in the "binding.sca" section of the spec.

It is described in the sections on reference/service also. In
particular there is a section "4.3.1 Specifying the Target Service(s)
for a Reference" that describes it in some detail.

>
> I haven't personally been participating in the OASIS spec
> discussions.. not sure if anyone is following this thread who is would
> agree that this is worth bringing up... or I could jump in that OASIS
> mailing list I guess.
>
> Scott
>

Re: SCAClient API spec proposal

Posted by Scott Kurz <sc...@gmail.com>.
On Wed, Apr 22, 2009 at 3:55 PM, Raymond Feng <en...@gmail.com> wrote:
> 2892 If a reference does not have a binding, then the binding used can be
> any of the bindings
> 2893 specified by the service provider, as long as the intents attached to
> the reference and
> 2894 the service are all honoured.

That's interesting.  So this is the OASIS Assembly Spec Sec. 8.5.

I see a number of problems with this section:

1. By "reference does not have a binding" it is not clear if they are
talking about the lack of a binding element (in which case the
<binding.sca> might be set to be implicitly present) or the lack of a
binding, period (in the case of this SCAClient-created proxy), or
both.   I'm guessing they mean both.   This is a significant change
from OSOA.   But this is only a minor clarification needed.

2.
2876   .....   If the interface of the service or reference is
remotable, then either
2877  the local or remote variant of the SCA binding will be used
depending on whether source
2878  and target are co-located or not.

This is confusing.  It almost sounds like for a co-located service
with a remotable interface, you would expect PBR instead of PBV.
Though there must be a local vs. remotable variant of the SCA binding
impl, there may or may not be a co-located vs. non-co-located variant.
  This text should probably just be deleted.

3.  organization - This specification of a behavior about references
shouldn't be buried in the "binding.sca" section of the spec.

I haven't personally been participating in the OASIS spec
discussions.. not sure if anyone is following this thread who is would
agree that this is worth bringing up... or I could jump in that OASIS
mailing list I guess.

Scott

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
2892 If a reference does not have a binding, then the binding used can be 
any of the bindings
2893 specified by the service provider, as long as the intents attached to 
the reference and
2894 the service are all honoured.

--------------------------------------------------
From: "Scott Kurz" <sc...@gmail.com>
Sent: Wednesday, April 22, 2009 12:06 PM
To: <de...@tuscany.apache.org>
Subject: Re: SCAClient API spec proposal

> On Wed, Apr 22, 2009 at 11:54 AM, Raymond Feng <en...@gmail.com> 
> wrote:
>> Here are my two cents based on my understanding of the OASIS spec:
>>
>> 1) SCAClient.getService() is similar to connect an SCA service using a 
>> dummy
>> reference without any binding declarations. The OASIS spec says the 
>> binding
>> for the reference will be provided by the service binding in such cases.
>
> What part of which spec are you referring to?  Though the wire format,
> as part of the binding, would be covered by that statement ... I'm
> still wondering if anything is said about the interface.
>
> Thanks, Scott 


Re: SCAClient API spec proposal

Posted by Scott Kurz <sc...@gmail.com>.
On Wed, Apr 22, 2009 at 11:54 AM, Raymond Feng <en...@gmail.com> wrote:
> Here are my two cents based on my understanding of the OASIS spec:
>
> 1) SCAClient.getService() is similar to connect an SCA service using a dummy
> reference without any binding declarations. The OASIS spec says the binding
> for the reference will be provided by the service binding in such cases.

What part of which spec are you referring to?  Though the wire format,
as part of the binding, would be covered by that statement ... I'm
still wondering if anything is said about the interface.

Thanks, Scott

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
Here are my two cents based on my understanding of the OASIS spec:

1) SCAClient.getService() is similar to connect an SCA service using a dummy 
reference without any binding declarations. The OASIS spec says the binding 
for the reference will be provided by the service binding in such cases. 
Taking a step further, we can view the client as a special composite 
deployed to the SCA domain and it has references to all the top-level 
component services. It can be illustrated as follows:

<composite name="Client" ...>
    <component name="ClientComponent">
             <reference name="..." target="C1/S1">
                     <interface.java interface="my.Service1"/>
             </reference>
             <reference name="..." target="C1/S2">
                     <interface.java interface="my.Service2"/>
             </reference>
...
             <reference name="..." target="Cn/Sk">
                     <interface.java interface="my.ServiceK"/>
             </reference>

   </component>
</composite>

The behavior of SCAClient.getService() should be pretty much like 
ClientComponent.getService("clientRefToTheService").


2) The OASIS spec also says the meaning of composite services and references 
for a top-level composite is not defined. Service/reference promotions are 
only meaningful is the composite is used as "implementation.composite".

3762 11.6.1 add To Domain-Level Composite
3763 This functionality adds the composite identified by a supplied URI to 
the Domain Level Composite.
3764 The supplied composite URI refers to a composite within an installed 
contribution. The
3765 composite's installed contribution determines how the composite's 
artifacts are resolved (directly
3766 and indirectly). The supplied composite is added to the domain 
composite with semantics that
3767 correspond to the domain-level composite having an <include> statement 
that references the
3768 supplied composite. All of the composites components become top-level 
components and the
3769 component services become externally visible services (eg. they would 
be present in a WSDL
3770 description of the Domain). The meaning of any promoted services and 
references in the supplied
3771 composite is not defined; since there is no composite scope outside the 
domain composite, the
3772 usual idea of promotion has no utility.

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Wednesday, April 22, 2009 8:20 AM
To: <de...@tuscany.apache.org>
Subject: Re: SCAClient API spec proposal

> On Wed, Apr 22, 2009 at 4:10 PM, Simon Laws <si...@googlemail.com> 
> wrote:
>
>> Currently we have this trick in our local client where a new $self$
>> reference created. However It sounds ok to me to say that you can only
>> talk to things with an SCA binding. If you want to talk to something
>> without an sca binding then add binding.sca to the component in
>> question or add a proxy component to the domain to allow you to do it.
>> Does that make the client API too awkward to use?
>>
>> Simon
>>
>
> Or have the <service> outside of the component which then means
> binding.sca is available as well:
>
>   <service name="MyService" promote="Service1">
>      <binding.jms />
>   </service>
>
>    <component name="Service1">
>        <implementation.java
> class="org.apache.tuscany.sca.binding.jms.ServiceImpl"/>
>    </component>
>
> I think one of the reasons most of the Tuscany examples have the
> <service> within the component is that it saves a few characters (the
> promote attribute) and up until this SCAClient came along it didn't
> make much difference. Maybe we should revist that.
>
>   ...ant 


Re: SCAClient API spec proposal

Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 4:10 PM, Simon Laws <si...@googlemail.com> wrote:

> Currently we have this trick in our local client where a new $self$
> reference created. However It sounds ok to me to say that you can only
> talk to things with an SCA binding. If you want to talk to something
> without an sca binding then add binding.sca to the component in
> question or add a proxy component to the domain to allow you to do it.
> Does that make the client API too awkward to use?
>
> Simon
>

Or have the <service> outside of the component which then means
binding.sca is available as well:

   <service name="MyService" promote="Service1">
      <binding.jms />
   </service>

    <component name="Service1">
        <implementation.java
class="org.apache.tuscany.sca.binding.jms.ServiceImpl"/>
    </component>

I think one of the reasons most of the Tuscany examples have the
<service> within the component is that it saves a few characters (the
promote attribute) and up until this SCAClient came along it didn't
make much difference. Maybe we should revist that.

   ...ant

Re: SCAClient API spec proposal

Posted by Simon Laws <si...@googlemail.com>.
snip...
> Presumably an SCAClient impl would only be expected to talk to an SCA domain
> with a similar implementation?

Y - binding-sca only works inside a domain.

> So the Tuscany SCAClient would use the
> Tuscany SCA binding to talk to a Tuscany domain, but you wouldn't be able to
> use the Tuscany SCAClient to talk to a non-Tuscany domain as the SCA binding
> impl could be implemented totally differently.
>
> And also does that mean an SCACient be only able to talk to services exposed
> with the SCA binding?

Y

> So this:
>
>     <component name="Service1">
>         <implementation.java
> class="org.apache.tuscany.sca.binding.jms.ServiceImpl"/>
>         <service name="MyService">
>             <binding.jms />
>         </service>
>     </component>
>
> would not be invokeable via SCAClient as the service isn't exposed with the
> SCA binding.

Currently we have this trick in our local client where a new $self$
reference created. However It sounds ok to me to say that you can only
talk to things with an SCA binding. If you want to talk to something
without an sca binding then add binding.sca to the component in
question or add a proxy component to the domain to allow you to do it.
Does that make the client API too awkward to use?

Simon

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Wed, Apr 22, 2009 at 2:42 PM, Scott Kurz <sc...@gmail.com> wrote:

> Just wanted to note that it seems that an additional burden on the
> runtime implementor to support this API is to recognize if the service
> is described by <interface.wsdl>.
>
> If so the runtime has to establish this WSDL interface on the runtime
> representation of the reference built for the proxy without having the
> data in hand from the client side (but rather only from the side of
> the service in the domain).
>
> Would be good to have some tests for this variation with something
> like the axis2 binding.sca impl for which following the exact wsdl
> interface (instead of generating one bottom up) should matter.
>
> Scott
>

Thats an interesting point.

Presumably an SCAClient impl would only be expected to talk to an SCA domain
with a similar implementation? So the Tuscany SCAClient would use the
Tuscany SCA binding to talk to a Tuscany domain, but you wouldn't be able to
use the Tuscany SCAClient to talk to a non-Tuscany domain as the SCA binding
impl could be implemented totally differently.

And also does that mean an SCACient be only able to talk to services exposed
with the SCA binding? So this:

    <component name="Service1">
        <implementation.java
class="org.apache.tuscany.sca.binding.jms.ServiceImpl"/>
        <service name="MyService">
            <binding.jms />
        </service>
    </component>

would not be invokeable via SCAClient as the service isn't exposed with the
SCA binding.

   ...ant

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Fri, May 8, 2009 at 7:51 AM, Mike Edwards
<mi...@gmail.com> wrote:
> ant elder wrote:
>>
>> On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <si...@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

Re: SCAClient API spec proposal

Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Fri, Jun 26, 2009 at 11:36 AM, Simon Nash<na...@apache.org> wrote:
>> ant elder wrote:
>>> On Thu, Jun 25, 2009 at 5:12 PM, Raymond Feng<en...@gmail.com> wrote:
>>>> I don't think adding the callback pattern to SCAClient is good idea. IMO,
>>>> the client should be really lightweight and supporting incoming
>>>> connections
>>>> is too much in such environment.
>>>>
>>> Sure, it wouldn't be appropriate for all environments, but the client
>>> factory is plugable so if supporting a listener really causes issues
>>> then its easy to also have a simpler factory that doesn't support
>>> callbacks. But its not necessarily going to add much weight, the
>>> client is remote from the domain so it already needs code to handle
>>> the communication protocol, the callback listener wont add much more
>>> over that. If its an http protocol and jdk6 then that already comes
>>> with a built in mini http server.
>>>
>>>> Why don't you use an SCA composite/component if callback is required?
>>>>
>>> and you could go further on that path and say why have the SCAClient
>>> at all and everything could be an SCA composite/component ;)  Not
>>> everyone and everything is SCA yet, the async programing model is one
>>> of the interesting features of SCA and IMHO having things like this
>>> client being able to support that would help people see the utility of
>>> SCA before they've adopted it wholesale.
>>>
>>>   ...ant
>>>
>> There is (now) another way for non-SCA code to receive callbacks
>> from SCA code.  The public review draft of the WS Binding spec
>> defines a WS Binding Callback Protocol for which support is optional.
>> Any web service client could use this protocol to call an SCA
>> service and receive callbacks, as long as the service has a WS binding
>> and the SCA runtime supports this optional protocol.  IMO this is a
>> better way to meet this requirement than making the SCAClient API
>> more complex by adding an optional callback listener.
>>
>>  Simon
>>
> 
> Isn't saying the service could just use a WS binding similar to the
> other suggestion of just using a SCA composite/component, in that you
> could add a WS binding to any service and then use any regular WS
> client so why then have the SCAClient at all?
 >
I don't think it's the same at all.  The WS Callback Protocol allows
any code that uses Web Services to interact with SCA callbacks.
There's no need for this code to run within an SCA runtime, as a
composite/component would have to do.

The SCAClient API is intended to provide a simple way of accessing
SCA services from outside an SCA domain.  The important word is
"simple", which is why it doesn't handle things like policies,
binding selection, and callbacks.  I think that's a reasonable
trade-off.

 >                                               I didn't really expect
> this to get into the spec at this late stage, but i do still think it
> would be a useful thing to support, so how about we use Tuscany as a
> testing ground for it and try adding a TuscanySCAClient interface that
> supports callbacks to try it out, you'd get a regular SCAClient and if
> you want to do callbacks cast it to a TuscanySCAClient. If we can get
> it to work and try it out for a while to see if it makes things
> complicated or heavy weight, and if it works ok get it added to a
> letter spec release.
> 
I think we would be better spending our efforts on supporting all the
things that are in the OASIS specs, and getting Tuscany to pass the
OASIS compliance tests.

   Simon

>    ...ant
> 
> 



Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Fri, Jun 26, 2009 at 11:36 AM, Simon Nash<na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Thu, Jun 25, 2009 at 5:12 PM, Raymond Feng<en...@gmail.com> wrote:
>>>
>>> I don't think adding the callback pattern to SCAClient is good idea. IMO,
>>> the client should be really lightweight and supporting incoming
>>> connections
>>> is too much in such environment.
>>>
>>
>> Sure, it wouldn't be appropriate for all environments, but the client
>> factory is plugable so if supporting a listener really causes issues
>> then its easy to also have a simpler factory that doesn't support
>> callbacks. But its not necessarily going to add much weight, the
>> client is remote from the domain so it already needs code to handle
>> the communication protocol, the callback listener wont add much more
>> over that. If its an http protocol and jdk6 then that already comes
>> with a built in mini http server.
>>
>>> Why don't you use an SCA composite/component if callback is required?
>>>
>>
>> and you could go further on that path and say why have the SCAClient
>> at all and everything could be an SCA composite/component ;)  Not
>> everyone and everything is SCA yet, the async programing model is one
>> of the interesting features of SCA and IMHO having things like this
>> client being able to support that would help people see the utility of
>> SCA before they've adopted it wholesale.
>>
>>   ...ant
>>
> There is (now) another way for non-SCA code to receive callbacks
> from SCA code.  The public review draft of the WS Binding spec
> defines a WS Binding Callback Protocol for which support is optional.
> Any web service client could use this protocol to call an SCA
> service and receive callbacks, as long as the service has a WS binding
> and the SCA runtime supports this optional protocol.  IMO this is a
> better way to meet this requirement than making the SCAClient API
> more complex by adding an optional callback listener.
>
>  Simon
>

Isn't saying the service could just use a WS binding similar to the
other suggestion of just using a SCA composite/component, in that you
could add a WS binding to any service and then use any regular WS
client so why then have the SCAClient at all? I didn't really expect
this to get into the spec at this late stage, but i do still think it
would be a useful thing to support, so how about we use Tuscany as a
testing ground for it and try adding a TuscanySCAClient interface that
supports callbacks to try it out, you'd get a regular SCAClient and if
you want to do callbacks cast it to a TuscanySCAClient. If we can get
it to work and try it out for a while to see if it makes things
complicated or heavy weight, and if it works ok get it added to a
letter spec release.

   ...ant

Re: SCAClient API spec proposal

Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Thu, Jun 25, 2009 at 5:12 PM, Raymond Feng<en...@gmail.com> wrote:
>> I don't think adding the callback pattern to SCAClient is good idea. IMO,
>> the client should be really lightweight and supporting incoming connections
>> is too much in such environment.
>>
> 
> Sure, it wouldn't be appropriate for all environments, but the client
> factory is plugable so if supporting a listener really causes issues
> then its easy to also have a simpler factory that doesn't support
> callbacks. But its not necessarily going to add much weight, the
> client is remote from the domain so it already needs code to handle
> the communication protocol, the callback listener wont add much more
> over that. If its an http protocol and jdk6 then that already comes
> with a built in mini http server.
> 
>> Why don't you use an SCA composite/component if callback is required?
>>
> 
> and you could go further on that path and say why have the SCAClient
> at all and everything could be an SCA composite/component ;)  Not
> everyone and everything is SCA yet, the async programing model is one
> of the interesting features of SCA and IMHO having things like this
> client being able to support that would help people see the utility of
> SCA before they've adopted it wholesale.
> 
>    ...ant
> 
There is (now) another way for non-SCA code to receive callbacks
from SCA code.  The public review draft of the WS Binding spec
defines a WS Binding Callback Protocol for which support is optional.
Any web service client could use this protocol to call an SCA
service and receive callbacks, as long as the service has a WS binding
and the SCA runtime supports this optional protocol.  IMO this is a
better way to meet this requirement than making the SCAClient API
more complex by adding an optional callback listener.

   Simon



Re: SCAClient API spec proposal

Posted by ant elder <an...@apache.org>.
On Thu, Jun 25, 2009 at 5:12 PM, Raymond Feng<en...@gmail.com> wrote:
> I don't think adding the callback pattern to SCAClient is good idea. IMO,
> the client should be really lightweight and supporting incoming connections
> is too much in such environment.
>

Sure, it wouldn't be appropriate for all environments, but the client
factory is plugable so if supporting a listener really causes issues
then its easy to also have a simpler factory that doesn't support
callbacks. But its not necessarily going to add much weight, the
client is remote from the domain so it already needs code to handle
the communication protocol, the callback listener wont add much more
over that. If its an http protocol and jdk6 then that already comes
with a built in mini http server.

> Why don't you use an SCA composite/component if callback is required?
>

and you could go further on that path and say why have the SCAClient
at all and everything could be an SCA composite/component ;)  Not
everyone and everything is SCA yet, the async programing model is one
of the interesting features of SCA and IMHO having things like this
client being able to support that would help people see the utility of
SCA before they've adopted it wholesale.

   ...ant

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
I don't think adding the callback pattern to SCAClient is good idea. IMO, 
the client should be really lightweight and supporting incoming connections 
is too much in such environment.

Why don't you use an SCA composite/component if callback is required?

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Wednesday, June 24, 2009 11:58 PM
To: <de...@tuscany.apache.org>
Subject: Re: SCAClient API spec proposal

> On Wed, Jun 24, 2009 at 10:47 PM, ant elder<an...@gmail.com> wrote:
>> On Tue, Jun 23, 2009 at 7:14 AM, Mark Combellack<mc...@apache.org> 
>> wrote:
>>
>>
>>>
>>> Hi,
>>>
>>> I am planning to put this on the agenda for the SCA-J call on Monday 
>>> 29th of
>>> June. If anyone has any additional feedback, it would be great to hear 
>>> it
>>> before then so we can consider it too when looking into this issue.
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>
>> Ok, it would make the API simpler to use if the domain uri could be
>> passed in as a String instead of a URI, so users can just do:
>>
>> SCAClientFactory.newInstance("SomeDomainURI")
>>
>> instead of:
>>
>> SCAClientFactory.newInstance(URI.create("SomeDomainURI"))
>>
>>  ...ant
>>
>
> Another would be to support services with bidirectional interfaces.
> Thats one of the interesting features of SCA so its a shame the
> current client doesn't support them. One way to do that could be by
> adding an additional getService method to the SCAClient which includes
> a callback handler parameter:
>
>   <T> T getService(Class<T> interface, String serviceURI, Object
> callbackHandler)
>
> where the callbackHandler object must implement the service's callback
> interface, and the SCAClient impl handles running any listeners and
> threads that are be needed to support that. Might also need to add a
> close() method to SCAClient as well to stop the listeners.
>
>   ...ant 


Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Wed, Jun 24, 2009 at 10:47 PM, ant elder<an...@gmail.com> wrote:
> On Tue, Jun 23, 2009 at 7:14 AM, Mark Combellack<mc...@apache.org> wrote:
>
>
>>
>> Hi,
>>
>> I am planning to put this on the agenda for the SCA-J call on Monday 29th of
>> June. If anyone has any additional feedback, it would be great to hear it
>> before then so we can consider it too when looking into this issue.
>>
>> Thanks,
>>
>> Mark
>>
>
> Ok, it would make the API simpler to use if the domain uri could be
> passed in as a String instead of a URI, so users can just do:
>
> SCAClientFactory.newInstance("SomeDomainURI")
>
> instead of:
>
> SCAClientFactory.newInstance(URI.create("SomeDomainURI"))
>
>  ...ant
>

Another would be to support services with bidirectional interfaces.
Thats one of the interesting features of SCA so its a shame the
current client doesn't support them. One way to do that could be by
adding an additional getService method to the SCAClient which includes
a callback handler parameter:

   <T> T getService(Class<T> interface, String serviceURI, Object
callbackHandler)

where the callbackHandler object must implement the service's callback
interface, and the SCAClient impl handles running any listeners and
threads that are be needed to support that. Might also need to add a
close() method to SCAClient as well to stop the listeners.

   ...ant

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Tue, Jun 23, 2009 at 7:14 AM, Mark Combellack<mc...@apache.org> wrote:


>
> Hi,
>
> I am planning to put this on the agenda for the SCA-J call on Monday 29th of
> June. If anyone has any additional feedback, it would be great to hear it
> before then so we can consider it too when looking into this issue.
>
> Thanks,
>
> Mark
>

Ok, it would make the API simpler to use if the domain uri could be
passed in as a String instead of a URI, so users can just do:

SCAClientFactory.newInstance("SomeDomainURI")

instead of:

SCAClientFactory.newInstance(URI.create("SomeDomainURI"))

  ...ant

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Tue, Jun 23, 2009 at 7:14 AM, Mark Combellack<mc...@apache.org> wrote:


>
> Hi,
>
> I am planning to put this on the agenda for the SCA-J call on Monday 29th of
> June. If anyone has any additional feedback, it would be great to hear it
> before then so we can consider it too when looking into this issue.
>
> Thanks,
>
> Mark
>

FYI, some updates to this yesterday at:
http://lists.oasis-open.org/archives/sca-j/200906/msg00157.html

The API now looks like:

SCAClientFactory factory =
SCAClientFactory.newInstance(URI.create("someDomainURI"));
SomeService service = factory.getService(SomeService.class, "SomeServiceURI");

So thats a big improvement.

Still no call back support :( but that wasn't a surprise.

It still uses a URI type for the domainURI on the newInstance call, is
there a reason the suggestion to use a String wasn't done? It would be
simpler to use a String and seems a bit inconsistent to have the
serviceURI be a String but the domainURI be a URI.

Also, the name "SCAClientFactory" doesn't feel right now that the
factory isn't creating SCAClients anymore, so wouldn't it be better to
have it named  something to do with service or service proxys to match
what it creates and its single getService method? Or to have got rid
of  SCAClientFactory instead of SCAClient so it became:

SCAClient scaClient = SCAClient.newInstance(URI.create("someDomainURI"));
SomeService service = scaClient.getService(SomeService.class, "SomeServiceURI");

and then when you look at the two lines together like this and read
that the spec says the service URI is relative to the domain URI
couldn't that be simplified to just use a single uri for them both -
domainURI/serviceURI? You could even simplify it to have a static
helper method that under the covers still uses the newInstance and
SCAClientFactoryFinder but users can do just:

SomeService service = SCAClient.getService(SomeService.class,
"someDomainURI/SomeServiceURI");

   ...ant

Re: SCAClient API spec proposal

Posted by Mark Combellack <mc...@apache.org>.
ant elder wrote:
> On Thu, May 14, 2009 at 3:45 PM, ant elder<an...@gmail.com> wrote:
>   
>> On Thu, May 14, 2009 at 3:15 PM, Simon Nash <na...@apache.org> wrote:
>>     
>>> Thanks for this proposal.  It helps to see something concrete.
>>> See questions/comments inline below.
>>>
>>>  Simon
>>>
>>> ant elder wrote:
>>>       
>>>> On Thu, May 14, 2009 at 1:30 PM, Simon Nash <na...@apache.org> wrote:
>>>>         
>>>>> ant elder wrote:
>>>>>           
>>>>>> On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com>
>>>>>> wrote:
>>>>>>             
>>>>>>> Hi Simon
>>>>>>>
>>>>>>> It's not clear to me from your answer whether you think that
>>>>>>> SCAClientFactory is or isn't intended to return an SCAClient
>>>>>>> implementation appropriate for the domain you which to retrieve
>>>>>>> services from.
>>>>>>>
>>>>>>>               
>>>>> It is able to do this, but the user needs to set things up
>>>>> correctly to ensure that this happens.
>>>>>
>>>>>           
>>>>>>>> The SCAClientFactory.newInstance() call uses various mechanisms
>>>>>>>> to identify which vendor-specific SCAClient implementation to
>>>>>>>> return.  The returned SCAClient object will be capable of locating
>>>>>>>> all domains that use the same vendor implementation that created
>>>>>>>> the SCAClient object.
>>>>>>>>                 
>>>>>>> Suggests to me that you think it should
>>>>>>>
>>>>>>>               
>>>>> Yes, this is what the current proposal says.
>>>>>
>>>>>           
>>>>>>>> The alternative form suggested above doesn't work because it would
>>>>>>>> require the SCAClientFactory to maintain some global knowledge of
>>>>>>>> which domains use which vendor implementations, and return the
>>>>>>>> appropriate SCAClient vendor implementation for the domain specified.
>>>>>>>>                 
>>>>>>> Suggests to me that you think it shouldn't.
>>>>>>>
>>>>>>>               
>>>>> Sorry that I wan't clear.  I was trying to explain that automating
>>>>> the selection of the correct vendor implementation for a specific
>>>>> domain can't be supported by the mechanisms in the current spec
>>>>> proposal, because this would require SCAClientFactory to have global
>>>>> knowledge of available domains and the vendor implementations that
>>>>> those domains require.
>>>>>
>>>>>           
>>>>>>> There are two thing going on here.
>>>>>>>
>>>>>>> 1/ establish what sort of client you need - depends on the technology
>>>>>>> of the domain you wish to talk to
>>>>>>>               
>>>>> This is what newInstance() does.  It doesn't require any swapping
>>>>> on the classpath, because the SCAClientFactory is able to use
>>>>> properties and a class loader object to find the correct vendor
>>>>> implementation.  The newInstance() call invokes standard SCA code
>>>>> that is not vendor specific.
>>>>>
>>>>>           
>>>>>>> 2/ establish precise domain you need
>>>>>>>
>>>>>>>               
>>>>> This is what getService() does.  The getService() call invokes
>>>>> vendor-specific code, which is presumed to be able to handle any
>>>>> domains that were created by the same vendor-specific code.
>>>>>
>>>>>           
>>>>>>> 1/ could certainly be achieved by swapping in and out the specific
>>>>>>> factory implementation you have on the application classpath. Hence
>>>>>>> you don't need a domain ID to choose as the choice is made for you
>>>>>>> before the code runs. However I don't see why having the domain ID
>>>>>>> does any harm here in that it would allow Tuscany to make step 2
>>>>>>> transparent. Unless the argument here is that the Assembly spec
>>>>>>> doesn't define what a domain ID looks like so we can't type it in the
>>>>>>> interface.
>>>>>>>               
>>>>> No, that isn't the reason.  A domain ID is just a URI.  In order to
>>>>> allow this to be specified in step 1, it would be necessary to extend
>>>>> the role of SCAClientFactory to act as a global registry of domain IDs
>>>>> and their corresponding vendor client implementations.  This isn't
>>>>> part of the current proposal, and I don't think it's a good idea
>>>>> to add this extra complexity within the SCA standardized code.
>>>>>
>>>>>           
>>>> I don't what to debate this too much as I know the proposal is still
>>>> being worked on by the spec group, but IMHO this seems like a better
>>>> approach so i will show that its not too hard to do at all:
>>>>
>>>> Add a new abstract method to org.oasisopen.sca.client.SCAClientFactory
>>>> to test if the vendor factory supports a domain:
>>>>
>>>>    protected abstract boolean supportsDomain(URI domainURI);
>>>>
>>>>         
>>> I understand this part.
>>>
>>>       
>>>> Change the org.oasisopen.sca.client.SCAClientFactoryFinder method to
>>>> take the domainURI and return an array of SCAClientFactorys:
>>>>
>>>>    public static SCAClientFactory[] find(URI domainURI, Properties
>>>> properties, ClassLoader classLoader) {
>>>>
>>>>         
>>> I don't understand this.  How (and why) does this method return an
>>> array of SCAClientFactory objects?
>>>
>>>       
>>>> And then update the existing
>>>> org.oasisopen.sca.client.SCAClientFactoryFinder find method to use
>>>> that new supportsDomain method:
>>>>
>>>>         
>>> It seems the suggestion is to have two find() methods, one returning
>>> a single factory object, and the other returning an array of factory
>>> objects.  Why are both of these needed?
>>>
>>>       
>>>>        final String[] factoryImplClassNames =
>>>> discoverProviderFactoryImplClass(properties, classLoader);
>>>>         
>>> There would be additional changes needed to make this work.  The
>>> discoverProviderFactoryImplClass method currently returns a single
>>> vendor-specific factory class name that is found by searching the
>>> properties object and/or META-INF/services.  Returning an array
>>> of class names would require extending the property value and the
>>> META-INF/services value to be a list of candidate class names
>>> instead of a single class name.
>>>
>>>       
>>>>        for (String factoryImplClassName : factoryImplClassNames) {
>>>>           final Class<? extends SCAClientFactory> factoryImplClass =
>>>> loadProviderFactoryClass(factoryImplClassName, classLoader);
>>>>         
>>> This assumes that a single class loader is used for all the factory
>>> class names.  I don't think this limitation is acceptable.  The current
>>> design allows each factory class name to have its own class loader.
>>>
>>>       
>>>>           final SCAClientFactory factory =
>>>> instantiateSCAClientFactoryClass(factoryImplClass);
>>>>           if (factory.supportsDomain(domainURI)) {
>>>>              return factory;
>>>>           }
>>>>        }
>>>>         
>>> This could instantiate factories that are never returned because
>>> they don't support the domain.  This would be a problem if the
>>> instantiation has any side effects or allocates memory.
>>>
>>>       
>>>>        throw new NoSuchDomainException("No such domain or no
>>>> available SCAClientFactory");
>>>>
>>>> Thats it. The SCAClientFactory doesn't need to act as a global
>>>> registry of domain IDs because its down to the vendor specific
>>>> SCAClientFactory implementation to decide how to determine if it
>>>> supports a domain uri. They could see if that id exists in some local
>>>> table or make a remote call to a vendor domain manager or whatever
>>>> else appropriate for their domain implementation.
>>>>
>>>>         
>>> This part should work OK.
>>>
>>>  Simon
>>>
>>>       
>>>>   ...ant
>>>>
>>>>
>>>>         
>> I'd hacked this up in the tuscany sca-api module so the diff for those
>> changes are at:
>> http://people.apache.org/~antelder/tuscany/sca-api-diff.txt
>>
>> The main change and how it works is that
>> checkMETAINFServicesForClassName is changed to use the Classloader
>> getResources method instead of getResource so that it gets all the
>> available meta-inf/service files instead of just the first one.
>>
>> I think the rest of your comments are probably right. It could also be
>> updated to support multiple class names in the properties, but like
>> you say it uses the one classloader and may be instantiating multiple
>> factories which may not get used.
>>
>>   ...ant
>>
>>     
>
> Looks like the spec folks are now looking at moving the domain name
> from the getService method to the newInstance method, see:
> http://lists.oasis-open.org/archives/sca-j/200906/msg00126.html
>
> Yay :)
>
>  ...ant
>   
Hi,

I am planning to put this on the agenda for the SCA-J call on Monday 
29th of June. If anyone has any additional feedback, it would be great 
to hear it before then so we can consider it too when looking into this 
issue.

Thanks,

Mark

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Thu, May 14, 2009 at 3:45 PM, ant elder<an...@gmail.com> wrote:
> On Thu, May 14, 2009 at 3:15 PM, Simon Nash <na...@apache.org> wrote:
>> Thanks for this proposal.  It helps to see something concrete.
>> See questions/comments inline below.
>>
>>  Simon
>>
>> ant elder wrote:
>>>
>>> On Thu, May 14, 2009 at 1:30 PM, Simon Nash <na...@apache.org> wrote:
>>>>
>>>> ant elder wrote:
>>>>>
>>>>> On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi Simon
>>>>>>
>>>>>> It's not clear to me from your answer whether you think that
>>>>>> SCAClientFactory is or isn't intended to return an SCAClient
>>>>>> implementation appropriate for the domain you which to retrieve
>>>>>> services from.
>>>>>>
>>>> It is able to do this, but the user needs to set things up
>>>> correctly to ensure that this happens.
>>>>
>>>>>>> The SCAClientFactory.newInstance() call uses various mechanisms
>>>>>>> to identify which vendor-specific SCAClient implementation to
>>>>>>> return.  The returned SCAClient object will be capable of locating
>>>>>>> all domains that use the same vendor implementation that created
>>>>>>> the SCAClient object.
>>>>>>
>>>>>> Suggests to me that you think it should
>>>>>>
>>>> Yes, this is what the current proposal says.
>>>>
>>>>>>> The alternative form suggested above doesn't work because it would
>>>>>>> require the SCAClientFactory to maintain some global knowledge of
>>>>>>> which domains use which vendor implementations, and return the
>>>>>>> appropriate SCAClient vendor implementation for the domain specified.
>>>>>>
>>>>>> Suggests to me that you think it shouldn't.
>>>>>>
>>>> Sorry that I wan't clear.  I was trying to explain that automating
>>>> the selection of the correct vendor implementation for a specific
>>>> domain can't be supported by the mechanisms in the current spec
>>>> proposal, because this would require SCAClientFactory to have global
>>>> knowledge of available domains and the vendor implementations that
>>>> those domains require.
>>>>
>>>>>> There are two thing going on here.
>>>>>>
>>>>>> 1/ establish what sort of client you need - depends on the technology
>>>>>> of the domain you wish to talk to
>>>>
>>>> This is what newInstance() does.  It doesn't require any swapping
>>>> on the classpath, because the SCAClientFactory is able to use
>>>> properties and a class loader object to find the correct vendor
>>>> implementation.  The newInstance() call invokes standard SCA code
>>>> that is not vendor specific.
>>>>
>>>>>> 2/ establish precise domain you need
>>>>>>
>>>> This is what getService() does.  The getService() call invokes
>>>> vendor-specific code, which is presumed to be able to handle any
>>>> domains that were created by the same vendor-specific code.
>>>>
>>>>>> 1/ could certainly be achieved by swapping in and out the specific
>>>>>> factory implementation you have on the application classpath. Hence
>>>>>> you don't need a domain ID to choose as the choice is made for you
>>>>>> before the code runs. However I don't see why having the domain ID
>>>>>> does any harm here in that it would allow Tuscany to make step 2
>>>>>> transparent. Unless the argument here is that the Assembly spec
>>>>>> doesn't define what a domain ID looks like so we can't type it in the
>>>>>> interface.
>>>>
>>>> No, that isn't the reason.  A domain ID is just a URI.  In order to
>>>> allow this to be specified in step 1, it would be necessary to extend
>>>> the role of SCAClientFactory to act as a global registry of domain IDs
>>>> and their corresponding vendor client implementations.  This isn't
>>>> part of the current proposal, and I don't think it's a good idea
>>>> to add this extra complexity within the SCA standardized code.
>>>>
>>>
>>> I don't what to debate this too much as I know the proposal is still
>>> being worked on by the spec group, but IMHO this seems like a better
>>> approach so i will show that its not too hard to do at all:
>>>
>>> Add a new abstract method to org.oasisopen.sca.client.SCAClientFactory
>>> to test if the vendor factory supports a domain:
>>>
>>>    protected abstract boolean supportsDomain(URI domainURI);
>>>
>> I understand this part.
>>
>>> Change the org.oasisopen.sca.client.SCAClientFactoryFinder method to
>>> take the domainURI and return an array of SCAClientFactorys:
>>>
>>>    public static SCAClientFactory[] find(URI domainURI, Properties
>>> properties, ClassLoader classLoader) {
>>>
>> I don't understand this.  How (and why) does this method return an
>> array of SCAClientFactory objects?
>>
>>> And then update the existing
>>> org.oasisopen.sca.client.SCAClientFactoryFinder find method to use
>>> that new supportsDomain method:
>>>
>> It seems the suggestion is to have two find() methods, one returning
>> a single factory object, and the other returning an array of factory
>> objects.  Why are both of these needed?
>>
>>>        final String[] factoryImplClassNames =
>>> discoverProviderFactoryImplClass(properties, classLoader);
>>
>>>
>> There would be additional changes needed to make this work.  The
>> discoverProviderFactoryImplClass method currently returns a single
>> vendor-specific factory class name that is found by searching the
>> properties object and/or META-INF/services.  Returning an array
>> of class names would require extending the property value and the
>> META-INF/services value to be a list of candidate class names
>> instead of a single class name.
>>
>>>        for (String factoryImplClassName : factoryImplClassNames) {
>>>           final Class<? extends SCAClientFactory> factoryImplClass =
>>> loadProviderFactoryClass(factoryImplClassName, classLoader);
>>
>>>
>> This assumes that a single class loader is used for all the factory
>> class names.  I don't think this limitation is acceptable.  The current
>> design allows each factory class name to have its own class loader.
>>
>>>           final SCAClientFactory factory =
>>> instantiateSCAClientFactoryClass(factoryImplClass);
>>>           if (factory.supportsDomain(domainURI)) {
>>>              return factory;
>>>           }
>>>        }
>>
>>>
>> This could instantiate factories that are never returned because
>> they don't support the domain.  This would be a problem if the
>> instantiation has any side effects or allocates memory.
>>
>>>        throw new NoSuchDomainException("No such domain or no
>>> available SCAClientFactory");
>>>
>>> Thats it. The SCAClientFactory doesn't need to act as a global
>>> registry of domain IDs because its down to the vendor specific
>>> SCAClientFactory implementation to decide how to determine if it
>>> supports a domain uri. They could see if that id exists in some local
>>> table or make a remote call to a vendor domain manager or whatever
>>> else appropriate for their domain implementation.
>>>
>> This part should work OK.
>>
>>  Simon
>>
>>>   ...ant
>>>
>>>
>>
>
> I'd hacked this up in the tuscany sca-api module so the diff for those
> changes are at:
> http://people.apache.org/~antelder/tuscany/sca-api-diff.txt
>
> The main change and how it works is that
> checkMETAINFServicesForClassName is changed to use the Classloader
> getResources method instead of getResource so that it gets all the
> available meta-inf/service files instead of just the first one.
>
> I think the rest of your comments are probably right. It could also be
> updated to support multiple class names in the properties, but like
> you say it uses the one classloader and may be instantiating multiple
> factories which may not get used.
>
>   ...ant
>

Looks like the spec folks are now looking at moving the domain name
from the getService method to the newInstance method, see:
http://lists.oasis-open.org/archives/sca-j/200906/msg00126.html

Yay :)

 ...ant

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Thu, May 14, 2009 at 3:15 PM, Simon Nash <na...@apache.org> wrote:
> Thanks for this proposal.  It helps to see something concrete.
> See questions/comments inline below.
>
>  Simon
>
> ant elder wrote:
>>
>> On Thu, May 14, 2009 at 1:30 PM, Simon Nash <na...@apache.org> wrote:
>>>
>>> ant elder wrote:
>>>>
>>>> On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>>>
>>>>> Hi Simon
>>>>>
>>>>> It's not clear to me from your answer whether you think that
>>>>> SCAClientFactory is or isn't intended to return an SCAClient
>>>>> implementation appropriate for the domain you which to retrieve
>>>>> services from.
>>>>>
>>> It is able to do this, but the user needs to set things up
>>> correctly to ensure that this happens.
>>>
>>>>>> The SCAClientFactory.newInstance() call uses various mechanisms
>>>>>> to identify which vendor-specific SCAClient implementation to
>>>>>> return.  The returned SCAClient object will be capable of locating
>>>>>> all domains that use the same vendor implementation that created
>>>>>> the SCAClient object.
>>>>>
>>>>> Suggests to me that you think it should
>>>>>
>>> Yes, this is what the current proposal says.
>>>
>>>>>> The alternative form suggested above doesn't work because it would
>>>>>> require the SCAClientFactory to maintain some global knowledge of
>>>>>> which domains use which vendor implementations, and return the
>>>>>> appropriate SCAClient vendor implementation for the domain specified.
>>>>>
>>>>> Suggests to me that you think it shouldn't.
>>>>>
>>> Sorry that I wan't clear.  I was trying to explain that automating
>>> the selection of the correct vendor implementation for a specific
>>> domain can't be supported by the mechanisms in the current spec
>>> proposal, because this would require SCAClientFactory to have global
>>> knowledge of available domains and the vendor implementations that
>>> those domains require.
>>>
>>>>> There are two thing going on here.
>>>>>
>>>>> 1/ establish what sort of client you need - depends on the technology
>>>>> of the domain you wish to talk to
>>>
>>> This is what newInstance() does.  It doesn't require any swapping
>>> on the classpath, because the SCAClientFactory is able to use
>>> properties and a class loader object to find the correct vendor
>>> implementation.  The newInstance() call invokes standard SCA code
>>> that is not vendor specific.
>>>
>>>>> 2/ establish precise domain you need
>>>>>
>>> This is what getService() does.  The getService() call invokes
>>> vendor-specific code, which is presumed to be able to handle any
>>> domains that were created by the same vendor-specific code.
>>>
>>>>> 1/ could certainly be achieved by swapping in and out the specific
>>>>> factory implementation you have on the application classpath. Hence
>>>>> you don't need a domain ID to choose as the choice is made for you
>>>>> before the code runs. However I don't see why having the domain ID
>>>>> does any harm here in that it would allow Tuscany to make step 2
>>>>> transparent. Unless the argument here is that the Assembly spec
>>>>> doesn't define what a domain ID looks like so we can't type it in the
>>>>> interface.
>>>
>>> No, that isn't the reason.  A domain ID is just a URI.  In order to
>>> allow this to be specified in step 1, it would be necessary to extend
>>> the role of SCAClientFactory to act as a global registry of domain IDs
>>> and their corresponding vendor client implementations.  This isn't
>>> part of the current proposal, and I don't think it's a good idea
>>> to add this extra complexity within the SCA standardized code.
>>>
>>
>> I don't what to debate this too much as I know the proposal is still
>> being worked on by the spec group, but IMHO this seems like a better
>> approach so i will show that its not too hard to do at all:
>>
>> Add a new abstract method to org.oasisopen.sca.client.SCAClientFactory
>> to test if the vendor factory supports a domain:
>>
>>    protected abstract boolean supportsDomain(URI domainURI);
>>
> I understand this part.
>
>> Change the org.oasisopen.sca.client.SCAClientFactoryFinder method to
>> take the domainURI and return an array of SCAClientFactorys:
>>
>>    public static SCAClientFactory[] find(URI domainURI, Properties
>> properties, ClassLoader classLoader) {
>>
> I don't understand this.  How (and why) does this method return an
> array of SCAClientFactory objects?
>
>> And then update the existing
>> org.oasisopen.sca.client.SCAClientFactoryFinder find method to use
>> that new supportsDomain method:
>>
> It seems the suggestion is to have two find() methods, one returning
> a single factory object, and the other returning an array of factory
> objects.  Why are both of these needed?
>
>>        final String[] factoryImplClassNames =
>> discoverProviderFactoryImplClass(properties, classLoader);
>
>>
> There would be additional changes needed to make this work.  The
> discoverProviderFactoryImplClass method currently returns a single
> vendor-specific factory class name that is found by searching the
> properties object and/or META-INF/services.  Returning an array
> of class names would require extending the property value and the
> META-INF/services value to be a list of candidate class names
> instead of a single class name.
>
>>        for (String factoryImplClassName : factoryImplClassNames) {
>>           final Class<? extends SCAClientFactory> factoryImplClass =
>> loadProviderFactoryClass(factoryImplClassName, classLoader);
>
>>
> This assumes that a single class loader is used for all the factory
> class names.  I don't think this limitation is acceptable.  The current
> design allows each factory class name to have its own class loader.
>
>>           final SCAClientFactory factory =
>> instantiateSCAClientFactoryClass(factoryImplClass);
>>           if (factory.supportsDomain(domainURI)) {
>>              return factory;
>>           }
>>        }
>
>>
> This could instantiate factories that are never returned because
> they don't support the domain.  This would be a problem if the
> instantiation has any side effects or allocates memory.
>
>>        throw new NoSuchDomainException("No such domain or no
>> available SCAClientFactory");
>>
>> Thats it. The SCAClientFactory doesn't need to act as a global
>> registry of domain IDs because its down to the vendor specific
>> SCAClientFactory implementation to decide how to determine if it
>> supports a domain uri. They could see if that id exists in some local
>> table or make a remote call to a vendor domain manager or whatever
>> else appropriate for their domain implementation.
>>
> This part should work OK.
>
>  Simon
>
>>   ...ant
>>
>>
>

I'd hacked this up in the tuscany sca-api module so the diff for those
changes are at:
http://people.apache.org/~antelder/tuscany/sca-api-diff.txt

The main change and how it works is that
checkMETAINFServicesForClassName is changed to use the Classloader
getResources method instead of getResource so that it gets all the
available meta-inf/service files instead of just the first one.

I think the rest of your comments are probably right. It could also be
updated to support multiple class names in the properties, but like
you say it uses the one classloader and may be instantiating multiple
factories which may not get used.

   ...ant

Re: SCAClient API spec proposal

Posted by Simon Nash <na...@apache.org>.
Thanks for this proposal.  It helps to see something concrete.
See questions/comments inline below.

   Simon

ant elder wrote:
> On Thu, May 14, 2009 at 1:30 PM, Simon Nash <na...@apache.org> wrote:
>> ant elder wrote:
>>> On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>> Hi Simon
>>>>
>>>> It's not clear to me from your answer whether you think that
>>>> SCAClientFactory is or isn't intended to return an SCAClient
>>>> implementation appropriate for the domain you which to retrieve
>>>> services from.
>>>>
>> It is able to do this, but the user needs to set things up
>> correctly to ensure that this happens.
>>
>>>>> The SCAClientFactory.newInstance() call uses various mechanisms
>>>>> to identify which vendor-specific SCAClient implementation to
>>>>> return.  The returned SCAClient object will be capable of locating
>>>>> all domains that use the same vendor implementation that created
>>>>> the SCAClient object.
>>>> Suggests to me that you think it should
>>>>
>> Yes, this is what the current proposal says.
>>
>>>>> The alternative form suggested above doesn't work because it would
>>>>> require the SCAClientFactory to maintain some global knowledge of
>>>>> which domains use which vendor implementations, and return the
>>>>> appropriate SCAClient vendor implementation for the domain specified.
>>>> Suggests to me that you think it shouldn't.
>>>>
>> Sorry that I wan't clear.  I was trying to explain that automating
>> the selection of the correct vendor implementation for a specific
>> domain can't be supported by the mechanisms in the current spec
>> proposal, because this would require SCAClientFactory to have global
>> knowledge of available domains and the vendor implementations that
>> those domains require.
>>
>>>> There are two thing going on here.
>>>>
>>>> 1/ establish what sort of client you need - depends on the technology
>>>> of the domain you wish to talk to
>> This is what newInstance() does.  It doesn't require any swapping
>> on the classpath, because the SCAClientFactory is able to use
>> properties and a class loader object to find the correct vendor
>> implementation.  The newInstance() call invokes standard SCA code
>> that is not vendor specific.
>>
>>>> 2/ establish precise domain you need
>>>>
>> This is what getService() does.  The getService() call invokes
>> vendor-specific code, which is presumed to be able to handle any
>> domains that were created by the same vendor-specific code.
>>
>>>> 1/ could certainly be achieved by swapping in and out the specific
>>>> factory implementation you have on the application classpath. Hence
>>>> you don't need a domain ID to choose as the choice is made for you
>>>> before the code runs. However I don't see why having the domain ID
>>>> does any harm here in that it would allow Tuscany to make step 2
>>>> transparent. Unless the argument here is that the Assembly spec
>>>> doesn't define what a domain ID looks like so we can't type it in the
>>>> interface.
>> No, that isn't the reason.  A domain ID is just a URI.  In order to
>> allow this to be specified in step 1, it would be necessary to extend
>> the role of SCAClientFactory to act as a global registry of domain IDs
>> and their corresponding vendor client implementations.  This isn't
>> part of the current proposal, and I don't think it's a good idea
>> to add this extra complexity within the SCA standardized code.
>>
> 
> I don't what to debate this too much as I know the proposal is still
> being worked on by the spec group, but IMHO this seems like a better
> approach so i will show that its not too hard to do at all:
> 
> Add a new abstract method to org.oasisopen.sca.client.SCAClientFactory
> to test if the vendor factory supports a domain:
> 
>     protected abstract boolean supportsDomain(URI domainURI);
> 
I understand this part.

> Change the org.oasisopen.sca.client.SCAClientFactoryFinder method to
> take the domainURI and return an array of SCAClientFactorys:
> 
>     public static SCAClientFactory[] find(URI domainURI, Properties
> properties, ClassLoader classLoader) {
> 
I don't understand this.  How (and why) does this method return an
array of SCAClientFactory objects?

> And then update the existing
> org.oasisopen.sca.client.SCAClientFactoryFinder find method to use
> that new supportsDomain method:
> 
It seems the suggestion is to have two find() methods, one returning
a single factory object, and the other returning an array of factory
objects.  Why are both of these needed?

>         final String[] factoryImplClassNames =
> discoverProviderFactoryImplClass(properties, classLoader);
 >
There would be additional changes needed to make this work.  The
discoverProviderFactoryImplClass method currently returns a single
vendor-specific factory class name that is found by searching the
properties object and/or META-INF/services.  Returning an array
of class names would require extending the property value and the
META-INF/services value to be a list of candidate class names
instead of a single class name.

>         for (String factoryImplClassName : factoryImplClassNames) {
>            final Class<? extends SCAClientFactory> factoryImplClass =
> loadProviderFactoryClass(factoryImplClassName, classLoader);
 >
This assumes that a single class loader is used for all the factory
class names.  I don't think this limitation is acceptable.  The current
design allows each factory class name to have its own class loader.

>            final SCAClientFactory factory =
> instantiateSCAClientFactoryClass(factoryImplClass);
>            if (factory.supportsDomain(domainURI)) {
>               return factory;
>            }
>         }
 >
This could instantiate factories that are never returned because
they don't support the domain.  This would be a problem if the
instantiation has any side effects or allocates memory.

>         throw new NoSuchDomainException("No such domain or no
> available SCAClientFactory");
> 
> Thats it. The SCAClientFactory doesn't need to act as a global
> registry of domain IDs because its down to the vendor specific
> SCAClientFactory implementation to decide how to determine if it
> supports a domain uri. They could see if that id exists in some local
> table or make a remote call to a vendor domain manager or whatever
> else appropriate for their domain implementation.
>
This part should work OK.

   Simon

>    ...ant
> 
> 



Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Thu, May 14, 2009 at 1:30 PM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>>> Hi Simon
>>>
>>> It's not clear to me from your answer whether you think that
>>> SCAClientFactory is or isn't intended to return an SCAClient
>>> implementation appropriate for the domain you which to retrieve
>>> services from.
>>>
> It is able to do this, but the user needs to set things up
> correctly to ensure that this happens.
>
>>>> The SCAClientFactory.newInstance() call uses various mechanisms
>>>> to identify which vendor-specific SCAClient implementation to
>>>> return.  The returned SCAClient object will be capable of locating
>>>> all domains that use the same vendor implementation that created
>>>> the SCAClient object.
>>>
>>> Suggests to me that you think it should
>>>
> Yes, this is what the current proposal says.
>
>>>> The alternative form suggested above doesn't work because it would
>>>> require the SCAClientFactory to maintain some global knowledge of
>>>> which domains use which vendor implementations, and return the
>>>> appropriate SCAClient vendor implementation for the domain specified.
>>>
>>> Suggests to me that you think it shouldn't.
>>>
> Sorry that I wan't clear.  I was trying to explain that automating
> the selection of the correct vendor implementation for a specific
> domain can't be supported by the mechanisms in the current spec
> proposal, because this would require SCAClientFactory to have global
> knowledge of available domains and the vendor implementations that
> those domains require.
>
>>>
>>> There are two thing going on here.
>>>
>>> 1/ establish what sort of client you need - depends on the technology
>>> of the domain you wish to talk to
>
>>
> This is what newInstance() does.  It doesn't require any swapping
> on the classpath, because the SCAClientFactory is able to use
> properties and a class loader object to find the correct vendor
> implementation.  The newInstance() call invokes standard SCA code
> that is not vendor specific.
>
>>> 2/ establish precise domain you need
>>>
> This is what getService() does.  The getService() call invokes
> vendor-specific code, which is presumed to be able to handle any
> domains that were created by the same vendor-specific code.
>
>>> 1/ could certainly be achieved by swapping in and out the specific
>>> factory implementation you have on the application classpath. Hence
>>> you don't need a domain ID to choose as the choice is made for you
>>> before the code runs. However I don't see why having the domain ID
>>> does any harm here in that it would allow Tuscany to make step 2
>>> transparent. Unless the argument here is that the Assembly spec
>>> doesn't define what a domain ID looks like so we can't type it in the
>>> interface.
>
>>
> No, that isn't the reason.  A domain ID is just a URI.  In order to
> allow this to be specified in step 1, it would be necessary to extend
> the role of SCAClientFactory to act as a global registry of domain IDs
> and their corresponding vendor client implementations.  This isn't
> part of the current proposal, and I don't think it's a good idea
> to add this extra complexity within the SCA standardized code.
>

I don't what to debate this too much as I know the proposal is still
being worked on by the spec group, but IMHO this seems like a better
approach so i will show that its not too hard to do at all:

Add a new abstract method to org.oasisopen.sca.client.SCAClientFactory
to test if the vendor factory supports a domain:

    protected abstract boolean supportsDomain(URI domainURI);

Change the org.oasisopen.sca.client.SCAClientFactoryFinder method to
take the domainURI and return an array of SCAClientFactorys:

    public static SCAClientFactory[] find(URI domainURI, Properties
properties, ClassLoader classLoader) {

And then update the existing
org.oasisopen.sca.client.SCAClientFactoryFinder find method to use
that new supportsDomain method:

        final String[] factoryImplClassNames =
discoverProviderFactoryImplClass(properties, classLoader);
        for (String factoryImplClassName : factoryImplClassNames) {
           final Class<? extends SCAClientFactory> factoryImplClass =
loadProviderFactoryClass(factoryImplClassName, classLoader);
           final SCAClientFactory factory =
instantiateSCAClientFactoryClass(factoryImplClass);
           if (factory.supportsDomain(domainURI)) {
              return factory;
           }
        }
        throw new NoSuchDomainException("No such domain or no
available SCAClientFactory");

Thats it. The SCAClientFactory doesn't need to act as a global
registry of domain IDs because its down to the vendor specific
SCAClientFactory implementation to decide how to determine if it
supports a domain uri. They could see if that id exists in some local
table or make a remote call to a vendor domain manager or whatever
else appropriate for their domain implementation.

   ...ant

Re: SCAClient API spec proposal

Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com> wrote:
>> Hi Simon
>>
>> It's not clear to me from your answer whether you think that
>> SCAClientFactory is or isn't intended to return an SCAClient
>> implementation appropriate for the domain you which to retrieve
>> services from.
>>
It is able to do this, but the user needs to set things up
correctly to ensure that this happens.

>>> The SCAClientFactory.newInstance() call uses various mechanisms
>>> to identify which vendor-specific SCAClient implementation to
>>> return.  The returned SCAClient object will be capable of locating
>>> all domains that use the same vendor implementation that created
>>> the SCAClient object.
>> Suggests to me that you think it should
>>
Yes, this is what the current proposal says.

>>> The alternative form suggested above doesn't work because it would
>>> require the SCAClientFactory to maintain some global knowledge of
>>> which domains use which vendor implementations, and return the
>>> appropriate SCAClient vendor implementation for the domain specified.
>> Suggests to me that you think it shouldn't.
>>
Sorry that I wan't clear.  I was trying to explain that automating
the selection of the correct vendor implementation for a specific
domain can't be supported by the mechanisms in the current spec
proposal, because this would require SCAClientFactory to have global
knowledge of available domains and the vendor implementations that
those domains require.

>>
>> There are two thing going on here.
>>
>> 1/ establish what sort of client you need - depends on the technology
>> of the domain you wish to talk to
 >
This is what newInstance() does.  It doesn't require any swapping
on the classpath, because the SCAClientFactory is able to use
properties and a class loader object to find the correct vendor
implementation.  The newInstance() call invokes standard SCA code
that is not vendor specific.

>> 2/ establish precise domain you need
>>
This is what getService() does.  The getService() call invokes
vendor-specific code, which is presumed to be able to handle any
domains that were created by the same vendor-specific code.

>> 1/ could certainly be achieved by swapping in and out the specific
>> factory implementation you have on the application classpath. Hence
>> you don't need a domain ID to choose as the choice is made for you
>> before the code runs. However I don't see why having the domain ID
>> does any harm here in that it would allow Tuscany to make step 2
>> transparent. Unless the argument here is that the Assembly spec
>> doesn't define what a domain ID looks like so we can't type it in the
>> interface.
 >
No, that isn't the reason.  A domain ID is just a URI.  In order to
allow this to be specified in step 1, it would be necessary to extend
the role of SCAClientFactory to act as a global registry of domain IDs
and their corresponding vendor client implementations.  This isn't
part of the current proposal, and I don't think it's a good idea
to add this extra complexity within the SCA standardized code.

>> 2/ needs the domain ID
>>
>> Simon
>>
> 
> Right thats what i don't understand too.
> 
> The only way i see it would be possible with the current API to have
> some generic code talk to different vendor domains is by swapping out
> the vendor specific sca client implementation jars from the classpath.
> 
There is an ongoing discussion in the spec group about how this
should be supported, and how much flexibility to use multiple
vendor implementations concurrently should be provided.

On the specific point about different vendor-specific jars, this
would not be necessary.  Each vendor implementation can use its
own package name, so it would be posssible to have multiple
vendor implementations on the classpath at the same time.
The SCAClientFactory uses properties and an optional class loader
to locate the particular vendor implementation that it should use.

> On the other hand if the SCAClientFactory newInstance was given the
> domain URI then you could have all the differnet vendor sca client
> impl jars on the classpath together and the SCAClientFactory SPI could
> be coded to find all those sca client implementation providers and ask
> them if they can talk to the domain the URI identifies and then use
> the one that can to create the SCAClient instance.
> 
The spec proposal does not include this capability.  Providing this
would require adding a lot more mechanism to SCAClientFactory and the
SCAClient implementation providers, with the SCAClientFactory acting
as a global registry and using new SPIs to allow it to talk to
SCAClient implementation providers to find the one that should be used.

   Simon

>    ...ant
> 
> 



Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Wed, May 13, 2009 at 3:20 PM, Simon Laws <si...@googlemail.com> wrote:
> Hi Simon
>
> It's not clear to me from your answer whether you think that
> SCAClientFactory is or isn't intended to return an SCAClient
> implementation appropriate for the domain you which to retrieve
> services from.
>
>> The SCAClientFactory.newInstance() call uses various mechanisms
>> to identify which vendor-specific SCAClient implementation to
>> return.  The returned SCAClient object will be capable of locating
>> all domains that use the same vendor implementation that created
>> the SCAClient object.
>
> Suggests to me that you think it should
>
>>
>> The alternative form suggested above doesn't work because it would
>> require the SCAClientFactory to maintain some global knowledge of
>> which domains use which vendor implementations, and return the
>> appropriate SCAClient vendor implementation for the domain specified.
>
> Suggests to me that you think it shouldn't.
>
>
> There are two thing going on here.
>
> 1/ establish what sort of client you need - depends on the technology
> of the domain you wish to talk to
> 2/ establish precise domain you need
>
> 1/ could certainly be achieved by swapping in and out the specific
> factory implementation you have on the application classpath. Hence
> you don't need a domain ID to choose as the choice is made for you
> before the code runs. However I don't see why having the domain ID
> does any harm here in that it would allow Tuscany to make step 2
> transparent. Unless the argument here is that the Assembly spec
> doesn't define what a domain ID looks like so we can't type it in the
> interface.
> 2/ needs the domain ID
>
> Simon
>

Right thats what i don't understand too.

The only way i see it would be possible with the current API to have
some generic code talk to different vendor domains is by swapping out
the vendor specific sca client implementation jars from the classpath.

On the other hand if the SCAClientFactory newInstance was given the
domain URI then you could have all the differnet vendor sca client
impl jars on the classpath together and the SCAClientFactory SPI could
be coded to find all those sca client implementation providers and ask
them if they can talk to the domain the URI identifies and then use
the one that can to create the SCAClient instance.

   ...ant

Re: SCAClient API spec proposal

Posted by Simon Laws <si...@googlemail.com>.
Hi Simon

It's not clear to me from your answer whether you think that
SCAClientFactory is or isn't intended to return an SCAClient
implementation appropriate for the domain you which to retrieve
services from.

> The SCAClientFactory.newInstance() call uses various mechanisms
> to identify which vendor-specific SCAClient implementation to
> return.  The returned SCAClient object will be capable of locating
> all domains that use the same vendor implementation that created
> the SCAClient object.

Suggests to me that you think it should

>
> The alternative form suggested above doesn't work because it would
> require the SCAClientFactory to maintain some global knowledge of
> which domains use which vendor implementations, and return the
> appropriate SCAClient vendor implementation for the domain specified.

Suggests to me that you think it shouldn't.


There are two thing going on here.

1/ establish what sort of client you need - depends on the technology
of the domain you wish to talk to
2/ establish precise domain you need

1/ could certainly be achieved by swapping in and out the specific
factory implementation you have on the application classpath. Hence
you don't need a domain ID to choose as the choice is made for you
before the code runs. However I don't see why having the domain ID
does any harm here in that it would allow Tuscany to make step 2
transparent. Unless the argument here is that the Assembly spec
doesn't define what a domain ID looks like so we can't type it in the
interface.
2/ needs the domain ID

Simon

Re: SCAClient API spec proposal

Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Wed, May 13, 2009 at 1:05 PM, Simon Laws <si...@googlemail.com> wrote:
>>> I had a chat with Mike about what to do to improve this and we have a
>>> way that will help for now while we don't have a more comprehensive
>>> approach that works when we've support for distributed domains and
>>> clients remote from the nodes. I'll commit a strawman and post back
>>> here with details when thats in.
>>>
>>>   ...ant
>>>
>> Just looking at ...
>>
>> public class SCAClientImpl implements SCAClient {
>>
>>   ....
>>
>>    public static void addDomain(URI domainName, Node node) {
>>        nodes.put(domainName, node);
>>    }
>>
>>    public static Node removeDomain(URI domainName) {
>>        return nodes.remove(domainName);
>>    }
>>
>> Why wouldn't we create a client for a specified domain. What is the
>> scenario where we would want to add more than one?
>>
>> Simon
>>
> 
> Actually i agree that seems more natural but thats not the approach
> being taken by the current SCAClient API. The API is:
> 
>    SCAClient scaClient = SCAClientFactory.newInstance();
> 
> so there is no domain name in there and the returned SCAClient is
> generic for any/all domains.
> 
> Then you tell it which domain you want to talk to in the getService call:
> 
>    scaClient.getService(type, serviceName, domainURI)
> 
> What i think you're asking and what i thought seemed more natural
> would be to have:
> 
>    SCAClient scaClient = SCAClientFactory.newInstance(domainURI);
>    scaClient.getService(type, serviceName);
> 
> I guess its a different way of thinking about what an SCAClient is,
> maybe if any of the spec folks are listening they could explain more?
> 
>    ...ant
> 
> 
The SCAClient is vendor implementation specific.  This is because it
needs to deal with domains, and domains are vendor implementation
specific.

Imagine the situation where vendor A's implementation is used for
domains A1 and A2, and vendor B's implementation is used for domains
B1 and B2.  It would not be possible to have a single SCAClient
or SCAClientFactory that understands all four of these domains.
Therefore the spec API proposal (it's not agreed yet, and there is
some discussion on whether we have the right defaulting mechanism)
requires vendor A to provide an SCAClientFactory implementation that
returns an SCAClient capable of locating domains A1 and A2 using
some proprietary mechanism.  Vendor B also needs to provide an
SCAClientFactory implementation that returns an SCAClient capable of
locating domains B1 and B2 using some other proprietary mechanism.

The SCAClientFactory.newInstance() call uses various mechanisms
to identify which vendor-specific SCAClient implementation to
return.  The returned SCAClient object will be capable of locating
all domains that use the same vendor implementation that created
the SCAClient object.

The alternative form suggested above doesn't work because it would
require the SCAClientFactory to maintain some global knowledge of
which domains use which vendor implementations, and return the
appropriate SCAClient vendor implementation for the domain specified.

   Simon



Re: SCAClient API spec proposal

Posted by ant elder <an...@apache.org>.
On Wed, May 13, 2009 at 1:05 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>
>> I had a chat with Mike about what to do to improve this and we have a
>> way that will help for now while we don't have a more comprehensive
>> approach that works when we've support for distributed domains and
>> clients remote from the nodes. I'll commit a strawman and post back
>> here with details when thats in.
>>
>>   ...ant
>>
>
> Just looking at ...
>
> public class SCAClientImpl implements SCAClient {
>
>   ....
>
>    public static void addDomain(URI domainName, Node node) {
>        nodes.put(domainName, node);
>    }
>
>    public static Node removeDomain(URI domainName) {
>        return nodes.remove(domainName);
>    }
>
> Why wouldn't we create a client for a specified domain. What is the
> scenario where we would want to add more than one?
>
> Simon
>

Actually i agree that seems more natural but thats not the approach
being taken by the current SCAClient API. The API is:

   SCAClient scaClient = SCAClientFactory.newInstance();

so there is no domain name in there and the returned SCAClient is
generic for any/all domains.

Then you tell it which domain you want to talk to in the getService call:

   scaClient.getService(type, serviceName, domainURI)

What i think you're asking and what i thought seemed more natural
would be to have:

   SCAClient scaClient = SCAClientFactory.newInstance(domainURI);
   scaClient.getService(type, serviceName);

I guess its a different way of thinking about what an SCAClient is,
maybe if any of the spec folks are listening they could explain more?

   ...ant

Re: SCAClient API spec proposal

Posted by Simon Laws <si...@googlemail.com>.
>>
>
> I had a chat with Mike about what to do to improve this and we have a
> way that will help for now while we don't have a more comprehensive
> approach that works when we've support for distributed domains and
> clients remote from the nodes. I'll commit a strawman and post back
> here with details when thats in.
>
>   ...ant
>

Just looking at ...

public class SCAClientImpl implements SCAClient {

   ....

    public static void addDomain(URI domainName, Node node) {
        nodes.put(domainName, node);
    }

    public static Node removeDomain(URI domainName) {
        return nodes.remove(domainName);
    }

Why wouldn't we create a client for a specified domain. What is the
scenario where we would want to add more than one?

Simon

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Fri, May 8, 2009 at 7:51 AM, Mike Edwards
<mi...@gmail.com> wrote:

> ant elder wrote:
>>
>> On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <si...@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 had a chat with Mike about what to do to improve this and we have a
way that will help for now while we don't have a more comprehensive
approach that works when we've support for distributed domains and
clients remote from the nodes. I'll commit a strawman and post back
here with details when thats in.

   ...ant

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
+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/dev@tuscany.apache.org/msg06447.html
[2] http://www.mail-archive.com/dev@tuscany.apache.org/msg06689.html

Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Thursday, May 07, 2009 11:51 PM
To: <de...@tuscany.apache.org>
Subject: Re: SCAClient API spec proposal

> ant elder wrote:
>> On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <si...@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. 


Re: SCAClient API spec proposal

Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
> On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <si...@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.

Re: SCAClient API spec proposal

Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 9:26 AM, Simon Laws <si...@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

Re: SCAClient API spec proposal

Posted by Scott Kurz <sc...@gmail.com>.
Just wanted to note that it seems that an additional burden on the
runtime implementor to support this API is to recognize if the service
is described by <interface.wsdl>.

If so the runtime has to establish this WSDL interface on the runtime
representation of the reference built for the proxy without having the
data in hand from the client side (but rather only from the side of
the service in the domain).

Would be good to have some tests for this variation with something
like the axis2 binding.sca impl for which following the exact wsdl
interface (instead of generating one bottom up) should matter.

Scott

Re: SCAClient API spec proposal

Posted by Simon Laws <si...@googlemail.com>.
On Tue, Apr 21, 2009 at 4:37 PM, ant elder <an...@apache.org> wrote:
> 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

...snip

Back in the good/bad (delete as appropriate) old days when we first
started with the node and domain idea the node implemented both node
and domain interfaces and, using the domain interface on the node, you
could retrieve a reference to any service available in the domain by
exploiting binding.sca under the covers regardless of whether the
local node was actually running that component. This worked well but
it felt awkward in it's attachment to the local node.

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
- to move beyond this requires some new interfaces on the domain
manager as the old ones that made this work were removed (but we could
do with some for the more dynamic scenarios of late binding and being
able to start nodes in arbitrary orders so that's a good discussion to
have)

Simon

Re: SCAClient API spec proposal

Posted by ant elder <an...@apache.org>.
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 <en...@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 <en...@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
>

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
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 <en...@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 


Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
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 <en...@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

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
Hi,

The following code shows what I have in mind for the standalone case:

public class SCAClientTestCase extends TestCase {

   private Node node;

   @Override
   protected void setUp() throws Exception {
       NodeConfiguration config = ...; // Create or discover the node 
configuration, the domain URI will be part of the node config
       node = NodeFactory.newInstance().createNode(config);   // Create a 
standalone node
       /*
            Start the node. The node instance will be associated with some 
context, such as the thread, the classloader, the OSGi bundle.
            It can also potentially inject the default factory to 
SCAClientFactory class in the same scope
       */
       node.start();
   }

   public void testInvoke() throws Exception {
       /*
            Create the SCAClient, some context can be passed in through the 
classloader or properties to help the runtime to associate the client with 
the node in scope
       */
       SCAClient client = SCAClienfFactory.newInstance(); // The SCAClient 
can be implemented by NodeImpl as well
       /*
           We might check if the domain URI matches the Node. If not, an 
exception can be thrown as the Node cannot deal with that SCA domain
       */
       HelloworldService service = 
client.getService(HelloworldService.class, "HelloworldComponent", 
"urn:someDomainUri");
       assertEquals("Hello petra", service.sayHello("petra"));
   }

   @Override
   protected void tearDown() throws Exception {
       node.stop();
   }

}

Thanks,
Raymond

From: ant elder
Sent: Tuesday, April 14, 2009 4:14 AM
To: dev@tuscany.apache.org
Subject: Re: SCAClient API spec proposal


One general comment is that it i'm finding it a little hard to tell in
places if you're talking about things that already exist in the current code
or if you're talking about things we might be able to do in the future to
support this. I also wonder if we may be looking at this from different
angles so talking across each other.

So using the simplest scenario of a standalone/offline mode like we use in
most itests/samples could you post some pseudo code of what this might look
like? I'll post again here the example test i used earlier which is using
the Node APIs (the existing impl would need to be modified to work with
SCAClient and provide some way to give the Node a domain uri) but i'm now
wondering if we should have some sort of SCADomain API, but could you/others
modify this test code to show what you're thinking this could work like?

public class SCAClientTestCase extends TestCase {

   private Node node;

   @Override
   protected void setUp() throws Exception {
       node = NodeFactory.newInstance().createNode();

   }

   public void testInvoke() throws Exception {
       HelloworldService service =
SCAClientFactory.newInstance().getService(HelloworldService.class,
"HelloworldComponent", "urn:someDomainUri");
       assertEquals("Hello petra", service.sayHello("petra"));
   }

   @Override
   protected void tearDown() throws Exception {
       node.stop();
   }

}

   ...ant 


Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
One general comment is that it i'm finding it a little hard to tell in
places if you're talking about things that already exist in the current code
or if you're talking about things we might be able to do in the future to
support this. I also wonder if we may be looking at this from different
angles so talking across each other.

So using the simplest scenario of a standalone/offline mode like we use in
most itests/samples could you post some pseudo code of what this might look
like? I'll post again here the example test i used earlier which is using
the Node APIs (the existing impl would need to be modified to work with
SCAClient and provide some way to give the Node a domain uri) but i'm now
wondering if we should have some sort of SCADomain API, but could you/others
modify this test code to show what you're thinking this could work like?

public class SCAClientTestCase extends TestCase {

   private Node node;

   @Override
   protected void setUp() throws Exception {
       node = NodeFactory.newInstance().createNode();
   }

   public void testInvoke() throws Exception {
       HelloworldService service =
SCAClientFactory.newInstance().getService(HelloworldService.class,
"HelloworldComponent", "urn:someDomainUri");
       assertEquals("Hello petra", service.sayHello("petra"));
   }

   @Override
   protected void tearDown() throws Exception {
       node.stop();
   }

}

   ...ant

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, April 09, 2009 5:55 AM
To: <de...@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.


> Comments?
>
>   ...ant
>
> public class SCAClientTestCase extends TestCase {
>
>    private Node node;
>
>    @Override
>    protected void setUp() throws Exception {
>        node = NodeFactory.newInstance().createNode();
>    }
>
>    public void testInvoke() throws Exception {
>        HelloworldService service =
> SCAClientFactory.newInstance().getService(HelloworldService.class,
> "HelloworldComponent", "urn:someDomainUri");
>        assertEquals("Hello petra", service.sayHello("petra"));
>    }
>
>    @Override
>    protected void tearDown() throws Exception {
>        node.stop();
>    }
>
> }
>
>   ...ant 


Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Tue, Apr 7, 2009 at 7:50 PM, ant elder <an...@gmail.com> wrote:
> On Wed, Apr 8, 2009 at 1:06 AM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>>
>> This is interesting. One thing I'm not sure is if
>> SCAClientFactory.newInstance() should trigger the "start" of the node. What
>> I understand from the spec discussion is that the SCAClientFactory provides
>> an entry point to a running SCA domain. We may have to get clarifications
>> from the spec side.
>>
>> Thanks,
>> Raymond
>>
>
> Yes, that was an easy way to get it working simply, we need a way to
> get the SCAClient to find an already created node. To do that we
> probably need to change the SCAClient impl to be a new class instead
> of the NodeImpl and have that class find a Node and choose one based
> on the domain URI passed in on the SCAClient getService call.  It does
> seem convenient to me in a JSE environment for that to create an
> underlying node to use if there's not an already started Node to use.
>
>   ...ant
>

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.
- 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
 - 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.

Comments?

  ...ant

public class SCAClientTestCase extends TestCase {

   private Node node;

   @Override
   protected void setUp() throws Exception {
       node = NodeFactory.newInstance().createNode();
   }

   public void testInvoke() throws Exception {
       HelloworldService service =
SCAClientFactory.newInstance().getService(HelloworldService.class,
"HelloworldComponent", "urn:someDomainUri");
       assertEquals("Hello petra", service.sayHello("petra"));
   }

   @Override
   protected void tearDown() throws Exception {
       node.stop();
   }

}

   ...ant

Re: SCAClient API spec proposal

Posted by ant elder <an...@gmail.com>.
On Wed, Apr 8, 2009 at 1:06 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> This is interesting. One thing I'm not sure is if
> SCAClientFactory.newInstance() should trigger the "start" of the node. What
> I understand from the spec discussion is that the SCAClientFactory provides
> an entry point to a running SCA domain. We may have to get clarifications
> from the spec side.
>
> Thanks,
> Raymond
>

Yes, that was an easy way to get it working simply, we need a way to
get the SCAClient to find an already created node. To do that we
probably need to change the SCAClient impl to be a new class instead
of the NodeImpl and have that class find a Node and choose one based
on the domain URI passed in on the SCAClient getService call.  It does
seem convenient to me in a JSE environment for that to create an
underlying node to use if there's not an already started Node to use.

   ...ant

Re: SCAClient API spec proposal

Posted by Raymond Feng <en...@gmail.com>.
Hi,

This is interesting. One thing I'm not sure is if 
SCAClientFactory.newInstance() should trigger the "start" of the node. What 
I understand from the spec discussion is that the SCAClientFactory provides 
an entry point to a running SCA domain. We may have to get clarifications 
from the spec side.

Thanks,
Raymond

--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Tuesday, April 07, 2009 6:27 AM
To: <de...@tuscany.apache.org>
Subject: SCAClient API spec proposal

> I think the SCACLient API proposal going on in the spec group looks
> interesting so i've started adding support for that code to the
> Tuscany 2.x trunk, see r762759/762760 and an itest at:
> https://svn.apache.org/repos/asf/tuscany/java/sca/itest/scaclient-api/src/test/java/SCAClientTestCase.java
>
> There's a thread in the spec mailing list about it:
> http://lists.oasis-open.org/archives/sca-j/200903/msg00121.html
>
> ...ant