The WebSphere SOA Runtime Stack

In a service oriented architecture approach there are a number of different types of services involved:

Simple services – the web services, or messaging applications exposed as services.

Mediation services – allow you to perform simple message mediation between services.

Business services – allow you to choreograph services.

Each of these services require a runtime with specific capabilities to be able to run.

The WebSphere platform supports these 3 types of service through 3 different runtimes: WebSphere Process Server, WebSphere ESB and WebSphere Application Server. The differences between these are described in the table below:

Runtime Can host simple services Can host mediation services Can host business services
WebSphere Process Server Yes Yes Yes
WebSphere Enterprise Service Bus Yes Yes No
WebSphere Application Server Yes No No

It won’t suprise you to learn that WebSphere Process Server is built on top of WebSphere ESB, and WebSphere ESB is built on top of WebSphere Application Server (I like to think of it like a Russian Doll – open up WebSphere Process Server and you will find WebSphere ESB, open up WebSphere ESB and you will find WebSphere Application Server). Consequently moving from one runtime to another is relatively simple as many of the concepts are the same, e.g. administration, clustering, configuration, install etc, etc. Plus, any of the things you could do at the lower level you can do at the higher level too if you choose to do so (i.e. you can host a simple service on WebSphere Process Server if you choose to do so).

These set of products effectively form the WebSphere SOA Runtime stack.


One Response to The WebSphere SOA Runtime Stack

  1. Thanks, Chris, I like the table. It’s probably just worth adding that Application Server can do basic mediation via platform messaging mediations – which are totally independent of the more sophisticated mediation flows found in ESB (which I think is what you are referring to). These mediations use a different model from ESB – messages are altered in place, and there is less out-of-the-box flexibility. Take a look at this article I wrote some time ago for more information:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: