Service-Oriented Architecture: The Future is Now

Service-oriented architecture (SOA) is the foundation of a new platform consisting of loosely coupled software parts. And as anyone reading the computer industry press could attest, the SOA notion is sweeping the application, process management, and integration sectors of the software industry. Major vendors, including BEA, IBM, Microsoft, SAP, and WebMethods are making SOA the new paradigm for their software and application offerings. As with past computing platform paradigms, the clear goal of SOA is to reap the benefits of software assembly and enable the construction and maintenance of better, faster, and cheaper applications. The difference is that SOA ushers in a new era of "synthesized" computing. The synthesis rests primarily on XML's role as a common denominator across virtually all aspects of computing, including messaging, storage, and the new breed of computing languages and specifications.

The common perception is that the major value of SOA lies simply in the ability to connect and integrate enterprise applications. However, this represents a narrow view. The greater value of SOA comes when you take a broader perspective on integration and grasp the potential efficiency that comes from connecting software "artifacts" encountered along the way — and thus make everything interact in a coherent manner. A typical organization has spreadsheets, email packages, instant messaging applications, calendars, ERP systems, CRM systems, and more, each of which has, at a minimum, its own software interface. SOA addresses how you can connect these software artifacts in a flexible, logical fashion to streamline daily business processes. The result of which is a newfound cohesiveness between transactional, document, and collaborative systems.

While most business processes are associated solely with specific enterprise systems, we actually use all of the software artifacts mentioned in the previous paragraph, and more, to perform daily functions as participants in our portions of business processes. The difficulty is that these enterprise- and artifact-specific processes are so disjointed that we struggle to conceive of them as parts of larger business process flows. SOA aims at enabling a more powerful software platform that ties together disparate activities and systems, increasing productivity, efficiency, and business agility. Whether sending a request for proposal (RFP), emailing a colleague about a decision on a credit-hold order, or checking a customer's daily sales, we are performing activities that contain predetermined rules and workflows that can — and should be — organized, analyzed, and monitored.

A few years ago, Web services arrived on the scene with great fanfare: but the uptake has been slow. This is because customers are looking for more comprehensive solutions than what first-generation technology offered — customers insist upon transaction, security, and reliability support on par with dedicated middleware packages. Unmet demand has put SOA on the fast track. However, SOA is an enterprise-level technology and as with all high-end offerings, embracing it, especially rapidly, requires organizations learn a new set of technologies and begin thinking of systems in terms of loosely coupled services. The learning curve is not trivial.

Throughout the history of software, it has been the case that the more you automate, the greater the additional complexity — and the greater the difficulty of changing systems in the future. A major goal of SOA is to establish a more advanced "manufacturing" process that breaks from the past by supporting incremental change. The goal is that systems will incorporate new functionality without compromising future flexibility.

SOA Components

Presented in three parts, this article will explore five components that build on each other to establish the benefits of SOA. Before delving into each component in greater detail, let's consider all five more briefly to gain the big picture.

Integration framework. Standalone software applications consist of and are assembled via message transmission between their internal operations. Messages benefit from the security and reliability built into the applications. In addition, common semantics to support such benefits as data models with consistent customer records and algorithms that can work against a common way to calculate pricing. SOA looks to make much of this infrastructure and semantic support available as services, and, thus, to drastically reduce the barrier to integration and software reuse and usher in pervasive distributed computing.

Synthesized computing. A typical business process spans multiple enterprise systems (such ERP, CRM, and legacy), productivity systems (including Microsoft Excel, Word, and PowerPoint), and collaborative systems (such as email, portal, phone, and fax). Orders that go on credit-hold commonly necessitate emails and phone calls between sales, accounting, and customer service to determine whether to extend the customer credit. Finance fills in spreadsheets to tally and characterize orders that its policies might override. Credit-hold calculations require data and processes across ERP and CRM systems. SOA needs to support the synthesis of parts to enable efficient enterprisewide business processes.

