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:
From:
Simon Nash <>
To:
OASIS Java <>
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.
Simon
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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
