WebSphere Process Server

WebSphere Process Server is built on WebSphere ESB, thus providing it with the mediation functionality of WebSphere ESB and the qualities of service that WebSphere Application Server provides (for example, clustering, failover, scalability, and security). To this, WebSphere Process Server adds the ability to build business processes that orchestrate multiple services to achieve a business goal.

The WebSphere Process Server architectural model consists of the three layers shown in Figure 2-6 on page 41.

Event-driven processing 򐂰 Supports event-driven

processing by leverage adapters for capture and dissemination of business events

򐂰 Supports complex event processing (processing of events formed by several earlier ones)

Figure 2-6 Architectural model of WebSphere Process Server

Above the infrastructure provided by WebSphere Application Server, WebSphere Process Server implements a layer called the SOA Core that includes the following:

򐂰 Service Component Architecture (SCA)

Using SCA, every integration component is described through an interface. These services can then be assembled in a Component Assembly editor, thus enabling a very flexible and encapsulated solution.

򐂰 Business objects

Business objects are the universal data description. They are used as data going in and out of services and are based on the Service Data Object (SDO) standard. SCA bindings contain the physical description of components. Services can be accessed as Java objects (POJOs), EJBs, Web services, JMS messages, and adapters.

򐂰 Common Event Infrastructure

The Common Event Infrastructure is the foundation for monitoring

applications. IBM uses this infrastructure throughout its product portfolio, and monitoring products from Tivoli as well as WebSphere (WebSphere Business Monitor) exploit it. The event definition (Common Business Event, CBE) is being standardized through the OASIS standards body so that other

companies as well as clients can use the same infrastructure to monitor their environment.

On top of this SOA Core layer lie the service components and supporting services layers. WebSphere Process Server implements a number of

Service Component Architecture

WebSphere Application Server Network Deployment (J2EE Runtime) Business

Objects Common EventInfrastructure Business

State Machines Business

Processes HumanTasks BusinessRules

Interface Maps Business Object Maps Relation- ships Service Components Supporting Services SOA Core Mediation (ESB) Dynamic Service Selection

components and services that can be used in an integration solution. In the service components layer you will find the following:

򐂰 Business processes

The business process component in WebSphere Process Server implements a WS-BPEL compliant process engine. Clients can develop and deploy business processes with support for long-running and short-running business processes and a robust compensation model in a highly scalable

infrastructure. WS-BPEL models can be created in WebSphere Integration Developer or imported from a business model that has been created in WebSphere Business Modeler.

򐂰 Human tasks

Human tasks in the WebSphere Process Server are standalone components that can be used to assign work to employees or to invoke any other service. Additionally, the Human Task Manager supports the ad-hoc creation and tracking of tasks. Existing LDAP directories (as well as operating system repositories and the WebSphere user registry) can be used to access staff information. Of course, WebSphere Process Server supports multi-level escalation for human tasks including e-mail notification.

The WebSphere Process Server also includes an extensible Web client that can be used to work with tasks or processes. This Web client is built based on a set of reusable Java Server Faces (JSF) components that can also be used to create custom clients or embed human task functionality into other Web applications.

򐂰 Business state machines

A business state machine provides another way of modeling a business process. This enables businesses to represent their business processes based on states and events, which are sometimes easier to model than a graph-oriented business process model. One example would be an ordering process where the order can be cancelled or modified at any time during the order process.

򐂰 Business rules

Business rules are a means of implementing and enforcing business policy through externalization of business function. This enables dynamic changes of a business process for a more responsive businesses environment. Business rule authoring is supported within an Eclipse-based desktop tool. The WebSphere Process Server also includes a Web-based runtime tool for the business analyst so that business rules can be updated as business needs dictate without affecting other SCA services.

transformation, which is not surprising. There are a number of transformation challenges when connecting components and external services, each of which is being addressed by a component of WebSphere Process Server:

򐂰 Interface maps

Very often interfaces of existing components match semantically but not syntactically (for example, updateCustomer versus updateCustomerInDB2). This is especially true for already existing components and services that need to be accessed. Interface maps allow the invocation of these components by translating these calls. Additionally, business object maps can be used to translate the actual business object parameters of a service invocation. 򐂰 Business object maps

A business object map is used to translate one type of business object into another type of business object. These maps can be used in a variety of ways, for example, in an interface map to convert one type of parameter data into another.

򐂰 Relationships

In business integration scenarios it is often necessary to access the same data (for example, client records) in various backend systems (for example, an ERP system and a CRM system). A common problem for keeping business objects in sync is that different backend systems use different keys to represent the same objects. The relationship service in the WebSphere Process Server can be used to establish relationship instances between objects in these disparate backend systems. These relationships are typically accessed from a business object map when translating one business object format into another.

򐂰 Dynamic service selection

A selector component allows dynamic selection and invocation of different services, which all share the same interface. For example, a customer support process could use different human tasks implementations during different times of day. This would enable routing of work to different support centers (Americas, Europe, Asia-Pacific) based on the time of day. Just like for the business rule component, WebSphere Process Server offers a Web-based interface to enable dynamic updates to the selection criteria and target services.

򐂰 Mediation

The mediation component can act on messages flowing between the requestor and the service. For example, it can transform messages from the format used by the requestor to the format required by the service. Other typical actions include routing based on message content and protocol transformation.

The primary development tool for the WebSphere Process Server is WebSphere Integration Developer. This is the same tool used for WebSphere ESB

development tasks.

You can find more information about IBM WebSphere Process Server V6 at: 򐂰 WebSphere Process Server home page:

http://www.ibm.com/software/integration/wps/

򐂰 Technical Overview of WebSphere Process Server and WebSphere Integration Developer, REDP-4041