ant elder wrote:
On Wed, May 13, 2009 at 3:20 PM, Simon Laws <[email protected]> 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
