WebSphere Process Server and WebSphere Enterprise Service Bus deployment patterns, Part 1: Selecting your deployment pattern

Finding the topology that is right for you requires an analysis of application properties and of non-functional requirements.

Sorting through all of the deployment options that are available with WebSphere Process Server and WebSphere Enterprise Service Bus can be a daunting task. If you have a topology that accommodates any possible application, you can end up with more configuration than you require. However, if you customize the environment so that you have exactly what you need, you may need to spend more effort to gain knowledge than you can afford to spend. This article identifies deployment patterns that fall between these two extremes. These patterns may not be fully optimized to your needs, but they require much less analysis than a fully customized environment. In this article, we identify the application properties and availability expectations that you can use to select a specific deployment pattern. This article includes a downloadable reference guide that describes these deployment patterns and how the requirements map to them. You can use future articles in this series to guide you through the steps to create a deployment environment.

Share:

Chalie Redlin (redlin@us.ibm.com), WebSphere Process Server Architect, IBM Rochester Lab

Charlie Redlin is an architect on the WebSphere Process Server development team in Rochester Minnesota. He has worked in the development of WebSphere clusters and network deployment environments for many years. He currently works in a bring-up lab and is focused on the deployment and integration of WebSphere Process Server.



Karri Carlson-Neumann (karricar@us.ibm.com), Technology Integration Developer, IBM Rochester

Karri Carlson-Neumann is a Senior Software Engineer on the WebSphere Process Server development team in Rochester, Minnesota. She has been involved with the development of WebSphere Business Integration Server Foundation and WebSphere Process Server for many years. She currently works in a bring-up lab and is focused on the deployment and integration of WebSphere Process Server.



08 November 2006

Module design and your deployment

Terminology

SOAP
Simple Object Access Protocol. An XML message format and the W3C standard wire format for Web services messages.
SOAP/HTTP
SOAP over HTTP. SOAP message transmitted over HTTP protocol.
SOAP/JMS
SOAP messages transmitted over a protocol that underlies the JMS interface.
Service Component Architecture (SCA)
(1) A set specifications that enable simplified application development in a Service Oriented Architecture (SOA) environment. (2) The implementation of the architecture found in WebSphere Process Server and WebSphere Enterprise Service Bus.
Service-oriented architecture (SOA)
A style of organizing services and their users in a loosely coupled way.
Common Event Infrastructure (CEI)
(1) A consistent approach for generating and collecting business events. (2) The implementation of that approach found in the WebSphere Process Server.

Your deployment environment is impacted by the modules that will be deployed because specialized support is needed for each component type (in the modules) and for each interaction type (between components and between modules). The patterns article includes a "golden" or "reference" pattern that covers the needs of all component types. The other patterns include support for a subset of the component types. The reference pattern also includes support for Service Component Architecture (SCA) iterations (asynchronous and synchronous), Web service interactions (SOAP/HTTP and SOAP/JMS), and JMS interactions. The other patterns include support for a subset of the component and module interaction types. To be able to select one of these less complicated topology patterns, you need to be aware of the module designs. In particular you need to be aware of the following:

  • Export types (entry points of the module).
  • Connections to the exports and the interactions with the exports (the way the module is used).
  • Component types and the interactions between components (the pieces that make up the module).
  • Import types (the partners of the module).
  • Connections to the imports and the interactions with the imports (the way the partners are used).
  • Resources needed by the components, which includes things like databases or JMS resources that are called directly in the application.
  • Production and consumption of the business event; that is, whether the business events are collected, whether they are collected asynchronously or synchronously, and so forth.
  • Interactions that business administrators have with the business modules, such as the need for accessing the business rules manager, need to access the BPC explorer, and so forth.

Application types and your deployment

A single WebSphere cell can support at least J2EE applications, Web applications, Process Server applications, Enterprise Service Bus applications and Portal applications. Making the decision on how many cells you need and the distribution of applications among those cells should be based on the isolation needs of the applications or their management or based on geography. The article presents deployment patterns with a scope limited to IBM® WebSphere® Process Server (hereafter known as Process Server) and IBM WebSphere Enterprise Service Bus (hereafter known as Enterprise Service Bus) applications. When your deployment environment includes other application types, you will need to extend or customize the pattern as needed to support these other application types.


