Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7

Business Processes represent the flow of activities required to complete a business process, which, in turn, help achieve a business objective. They are orchestrations, choreography, or compositions of Business Services targeted to achieve business goals.

Business Service, to be more precise, represents a discrete business function that makes meaningful sense to an organization. A Business Service can be composed of one of the many fine-grained functions or atomic services, and by the true definition of SOA, encapsulation, it can dynamically behave depending on how it is invoked. Services form the building blocks of SOA and should be reusable, decoupled, exposed in a standardized fashion, and derived from disparate IT resources.

Components realize and provide services from one or more applications and these components are wrapped into the Business Services. Components help realize not only the functionality of the services they expose, but also ensure that their Quality of Service (QoS) is good, as guaranteed by the service provider. The following figure depicts how all of the above are interrelated and interconnected at a very high level.

You may have been reading a lot about Business Process Management. What is it? BPM is a discipline that focuses on process modeling, design, automation, management, and continuous improvement. It is not a technology or a product. It covers the full range of application-to-application, inter-application, workflow, and person-to-person process management, including process modeling, design, automation, monitoring, management, and continuous improvement. The core and basic components of BPM include (but are not limited to):

Businesses very well understand that their core (and differentiating) business processes will have to be automated (post integration) and be able to externalize these from end applications. Process-driven integration is about bringing people, processes, information, and systems together using the Business Process management (BPM) approach enabled by an SOA approach. This approach requires a solid technology platform and of course an over-arching methodology that will offer you prescriptive guidance on how to deliver solutions. So what are these core building blocks? They include:

Now let's look briefly at each of these core building blocks/capabilities that are needed for achieving success in a business process-driven integration provided, as shown in the following figure:

This is the starting point where you discover and document the various other business process(s) (using a modeling notation such as Business Process Modeling Notation BPMN) that might exist on paper or even in the minds of some subject matter experts and document it with business modeling. Also, once the processes are modeled, you will have the ability to run model simulations and try out various 'what-if' scenarios to forecast what would happen if you altered the process. Based on these simulations, you arrive at an optimal process design. The process modeling exercise also helps to identify the SOA services that will have to be specified, realized, and also in many cases, reused.

Once the business processes have been modeled, they will have defined in an executable format (such as Business Process Execution Language (BPEL)) and deployed on a standard-based process execution platform that supports both the business process execution environment and the packaging of business tasks as services. The assembly, sequencing, orchestration, and choreography of existing services and new services results in the realization of a deployable process model. This assembly should be based on industry standards such as Service Component Architecture (SCA). The execution platform must also support human interaction for both participants in the business process and administrators of the business process. The runtime should also provide a variety of administrative capabilities required to configure the environment for the applications that are installed.

Enterprise Service Bus (ESB) provides the underlying connectivity and backbone infrastructure for SOA to connect applications. An ESB is essentially an architecture pattern that provides capabilities including connectivity, communications, message queuing, message routing, message transformation, reliable messaging, protocol transformation and binding, event handling, fault handling, message level security, and so on. It enables loose coupling between service consumers and service providers, and thus enhances the ability to rapidly change and introduce new Business Services into the environment. An ESB typically would leverage a service registry and repository to provide information about service endpoints.

Policies and rules can make the business processes highly flexible and responsive. A business policy represents a key piece of domain knowledge, externalized from a business process and is applied when a particular request context is met. An example could be, all purchase orders that include order items such as Oxygen Canisters are deemed critical orders, order amount worth over $1000 has to be shipped overnight, and so on. Metadata elements such as "order item" and "order amount" are deemed as the business domain vocabulary and values of which can change (you can add "Defibrillator" along to the critical items list), which will have to be externalized from the business process.

A business rule is a statement that defines or constrains some aspect of the business. They are typically atomic and cannot be broken down further. An example would be, say, in a loan origination business process, at each step of the process, business analysts identify rules that must be met by the loan staff and underlying systems. In traditional banking systems, these rules reside within the loan origination system itself, so changing the rules means modifying the application. When the rules are abstracted from the loan origination systems, they reside in a business rules engine. As a result, bank management can identify those activities that change rapidly, such as decisions relating to FICO® scores, and then, instead of changing the process and its underlying application, they change only the decision point within the business process, which in turn resides in a business rules engine (external to the process itself). This capability adds agility to the process by reducing the time, costs, and resources necessary to respond to changing conditions.

While the business processes are deployed and are executing, data must be captured that provides information about the processes. This data can be analyzed to determine if the business processes are performing as expected. Both business-related information and IT-related information can be captured for monitoring. You should also be able to visually define dashboards based on Key Performance Indicators (KPI), which are based on the monitor model deployed for the business process, providing a visual display of the business process status.

