Introducing IBM BPM and ESB : IBM SOA Reference Architecture & Introducing IBM WebSphere Process Server

IBM SOA Reference Architecture

IBM's SOA Reference Architecture defines a vendor and technology agnostic set of comprehensive IT capabilities that are required to support your SOA at each stage in a typical SOA life cycle. When an organization defines a solution architecture based on this reference architecture, they would not need all of the capabilities needed initially. But over time, to be successful in SOA, all the capabilities need to be evolved and added.

What is Reference Architecture?

A Reference Architecture captures the essence of the architecture of a collection of systems. It models the abstract architectural elements in the domain or a solution area, independent of the technologies, products, and protocols that are used to implement the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain. Thus reference architecture is useful for:

• Providing a common ground domain model

• Basis for realizing an architecture vision

• Providing key architectural guidance and a blueprint as a baseline

Reference architecture is typically abstract and is abstract for a purpose. You typically instantiate or create solution/system architectures based on the reference architecture. Example reference architecture includes Unisys 3D Blueprints, IBM Insurance Application Architecture, and NGOSS reference architecture from the TM Forum, and so on.

Key elements of IBM SOA Reference Architecture

The IBM Software Reference Architecture is a reference model that lets you leverage information, applications, and tools as services in an interoperable, system-independent way. The subsequent diagram shows the IBM SOA Reference Architecture organized around the key capabilities required for building any SOA-based solution.

• Development Services provide the capabilities in terms of development tools for the end users to efficiently complete specific tasks and create specific output based on their skills.

• Interaction Services provide the user interaction capabilities required to deliver the Business Services and data to end users.

• Process Services provide the control, management, choreography, and orchestration of the business processes that interact with multiple services.

• Information Services provide the capabilities required to federate, unionize, and transform data from one or multiple applications or data sources and expose them as services.

• Enterprise Service Bus delivers all the connectivity capabilities required to leverage and use services implemented across the entire organization.

• Business Innovation and Optimization Services provide the monitoring capabilities and manage the runtime implementations at both the IT and business process levels.

• Business Application Services are services provided by existing applications or ones that will have to be exposed by the applications itself including third-party systems.

• Access Services allow access to the end applications, legacy applications, pre-packaged applications, enterprise data stores (including relational, hierarchical, and nontraditional, unstructured sources such as XML and Text), and so on using a consistent approach. These typically leverage the business application services.

• Infrastructure Services provide security, directory, IT system management, and virtualization capabilities to the SOA solution.

• Partner Services provide the capabilities for the efficient implementation of business-to-business processes and interactions.

So what is the relationship between the process integration, key capabilities needed for successful process integration, SOA, IBM SOA reference architecture, IBM WebSphere Process Server, and IBM WebSphere Enterprise Service Bus? The answer is pretty obvious.

Having defined the essential elements for a BPM enabled by SOA approach, having explained the need for a reference architecture, and in particular, what IBM's SOA reference architecture is all about how does it all come together? How would a (reference) solution architecture, based on the IBM SOA Reference Architecture, look? The following figure shows one such instantiation of the "BPM enabled by SOA" solution architecture. It incorporates all of the building explained above, as categorized and organized into the appropriate IBM SOA reference architecture buckets/layers. Also, what each layer and each building block should have as capabilities within itself is explained.

Introducing IBM WebSphere Process Server (WPS)

WebSphere Process Server (WPS) is one of the key and core products in the IBM WebSphere BPM suite. Referring back to the key capabilities needed for a successfully process-driven integration approach enabled by SOA, WPS addresses capabilities including Business Process Execution, Business Rules, Enterprise Service Bus, and a key enabler for Business Process Monitoring. WPS platform provides a standards-based uniform programming model for representation of data, invocation of services, and structure of composite applications. It provides a unified tooling, namely, WebSphere Integration Developer (WID) for the visual development of composite applications.

Role of WPS in SOA

As explained in the previous sections, process integration is fundamentally built on the concept of an SOA. In recent times, most of the applications expose web services. These services, which may be very fine-grained or atomic in nature, will have to be assembled into coarse-grained services that make meaningful sense to the business. A process-driven integration leverages these Business Services as business tasks in the larger choreography or orchestration of a business process. Because of the fact that fine-grained atomic services are assembled into coarse-grained business services, the use of the service is independent of the IT infrastructure needed to accomplish the task. Each Business Service then becomes a building block that, when combined with other Business Services, can become the fundamental building block to realize an end to end business process. The structuring of business processes, in this way, provides a flexible solution to real business problems, allowing the creation of new and modified processes easily. You can use WPS to develop and execute standard-based, component-based Business Integration applications using an SOA approach. The use of standards-based technology, including Web Services, helps to make the SOA vision a reality.

WPS leverages a programming model, which is very fundamental to understanding how applications are developed in WPS and WID (as explained earlier, WID is the integrated development environment for WPS). The programming model has three parts:

1. Invocation Model-defines

   Invocation is the way in which a request is made from one piece of code to another. Programmatically, there are several methods of invocation including REST, HTTP, EJB stateless session beans, JAX-WS, JAX-RPC, JDBC for communicating with databases, JMS for messaging, and so on. WPS has adopted the Service Component Architecture (SCA) specifications as the basis for its invocation model. SCA is a set of specifications that describe a model for building applications and systems using an SOA approach. SCA divides the steps in building a service-oriented application into two major parts:

   • The implementation of components which expose (export) services and consume (import) other services

   • The assembly of sets of components to build business applications, through the wiring of references to services

     SCA uses Service Data Objects (SDO) to represent the business data that forms the request and response values of service and/or components. SCA supports bindings to a wide range of access mechanisms used to invoke services and also through both synchronous and asynchronous programming styles.

2. Data Model-defines

   Programmatically, there are several ways to represent data-EDI message, JDBC row set, JMS message, Java Persistence API (JPA), and so on. WPS has standardized the way in which data is represented and will be using Business Object (BO). BOs are extensions of Service Data Objects (SDO) to provide an abstraction layer for data access. Business Objects include some extensions that are very important for integration solutions and further describe the data that is being exchanged between Service Component Architecture-based services. This includes metadata-like change history or information on the context of the data such as update, create, delete, and so on.

3. Composition Model-how

   WPS has adopted Business Process Execution Language (BPEL) as the way to define the overall business process. When the business process accesses data, it does so by making calls to SCA services passing Business Objects.

Platform architecture

WPS at its core is built on WebSphere Application Server, providing a robust application server runtime with capabilities that the process server implementation can exploit such as Java Message Service (JMS) messaging and enterprise beans. It can also make use of the application server qualities of services such as transactions, security, and clustering. The following image shows the platform architecture of WPS and the different components it is made up of.

The components in the WPS platform architecture can be categorized as follows:

• SOA Core

  The foundation of SOA includes the main components, namely, the Service Component Architecture (SCA), Business Objects (BOs), and the Common Event Infrastructure (CEI). The CEI provides the foundation architecture for the management and handling of events produced by business processes. This is essential for enabling the monitoring of business processes with products such as the WebSphere Business Monitor.

• Supporting Services

  On top of the SOA Core are a set of Supporting Services, which provide the transformation primitives required when building SOA solutions using SCA and BO. These include:

  • Interface maps which enable mapping to semantically similar but syntactically different interfaces.

  • Business object maps, which enable the transformation of business data between fields of Business Objects.

  • Relationships enable the correlation and synchronization of data representing the same business entity stored in multiple backend systems.

  • Selectors provide for a dynamic invocation of a target.

  • Java to invoke Java code.

• Service Components

  Service Components provide different component types that can all be assembled together when building an SOA solution.

  • Business Processes, which are defined using BPEL, realize an executable version of a business process in which the different activities of the process are carried out by making calls to the individual SCA services that implement the specific activities.

  • Human Tasks provide the human task capabilities for people to participate and collaborate with the business processes. Human tasks can be integrated directly into the BPEL.

  • Business State Machines are another way of modeling a business process that are highly event-driven and are well suited to being thought of in terms of a state transition diagram. The Business State Machine component allows you to model the business process using similar constructs as UML 2.0 state machine support and then generates BPEL for the implementation.

  • Business rules enable the implementation and enforcement of business policy business rules and also for them to be managed independently from other aspects of an application. There are two styles of business rules, if-then rule sets and decision tables. A Web client is provided where the parameters of business rules can be changed by a business user using a natural language.

  • Adapters are used for integration with various applications and backend systems that are external to the WPS. Adapters are categorized into technology and application adapters. These adapters are compliant with the Java Connector Architecture (JCA) 1.5 specification.

Common BPM adoption scenarios

In the collection of patterns for e-business, IBM has leveraged its vast experience from its architects and solutions and developed various classes and categories of patterns that can be applied to create solutions rapidly, whether for a small local business or a large multinational enterprise. The site http://www.ibm.com/developerworks/patterns/ breaks down these pattern assets into the following elements:

• Business patterns

• Integration patterns

• Custom designs

• Application and Runtime

• Product mappings

• Guidelines

All of the above integration patterns give interesting insight into how to integrate applications and data within an individual business pattern. At its highest level, application integration by itself is divided into Process Integration and Data Integration patterns.

Now let's look at some of the most common BPM adoption patterns, and more specifically, how WPS can be adopted in real-life client scenarios. IBM's BPM adoption patterns are classified into the following broad categories:

• Process Automation-Streamline and automation of manual business processes to gain and hence optimize costs and efficiency. Examples include:

  • Automation of insurance rate-quote-issue process across multiple product lines

  • Customer billing and invoice inquiry or dispute process automation in the telecommunications industry

  • Order handling business process automation applicable to several vertical industries

  • Member/Patient claims handling processes automation in healthcare

  • Automation of student registration/on-boarding in education

• Capture Insights for Effective Actions-Achieve visibility through monitoring and capturing new insights to seize opportunities and mitigate risks. Business Activity Monitoring (BAM), in combination with role-based dashboards, augments and helps deliver this capability. Examples include:

  • Define time-bound KPIs on loan origination and approval business processes in the banking industry and act on them.

  • Detecting the root cause of service activation failures in the Telecommunication industry and acting on them.

  • Based on strategically defined business goals to improve customer satisfaction (defined as KPI) and improve customer problem handling business processes.

  • Define fraud detection rules (too many withdrawals on an account from ATM, high rate of claims requests, and so on) and act on them appropriate by automating the detection and acting upon processes.

• Discover and Design-Unlock valuable process opportunities and uncover critical improvement areas by focusing on high return on investment (ROI) areas. Examples include:

  • Leveraging existing SOA service models and industry content to rapidly enable process modeling and automation efforts. IBM's Industry Content Packs is a good example here.

  • Define library of KPI models based on the particular industry’s information model, business terms and concepts and use it as a means to measure and monitor strategic business goals.

  • Leverage third-party content, collaborate on process models and bring them into your ecosystem.

• Adapt and Respond Dynamically to Change

  • Based on changing customer and market opportunities, make changes on-the-fly to business processes. Example would be adding new channels from which an order handling process can invoke dynamic behavior for certain types of customers.

In the white paper titled "BPM Process Patterns: Repeatable Design for BPM Process Models"-BPTrends May 2006, Dan Atwood has discussed, in detail, six categories of process design patterns.