SOA - One Service Many Forms

DRAFT VERSION

Service Oriented Architecture (SOA), an architecture which has one or more services defined and exposed by service provider to the service consumer. There are various forms in which you can expose a service to consumer. In JAVA world it can be web service, HTTP remoting, messaging, EJB, RMI etc.; if we see all these are various technologies, API or frameworks using which one can expose its core service to outer world.

Now when we think of service then it must cover other aspects which makes it a complete service like transaction, security, portability, interoperability, scalability and maintainability. Ideally it can be the POJO later on which can be exposed as service using java web service, remoting, rmi, EJB or messaging.

SAO is not just a web services many people think SOA means just a web service. When we thinking about writing a services; to fit it in SAO it must follow certain design principals and patterns soapatterns.

In general it is a messaging between two components, communication using request and response. Request and response defines a contract between provider and consumer of the service. To accomplish particular business function which has been wrapped in service, in nature it required certain type of input to produce expected type of output to fulfill certain business requirement. I am sure you must have come across terms like stub-skeleton, marshalling-un-marshalling these are the general terms we used while defining request and response for inter communication of components.

Request & response carries message payload no matter where the consumer resides; means a consumer either locally sitting in same runtime environment or different. Let’s say I have exposed a service using EJB in this case I have an option to consume it locally or remotely and the message payload over the network would be binary. Point I want to make here to process request and response you need JAVA on either end. So our exposed service can only be consumed by JAVA consumer – this is limiting our service interoperability and again the format of request and response not based on open standards. Other than JAVA no else can crack it. So we need to design request and response in such a way it must be transparent to the request and response processors. Answer to this is XML – this has been widely accepted. A well formed document which can easily wire over the network and processed using available XML parser.

We can define a XSD which acts as a blue print for the request & response XML. XSD defines elements, attributes, child elements, order of child elements, types of elements & attributes, default and fixed value for the element & attribute and many more. You can find more about XSD.

There are many ways to process the request & response XML message payload. We can use Java XML API like DOM, SAX, Stax, XSLT and also XPATH to parse and create a XML.

DOM

Memory foot prints depends on size of XML it dealing with, loads XML fully in memory, it can traverse in any direction and it can parse and create XML document.

SAX

Event based push parser. It sends an event out for XML entity. It has low memory foot prints compare to DOM, It can only traverse forward only direction. It can only parse XML and cannot crate document.

StAX

Event based pull parser. It has very low memory foot prints compare to DOM & SAX parsers. It sends an event out for XML entity but on demand. It can only traverse forward only direction and it can parse and create XML document.

XPath

This requires XML document loaded in memory. We can create XPpath expressions to retrieve value from the XML.

XSLT

It requires XSL and XML which produces desire output - XML is the one of the output format.

All above requires manual hand written code for parsing and creating XML. Alternative for this is XML data binding framework which gives you generated JAVA classes using which you can create and parse the XML document easily. Apache XMLBeans, JAXB, JiBX are some of them. Create the XSD and pass it to framework it will generate JAVA classes for you to deals with. No need to know any parser API. Use setter and getter to create and parse XML.

Apache XMLBeans

Apache XMLBean is the open source project. It claims 100% schema compatibility. It prefers array for collections and enumeration of value for the XSD choice.

JAXB

Comes with JDK, Prefers List for collection unlike apache XMLBean array. No enumarion support for XSD choice.

JiBX

Is the open source XML data binding framework. Performance wise JiBX out performs XMLBean & JAXB. Generating bindings out of it is little bit tedious job, but once done it gives you its real value. It weaves its biding code at the time of binding generation and not run time by using JAVA reflection.

Satx out performs other JAVA XML pareses and JiBX ranked number one in XML data binding frameworks. But before going for any of these parsers or XML data binding framework - “review the XML & XSD design and data binding framework schema compatibility”.

To be continued…