In-Depth

SOAs: Defining the Integration and Orchestration of Services

Service-oriented architecture starts with simple application integration and culminates with service choreography and next-gen “composite” applications

• By Stephen Swoyer
• 05/25/2004

SOA is a hot topic. Very hot.

Application vendors, for one, are mightily enthusiastic about SOAs. SAP, for example, touts its NetWeaver application architecture as a cure for the integration issues that have traditionally bedeviled even the most straightforward of ERP implementations. Similarly, CRM powerhouse Siebel Systems Inc. has invested millions in its Universal Application Network (UAN), while PeopleSoft Inc. touts its AppConnect architecture.

The common theme in each of these next-generation application architectures: the painless integration of your ERP applications with in-house and third-party applications, along with enhanced business value as a result of integration in the context of an SOA.

There's good reason for these (and other) vendors' optimism. Consultancy The Hackett Group, for example, says that SOAs—in tandem with associated technologies such as business process management and Web services—will “allow business processes to be much more flexible than possible with today’s rigid ERP architectures.” In fact, write Beth Hayes and Greg Pleasants, both senior business advisors with Hackett, “The technology is still in the early stages but service-enabled programs will free businesses to rapidly adapt their processes and to align strategic and technology architectures."

The Elusive Definition

Sounds great, you say, but what is an SOA, exactly? That seems to be the rub, says Steve Wilkes, technology analyst at The Middlware Company, a technology consultancy that sponsors a variety of knowledge sites—such as http://www.theserverside.com (J2EE), http://www.theserverside.net (.NET), and http://www.middlewareresearch.com. According to Wilkes, “We’re still at a point where the industry hasn’t 100 percent defined [SOA], and there can be some confusion around exactly what does SOA mean.”

To that end, The Middleware Company has produced a generic “blueprint” specification that can be used as a launch pad for ISVs and enterprise IT organizations to develop applications that exploit SOAs. At least one vendor, BEA Systems Inc., has based its own SOA application development blueprints on The Middleware Company’s specification.

Why the need for SOA blueprints? According to Wilkes, some SOA boosters have defined the technology largely in terms of Web services, which he argues is a mistake. “One of the things that we’re trying to fight is the association of SOA with Web services,” he confirms. “Because Web services got such a big rise to fame recently, people know about SOA because of Web services, but there’s a lot more to it than that.”

Wilkes and other SOA proponents argue that the technology must be able to encompass not just Web services standards such as SOAP and WSDL (as well as WSI), but application architectures such as J2EE and .NET, and—perhaps, to some extent—component architectures such as CORBA. In many cases, some experts say, it may also be necessary to use transport mechanisms other than HTTP to facilitate Web services interactions.

Take Web services messaging, for example. Kareem Yusuf, lead product portfolio strategist for IBM’s WebSphere platform, says that people usually think of messaging strictly in terms of SOAP over HTTP—although that doesn’t have to be the case. “When I say Web services, I am not necessarily implying that the interaction with that application is SOAP over HTTP. A very common pattern is SOAP over JMS, and what we have tried to provide by means of our implementation framework is to allow you to support SOAP over a variety of transports,” he comments.

Broadly speaking, then, a service-oriented architecture is a collection of services that communicate with one another across disparate applications and business units. In an SOA, services—which are often mapped to both manual and automated business processes—can invoke other services, often dynamically, as needed. Depending on how you’ve implemented it, your SOA can depend somewhat or entirely on Web services standards.

Integration: Choreographing Services

Sounds great, you say, but how do we get there from here? The answer involves integration of some kind—whether it’s straight-up integration by means of Web services standards or more complex integration scenarios that involve application architectures (such as SAP’s NetWeaver, PeopleSoft’s AppConnect, or IBM’s WebSphere Business Integration).

One principal underlying each of these approaches is what is known as “service choreography,” which IBM’s Yusuf describes as “the coordination of the interaction of a number of services based on some business logic and associated rules.”

Take a typical loan approval process, for example: “I could have a number of services associated with that process—such as .., a service to check the credit, a service to retrieve existing customer records, so on and so forth—and so the idea is how to orchestrate these services so you can move to the next service in the flow,” he says.

Service choreography, as described by Yusuf, involves the orchestration of both manual and automated processes.

“You’re bringing it all into this automated application, because one of the things that you can do around the manual aspects, you get into the concept of what we call staff resolution—or who should be assigned this particular task. You can even orchestrate processes like this,” he explains.

Service choreography is a more sophisticated aspect of the SOA building process, however. Before IT organizations can actually choreograph services between and among disparate systems, they must first integrate them.

In this respect, Yusuf and other advocates say, many customers are already taking baby steps toward SOAs—even if they don’t know it. “There are people doing application integration and various aspects of SOA, but it wasn’t called SOA when they started doing it,” says Salil Deshpande, CEO of The Middleware Company. “As this pattern gets more clearly defined, and as efforts like ours help doing that, more people will figure out, this is a best practice and this really works.”

The culmination of the SOA vision is what IBM’s Yusuf describes as “composite applications”—or applications that are essentially comprised of the interactions of other applications. “Where SOA fits into all of this is really across the entire stack, it really comes down to say that all of these interactions can be described in various ways as services. The idea is that I can choreograph those services together to create more complex services, and I also want to be able to discover services that I have either previously integrated,” he explains.