Wednesday, August 31, 2005

Great North Run

I haven’t blogged for long now. This is because I have been very busy at work. I will soon post several technical notes.
I should mentioned that I will be back in Newcastle from the 16th to the 19th of September. I will run my fourth Great North Run and this year I hope to run it in less that 1h 40 minutes.
I am seeing the GNR as part of my training for next April Paris’ Marathon. So I have decided to properly train and I have bought some magazines and books. I think that I will be bloging about my training very soon. The most difficult part of it will be giving up drinking beer and whisky :( According to my (French obviously) training book I am still allowed drinking a glass of red wine per day :)

Friday, August 12, 2005

Villars-sur-Glâne

Jim has recently blogged about WDSOA’05. I’ll try my best to submit a paper about versioning. I really think that versioning is of great importance when designing WS. Whatever happens I’ll tell you soon more about my current thinking (via the paper or in this blog).

I have been told by some friends that this blog is too technical and therefore annoying to death. So, let’s go for some news. I have now moved to Villars-sur-glâne next to Fribourg. My flat is very cool, 110 m2 (I know that people from the UK will not have any fucking idea of what 110 m2 is but I could tell you that this is larger that my Newcastle’s house) with a 15 m2 balcony and a lovely view on the pre-Alps. I don’t want to publish photos of it because I am afraid to see too many people visiting me this winter. I was going to forget mentioning that most importantly my cellar is in a nuclear shelter. Yes, I may survive the next global nuclear ware, at least for few weeks as I haven’t any food in my cellar.

So, as I am living close to the Alps and because all my colleagues are mountain bike addicted then I need now to buy myself a mountain bike. Not a nice one like Thomas’ one but I’ll try to find a good one.

Wednesday, August 03, 2005

Validate or not validate: that is the question

Should we validate incoming and/or outgoing SOAP messages against a schema? Shouldn’t we be able to switch validation on and off on our Web Service platform level? I am just concern that, for example when using a JAX-PC platform the Web Service platform does successfully transform invalid SOAP messages in JAVA objects.
I wonder if AXIS does it, ideally that should be done by the Castor stack. I am pretty certain that .net has this type of feature. It would be good if somebody can confirm that.
Regarding WebSphere they claim that:

“If a WebSphere web services client is developed with the supported programming model, like JAX-RPC and SAAJ, the web services engine will not serialize the request across to be a malformed XML document--i.e., the SOAP message should be structured according to the WSDL's style and use, and that it should conform with the WSDL's schema. A WebSphere web service won't accept a malformed, non-schema-compliant request that is not compatible with the WSDL describing the service, and if that request is malformed, the web services engine should throw some kind of exception.”

I am doubtful as simply because on of my document/literal wrapped Web Service response SOAP body contains the following:
....

losssets type="soapenc:Array" arraytype="p416:comindLossSetBase[2]"

....
Knowing that the schema describing the SOAP body is as followed (this is only a relevant snippet);
....

element type="comind:CILossSetSet" name="lossSets"
complextype
complextype name="CILossSetSet"
sequence
element type="" name="lossSet"

....
The SOAP body doesn’t validate against the schema! I guess that I have found an issue with WebSphere. Unfortunately, I haven’t managed to replicate this problem with some mock WSDLs. So, as I cannot give away our corporate data to IBM I only hope that IBM will give us an answer without the sacrosanct “standalone reproducible test case”.

So, should we validate or not? I would say that we should always validate attachment and certainly validate the SOPA body when our Web Service is externally exposed.

PS: Sorry about my SOAP code but I didn’t find a way of displaying the chevrons.

Tuesday, August 02, 2005

Java Web Service clients

Service lookup

There are two families of Web Service clients which differ in the way code is written and services are invoked:

Unmanaged clients i.e. J2SE or J2ME clients ==> Service lookup is through the JAX-RPC ServiceFactory, a factory for the creation of instances of services access points. {JSR 101: "The JAX-RPC ServiceFactory is the standard way to look up Web services in a J2SE environment."}

J2EE container-managed clients ==> Service lookup is through JNDI lookup {JSR 109: "JNDI lookup is the standard way to look up Web services in a J2EE environment."}

JAX-RPC ServiceFactory

The JAX-RPC ServiceFactory is an abstract class which acts as a factory for instantiating JAX-RPC Services. It is vendor independent that helps writing portable code. The ServiceFactory is instantiated and used as follows:
javax.xml.rpc.Service service = ServiceFactory.newInstance().createService(...);

JNDI service lookup

J2EE container-managed clients are packaged into Enterprise Archives (.EAR) files and run from inside a J2EE container. In addition to the Java code, descriptors are also packaged into the archive. JAX-RPC defines the programming model for unmanaged clients, whereas JSR 109, "Implementing Enterprise Web services", defines the programming model for J2EE container-managed clients. One of the goals of JSR 109 is that its client programming model is compatible with JAX-RPC. However, JSR 109 does not recommend the use of the JAX-RPC ServiceFactory. It recommends clients use Java Naming and Directory Interface (JNDI) instead to obtain a Service Interface. This is a two steps process:

1) Instantiate a local JNDI Context ==> Context ic = new InitialContext();
2) Do a JNDI lookup for the Web service name in this context ==> Service service = (Service) ctx.lookup("java:comp/env/service/MyService");

The logical name of the Web service, in this case java:comp/env/service/MyService, is specified in the client application's deployment descriptor. JSR 109 recommends that all service reference logical names be organized under the service sub-context. With the client environment context being java:comp/env.

The JNDI lookup returns a JAX-RPC Service Interface. The J2EE container makes sure an implementation of the generic JAX-RPC Service is bound at the location specified in the deployment descriptor.

Service access

The J2EE container typically generates the service Interface Implementation, JAX-RPC Service, during deployment. The Service Interface Implementation acts as a factory for Service Endpoint Interface (SEI). A SEI is basically the Java representation of the Web service operations described in the WSDL port type element. The Service Interface Implementation must provide a static stub and/or dynamic proxy for all ports declared by the service element in the WSDL description. A container provider must support at least one of static stubs or dynamic proxies, but may provide support for both. When both are supported then the choice of generated stub or dynamic proxy is a deploy time binding information. IBM WebSphere 6 only provides support for static stubs. I think that it make a lot of sense as it is facter than dynamic proxies.

J2EE container-managed clients access and invoke Web Services as follow:

1. Get a JAX-RPC Service ==> Context ic = new InitialContext();
Service service = (Service) ctx.lookup("java:comp/env/service/MyService");
2. Obtain a SEI using the JAX-RPC Service's getPort() method ==> MyPort aPort = (MyPort) service.getPort(MyPort.class);
3. Invoke the Web Service operations ==> aPort.myOperation(myArg);

Unmanaged clients i.e. J2SE or J2ME clients use one of the three following methods for accessing and invoking Web Services:
• Stub
• Dynamic Proxy
• Dynamic Invocation Interface (DII).
See the following documents for more details about those three techniques:
· http://java.sun.com/webservices/docs/1.3/tutorial/doc/JAXRPC5.html
· http://www-128.ibm.com/developerworks/webservices/library/ws-javaclient/

Welcome Thomas

I like to welcome my friend Thomas.
You should definitely have a look at his excellent blog, there is even a picture of me half-naked ;(