Folks,

I've done a pass at implementing Simon's thoughts in spec form here:

http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33076/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%207.doc

http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33077/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%207.pdf

The problem is that in doing this, I got to asking myself some more questions :-(

Can I ask why in this proposal we have the SCAClient interface separate from the SCAClientFactory? I can no longer see any purpose in this separation.

My thoughts are that we should get rid of the separate SCAClient interface and move the getService(....) method into the SCAClientFactory class.

This simplifies things for the client. What they now have to do is simply get themselves an SCAClientFactory using newInstance and then use the returned factory class to get the service proxy class that they need using clientFactory.getService(...). The factory is in other words a factory for service proxies, not for SCAClient objects, for the simple reason that all that the client wants really are those service proxies. Everything else is just machinery for getting those proxies. And the less machinery the better.

The current technology in the implementation of SCAClientFactory with its finder etc gives the necessary separation of the actual implementation from the client code. The addition of the domainURI parameter in principle allows for multiple SCAClientFactory implementations, one per domainURI, even if the current implementation does not actually do that - but the client should not have to change when the underlying code is upgraded to provide this function.

Thoughts?

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO. Co Chair OASIS SCA Assembly TC. IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 Email: mike...@uk.ibm.com

From: Simon Nash <oas...@cjnash.com> To: OASIS Java <sca...@lists.oasis-open.org> Date: 22/06/2009 20:03 Subject: [sca-j] JAVA-1: Moving the Domain URI from getService() to newInstance()

------------------------------------------------------------------------

Mike suggested on today's TC call that the domain URI could be moved from the SCAClient.getService() method to the SCAClientFactory.newInstance() method.

To make this work in the VendorA/VendorB situation that we have been discussing, it would be necessary to also do one of the following: a) add additional methods setDomainURI() and getDomainURI() to the SCAClientFactory abstract class b) require every factory to have a one-argument constructor that takes the domain URI as an argument. This could be enforced by putting a private no-argument constructor and a protected one-argument contructor on the SCAClientFactory abstract class, together with a protected concrete getDomainURI() method that returns the domain URI. Of these two options, my preference is for b).

To see why this in needed, consider the case of client code running within a VendorB runtime that has injected a VendorB factory finder. If the client code wants to access a domain DomainA that uses a VendorA implementation of the factory, the sequence of events is as follows:

1. Client calls SCAClientFactory.newInstance(properties, classLoader, "DomainA")

2. The VendorB factory finder looks up the VendorA factory class using the supplied properties and classLoader.

3. The VendorB factory finder does one of the following: a) calls a no-argument constructor on the VendorA factory class, then calls setDomainURI("DomainA") on the returned factory b) calls a one-argument constructor on the VendorA factory class, passing "DomainA" as the constructor argument In either case the result is an instance of Vendor A's factory implementation class that is bound to DomainA. If the domain URI were not passed in this step, the VendorA factory object would not know which domain URI to use for getService() calls.

4. Client calls the getService(interfaze, serviceURI) method on the VendorA/DomainA factory object returned by step 3. The VendorA concrete factory implementation class calls this.getDomainURI() to find the correct domain URI to use.

The above scheme is slightly more complex than the current proposal, but the "future-proofing" benefit may justify this.

/Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/