Giovani Salvador's Blog

Java, SOA and XML

I have been involved in SOA (Service Oriented Architecture) projects and also studying a lot all the aspects of the SOA world. It is interesting that I thought that I knew SOA before working effectively with SOA. More specifically, I thought my knowledge on XML parsing (of course, using a JAXP implementation) would be sufficient to say that I really know XML.

For example, when we think of an XML document we usually think of something like this:

<customer>
        <address>
                <zipcode>123</zipcode>
                …
        </address>
        <address>
                <zipcode>321</zipcode>
                …
        </address>
</customer>

and not this:

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" 
        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
        xmlns:tns="http://www.myservice.com/SyncBusiness/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="SyncBusiness"
        targetNamespace="http://www.myservice.com/SyncBusiness/">
        <types>
                <xsd:schema targetNamespace="http://www.myservice.com/SyncBusiness/" 
                        xmlns:xs="http://www.w3.org/2001/XMLSchema"
                        xmlns:order="http://www.myservice.com/order">
                        <xs:import namespace="http://www.myservice.com/order" schemaLocation="./order.xsd" />
                        <xsd:element name="submitOrderResponse" type="order:Order" />
                        <xsd:element name="submitOrder" type="order:Order" />
                </xsd:schema>
        </types>
        <message name="submitOrderResponse">
        ...
        </message>
        <portType name="SyncBusiness">
        ...
        </portType>
        <binding name="SyncBusinessSOAP" type="tns:SyncBusiness">
                <soap:binding style="document"
                        transport="http://schemas.xmlsoap.org/soap/http" />
                <operation name="submitOrder">
                ...
                </operation>
        </binding>
        <service name="SyncBusiness">
                <port binding="tns:SyncBusinessSOAP"
                        name="SyncBusinessSOAP">
                        ....
                </port>
        </service>
</definitions>

But when you get involved with SOA using an ESB (Enterprise Service Bus) implementation you start to deal with a world you typically have not any involvement.
For example, when using web services as part of the technologies of a SOA solution, how many of us pay special attention to the namespace declaration of a WSDL document? Or the types definition? Or bindings?

One may argue that we don’t need to pay attention to such things as we have tools that make all this job for us, especially when we need to consume services published in a specific web service or when we need to expose a service.
But we should consider taking a deeper look into those things. Why? Here a couple of reasons.

Design By Contract
In the SOA world, when using the “design by contract” approach, we probably start our service by writing (maybe getting help from a tool) our WSDL document and think of the services we are going to provide. We also need to think of the XML Schema Documents and all the complex types we are expecting to deal with. The binding section also deserves a closer look to define the protocol to be used.
For example, the port portion of a WSDL document let us know the location of the service as we can see in the following snippet.

        <service name="MyService">
                <port binding="ms:MyServiceSoapBinding"
                        name="MyServiceSoapPort">
                        <soap:address
                                location="http://172.168.15.1:7101/esb/myservice" />
                </port>
        </service>

If you use a tool that generated that location pointing to a specific ip address you will probably have some problems with dynamic IP. But if you are responsible for taking care of the contract between the client of an ESB and the ESB itself then you know that you need to specify carefully all the services and their locations.

I am not saying here that the design by contract should always be used when designing a service. The bottom line here is that this
approach makes you think of some things in advance that you usually don’t pay special attention. It makes you first think of defining a good contract for the clients and when you think oriented to interfaces you start making yourself questions in advance and avoid problems in the future while designing your SOA solution.

Schema Transformation
Consider you have a service exposed in a specific ESB implementation that returns customer data. This service consolidates data from two other services but those 2 other services are not directly visible to the clients of the ESB. Let’s imagine one represent customer data from a legacy system and the other from a new system and your company wants to have a single view of the customer data to clients.
In this case, when there is a call to the published service in the ESB, the ESB is responsible for calling those 2 existing services, get the data and consolidate that data into one single format to the clients. What happens at this point? Transformation inside the ESB. You can use a specific language like Xquery and XSLT to perform this transformation but problems happen when you have the same set of names for the customer representation in both services, the old and the new one, as you see in the following XSD files.

CustInfo.xsd

<xs:element name="customer" >

    <xs:complexType>

        <xs:sequence>

             <xs:element name="customerId" type="xs:string"/>

             <xs:element name="customerName" type="xs:string"/>

             <xs:element name="customerAddress" type="xs:string"/>

        </xs:sequence>

    </xs:complexType>

  </xs:element>

CustInfoOld.xsd

<xs:element name="customer" >

    <xs:complexType>

        <xs:sequence>

             <xs:element name="customerIdentification" type="xs:string"/>

             <xs:element name="customerName" type="xs:string"/>

             <xs:element name="customerAddress2" type="xs:string"/>

        </xs:sequence>

    </xs:complexType>

</xs:element>

In other words, both legacy and new systems have XML Schema Documents and you may have name conflicts. You avoid problems using namespaces to represent both old and new schemas.

xmlns:custnew="http://www.custdata.org/CustInfo"
xmlns:custlegacy="http://www.custdataLegacy.org/CustInfoLegacy"

If we need to work with both schemas to perform transformation in a language like XQuery than all we need to do is to declare both schemas, each one being represented by one namespace, and use the namespace as an alias to each one of them and their elements.
That’s the reason we need to understand how namespaces are organized inside XML documents like WSDLs and XSDs. For the time I have played with ESB most of the problems I faced were related to invalid namespace references.

Note: Transformation inside an ESB implementation can be performed using Java callouts (if you are using an ESB written in Java) and you will probably deal with an object oriented view of your XML document and avoid problems you face when you are performing transformation using a a language like XQuery.
But you need to make an analysis of the benefits because if you need to perform a modification in the transformation than you will need to recompile the code and, depending on the ESB implementation, perform a restart. Some ESB implementations allow you to modify your XQuery code without performing restart. In the other hand, transformation using Java gives you more power.

Final Comments and Questions

What SOA has to do with Java? Nothing, because SOA is not dependent of a specific technology. And everything. SOA has everything to do with Java like Java has everything to do with XML. And in the Java world there is a number of ESB implementations like Aqualogic, Mule, JBoss, etc.

Which one do you guys use? And which approach to perform transformations are you guys using (XQuery or any other language or Java Calls)?
Also, using the design by contract approach?
I Appreciate any comment.

Thank you all.

Comments

• WSDL-first ever, get skilled in XML and XSD schemas, know everything about namespaces and eat JAXB/JAXP & WSIMPORT every morning :) welcome to the SOA jungle....

  Posted by: felipegaucho on July 28, 2008 at 03:51 AM

This work is licensed under a Creative Commons License.