Many enterprises have devoted a large amount of time and energy into supporting the W3C SOAP and Web Service stack. In fact many people, when the term Service Oriented Architecture is brought up automatically think this is SOAP and the Web Service stack that goes along with it. However, this is wrong. RESTful JSON/XML web services are also a key aspect to implementing a SOA. SOA is much more though than just a web service a series of web services. There is the need to monitor, track, and manage access to the services. So regardless if you are implementing SOAP based web services or not the concepts developed over the years still apply.
With the popularlity of JSON and other NoSQL data standard formats, the complexity and in some cases the plain verbosity of XML formats are being shunned. However, XML and the abilities and standards that have formed around it have become key to the enterprise and their business processes. However, the needs of their customers require that they start to support multiple formats. To this end, tooling frameworks like Axis2 have started to add support for taking WSDL based services and generate JSON responses.
Enterprises need to live in this post SOAP world, but leverage the expertise and SOA infrastructures they have developed over the years. Axis2 is one way to do it, but it doesn’t provide monitoring and policy support of the box. Another alternative is the Turmeric SOA project from ebay. Natively out of the box one can take a WSDL like, the one provided by the STAR standard organization, and add support not only from SOAP 1.1/1.2, but also for REST style services serving XML, JSON, and other any other data format you would need to support.
There is a catch though, Turmeric SOA was not designed with full SOAP and the W3C web service stack in mind. It uses WSDL to only describe the operations and the data formats supported by the service. So advanced features like WS-Security, WS-Reliable Messaging, and XML Encryption are not natively built into Turmeric. Depending on your needs you will need to work with pipeline Handlers and enhance the protocol processors to support some of the advance features. However, these are items that can be worked around, and it can interoperate with existing web services to act as a proxy.
As an example, the STAR organisation provides a web service specification that has been implemented in the automative industry to provide transports for their specifications. Using a framework like Turmeric SOA existing applications can be made available to trading partners and consumer of the service in multiple formats. As an example, one could provide data in RESTful xml:
<?xml version='1.0' encoding='UTF-8'?>
<ns2:PullMessageResponse xmlns:ms="http://www.ebayopensource.org/turmeric/common/v1/types" xmlns:ns2="http://www.starstandards.org/webservices/2009/transport">
<ns2:payload>
<ns2:content id="1"/>
</ns2:payload>
</ns2:PullMessageResponse>
Or one can provide the same XML represented in a JSON format:
{
"jsonns.ns2": "http://www.starstandards.org/webservices/2009/transport",
"jsonns.ns3": "http://www.starstandards.org/webservices/2009/transport/bindings",
"jsonns.ms": "http://www.ebayopensource.org/turmeric/common/v1/types",
"jsonns.xs": "http://www.w3.org/2001/XMLSchema",
"jsonns.xsi": "http://www.w3.org/2001/XMLSchema-instance",
"ns2.PullMessageResponse": {
"ns2.payload": {
"ns2.content": [
{
"@id": "1"
}
]
}
}
}
The above is generated from the same web service, but with just a header changed to indicate the data format that should be returned. No actual changes to business logic or the web service implementation code itself has to change. In Turmeric this is handled with the Data Binding Framework and its corresponding pipeline handlers. With Axis2 this is a message request configuration entry. Regardless of how it is done, it is important to be able to leverage existing services, but provide the data in a format that your consumers require.
For those that are interested, I’ve created a sample STAR Web Service that can be used with Turmeric SOA to see how this works. Code is available at github.
While Turmeric handles the basics of the SOAP protocol, advance items like using and storing information in the soap:header are not as easily supported. You can get to the information, but because the use of WSDL in Turmeric Services are there just to describe the data formats and messages, the underlying soap transport support is not necessarily leveraged to the full specification. Depending on your requirements, Axis2 may be better, but Turmeric SOA provides additional items like Service Metrics, Monitoring Console, Policy Administration, Rate Limiting through XACML 2.0 based policies, and much more. If you already have existing web services written the W3C way, but need to provide data in other formats, Turmeric can be used along side. It isn’t a one or the other proposition. Leverage the tools that provide you the greatest flexibility to provide the data to your consumers, with the least amount of effort.
