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...@apache.org> on 2009/05/06 11:48:19 UTC
Re: SCAClient API spec proposal
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 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 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 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 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.