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: Source code for SCAClientFactory proposal - somethoughts



Mark,

Thank you for doing this work.

Unfortunately, it takes us down a path that I am very reluctant to follow.
- Now, in order to provide for alternative implementations, we are dictating an implementation style that
is inflexible and (based on experience) even hostile to certain programming environments such as OSGi.

There are competing concerns here, I realize, and we are going to have to collectively decide which are
the most important to deal with.

On the one hand, it is desirable for the client code to have a very simple and unchanging API to deal with.
This leads to the desire for a concrete class such as the SCAClientFactory and the return of an object
implementing the desired client API.  All well and good.

On the other hand, ideally, the actual code used to load the implementation is created entirely by the
provider, so that the style of loading etc is not dictated by us in the OASIS TC.

There seems also the desire to allow multiple different vendor implementations of providers to be used
simultaneously (eg for access to different domains??).

The ability to have a simple mechanism to allow a mock provider for testing purposes...
( - I'm not sure how your proposal really helps on this one, perhaps you could explain how it would work)


Perhaps a model that might be worth investigating is the one used by the XML Parsers.
This has a DocumentBuilderFactory which is an Abstract class with no public constructor - instead it has
a newInstance() method which itself looks for a "real" DocumentBuilderFactory implementation by
a variety of means.  This allows delegation of the actual factory behaviour to some implementation,
allowing the OASIS code to shirk the responsibility for this.  It's not ideal, but it allows us to minimise the
code we write...


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: "Mark Combellack" <mcombellack@avaya.com>
To: "OASIS Java" <sca-j@lists.oasis-open.org>
Date: 06/02/2009 10:49
Subject: [sca-j] JAVA-1: Source code for SCAClientFactory proposal





Hi,

 

I have an action item to write some code to show SCAClient as an interface and SCAClientFactory as a concrete class and still allow vendors to plug in implementations that provide the vendor specific functionality.

 

The main reasons for doing this include:

 

 

What I will do is run you through the main points of the code and how it works. The code could do with more polish before it is considered complete.

 

 

SCA Client Perspective

 

The scenario is fairly simple – some code that is running outside of the SCA Domain wants to lookup and use a Service that is inside the domain.

 

The following code shows how the HelloService could be looked up and invoked from unmanaged SCA Code.

 

        final String serviceURI = "SomeHelloServiceURI";

        final URI domainURI = new URI("SomeDomainURI");

       

        final SCAClient scaClient = SCAClientFactory.createSCAClient();

        final HelloService helloService = scaClient.getService(HelloService.class, serviceURI, domainURI);

        final String reply = helloService.sayHello("Mark");

 

The client first calls SCAClientFactory.createSCAClient() that returns an instance of SCAClient. This SCAClient instance can then be used to look up the HelloService

 

 

SCAClient Interface

 

The main change from Mike’s original proposal is to make SCAClient an interface rather than a class. The main reason for this is that it allows mocking of the SCAClient so that it can be unit tested.

 

The new definition of SCAClient interface would be:

 

public interface SCAClient {

 

    <T> T getService(Class<T> interfaze, String serviceURI, URI domainURI)

        throws NoSuchServiceException, NoSuchDomainException;    

}

 

 

SCAClientFactory class

 

The SCAClientFactory class is responsible for providing the indirection from the user’s generic SCA code and the vendor’s implementation of the SCA Runtime. The user’s code will ask it for a SCAClient via the createSCAClient() method.

 

The SCAClientFactory class provides this indirection to the vendor’s implementation by attempting to discover the class name of the vendor’s implementation using:

 

 

It is important to note that this class does not need to be updated by the Vendor to include their implementation. All the Vendor needs to do is set the System Property or provide the correct services file

 

 

What does the Vendor need to do?

 

The Vendor will need to provide a class that will be able to look up a Service in their SCA Runtime. To do this, they need to:

 

 

The SCAClientFactorySPI interface has a single method that the vendors need to implement:

 

public interface SCAClientFactorySPI {

 

    SCAClient createSCAClient();

 

}

 

 

Source Code

 

I have attached a ZIP file that contains the source code for the above. The ZIP file contains:

 

Implementation of SCAClient and SCAClientFactory in the org.oasisopen.sca package

Implementation of SCAClientFactorySPI in the org.oasisopen.sca.spi package

 

When loading the Eclipse project file, you may need to set the target JDK to match the JDK you have installed. To do this simply:

 

 

 

 

I would appreciate your thoughts/comments on this proposal.

 

Thanks,

 

Mark

Mark Combellack| Software Developer| Avaya | Eastern Business Park | St. Mellons | Cardiff | CF3 5EA | Voice: +44 (0) 29 2081 7624 | mcombellack@avaya.com

 

[attachment "JAVA-1_Code_Proposal.zip" deleted by Mike Edwards/UK/IBM]


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