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:  

From:
"Mark Combellack" <>

To:
"OASIS Java" <>

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:

 

Since SCAClient
is an interface, it can be mocked for testing purposes

SCAClientFactory
allows vendors to plug in an implementation without modifying the SCAClientFactory
class

The SCA API jar can be shipped without modification
by the vendors 

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:

 

The org.oasisopen.sca.SCAClientFactory
System Property

The META-INF/services/org.oasisopen.sca.SCAClientFactory
file. 

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:

 

Provide an implementation of the org.oasisopen.sca.SCAClientFactorySPI
interface

Provide a META-INF/services/org.oasisopen.sca.SCAClientFactory
file that points to their implementation class 

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

A sample implementation of the SCAClientFactorySPI
in the com.myscaruntime.impl
package

A unit test that looks up the HelloService
using the SCAClientFactory

An Eclipse project file 

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:

 

Select the Properties menu item on the Project
menu. 

Select the Java Build Path in the list on
the left hand side

Select the JRE System Library on the right
hand side

Press the Edit button

Make sure the workspace default JRE is selected
and press Finish

Press OK 

 

 

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 |


 

[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