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 de-couple 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."
Con-Way also has implemented SOA-based component partitioning on many midtier J2EE-based and Web-accessible applications.
Some corporate IT groups take coarse-grained SOA to its logical extreme. "SOA for us is mostly providing a rational framework for distributed server connectivity between distinct application servers," says Adam Blum, director of server engineering at Good Technology, a Santa Clara, Calif., provider of wireless products.
"For example, our e-mail servers behind the customer company firewall, which connect to Microsoft Exchange and forward e-mail, need to connect to our hosted router for forwarding traffic and to our Web store to validate purchased licenses. We do this through a set of XML messages. An important aspect of SOA for us is expressing common abstractions [users, customer companies, messages, licenses, server information] in common ways."
2. Service reuse: The big payoff
Service reuse is where SOA pays off. Companies that make the most of SOAs train, encourage and reward programmers to reuse existing services -- no matter who developed them -- to the maximum extent possible.
In an SOA nirvana, programmers would write as little new code as possible when constructing new applications, and the only new code would simply orchestrate new interaction patterns among existing services.
Greater service reuse translates into lower costs and accelerated development cycles. "In 2004, we were able to implement several major business initiatives within extremely short timelines, because of our ability to reuse existing functionality and to protect existing consumers from the impact of changes to existing functionality," Tibbling says. "Our core business components such as Customer and Shipment offer services that every single application ends up using. This has allowed greatly enhanced time to market for subsequent projects."
In practice, service reuse depends on middleware that allows any service to interoperate with any other service over networks. Increasingly, Web services environments are the middleware fabrics of choice for SOA, leveraging WSDL, SOAP and other WS-* standards. But in SOA implementations, services are being shared, reused, orchestrated and invoked over a broad range of legacy middleware environments that interoperate in various ways.
"We chose XML, not necessarily Web services [for exposing application interfaces across our SOA environment]," Thomson Learning's Crowhurst says. "We transfer XML over HTTP, and XML over file transfer. We also do XML over message queuing transports for abstraction of application interfaces."
Con-Way Transportation runs SOA over a heterogeneous, evolving middleware environment in which Web services are still just a bit player. "We are using Tibco BusinessWorks to orchestrate asynchronous business processes in near real-time using [J2EE] ServiceLocator [patterns], but invoked from the integration infrastructure," Tibbling says.
Con-Way's XML Web services implementation is growing. Nevertheless, it also is given J2EE a growing role in its SOA. "Java Message Service is being used more and more," Tibbling says.
"As we upgrade our J2EE environment, we anticipate using MessageBeans as process triggers into the integration layer," she adds.
Con-Way isn't the only SOA shop that has limited its use of Web services primarily to support external interoperability. "We've selected IBM WebSphere as our primary application server," Standard Life's Ireland says. "We also use Java as our principal development language, IBM WebSphere MQ Integrator as our [message-oriented middleware] integration platform, and XML as the markup syntax for all interoperability interfaces. . . . We don't see the advantage of using Web services and SOAP [in place of WebSphere MQ] for integration. But we will use SOAP when it's appropriate, such as for B2B integration."
3. Service brokering: Ads pay
Service brokering encourages reuse by allowing developers to "advertise" their programs' service contracts and other descriptive metadata in a shared online registry, repository or catalog.
Service brokering infrastructures take many forms and are often specific to particular middleware or platform environments. The UDDI standard defines a service-brokering environment for Web services.
The UDDI standard is part of the emerging world of Web services. Other common service-brokering environments include Common Object Request Broker Architecture Naming Service, Distributed Computing Environment Cell Directory Service, Windows NT Registry, Java Remote Method Invocation Registry and Electronic Business XML repositories.
If they wish, companies also can deploy a database management system as a service-brokering node for their SOA.
"Our SOA environment includes a runtime business service directory that runs on IBM Universal Database/DB2 on a mainframe," Ireland says.
Abebooks has implemented a hybrid UDDI/LDAP registry architecture, according to company CIO Minard. "We've implemented an open source UDDI registry outside our firewall to publish external service interfaces that our partners can use to connect to our services. The external UDDI registry uses LDAP to do lookups of the master service directory that sits behind our firewall."
Platform-agnosticism is the essence of true SOA. Companies should take care not to introduce specific dependencies on WSDL, SOAP, UDDI or any other Web services standards or specifications. SOA implementers should treat Web services -- and any other development, interoperability and operating environment -- as implementation details.
"SOA is clearly a work in progress. Actually, SOA is a target state that many organizations may approach but never fully attain. It's all about achieving maximum reuse and minimum redundancy of services throughout complex, multiplatform distributed environmentss."
Kobielus is a senior technical systems advisor at EXOstar. He can be reached at james_ email@example.com -- Network World (US)