Abstracted service taxonomy (AST). AST is the extraction of business system and platform component functionality into a grid. The grid groups together like business functionality, including customer, order, and invoice, across business systems. The AST grid joins these with platform component system functionality, including search, index, and workflow. The AST extraction solves three major problems: lack of access to business system functionality; complexity required to manage redundant and incompatible information and functionality across systems; and inability to employ platform functionality across all or most enterprise business processes.

Business activity monitoring (BAM) and events. Emerging event-based computing is complementary with SOA. Both paradigms benefit from loosely coupled services. As events occur — for example, an order ships late — an SOA-based system can trigger actions by calling other services. Through services, direct access to business intelligence (BI) systems enables quick analysis to determine what actions are warranted. Ties to collaborative systems enable an organization to tie the associated routing and escalations to the process. Events should be trapped across all aspects of the SOA, including the layers of the AST stack and across the process. Events should be trapped across all aspects of the SOA, including the layers of the AST stack and across the process life cycle, which is summarized in the next paragraph and will be discussed in detail in the third part of this article.

Full life-cycle process. As the practice of creating software evolves from writing custom code to assembling services, the processes created differ from their predecessors. The inner workings of processes created by custom code are largely unknown, unquantifiable, and fragile. Processes assembled from services with well-defined interfaces are substantially more predictable and understandable. The more robust makeup of these processes, combined with the new products designed to exploit them, will foster a new genre of full life-cycle processes that provide additional functionality above and beyond standard computation.

With a sense of all five components, let's turn to each in more detail. Part one of this article will explore the integration framework. Parts two and three will discuss the remaining four components.

Integration Framework

The SOA integration framework is an improved software manufacturing process. It leverages standardized software parts and connectivity to increase the ease and amount of functionality available for reuse, which will enable better, faster, and cheaper software automation. The integration framework, which enables discrete software systems to communicate at the process level in a standardized way, represents the next step in business process integration (BPI).

The goal of an SOA integration framework is to enable software assembly and interoperability, whether you are creating an application or integrating multiple applications. The integration framework does this by addressing the following goals:

SOA differs from past component and integration technologies. Unlike past component technologies — DCOM, EJB, and CORBA — that forced common middleware technology on both sides and communicated via proprietary messaging, the integration framework enables customers to use their current systems and communicate via standard messaging. Prior integration technologies utilized expensive proprietary tools that required specialized training and highly skilled and costly developers. The outcome was custom integration that was not usable by other applications. SOA support is being built into all popular development tools.

Benefits of Vendor Unity

SOA has become feasible thanks to a standardized messaging infrastructure using the Internet; XML, which offers a flexible, extensible, and widely accepted industry standard messaging format; 30 years of accumulated business logic that may be repurposed; and recent tools that are making it easier to integrate software. In principle, all major enterprise application, integration, platform, and development tool vendors all agree on SOA. This differs from the recent past, when enterprise application vendors were pushing closed enterprise applications, proprietary application connectivity, and proprietary component technologies; and platform providers were offering expensive, proprietary integration. Although each has its own version that naturally grows from its competitive interests, the unity about SOA in principle is different.

Thus, SOA is a new architecture derived from standardized parts and messaging that portends to change the way software is developed and shatter the difference between software applications and integration. SOA is a disruptive technology that will change the nature of application development. It will enable the creation of composite applications, even by nondevelopers using tools like Microsoft's Visio.

More mature manufacturing industries, such as automobiles, have a clear separation between component development and assembly and configuration. Software can now allow the parts to keep advancing, as can happen in automotive assembly. There, makers can use many automobile parts across models and manufacturers. SOA is creating the same dynamic in software: Service developers will code services and interface developers and business users will model and configure them into useful composite applications.

The SOA integration framework, with a more solid messaging and service infrastructure, forms the basis of all other SOA derivative benefits to be described in the next two installments: synthesized computing, abstracted service taxonomy, BAM and events, full life-cycle processes.

SOA and Scale

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