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()


Mike Edwards wrote:
> 
> 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 
> 
I took a quick look through this and I don't see anything to support
the following requirement from my previous email about this:

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).

Please refer to my previous email for more detail on why this
is needed.

> 
> 
> 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.
> 
This seems to be a useful simplification.  It doesn't reduce the
amount of code that the client has to write, but it reduces the
number of classes and interfaces in the SCA API, with (I think) no loss
of flexibility or capability.  Currently, the client needs to write
code like:
   SCAClient client = SCAClientFactory.newInstance(..., domainURI);
   MyService = client.getService(MyService.class, serviceURI);
With this change, the code would be:
   SCAClientFactory client = SCAClientFactory.newInstance(..., domainURI);
   MyService = client.getService(MyService.class, serviceURI);

   Simon

> 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]