OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-j] JAVA-1: Moving the Domain URI from getService() to newInstance()



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_edwards@uk.ibm.com



From: Simon Nash <oasis@cjnash.com>
To: OASIS Java <sca-j@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.

  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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]