map butcher

I’ve been working on a WCF solution for a while now and I’ve been putting off answering the inevitable question: How interoperable is my service? Up until now we’ve used WCFStorm as a test harness which has been a really great integration test harness, however it’s essentially a .Net client onto my .Net services.

So I’ve decided to dip my wick into Java to see how easy it is to call my endpoints from a Java client/service.  I’ve decided to use NetBeans (6.7.1) with Metro (1.4) as my tool set (based upon a recommendation) and here are a few things I’ve learnt along the way….

1 Adding a web service client.

This is really easy, once you’ve created a project then right click on the project name and select new web service client:

JAX-WS (wsGen) will do the nuts and bolts to crank out the java proxy objects. You’ll now have a web service reference and generated source element in your project tree:

2. Using the web service

A  really nice function in NetBeans is the ability to drag the service reference into your code – Select the method on the service you’d like to invoke (from the project panel) and drag it into your class – NetBeans will stub out the basic structure of the call. If you have a simple service then you’re almost ready to go – other than initialising any parameters required by the service. In my case my interface is complex and I want to know how Java has translated my types into java types.

3. WCF to Java Type fun

In the following code from my Java class you can see I am initialising an object LocationIdentifier which I need to pass as a parameter to my service. What’s funny about this initialisation?

            LocationIdentifier lid = new LocationIdentifier();
            lid.setEntityId(JAXBHandler.createString("9999"));
            lid.setSystemId("TestSystem");

What the hell is this JAXBHandler? Well this is a nasty little class of mine which handles the creation of JAXBElement<> types. But what is different between the entity id property and the system id property on LocationIdentifier? Very little –  both properties are of type string, however wsGen interprets these differently depending upon the type definition in the wsdl.  So why is WCF generating these members differently in the wsdl?

When the wsdl defines an element having both minOccurs=”0″ and  nillable=”true” then wsGen creates a proxy object with a JAXBElement<> type instead of a standard java type. More discussion can be found here. In WCF when a type is nullable i.e. String then WCF will generate the WSDL element for this type with a property nillable=”true”.  Class properties in WCF which are exposed via the WCF DataMember attribute can optionally include a parameter IsRequired which can be used to control the occurance of minOccurs in the wsdl.

So if we look at the LocationIdentifier class in .Net:

...
        [DataMember(Name = "SystemId",IsRequired=true)]
        public string System
        {
            get { return system; }
            set{system = value;}
        }
...
        [DataMember(Name = "EntityId")]
        public string Id
        {
            get { return id; }
            set{id = value;}
        }

This manifests itself in the wsdl like:

<xs:element minOccurs="0" name="EntityId" nillable="true" type="xs:string">
<xs:element name="SystemId" nillable="true" type="xs:string">

Depending upon your preferences you can work with JAXBElement<> types however it makes life much easier for a Java developer who uses your WCF service if they can work with the more obvious Java types. Overall it’s been really easy to get going and test my service from a Java client, I like both NetBeans and Metro especially over previous experiences I’ve had with Eclipse. If I’m not careful I’ll become a grumpy dissatisfied Java developer!