Many companies that have embraced Service-Oriented Architecture (SOA) concepts start by creating reusable services from existing applications. With billions of lines of code representing decades of business logic, it doesn’t make sense to throw it out and start over. Harvesting these assets to fashion SOA components makes sense financially and technically.

There are many tools that let companies build services without having to modify what may be brittle applications. Putting a service facade in front of the application is an easy way to create the service building block. The service facade separates the service requestor from knowledge about how the service is being rendered. The flexibility of this loose coupling between requestor and provider is a major SOA benefit.

Loose coupling has great value for reducing inter-application dependencies and increasing flexibility, but that’s only part of the SOA story. Creating services from existing applications facilitates flexible, agile business processes. Once the services are created, they can be easily wired together to produce process flows that can be managed with Business Process Management (BPM) tools. Services can be plugged in or out of the process flow without deep IT knowledge or skills. Services can be reused in multiple process flows without having to create multiple copies.

As SOA has matured, the focus has shifted toward combining these newly minted services into flexible process flows. Tools are emerging that enable building and managing process flows from these elemental service components. The architectural view of two such process flow tools from IBM is the subject of this article.

WebSphere Process Server

WebSphere Process Server (WPS) is IBM’s business process integration server that facilitates development and deployment of component-based business integration applications in SOA. WebSphere Application Server (WAS) provides the run-time environment for WPS. This open standards-based process management tool can use underlying WAS capabilities, such as workload management, transactional integrity, clustering, failover, security, etc., to provide a robust, scalable integration environment.

The architectural model for WPS is comprised of three main layers: the SOA Core layer, the Supporting Services layer, and the Service Components layer (see Figure 1).The SOA Core layer includes two uniform programming models: the Service Component Architecture (SCA) and the Service Data Objects (SDO). At an invocation level, the SCA programming model renders integration artifacts as service components with well-defined external interfaces. SCA facilitates grouping service components into modules. Modules form complete integration solutions and provide a layer of encapsulation for the integration logic. Changes made to a service in a particular module don’t affect other interconnected modules, provided the interface to the changed module is intact.

At a data level, the data representation model, SDO, provides a universal way to describe disparate data. SDOs implement business objects, which are the primary mechanism for representing and accessing the data flowing between service components. SDOs decouple the data definitions from actual implementations.

The Supporting Services layer equips WPS with mapping, transformation, and synchronization capabilities. This layer primarily consists of Enterprise Service Bus (ESB) functions. The WebSphere Enterprise Service Bus (WESB) is packaged with WPS and provides most of these services.

The Services Components layer of WPS includes support for business processes, human tasks, business state machines, and business rules. These ready-to-use SCA functional components are vital for building composite applications. Business processes are choreographed using Web Services Business Process Execution Language (WS-BPEL) as the representation. WSBPEL models are either created using the WebSphere Integration Developer (WID) tool or are imported from a business model constructed in WebSphere Business Modeler (WBM).

6 Pages