Comment lines: Bobby Woolf: A quick intro to WebSphere Business Process Management

Introducing WebSphere® Business Process Management, IBM®'s new solution specifically designed to model, assemble, deploy, and manage applications with service-oriented architectures.


Bobby Woolf, ISSW WebSphere J2EE Consultant, EMC

Bobby WoolfBobby Woolf is a member of IBM Software Services for WebSphere, consultants who help customers achieve success with WebSphere products. He is a coauthor of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion. Bobby assists clients in developing applications with service-oriented architecture for IBM WebSphere Process Server using IBM WebSphere Integration Developer. Bobby is also a frequent speaker at various conferences. Read more at Bobby's blog on developerWorks.

22 February 2006

From the IBM WebSphere Developer Technical Journal.


IBM WebSphere Business Process Management is a solution for modeling, assembling, deploying, and managing applications that embody a service-oriented architecture (SOA) and are integrated using an enterprise service bus (ESB). The core set of products in the solution are:

Additional products that supplement this solution include:

In addition to WebSphere Enterprise Service Bus, other IBM products that are helpful for building ESBs include:

Let's take a look at how these products work together to help implement SOA applications.

What is SOA?

Service-oriented architecture is an enterprise-scale IT architectural style that develops IT resources as business-aligned services to fulfill business needs. SOA supports service orientation, which is a way of integrating your business as linked services and the outcomes that they bring. Service orientation enables applications to invoke each others' behavior as services, that is, repeatable business tasks that are self-describing and discoverable, meet specified quality of service requirements, and can be managed through governance. Whereas a component is a unit of code that can be executed to provide functionality, a service is a component that is actually running, often in its own process hosted independently from the applications that are invoking it. Indeed, the applications themselves can be broken into parts that each run in their own process and invoke each other through services. This is a composite application, a set of related and integrated services that support a business process built on an SOA.

A related concept is the enterprise service bus, which enables software applications running on different platforms -- written in different programming languages and using different programming models -- to communicate with each other, without requiring expensive, time-consuming reengineering. An ESB enables routing and transformation to be applied to messages during transmission. It is standards-based, which helps facilitate integrating products from different vendors and avoid an SOA requiring vendor lock-in.

One of the main jobs an ESB performs is connecting together service consumers (which invoke services) with service providers (which implement services). The ESB enables a consumer to invoke a service and matches that invocation with a provider that performs the service. In this way, the consumers and providers do not need to know about each other, they just need to all connect to the ESB.

SOA and ESB are not new ideas, but rather the latest version of evolving practices for encapsulating and integrating application functionality. That evolution is shown in Figure 1.

Figure 1. IBM technology ready to meet customer needs
Figure 1. IBM technology ready to meet customer needs

Another important aspect of SOA is business service choreography, which enables the development and execution of business process flow logic, which is centrally controlled and outside application logic. Service choreography enables multiple services to be run sequentially in a coordinated fashion that implements a business process. The business process is itself a service, one that combines simpler services into a long running flow of services.

What does an SOA application look like?

IBM has developed an SOA reference architecture that shows the kinds of services and other capabilities that can be part of an SOA and how they fit together. Any given SOA application need not use all of the capabilities; different applications will use different capabilities. The architecture is a vendor-neutral way of looking at and planning the set of services that go into building an SOA. It does not necessarily require any IBM products, although the WebSphere Business Process Management solution provides everything you need to build this architecture. A single architecture can contain products from multiple vendors which are able to integrate successfully because they adhere to industry standards. Figure 2 shows IBM's SOA reference architecture.

Figure 2. SOA reference architecture
Figure 2. SOA reference architecture

The parts of the reference architecture are:

  • Interaction services - User interfaces that enable people to work with services.
  • Process services - Enable the execution of business processes.
  • Information services - Enable access to enterprise sources of data.
  • Partner services - Enable connections to outside partners and suppliers.
  • Business application services - Enable the execution of new application components.
  • Access services - Enable connections to existing enterprise applications.
  • Enterprise service bus - Enables interconnectivity between services.
  • Infrastructure services - Enables the execution of services with defined qualities of service.
  • IT service management - Provides quality-of-service enhancements like scalability and security.
  • Business innovation and optimization services - Monitoring capabilities to ensure proper functioning and measure execution.
  • Development services - Programming tools for implementing and integrating services.

The reference architecture shows the parts needed to fully realize the promise of SOA. The IBM WebSphere Business Process Management solution provides a complete and compatible set of products for achieving this architecture.

What does an SOA application run in?

IBM WebSphere Process Server is the flagship product in the WebSphere Business Process Management solution. It is a run time server platform for executing SOA applications; although WebSphere Process Server is not required to execute an SOA application, it is quite helpful. WebSphere Process Server supports SOA applications by providing many of the capabilities defined in the SOA reference architecture. By providing these capabilities, applications do not need to implement the capabilities themselves; the applications only need to implement the custom business functionality and services that make use of these capabilities. In this way, WebSphere Process Server is like an operating system for SOA applications.

