Enabling SOA Using WebSphere Messaging

40 Enabling SOA Using WebSphere Messaging

To summarize:

򐂰 WebSphere ESB

Building an ESB that is based entirely on WebSphere ESB is an option when

Web services support is critical and the service provider and consumer

environment is predominantly built on open standards. WebSphere ESB is

most suitable for environments that are based on Web services standards

and provides facilities to integrate services that are offered via enterprise

application integration messaging and other sources. However, if integration

with non-Web service standards-based services is a major requirement then

WebSphere ESB may not be the right choice.

򐂰 WebSphere Message Broker

WebSphere Message Broker is considered to be suitable where advanced

ESB functionality is required. WebSphere Message Broker is an option when

Web services support is not critical and quality-of-service requirements

demand the use of mature middleware. WebSphere Message Broker can

support all the ESB capabilities that WebSphere ESB does but is not limited

to open standards. However, in comparison with WebSphere ESB, it lacks

the sophistication of Web services support that might be required in an ESB

implementation, which makes extensive use of these standards.

2.7 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)

WebSphere ESB WebSphere Message Broker

Chapter 2. Product selection 41

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 Event

Infrastructure

Business

State

Machines

Business

Processes

Human

Tasks

Business

Rules

Interface

Maps

Business

Object

Maps

Relation-

ships

Service

Components

Supporting

Services

SOA Core

Mediation

(ESB)

Dynamic

Service

Selection