Service-Oriented Architecture: The Future Is Now 2

Some believe that Web services and SOA are magic — others believe that they're nothing. I think the move toward SOA and away from simple Web services has proven that something more substantial to handle complexity was needed. Integration was occurring even without SOA, as were other SOA benefits, including the graphical modeling of business processes. The software industry would have continued to progress slowly. However, the advent of the Internet brought Web service standards and XML. Now, new tools can move 30 years of processes into the mainstream.

There may be very little in SOA that could not be done without it; SOA just increases the scale, which is necessary for organizations trying to bring sophisticated applications to the masses. SOA enables mass services and standardized messaging, which combine to create a new distributed computing architecture.

In the next installment, I will continue with a discussion of the four other key components of SOA: synthesized computing, AST, BAM and events, and full life-cycle computing.

Robert Eisenberg [[email protected]], principal of RE Associates, consults, speaks, and writes on business process management and service-oriented architecture. He has owned two software companies, sold one, and held a senior IT position at a public corporation.

SOA: Essential Standards

The SOA standards are useful alone or put together to provide additional functionality. If you need simple interoperability, simple object access protocol (SOAP) and Web Services Description Language (WSDL) form a good combination. For more complicated process flow, Business Process Execution Language (BPEL) is the correct choice. Adding one or more WS-Security specifications would provide guaranteed delivery, federated security, or other functionality, if desired. The reason for putting standards together into a "composable" architecture is that then you can have simple stacks for noncritical activities and other stacks for partners with limited capabilities. Sophisticated operations with larger partners can embrace more complicated standards that lie at higher levels of the stack.

This sidebar presents some of the key SOA standards. More will be presented in later installments of this article.

Transport. An SOA must support standard Internet protocols, HTTP, HTTPS, and SMTP. Others, including TCP/IP are optional.

Messaging. An SOA must support XML, SOAP, and WS-Addressing to enable message encoding. XML and XML Schema provides a standard way to describe the message. SOAP enables message encoding. WS-Addressing separates addressing from transports. This is useful when you want asynchronous services to listen on a different address; support correlation in long-running services that require human intervention; and allow message processing through intermediaries.

Description. Web services afford a standardized way to describe services — in a way that isn't tied to any middleware platform, development environment, or system of protocols. Your application system can describe services, using XML Schemas embedded in WSDL contracts, which any vendor's development tools can consume. WS-Policy contributes semantic information about a service, augmenting the technical description capabilities in WSDL and XML Schema Definition (XSD). With WS-MetadataExchange, development tools can extract the WSDL and WS-Policy information from a service.

WSDL. The embedded schemas in XSD describe the types or objects: for example, customer or purchase order and the message syntax, such as "SendPo." The WSDL contract groups the messages into synchronous and asynchronous operations, and binds them to transports and endpoints.

- Robert Eisenberg