Impacts of deployment requirements on the application design

Process Server and Enterprise Service Bus are a part of the IBM service-oriented architecture (SOA) implementation. Understanding which parts or your application or solution are best implemented in which product is beyond the scope of this article.

Some of the ways that non-functional requirements are reflected in the development of the application are:

  • A requirement for late binding generally requires a level of indirection in the application. For example looking up a JNDI name that is set up during deployment.
  • A requirement for clustering generally requires static data to be stored someplace besides in memory. For example, when the next order number is updated, every cluster member needs to see the same value.
  • A requirement for clustering generally requires stateless behavior. For example, there is no affinity requirement between a client and a specific cluster member.

Impacts of licensing on the deployment

In the deployment patterns, you will find that a separation of the deployment targets or other Process Server or Enterprise Service Bus components (CEI servers, Messaging engines, and so forth) impacts the distribution and failover properties of the applications. When you select a pattern that includes a separation of these resources, you are free to deploy them on the same machine or on different machines. However, you need to make the standard trade off between memory and the number of server processes (including dmgr, cluster members and node agents) that are running on that machine. Normal engineering tradeoffs are needed to balance the need for licenses, memory, and machines.


Environment overview

In this section we present the basic patterns for in all of the deployments.

Enterprise Service Bus deployment environment

When you develop a mediation module, you expect that the module will be placed between an enterprise service and the users of that service. As a developer, you may also expect that the mediation module will provide some data to meet a logging or monitoring requirement. This development view of the mediation module is depicted in Figure 1.

Figure 1. Interactions with the Enterprise Service Bus environment
WESB Interactions

When you deploy a mediation module, you need to set up the connections with the exports and imports of the mediation module, as well as with any other resources that have been defined by the module. Some of the mediation module primitives (like the logging primitive) require some additional resources to be set up as well. Because we think of a mediation module as being a part of the Enterprise Service Bus, we can sometimes think of the connections for the imports and exports as connections to the Enterprise Service Bus fabric. This deployment environment is shown in Figure 2.

Figure 2. WebSphere Enterprise Service Bus mediation deployment
WESB Deployment

The patterns presented in this article expand upon this basic pattern and are derived from an analysis of the composition of the mediation module.

Process Server deployment environment

When you develop a Process Server module, you expect that the module will either be used as a service, will use some services, or both. As a developer, you may also expect that some business-level administration is required, including the monitoring of business events and the configuration of business policies. Figure 3 shows the view of the business module from the perspective of the developer.

Figure 3. Enterprise Service and its users
WPS Components

When you deploy a business module, you need to set up the connections with the exports and imports of the business module, as well as any other resources that have been used by the module. You will also need to set up the resources needed to support the component types within the module. Finally. you need to set up the business administrator support for the business module. This deployment environment is shown in Figure 4.

Figure 4. Supporting a WebSphere Process Server Enterprise Service
WPS Components

The patterns presented in this article expand upon this basic pattern and are derived from an analysis of the composition of the enterprise service (business module).


Conclusion

The deployment topology of a module is dependent upon the properties of that module and the non-functional requirements of the module. Some modules can be supported by the patterns presented in this article. Practice is needed for the first clustered topology that you create. Future companion articles will provide a reference and a guide to help you create a deployment environment.


Acknowledgments

The following individuals contributed great insight and knowledge to this document: Karri Carlson, Stephen Cocks, Kyle Schlosser, Walid Danaf, Malcolm Aires, and Graham Wallis.


Download

DescriptionNameSize
Reference guide10611_redlin-deploypatterns.pdf800KB

Note

  1. Contains the reference guide pdf file.

Resources

Comments

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Architecture
ArticleID=171203
ArticleTitle=WebSphere Process Server and WebSphere Enterprise Service Bus deployment patterns, Part 1: Selecting your deployment pattern
publish-date=11082006