Enterprise Software

Secrets to designing a service-oriented architecture using Web services

If you're a consultant preparing for the Web services revolution, this is the advice that will make you the architect and the most trusted advisor on the project.

By Chris McManaman

For the past six months at RCG Information Technology, Inc., I’ve been implementing a service-oriented architecture (SOA) using Web services and a business process management tool. This experience gives me confidence to share with you the secrets to building the ultimate SOA. The following lessons learned will allow your company to move from reliance on ERP applications to application and vendor independence. Your company will begin operating in real time, and the word batch will take its place next to punch cards in the IT department’s lexicon.

Avoid the "blame the middleware" game
When we first built our SOA, we put everything in the middleware. It did the XSL transformation for the target Web service, queried the UDDI for the location of the target Web service, and invoked the target Web service. Suddenly, every problem in the project could be blamed on “the middleware.”

So we took everything out of the middleware, and it simply became a “wire” connecting one application to another. The source gave the middleware the XML, and the middleware parsed the XML to find the intended destination and passed the XML to the target. The target was responsible for transforming the XML.

The lesson here is: Remove everything you possibly can from the middleware and use it only to represent the business processes or moving XML from one location to the other.

Master XSLT to convert data to any format
XSLT is essential for cross-application communication. We have yet to find a system that can't talk with another system with the help of a little XSLT. XSLT is a paradigm shift and requires first-time users to start off with a small function and build from there. My favorite book is Beginning XSLT by Jeni Tennison. It contains 90 percent of the XSLT you'll ever use.

Plan to fail/notify by mail
Everyday, networks go down, databases fail, application servers bomb, XML is malformed, XSLT doesn’t do what you thought it was supposed to do, and yes…you actually created a mistake in the middleware. So prepare for it and automate the handling of these everyday problems. Don’t let people handle them manually. This will only cause problems when they want to go on vacation or move on to new projects. Instead, approach the project this way:
  • Set up mail groups based on systems or integration points.
  • List all the errors that could possibly be attached to a system and one generic error for the ones you forgot.
  • Allow users to set up the errors for their system.
  • Allow users and developers to administer which errors they want to be notified about based on system and integration points.

Users will beg to have the errors resolved, since the notifications will start filling up their inboxes. The developers cannot ignore them and let them happen.

During the first weeks of the implementation, we calculated the top errors for each integration point to set our priorities on which errors to address first. Now, our developers are rarely notified about errors from production.
  • We built queues and actions to take care of the errors.
  • We used first-in/first-out queues to handle application downtimes.
  • We notified the source system to resend records that did not get into the target system.

If someone entered the wrong WSDL file location, we requeried the UDDI on a set interval so that the developer could simply update the UDDI and not have to resend the record.

The entire SOA appears to be humming along, even when problems occur, because the middleware and queues take care of the errors. Now the developers manage by exception and are able to focus on future business development initiatives rather than on maintaining the old.

Bless dynamic invocation
If you're creating an SOA, learn to dynamically invoke a Web service. This will give you one Web service client that will invoke any target Web service by passing the WSDL file location, the method you want to invoke, and the proper parameters to the client. This will cut down on maintenance. We used Apache’s WSIF for this project. If you build a client for every single Web service, you'll have to modify the client each time the Web service changes.

UDDI: The corporate services directory
We implemented an Enterprise UDDI using Systinet’s WASP UDDI. This made the difference between an SOA and an Enterprise SOA. The UDDI began to serve as the corporate directory of available Web services. Developers were associated with these Web services so that developers from other systems could contact them for passwords and testing coordination. We put together a manual of “how to plug into the enterprise” to show to developers of newly acquired/merged companies.

Developers query the location of the Web service based on a unique key (binding key). If the production server goes down, we can point all the binding keys to the Web services on the backup production server.

Debugging SOAP messages
A Web service is about sending and receiving SOAP messages. I send a SOAP message, which is like a letter enclosed in an envelope, to you. The SOAP body is enclosed within the SOAP envelope. I'm in control of the body until I put it in the envelope. The target system is in control of the SOAP body once it's able to open the envelope. However, at times the target system doesn't recognize the SOAP envelope as a valid SOAP message. This is particularly true in Java to .NET Web services using dynamic invocation because the SOAP message is dynamically created for you.

Fortunately, there are SOAP monitors that will capture the messages being sent between applications. You can see how the SOAP message, from the source system, is structured and modify it. We use the free SOAP monitor that comes with Axis (SOAP server) from Apache.org. We even use it to debug the .NET SOAP messages.

Tips for success
Here's some advice for designing an SOA using Web services:
  • Only use the middleware to route messages from source to target.
  • Become proficient in XSLT to massage the data once in the format understood by the target system.
  • Create an error notification system.
  • Become proficient in dynamically invoking a Web service to cut down on maintenance.
  • Get a SOAP monitor so that you're able to see what the source is sending the target.
  • Become an expert in manipulating SOAP messages.
  • If you're serious about creating an Enterprise SOA, look into acquiring a UDDI.

Editor's Picks