WebSphere Process Server is implemented on top of IBM WebSphere Application Server Network Deployment, IBM's flagship application server product which implements the Java™ 2 Enterprise Edition (J2EE™) specification. WebSphere Application Server is a mature product with proven success executing enterprise applications. WebSphere Process Server also contains WebSphere Enterprise Service Bus, which provides the capabilities to connect service consumers and providers, but not the capabilities to perform service choreography. Figure 3 shows the relationship of WebSphere Process Server being built on top of WebSphere Enterprise Service Bus, which in turn is built on top of WebSphere Application Server.

Figure 3. WebSphere Application Server, ESB, and Process Server
Figure 3. WebSphere Application Server, ESB, and Process Server

Figure 4 shows the components that comprise the main functionality of WebSphere Process Server.

Figure 4. WebSphere integration product family
Figure 4. WebSphere integration product family

These components are:

  • WebSphere Application Server Network Deployment - An implementation of J2EE.
  • Service Component Architecture - A service invocation and componentization model for SOA (discussed below).
  • Business objects - A format for data exchange between service components, based on service data objects (discussed below).
  • Common Event Infrastructure - A foundation for monitoring SOA applications; captures activities as Common Business Events.
  • Mediation flows - Perform logic on messages flowing through the ESB.
  • Interface maps - Adapts one service syntax to another.
  • Business object maps - Adapts one service data format to another.
  • Relationships - Converts one data store's keys to another's.
  • Dynamic service selection - Chooses which of multiple components with the same interface to invoke.
  • Business processes - Executes BPEL business processes for service choreography.
  • Human tasks - Enables people to perform business process activities.
  • Business state machines - Models a business process as a finite set of states and event transitions.
  • Business rules - Rule sets and decision tables for simple decision making.

WebSphere Enterprise Service Bus includes the components in the bottom tier: SOA core and mediation flows. WebSphere Process Server adds the top two component tiers: Service components and the remaining supporting services. WebSphere Process Server provides all of the basic functionality needed to run an SOA application.

What is an SOA application built from?

Service Component Architecture (SCA) is a new and unique programming model designed specifically for implementing SOA applications. It is a vendor- and technology-neutral open specification created by IBM and endorsed by other leading IT vendors. WebSphere Process Server implements the specification using Java technology.

SCA enables integration developers to implement SOA applications as sets of service components. SCAs can be created using WebSphere Integration Developer, an integrated development environment for implementing and wiring together service components. The general structure of a service component is shown in Figure 5.

Figure 5. Service Component Architecture overview
Figure 5. Service Component Architecture overview

A service component is a service provider that defines the service interface that it exposes to consumers, and zero or more service references that it consumes from other providers. The interface and references can be defined as either Web Services Definition Language (WSDL) port types or Java interfaces. The references enable the component to implement its service using other services, which may themselves be other SCA components, or simply non-SCA WSDL services and Java objects.

Data flows between components as business objects, an extension of service data objects (SDO), which is another open specification. Like SCA, SDO is a vendor- and technology-neutral format for exchanging data between services. The main two SDO transport formats are XML data described by an XML schema, and serialized Java objects. WSDL service interfaces use XML data; Java service interfaces typically use serialized Java objects, although they can be designed to instead use strings that are XML data.

A component's interface and references do not specify how the component implements its service. Rather, the service is implemented using one of several available technologies:

  • Java
  • BPEL business process
  • State machine
  • Business rule
  • Human task.

Also, if another component already implements the service, this component can simply connect to the other component by a couple of different means:

  • Selector
  • Interface maps.

Notice that these technologies for implementing service components correspond to the capabilities provided by WebSphere Process Server. This is not a coincidence. Service components are implemented using the capabilities of WebSphere Process Server, which is why they must execute in WebSphere Process Server at run time. WebSphere Integration Developer provides the tools to implement components using these run time capabilities.

Therefore, an SOA application can be built out of SCA components; SCA provides a programming model for developing SOA applications.


The combination of SOA and ESB is the most modern approach so far for developing enterprise applications that better align IT capabilities with business needs, and WebSphere Business Process Management is the most comprehensive set of products for doing so.

In this brief article, we took a high level look at some of the advantages of WebSphere Business Process Management, IBM's solution for modeling, assembling, deploying, and managing SOA applications, which included:

  • The WebSphere Business Process Management products and related products work together to implement the SOA reference architecture. The architecture also supports composite applications running across standards-compliant products from multiple vendors.
  • WebSphere Process Server, which is the main WebSphere Business Process Management product, contains WebSphere Enterprise Service Bus, which in turn contains WebSphere Application Server.
  • WebSphere Process Server's components provide most of the functionality SOA applications need to execute, with other WebSphere Business Process Management products providing additional, optional functionality. Together, the full product set provides all of the functions specified in the SOA reference architecture.
  • WebSphere Process Server models a composite SOA application as a set of SCA-compliant service components. WebSphere Integration Developer is an IDE for implementing service components.



Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere, SOA and web services, Architecture
ArticleTitle=Comment lines: Bobby Woolf: A quick intro to WebSphere Business Process Management