Thu, July 10, 2008 — InfoWorld — Time to get your feet wet. Take that whiteboard map and focus on one area as a pilot project. Identify a key point of redundancy in your set of related applications, spec out your first service, decide who will build it with what tools, and start provisioning. After testing, you can start modifying apps to call your new, shared service.

What basic characteristics should a service have? Timothy Vibbert of Lockheed lists them: “They’re reusable, they have a contract, they’re loosely coupled, they’re stateless, and they’re discoverable.” Most SOA practitioners would add that a service should also be “coarse-grained”—that is, it should map to a business process step or function rather than, say, an application component. This helps ensure reusability and avoids overlap with other functionality.

Scott Thompson of H&R Block learned the value of the coarse-grained approach the hard way. “I think in our early design, we tended to develop services that were more in tune with our object layer than they were true business services, and so the reusability of those wasn’t quite as high as what we had liked it to be,” he says. “So we’ve gone back and redesigned a lot of our services to be more reusable, not only to a specific project but really more in tune with the business purpose that they were designed to serve.”

Several stovepipe applications, for example, may have their own way of opening a customer account. Create a single coarse-grained service that each application can call on to open an account, and you eliminate redundancy and reduce application maintenance. Along the way, you may be able to glean other benefits: better compliance information, more security across a single repository rather than multiple data dumps, and better Web site management.

Typically, services are published as Web services—which promises the greatest potential for reuse because the standard protocols that define Web services are designed to transcend platforms and programming languages. In practice, however, SOAs typically expose other types of services, such as those accessible via JMS (Java Message Service).

How do you decide what type of service to use? “One thing it depends on is the payload,” Lockheed’s Vibbert says.

“If the messages you have going back and forth have relatively small data sizes, Web services are fine.

Or if it’s not time-critical, Web services are probably the best choice. But if you’ve got things that involve large amounts of data going back and forth or are time-critical, you might not go with a Web service” and instead build a service accessible through JMS or some other binary protocol.

Services can be deployed on Java application servers, on Windows Server, or provisioned on legacy systems themselves—and thanks to Web services interoperability, your developers can generally choose their favorite tools and platforms for provisioning. “One of the things that a service-oriented architecture gives you is the benefit of rendering that decision secondary,” says Charles Stack, CEO of SOA registry provider Flashline. “You can change deployment platforms at the service level without affecting your service-oriented architecture. Services abstract that very infrastructure level. It’s much less of a strategic decision than that sort of thing used to be.”

Correction:
In this article, Flashline's company description was originally misstated. The error has been corrected.

 

Eric Knorr is executive editor at large at InfoWorld. Oliver Rist is senior contributing editor of the InfoWorld

© IDG 2009