Service-oriented architecture (SOA) can be done with a minimum of J2EE and maximum of XML processing using
RouteOne, which is a joint venture by the major auto manufacturers providing Web services-based car loan processing for their dealerships, is also the poster child for IBM positioning of its DataPower XML processing appliance as an ESB. Using the IBM DataPower box to speed the XML processing, Subramaniam said he is transitioning from an aging enterprise application integration (EAI) system to SOA doing XML processing and as little J2EE as possible.
The five-year-old company's systems take the basic credit application information for a car buyer, validate it and apply business rules to it, then messaging middleware sends the information to lenders. The lenders process the application and send a response back to the dealership.
"In order to facilitate this process we have a large number of Web services," Subramaniam said, "for example, getting the credit bureau scores and the credit report on the customer. It's a large orchestration of Web services to get this done."
The overall system is designed to accommodate a variety of ways end user application information can be entered at the dealership, ranging from Web browser front-ends to legacy systems, and a variety of systems from lenders and credit bureaus, he said. While the Web services carry the data in XML format, it had to be translated into Java objects to be processed as J2EE applications, he explained.
"On the backend for the messaging system we used to use a EI [enterprise integration] product," Subramaniam said. "We are now in the process of migrating away from that to using IBM DataPower."
Even in the old EAI system, RouteOne was using the first DataPower XML appliance, prior to its acquisition by IBM, the chief architect said.
"We got DataPower when it was actually in beta," he said of the original implementation. "We used DataPower because we have fairly stringent legal requirements for proving that our system is tamper proof. We are exchanging fairly confidential financial data for the customer, so the level of security is pretty high. So we were using it for XML digital signatures. All our messages going in, coming out, pretty much all of them, are digitally signed. In those days [five years ago] there really wasn't a software solution that was fast enough to do XML digital signatures. So we discovered DataPower and we bought the XS-40 devices, which are XML security boxes."
While the original system was adequate, Subramaniam was looking for a way to do more processing making greater use of XML and XML standards and less use of J2EE with the transforming of XML data into Java objects.
"Over a period of time, I realized that all this business of marshalling and –un-marshalling XML was not a very efficient way to do XML," he recalled. "Most enterprises outside the Microsoft world are essentially using Java applications. So the tendency is to think in terms of Java because that's what you're used to. So what people would normally do is take the XML, turn it into a Java object process it in various ways and then give it to the next step in the process."
While seeking a more efficient way to handle the XML processing, Subramaniam said, he had a brainstorm one day while talking about the problem with a colleague.
"I realized the XML architecture is fairly rich these days," he said. "You have XQuery. You have XML security, XML Schema. So why not process XML as XML. The reason most people don't do that is because XML processing can be very CPU and memory intensive depending on how you do it."
Serendipitous to his brainstorm, IBM representatives talked to him about the concept of using the next generation of DataPower boxes as ESBs to solve the CPU and memory issues with XML processing.
"So we talked to IBM and they have a new product called the XI50, which they are positioning as a hardware enterprise service bus," he said. "It has all the features that an ESB should have. It's capable of routing and transforming, and validating data. It's capable of talking to a variety of things. It talks to LDAP servers, SQL databases. It can talk to any basic SOA or Web services applications."
RouteOne upgraded from the DataPower XS40, which it had been using for security to the XI50s and the XML processing is now being done in hardware. This allowed Subramaniam to minimize the amount of J2EE application processing.
"We decided before the application would even come into our J2EE layer, we would put a couple hardware boxes up front, so the message is validated and transformed," he said. "It's routed to the right gateway, to the right service endpoint. We'd do that in hardware."
This allowed him to avoid the Java-centric approach to SOA, which he finds "very heavyweight." He offers an example of why he believes J2EE-based SOA is problematic.
"The XML payload that we were using we had to marshal as a Java object at some stage," he explained. "The way it usually works is you take the schema and run a compiler that generates classes. In our case it generates 100 classes. It's difficult to figure out what all these classes are doing."
The new architecture Subramaniam created does this processing in XML with minimal Java.
"We use an object binding framework," he explained. "We use XSLT to transform it in hardware. So when the XML comes in, all the validation, all the business rules that are applied to it, all the transformations are done, so we get a clean XML that is exactly fitting the object that we want. So we can make one Java call, say un-marshal, and we have the object, lo and behold. We don't have compiled classes. We have no mapping. Nothing."
This approach bypasses the J2EE processes that analysts, most notably Richard Monson-Haefel of the Burton Group Inc., have been warning is not suitable for SOA.
"It is fundamentally our belief that you should be able to do XML processing in XML," Subramaniam said. "If you have a hardware-based ESB, you can do it very efficiently."
While there is still a J2EE layer in the RouteOne SOA environment, its interaction with the XML has been minimized.
"For example," he said, "if you have a message coming in and it fails some kind of schema validation then the J2EE layer doesn't even know about it because we turn right around and publish it back to the originating service right inside the box."