Book Image

SOA Cookbook

By : Michael Havey
Book Image

SOA Cookbook

By: Michael Havey

Overview of this book

<p>SOA Cookbook covers process-oriented SOA. BPEL is the best-known language in this area, and this book presents numerous BPEL examples. It also studies proprietary vendor process languages such as TIBCO's BusinessWorks and BEA's Weblogic Integration. If you are building SOA processes in the field, chances are you are using one of the languages discussed in SOA Cookbook. The book assumes that the reader is comfortable with XML and web services.<br /><br />Author Michael Havey works with SOA in the field for TIBCO (and previously for IBM, BEA, and Chordiant). SOA Cookbook is Michael's second book. Essential Business Process Modeling, his first book, was published in 2005.</p>
Table of Contents (14 chapters)
SOA Cookbook
Credits
About the Author
About the Reviewers
Preface

The Model Stack


Three-tier CORBA-based architecture has evolved into the SOA architecture, depicted in next figure. The ORB has been replaced by an Enterprise Service Bus (ESB), which acts as a service broker for the organization, routing messages between participants. IIOP is a thing of the past. External clients and partner services now use SOAP over HTTP to access services through the bus; internal ones typically use MOM queues as their access mechanism. Services are orchestration processes, which run either in a single burst (accepting the client request, running through a short string of processing steps, and sending back the response) or in multiple bursts (accepting multiple requests over time, and interacting with partner services in a conversation). (Refer to Chapter 5, a comparison of short-running- and long-running processes, for a precise definition of 'burst'.)

BPM, absent in the CORBA architecture, is a vital part of the SOA stack. The contemporary use case has both human and system activities, which when developed on this architecture are split between BPM processes and SOA orchestration processes. (Chapter 3 discusses BPM/SOA 'splitting' techniques.) Finally, like CORBA objects, SOA services integrate with legacy systems.

SOA vendors that sell platforms to support this architecture divide their stack into three pieces, shown in the next figure. At the bottom of the stack is the ESB, which is often bundled with the vendor's own MOM implementation; if the vendor does not have MOM, the ESB builds in support for third-party MOMs. Next up is an engine to run orchestration processes. This piece is sometimes referred to as the process integration engine, and it typically includes a variety of controls to help integrate with the backend. These controls simplify database access, data transformation, MOM integration, and other common integration needs. Some vendors also sell adapters (for example, mainframe adapter and SAP adapter) that plug-in to the process integration engine, providing orchestration processes with simplified access to major systems. At the top of the stack is the BPM engine, which executes BPM processes. The vendor builds in a bidirectional interface between the BPM engine and the process integration engine, allowing orchestration processes to call BPM processes and vice versa. The following two pieces are the 'SOA' part of the stack.

The following table divides the four leading SOA vendor suites into BPM, process integration, and ESB parts.

Vendor

BPM

Process Integration

ESB

TIBCO

iProcess

BusinessWorks

ActiveMatrix

BEA

AquaLogic BPM

Weblogic Integration

AquaLogic Service Bus

Oracle

'Fusion' BPA Suite

'Fusion' BPEL Process Manager

'Fusion' Enterprise Service Bus

IBM

Websphere Process Server, FileNet

Websphere Process Server, Websphere Interchange Server

Websphere Enterprise Service Bus, Websphere Message Broker

Sometimes smaller niche vendors combine forces to offer this stack. An example is the Lombardi's partnership with Progress; Lombardi provides BPM with Teamworks, which sits atop Progress' Sonic ESB.

A vendor with a good MOM implementation has street cred with customers. SOA might be the flavor of the month, but the vendor must demonstrate that it can solve the age-old problem of moving events swiftly and reliably at high volumes. IBM boasts that its ESB runs on MQ/Series, and TIBCO wins many deals because its SOA solution uses workhorse MOM products—Rendezvous and the Enterprise Message Service (EMS). BEA, despite having one of the industry's leading TP monitors in its arsenal (Tuxedo), insists that it's the application server that matters most, and brags that it has the best application server. Oracle has street cred in the database realm, and tells customers that database street cred matters most for SOA.

Standards, particularly web services standards, influence the design of the stack. Service interfaces are published as WSDLs. Messages are transported as SOAP over HTTP. Message payload is XML, which can be described with XSD and manipulated with XPath, XQuery, or XSLT. Services are registered with a UDDI registry. Service handling is subject to security (WS-Security, SAML), transactional (WS-Transaction), and reliability (WS-RM) considerations. On the process front, there is a standard visual notation for modeling (BPMN) and a standard programmable form for execution (BPEL). Standards are both a blessing and a curse for vendors. Some of them genuinely help make a better design. Others are useless but need to be supported to win customer deals.