3 steps to SOA nirvana

Here's a primer on the three core concepts behind service-oriented architectures :

1. Service virtualization

A service is a reusable chunk of code that can be invoked by other developers through a published metadata interface, known as a service contract.

"SOA requires that you stay at a high level in defining these reusable business services, rather than drill down too quickly into application code," says Christopher Crowhurst, vice president and principal architect at Thomson Learning, a Stamford, Conn., business unit of Thomson Corp. that provides technology and assessment services worldwide.

Under SOA, each service should have a recognizable business function that plays a clear role in multiple applications, adds Derek Ireland, group tech solutions manager at Standard Life Group, an Edinburgh, Scotland, insurance company. "Examples of these reusable business services in our SOA include 'provide pension valuation,' 'verify identity,' 'provide bank details,' 'maintain address' and 'produce statement.'"

Currently, we have around 300 business services in our SOA service catalog," Ireland adds. "These services are high-level business functions that abstract away from the underlying complexities of our principal platforms: WebSphere Application Server, WebSphere Business Integrator, WebSphere MQ IMS and .Net . Our SOA software framework allows the development teams to concentrate on the business aspects of the application under development," he says.

Another core SOA tenet is that services should have stable, well-bounded sets of functionality, so a change in the service's underlying implementation won't disrupt interoperability with existing consumers of that service.

"SOA is an approach for defining clear boundaries between business and technical services that need to be decoupled," says Jayson Minard, CIO at Abebooks, an online book marketplace in Victoria, British Columbia.

Typically, stable service contracts are coarsely detailed, which means they describe the interface to an entire business process or a substantial subprocess, rather than to the details of a particular platform's object model, classes and APIs.

But users are taking whatever approach best meets their particular needs. For example, Abebooks' SOA is based on the need to define fine-grained business services that correspond to particular business-to-business technical-integration connections.

Abebooks uses SOA practices to decouple the integration logic through which its Web sites connect with business partners.

More than 13,000 booksellers from 48 countries list their books on several Abebooks sites, and major online booksellers, such as Amazon and Barnes & Noble, have outsourced their used-book operations to the firm.

"We have a lot of legacy Java code, which we need to continually tweak to address the data translation and other functions specific to various partner integrations," Minard says. "Without clear boundaries among various code segments associated with partner integration, we would risk disrupting global interoperability with all of our partners every time we changed, say, a data-translation routine for one partner."

Maja Tibbling, application architect with Con-Way Transportation Services in Portland, Ore., adds, "Services can be fine-grained, such as a logging service, or coarse-grained, such as those services that contain an entire business process. Services should be defined at whatever granularity best promotes their reuse."

Con-Way's ongoing SOA initiative began in the late 1990s as a way to implement component-based development of mainframe applications. "Since then, we have successfully ventured into the [Java 2 Platform Enterprise Edition ] world and have deployed many business applications in the middle tier with Web-based front ends. So the next step [for SOA] was consuming the same back-end shared services through vendor-provided Java proxies to the mainframe."