Introducing IBM WebSphere Process Server (WPS)
Note
In this book we will cover WebSphere Integration Developer v7.0, WebSphere Process Server v7.0, and WebSphere Enterprise Service Bus v7.0 built on top of IBM WebSphere Application Server-ND v7.0.0.7.
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:
Invocation Model— defines how invocations of processes and services are made.
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.
Data Model—defines how data can be represented
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.
Composition Model—how you put together a series of invocations
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.
We will venture into more details about SCA, SDO and BO, and BPEL in the coming chapters.
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.
Note
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.