For a process-driven integration approach coupled with SOA to succeed, a common and enterprise level information model is required, which becomes the basis for the messages exchanged between processes and services, and also serves as the glossary for the business policies and rules. When dealing with applications that have disparate data and information models, use of this common information model shields the business processes away from the gory details of each and every individual system. The ESB provides capabilities to transform from this Canonical Data Model to the target system's format. The Canonical data model minimizes dependencies between integrated applications that use different data formats. Typically, one could leverage industry standards such as Tele Management Forum's Shared Information/Data Model (SID) and so on to define the information models.

A mind map, as shown in the following figure, sums up all the previous concepts.

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:

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.

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.

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. The book is about how you build SOA solutions with these two products and these two products indeed provide a majority of the capabilities, if not all, which are essential to a successful SOA. Now let's delve into what these two products are all about.

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.

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:

We will venture into more details about SCA, SDO and BO, and BPEL in the coming chapters.

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:

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:

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:

SOA mandates that the service providers and the service consumers be loosely coupled and support the use of explicit interfaces. This flexibility enables IT change with very limited impact such as the update or replacement of a given Business Service or the development of a new composite solution which leverages existing services. That is, the power of the ESB enables you to realize the full value of SOA. As shown in the following figure, interposing the ESB between the participants in an SOA ecosystem enables you to modulate their interactions through a logical construct called mediation. Mediations operate on messages in transit between service consumers and service providers. For complex interactions, mediations can be chained sequentially. The following figure lists the core capabilities that are provided by WESB and how they interact with the various backend applications and how they expose them to the service consuming layers north of it (Process Services and Business Services). In some cases, Interaction Services can also become consumers of these WESB mediations. But it is always preferable to have the mediation wrapped into Business Services because more than likely, you would want to expose core business functions to the service consumers. In doing so, you can account for service variability within the Business Service through the use of business policies and rules. An example would be that WESB can expose mediations that manipulate customer data from one or many customer information management systems. Which customer information system is chosen will depend on the business context of the request (examples include customer location – North America or Europe, type of customer—residential or commercial, service level agreements with the customer, or request priority and so on). All these account for service variability behavior and how the service should behave based on a combination of such cases. Having such a kind of processing logic within the WESB mediation flows is not preferable for the simple reason being it can change as business conditions change. Hence WESB, in an SOA architecture, should be positioned to deal with the hardcore integration and connectivity needs and should not be overloaded with capabilities it is not meant to do architecturally.

As depicted in the core platform architecture for WPS (as mentioned earlier WPS includes WESB), WESB is also built on top of WebSphere Application Server. WESB mediation flows provide routing, transformation, and logging operations on the messages. The information that governs their behavior is often held in headers flowing with the business messages. WESB also adopts the same programming model as WPS (explained in the previous sections), but also introduces the Service Message Object (SMO) pattern for SDOs to support this pattern of operating on the messages, including its headers. We will discuss in detail about SMO in the coming chapters.

As shown in the WPS platform architecture, mediation flows belong to the support services. The mediation flows provide capabilities that include:

The following figure is an example of a mediation flow that provides routing, transformation, and logging operations on the messages through the use of Mediation primitives. Mediation primitives are the smallest building blocks in WESB and are contained within a mediation flow. With Mediation primitives, you can change the format, content, or target of service requests, as well as log messages, perform database lookups, and so on and so forth. WESB can interconnect a variety of different service consumers and providers using standard protocols including JMS, SOAP/HTTP, SOAP/JMS, HTTP, and so on. It supports web services standards including WS-Security and WS-Atomic Transactions. It also includes Universal Description Discovery and Integration (UDDI), Version 3.0 that can be used to publish and manage service end point metadata, which enables service definitions to be made available to client applications. WESB also supports IBM WebSphere Service Registry and Repository and is used for cases where you may have to do dynamic endpoint lookup.

There are three categories of usage patterns when building WESB-based solutions:

Now let's look in more detail at some of the most common usage scenarios that belong to the preceding categories that WESB can be used in.

It's quite possible for an organization to have multiple ESB configurations/topologies. It's all driven by business needs and the ESB topologies may change as business requirements change. The flexibility and "service virtualization" provided by the ESB is achieved through what architects call "separation of concerns", the clear separation between the applications which run the business (including Business Services and business processes) and the ESB (the infrastructure for connecting applications and services together).

When selecting WESB, here are some of the most typical considerations or topics to consider include: