Deployment patterns for WebSphere Process Server and Enterprise

Deployment patterns for WebSphere Process Server and Enterprise Service Bus

Charlie RedlinWebSphere Business Integration BringUp LabIBM

Karri Carlson-NeumannWebSphere Business Integration BringUp LabIBM

November 8, 2006

© Copyright International Business Machines Corporation 2006. All rights reserved.

AbstractSorting 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. We have included a downloadable reference guide that describes these deployment patterns and the mapping of the requirements to them.

Table of contentsDeployment patterns for WebSphere Process Server and Enterprise Service Bus..............1

Abstract ................................................................................................................................ 1

Figures .............................................................................................................................. 3

About this article .................................................................................................................. 4

Introduction .......................................................................................................................... 5

Impacts of the module design on the deployment .......................................................... 6

Integration with the WebSphere family of products ........................................................ 6

Impacts of deployment requirements on the application design ...................................... 6

Impacts of licensing on the deployment .......................................................................... 7

of 48

Environment overview ......................................................................................................... 7

Enterprise Service Bus deployment environment ............................................................ 7

Process Server environment ............................................................................................. 8

Selecting a deployment pattern ............................................................................................ 9

Enterprise Service Bus deployment patterns ................................................................. 10

Process Server deployment patterns .............................................................................. 12

Full featured Enterprise Service Bus environment ............................................................ 18

Module properties .......................................................................................................... 18

Topology ........................................................................................................................ 19

My first Enterprise Service Bus cluster ............................................................................. 20


Topology ........................................................................................................................ 20

Topology variation ......................................................................................................... 21


Topology ........................................................................................................................ 22

Topology refactoring ..................................................................................................... 24

Enterprise Service Bus cluster with size tolerance ............................................................ 24


Topology ........................................................................................................................ 25

My first Process Server cluster .......................................................................................... 26


Topology ........................................................................................................................ 27


Loosely coupled Process Server cluster ............................................................................. 28


Topology ........................................................................................................................ 29


Process Server cluster with size tolerance ......................................................................... 31


Topology ........................................................................................................................ 32

Location tolerant Process Server cluster ............................................................................ 33


Topology ........................................................................................................................ 34

of 48


Process Server cluster with macroflows and partitioned queues ....................................... 36


Topology ........................................................................................................................ 37


Microflows and ad hoc business events queries ................................................................ 38


Topology ........................................................................................................................ 39



Location and cluster size tolerance, macroflows, and adhoc queries of events ................ 42


Topology ........................................................................................................................ 43

Refactoring the environment .......................................................................................... 44

Reference pattern ............................................................................................................... 44


Topology ........................................................................................................................ 45

Conclusion ......................................................................................................................... 47

Acknowledgements ............................................................................................................ 47

Resources ........................................................................................................................... 47

About the author ................................................................................................................ 48

FiguresFigure 1: Interactions with the Enterprise Service Bus environment ................................. 7

Figure 2: Enterprise Service Bus Mediation Deployment................................................... 8

Figure 3: Enterprise Service and its users............................................................................8

Figure 4: Supporting a Process Server Enterprise Service.................................................. 9

Figure 5: Enterprise Service Bus Deployment Patterns and Module properties............... 10

Figure 6: Enterprise Service Bus Deployment Pattern selection table.............................. 11

Figure 7: Process Server Deployment Pattern Selection Table......................................... 17

Figure 8: Enterprise Service Bus cluster with interactions outside of cell........................ 19

Figure 9: My first Enterprise Service Bus cluster..............................................................21

Figure 10: Loosely coupled Enterprise Service Bus cluster.............................................. 23

of 48

Figure 11: Enterprise Service Bus cluster that is tolerant of cluster size...........................25

Figure 12: My first Process Server cluster.........................................................................27

Figure 13: Loosely coupled Process Server cluster........................................................... 30

Figure 14: Process Server cluster with tolerance for cluster size...................................... 32

Figure 15: Process Server cluster with interactions outside of cluster.............................. 35

Figure 16: Process Server cluster with macroflows...........................................................37

Figure 17: Microflows and business events.......................................................................40

Figure 18: Complete Process Server environment with ad hoc queries for business events............................................................................................................................................43

Figure 19: Full featured, asynchronous exports, asynchronous event consumer.............. 46

About this articleThis article is the first of a series of articles related to deploying IBM® WebSphere® Enterprise Service Bus (hereafter known as Enterprise Service Bus) and IBM WebSphere Process Server (hereafter known as Process Server) environments. If you cannot find a particular companion article, it may be because the article has not been released yet. Check with the BringUp lab (Web pages or a call) for help when the articles are not available.

Creating an Enterprise Service Bus or Process Server deployment environment requires some planning and a fair amount of knowledge. This article presents design patterns that reduce the amount of effort and knowledge needed to design these deployment environments. You can use this article alone or with the companion articles when you set up your particular deployment environment.

If you are an expert with the WebSphere Application Server and Process Server clustering environments, you can use this article as a stand alone document. Select a deployment environment pattern that best meets your needs from the “Enterprise ServiceBus Deployment Pattern selection table” or the “Process Server Deployment PatternSelection Table” (Figure 6 or Figure 7). Use the section corresponding to the selected pattern to verify that the pattern does meet your needs. Finally, use the cheat sheet in that same section to guide you through the process of creating your environment.

If you are a novice to the Process Server and WebSphere Application Server clustering world you can use this article as a starting point for your adventure of setting up deployment environments. Use the same tables, “Enterprise Service Bus DeploymentPattern selection table” and “Process Server Deployment Pattern Selection Table” (Figure6 and Figure 7) and select a pattern that is best suited to your needs. Use the section that corresponds to the selected pattern and verify that the pattern does meet your needs. Use the cheat sheet, in the same section, to get familiar with the design and the process needed to create the environment.

of 48

The final step is to find the step by step guide for the deployment pattern, this guide is one of the companion articles described earlier. If this is your first deployment environment we highly recommend that you practice setting up the environment a couple of times before you set it up for real. This is because there are a fair number of steps and the penalty for performing some of them incorrectly is to discover the error, undo the incorrect actions and redo the correct actions. In a practice environment you always have the option of throwing it all away and start all over again. Many times starting over is better than paying the penalty.

When you consider yourself to be someplace between an expert and a novice, you can use this document in the same ways described earlier; you can also find the corresponding step-by-step guide. However, you can use the companion article as a reference, while creating the environment.

When you find that the patterns contained in this article do not meet your needs exactly, you can use companion article (the design guide) that describes how to design your own deployment environment.

This article is best read by someone with a general understanding of Enterprise Service Bus or Process Server programming models (SCA, BPEL, HTM, Selectors, etc), the clustering technologies provided by WebSphere Application Server (WebSphere Application Server), the clustering concepts of the System Integration Bus (SIB), and the deployment environment of WebSphere Application Server Network Deployment (WebSphere Application Server ND).

The overview sections and the deployment sections cover both Enterprise Service Bus and Process Server. You only need to read the parts of those sections that pertain to the specific product are you working on. Because there is complete overlap in the data presented, you do not miss any pertinent data by skipping over the parts that do not relate.

IntroductionWebSphere Process Server (Process Server) and WebSphere Enterprise Service Bus (Enterprise Service Bus) are two relatively new products in the WebSphere portfolio. These products help solve the complex business integration and enterprise service bus challenges facing agile and competitive organizations.

When a deployment environment, involving these products, is built with care, then that environment can enhance the business value, of these products, to a customer. When configured with this business value, the environment is easier to manage and has the capability to be extended and evolved over time. The environment also meets a wide variety of requirements for workload management, service level agreements, security, high availability and disaster recovery. Because these products focus on the enterprise service bus and application integration, the deployment environments also include an abundance of interactions with external systems (for example databases, the embedded messaging infrastructure of WebSphere Application Server and other Messaging Providers).

of 48

Impacts of the module design on the deployment The design and set up of a deployment environment is dependant upon the content and interactions of the business module being deployed. In this article, we recognize that the make up of a business module impacts the deployment environment design. We provide a mapping between a specific deployment pattern and the business module properties 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, such as databases or JMS resources that are called directly in the application.

Production and consumption of business events, for example, whether business events are collected, if they are collected asynchronously or synchronously, and so forth.

Interactions that business administrators have with the business modules (need for accessing the business rules manager, need to access the BPC explorer, and so forth.)

Integration with the WebSphere family of productsMaking the decision of which applications should be deployed into a single cell should be based on isolation requirements because the Process Server or Enterprise Service Bus modules will work very well in a cell that also includes Portal, J2EE applications or Web applications. Your isolation criteria could be based on who has administrative access, or the scope of impact a single piece of rogue code can have on the entire environment. In this article, we describe the environment necessary to deploy Process Server and Enterprise Service Bus modules. These should be considered to be a portion of the environment. Multiple environments may exist in the same cell or in a cell with other WebSphere family applications also deployed.

Impacts of deployment requirements on the application designProcess Server and Enterprise Service Bus are a part of IBM’s 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:

of 48

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 not affinity requirement between a client and a specific cluster member.

Impacts of licensing on the deploymentYou will find in the deployment patterns 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 the need for memory and the need for machines.

Environment overviewIn this section, we present the basic patterns for in all of the deployments. The patterns presented for the full environment include the non-functional requirement of failover.

Enterprise Service Bus deployment environmentWhen 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

When you deploy a mediation module, you need to set up the connections with the mediation module’s exports and imports, 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.

of 48

Figure 2: Enterprise Service Bus Mediation 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 environmentWhen 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 this developer’s view of the business module.

Figure 3: Enterprise Service and its users

When you deploy a business module, then you need to set up the connections with the business module’s exports and imports, 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.

of 48

Figure 4: Supporting a Process Server Enterprise Service

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

Selecting a deployment patternEach pattern presented in this article supports some modules and provides some non-functional properties. A summary of the patterns included in this article is contained in either Figure 6 or Figure 7. For each pattern, the table includes both the characteristics of the modules that can be supported by that pattern and the non-functional properties that are provided by that pattern. There will likely be more than one pattern that supports your module. You will need to make one of the classic engineering trade offs (complexity versus flexibility versus performance) as you decide which of the patterns to choose. When you find multiple patterns that meet your needs, choose the one that is the least complex, if it meets your performance needs. It will save you some computing resources or some administration resource to maintain or some administration resource to set up.

After you have designed your deployment environment, you then need to set it up. For each deployment pattern, we have included a cheat sheet on how to set up the environment. When you are comfortable with setting up these deployment environments, this cheat sheet should provide enough of a context for you to successfully set it up. When you do not feel that the cheat sheet provides enough detail for you, then you should seek out the article that contains the details.

of 48

Enterprise Service Bus deployment patterns


Module properties Reference pattern

Isolate deployment concerns

Loosely coupled

Very basic

Export

WebServices bindings with SOAP/HTTP transport

WebServices bindings with SOAP/JMS transport

SCA bindings

JMS bindings

Export client

Asynchronous Invocation (one way, two way or deferred response)

Deployed in the same cell

Primitives Logging

Import

SCA bindings

JMS bindings



Figure 5: Enterprise Service Bus Deployment Patterns and Module properties

of 48


Non-functional Properties Reference pattern

Isolate deployment concerns

Loosely coupled

Very basic

Topology refactoring

Modify number of cluster members without impacting clients

Failure isolation

Failure of partner results in delays rather than failures

Locality

Module client and module in the same cell

Module and its partners are in the same cell

Module is the export (entry point)to the data center

Module is the import (exit point) to the data center

Figure 6: Enterprise Service Bus Deployment Pattern selection table

of 48

Process Server deployment patternsProcess Server deployment patterns

Module properties Reference (page 44)

My firstProcessServercluster (page 26)

LooselycoupledProcessServercluster (page 28)

Microflowsand ad hocbusinesseventsqueries (page 38)

ProcessServerclusterwith sizetolerance (page 31)

LocationtolerantProcessServercluster (page 33)

ProcessServercluster withmacroflowsandpartitionedqueues (page 36)

Locationand clustersizetolerance,macroflows, and adhocqueries ofevents (page 42)

Export

SCA bindings



JMS bindings

of 48

Process Server deployment patterns









Export client

Asynchronous invocation

May be deployed outside of cell

Requests are processed in order

of 48










Components

Process components with macro flows

Human task

Asynchronous interactions

Business administration

Manage business rules

of 48










Topology refactoring

Alter size of deployment target cluster

1

Business events

1 Altering the size of the cluster does not impact the client but it does require that the CEI cluster is rippled.

of 48










Imports

SCA bindings

WebServices Bindings with SOAP/HTTP transport


JMS bindings

of 48










Import target

Deployed in a different cell

Will process requests in order

Figure 7: Process Server Deployment Pattern Selection Table

of 48

Full featured Enterprise Service Bus environmentThis is the first deployment environment that we recommended, because it is capable of supporting the greatest number of mediation modules. However, this wide support comes at a cost of being overly complex when the mediation module does not need all of the function provided. We recommend this pattern to you when you do not know the particulars of the mediation module that will be deployed to the environment2.

This pattern provides a loose coupling between a mediation module and the services involved with the mediation. The decoupling involves both the interface of the service and the availability of the service. An additional property of this design is that any modification of the size of the cluster does not require the users of the mediation (or the enterprise service) to be recycled.

For this design, neither the user of the mediation module nor the enterprise service is required to be a part of the same cell.

Module propertiesThe modules that are deployable with this design are able to take advantage of the promise of SOA and Enterprise Service Bus. They are also able to decouple the impact to the clients of topology changes to the servers. The mediation modules that are deployed into this environment have the following properties.

Export

• SCA binding

• JMS binding (via MQ)

Export user

• Binding invoked asynchronously (one way, deferred response or callback)

Module properties

• Synchronous component interactions

• Static data not stored in memory

Deployment target support

• No resources specific to the module are required.

Import

• SCA binding

Import deployment

• No restrictions

2 See the section titled “Impacts of deployment requirements on the application design” on page 6 to refresh your memory on the application properties that impact the deployment.

of 48

TopologyThis pattern creates two clusters: one which is used as the deployment target for the mediation module and the other which is used as the cluster member supporting the queues for the SCA interactions. The other elements of this deployment pattern include an additional server in the cell, the client of the service (also client of the mediation module) and the enterprise service.

This other server is used to connect the SIB to an external source or user of the enterprise service. This server is a bus member of the SCA.APPLICATION bus and is a part of the same OS cluster as the MQ queue manager. How to set up the service and how to set up the user of the service are not described in this design because they are not a part of the design. We do, however, point out that neither the user of the service nor the service is included and is required to be a part of the cell.

Figure 8: Enterprise Service Bus cluster with interactions outside of cell

This topology requires two remote databases (ME, WPRCSDB) to support the deployment target.

Use this cheat sheet to set up the topology:

1. Install the following:

• Enterprise Service Bus

• Drivers for database access

2. Create the databases.

• Create WPRCSDB and ME database (simple DB command).

3. Create the cell.

• Create and federate the profiles.

4. Create the clusters.

• Use Enterprise Service Bus template for deployment target.

• Use WebSphere Application Server template for ME cluster.

of 48

• Choose Advanced config => config SCA for default location with the ME cluster. Choose SCA for remote location for AppCluster.

• Configure the host alias.

5. Install the mediation modules.

My first Enterprise Service Bus clusterWe present this topology to help you get started in setting up Enterprise Service Bus clustered environments. Setting up this topology and getting a mediation module deployed is a very good exercise for getting started in the world of clustering. In addition to being useful for training this deployment pattern provides a suitable deployment environment for many modules providing mediations for interactions involving the SOAP/HTTP transport.

Module propertiesThe modules that are deployable with this design are, many times, the modules that are developed as a first project with WebSphere Integration Developer and Enterprise Service Bus. The mediation modules that are deployed into this environment have the following properties.

Export

• Web services binding with SOAP/HTTP transport

Module properties





Web Services binding with SOAP/HTTP transport

TopologyThis pattern creates a single cluster which is used as the deployment target for the mediation module. The queues for supporting SCA interactions are configured but since they are never used we choose the easiest deployment paths and locate them in the same cluster.

of 48

Figure 9: My first Enterprise Service Bus cluster






2. Create databases.


3. Create cell.

• Create and federate profiles.

4. Create the cluster.

• Use Enterprise Service Bus template.

• Choose Advanced config => config SCA for default location.

• Configure host alias.

5. Install mediation modules.

6. Generate the plug-in config file.

Topology variation1. When the client of the enterprise service is a server or cluster member in the same

cell as the deployment target of the enterprise service, then the router is embedded into that server or cluster member. Loosely coupled Enterprise Service Bus cluster

of 48

The topology pattern described is this section provides a loose coupling between a mediation module and the services involved with the mediation. The decoupling involves both the interface of service and the availability of the service.

For this design, the user of the mediation module, the mediation module, and the enterprise service are all deployed into the same cell.

Module propertiesThe modules that are deployable with this design are able to take advantage of the promise of SOA and Enterprise Service Bus. The mediation modules that are deployed into this environment have the following properties.

Export

• SCA binding

Export user

• Binding invoked asynchronously (one way or deferred response)

• User deployed into same cell as the Mediation module

Module properties





• Two remote databases (WPRCSDB, MEDB)

Import

• SCA binding

Import deployment

• Import deployed in the same cell as the mediation module

TopologyThis pattern creates a single cluster which is used as the deployment target for the mediation module. The queues for supporting the SCA interactions are created on the bus member that is the same cluster. The other element of this deployment pattern is two additional servers (or clusters) in the cell.

These other clusters (or servers) are the deployment targets of the user of the enterprise service (which is the user of the mediation), and the deployment target of the enterprise service. How these servers (or clusters) are set up is not described in this design because they are not a part of the design. It is only required that they are deployed to the same cell.

of 48

With this design each partition of the mediation module’s queue receives messages because of the designs of the SCA, SIB, WLM and connection components. (Read that to mean that this works because of the implementation rather than because the contracts of the interfaces assure the behavior.)

Figure 10: Loosely coupled Enterprise Service Bus cluster


Cheat sheet for setting up the topology





• Create the database to be used for the WPRCSDB and the ME databases (simple DB command).

3. Create the cell.


• Ensure that all cell members can access the applicable databases.


• Use the default Enterprise Service Bus template.



5. Create the MEs.

of 48

• Create additional MEs.

• Create HAmanager policies.


Topology refactoring7. Each new cluster member:

• Requires a new ME and new HAManager policy.

• Requires the recycle of the user of the enterprise service (user of the mediation).

Enterprise Service Bus cluster with size toleranceThe topology pattern described is this section provides a loose coupling between a mediation module and the services involved with the mediation. The decoupling involves both the interface of service and the availability of the service. An additional property of this design is that any modification of the size of the cluster does not require the users of the mediation (or the enterprise service) to be recycled.

For this design, the user of the mediation module, the mediation module, and the enterprise service are all deployed into the same cell.

Module propertiesThe modules that are deployable with this design are able to take advantage of the promise of SOA and Enterprise Service Bus. They are also able to decouple the impact to the clients of topology changes to the servers. The mediation modules that are deployed into this environment have the following properties.

Export

• SCA binding

Export the user


• User deployed into same cell as the Mediation module

Module properties





Import

of 48

• SCA binding

Import deployment

• Import deployed in the same cell as the mediation module

TopologyThis pattern creates two clusters: one which is used as the deployment target for the mediation module and the other which is used as the cluster member supporting the queues for the SCA interactions. The other element of this deployment pattern is two additional servers (or clusters) in the cell.

These other clusters (or servers) are the deployment targets of the user of the enterprise service (which is the user of the mediation), and the deployment target of the enterprise service. How these servers (or clusters) are set up is not described in this design because they are not a part of the design. It is only required that they are deployed to the same cell.

Figure 11: Enterprise Service Bus cluster that is tolerant of cluster size


Use this cheat sheet for setting up the topology:






3. Create the cell.


• Ensure that the database can be reached from the appropriate nodes.


• Use the default Enterprise Service Bus server template for deployment target.

of 48

• Use the default server template for ME cluster.

• Choose Advanced config => config SCA for default location with ME cluster, SCA for remote location for AppCluster.



My first Process Server clusterWe present this topology to help you get started in setting up Process Server clustered environments. Setting up this topology and getting a business module deployed is a very good exercise for getting started in the world of clustering. In addition to being useful for training this deployment pattern, it provides a suitable deployment environment for many simple process server modules.

Module propertiesThe modules that are deployable with this design are, many times, the modules that are developed as a first project with WebSphere Integration Developer and Process Server. The enterprise services (alias business modules) deployed into this environment have the following properties.

Export


Module properties

• Process with Microflow or no business process logic (No Macro flows)

• No relationships, business rules


• Static data is not stored in memory



Business events

• No business events

Business Admin

• Tight coupling between the business administrator and the physical topology

• Uses the BPC explorer

Import

• No imports

of 48

TopologyThis pattern creates a single cluster that is used as the deployment target for the business module. The queues for supporting SCA interactions and those for supporting macro flows are configured but since they are never used we choose the easiest deployment paths and locate them in the same cluster.

Figure 12: My first Process Server cluster

This topology requires three remote databases (ME, WPRCSDB, BPEDB) to support the deployment target.

Use this cheat sheet to set up this design:


• Process Server



• Create the WPRCSDB and ME databases (simple DB command).

• Create the BPC (Copy ddl to database machine and run the ddl).

3. Create the cell.



• Use the Process Server template.

of 48


• Configure the BPC and HTM (HTM needed for BPC explorer).


5. Recycle dmgr.

6. Install the business modules.


Topology variationWhen the client of the enterprise service is a server or cluster member in the same cell as the deployment target of the enterprise service, then the router is embedded into that server or cluster member.

Loosely coupled Process Server clusterThe topology pattern described is this section provides a loose coupling between a business module (enterprise service), the user of the service and any services used by business module. The decoupling involves both the interface of service and the availability of the service.

For this design, the user of the business module, the business module and any services used by the business module are all deployed into the same cell.

Module propertiesThe modules that are deployable with this design are able to take advantage of the promise of SOA and Enterprise Service Bus. The business modules that are deployed into this environment have the following properties.

Export

• SCA binding (JMS transports)

Export user


• User deployed into same cell as Process Server module

Module properties

• Requests are not required to be processed in the order received



• Microflows (no macro flows)

Deployment target

• Configured for BPEL and HTM

of 48



• Three remote databases (WPRCSDB, MEDB, BPCDB)

• Queues are configured on the deployment target

Import

• SCA binding

Dependent Service (Target of the import)

• Import deployed in the same cell as the business module

• Requests do not need to be processed in the order they are generated

TopologyThis pattern creates a single cluster which is used as the deployment target for the business module. The other elements of this deployment pattern include two additional servers (or clusters) in the cell.

These other clusters (or servers) are the deployment targets of the user of the enterprise service, and the deployment target of the enterprise service. How these servers (or clusters) are set up is not described in this design because they are not a part of the design. It is only required that they are deployed to the same cell.

We select the simplest setup option for the BPC queues because they are not used during the execution of the business module. The queues for supporting the SCA interactions are created on a bus member from the same cluster.

With this design each partition of the business module’s queue receives messages because of the designs of the SCA, SIB, WLM and connection components. (Read that to mean that this works because of the implementation rather than because the contracts of the interfaces assure the behavior.)

of 48

Figure 13: Loosely coupled Process Server cluster

This topology requires three remote databases (ME, WPRCSDB and BPCDB) to support the deployment target.



• Process Server

• Drivers for database access.


• Create the WPRCSDB and ME database (simple DB command).

• Create the BPCDB (copy, modify and run script).

3. Create the cell.





• BPC configuration wizard.

• HTM configuration wizard.

• Configure host alias.

5. Create the MEs.

of 48

• Create the additional MEs.

• Create the HAmanager policies.

6. Recycle dmgr.


Topology refactoring1. New cluster members

• Requires new ME and new HAMangaer policy

• Requires recycle of user of the enterprise service (user of the business module)

Process Server cluster with size toleranceThe topology pattern described is this section provides a loose coupling between the business module and the services interacting with the business module. The decoupling involves both the interface of service and the availability of the services. An additional property of this design is that any modification of the size of the cluster does not require the users of the business module (or the enterprise service) to be recycled.

For this design, the user of the business module, the business module and the dependent enterprise service (target of the import) are all deployed into the same cell.

Module propertiesThe modules that are deployable with this design are able to take advantage of the promise of SOA and Enterprise Service Bus. They are also able to decouple the impact to the clients of topology changes to the servers. The business modules that are deployed into this environment have the following properties.

Export

• SCA binding (JMS transports)

Export user


• User deployed into same cell as Process Server module

Module properties





Deployment target

of 48


Deployment target Support




Import

• SCA binding

Dependent service (Target of the import)

• Import deployed in the same cell as the business module


TopologyThis pattern creates two clusters: one which is used as the deployment target for the business module and the other which is used as the cluster member supporting the queues for the SCA interactions. The other element of this deployment pattern is two additional servers (or clusters) in the cell.

These other clusters (or servers) are the deployment targets of the user of the business module, and the dependent enterprise service (target of the import). How these servers (or clusters) are set up is not described in this design because they are not a part of the design. It is only required that they are deployed to the same cell.

We select the simplest setup option for the BPC queues because they are not used during the execution of the business module. The queues for supporting the SCA interactions are created on a bus member that is a separate cluster from the deployment cluster.

Figure 14: Process Server cluster with tolerance for cluster size

of 48




• Process Server




• Create BPCDB (copy, modify and run script).

3. Create the cell.



• Use the Process Server template for deployment target.

• Use the WebSphere Application Server template for ME cluster.


• BPC configuration wizard on the deployment target.

• HTM configuration wizard on the deployment target.


5. Create the MEs.

• Create the additional MEs.

• Create the HAmanager policies.

6. Recycle the dmgr.


Location tolerant Process Server clusterThe topology pattern described in this section provides a loose coupling between the business module and the services interacting with the business module. The decoupling involves both the interface of service and the availability of the services. An additional property of this design is that any modification of the size of the cluster does not require the users of the business module (or the enterprise service) to be recycled.

For this design, neither the user of the business module nor the dependent enterprise service (target of the import) is all deployed into the same cell.

of 48

Module propertiesThe modules that are deployable with this design are able to take advantage of the promise of SOA and Enterprise Service Bus. They are also able to decouple the impact to the clients of topology changes to the servers. The business modules that are deployed into this environment have the following properties.

Export

• JMS

Export user


Module properties





Deployment target






Import

• SCA binding

Dependent Service (Target of the import)


TopologyThis pattern creates two clusters: one which is used as the deployment target for the business module and the other which is used as the cluster member supporting the queues for the SCA interactions. The other element of this deployment pattern is two additional servers (or clusters) in the cell.

This other server is used to connect the SIB to an external source or user of the enterprise service. This server is a bus member of the SCA.APPLICATION bus and is a part of the same OS cluster as the MQ queue manager. How to set up the user of the business module and how to set up the dependent enterprise service (target of the import) are not described in this design because they are not a part of the design. We do, however, point

of 48

out that neither the user of the business module nor the dependent enterprise services are required to be a part of the cell.

We select the simplest setup option for the BPC queues because they are not used during the execution of the business module. The queues for supporting the SCA interactions are created on a bus member that is a separate cluster from the deployment cluster.

Figure 15: Process Server cluster with interactions outside of cluster




• Process Server




• Create the BPCDB (copy, modify and run script).

3. Create the cell.



• Use the Process Server template for deployment target.

• Use the WebSphere Application Server template for ME cluster.


of 48

• BPC configuration wizard on the deployment target.

• HTM configuration wizard on the deployment target.




Topology refactoringChanging the size of the deployment target cluster requires the recycling of the ME cluster members.

Process Server cluster with macroflows and partitioned queuesThe topology pattern presented in this section is the simplest to set up for a macro flow or interruptible process. It is comparable to the topology described in the section “My firstProcess Server cluster.”

Module propertiesThe modules that are deployable with this design take advantage of business processes that are interruptible. The enterprise services (alias business modules) deployed into this environment have the following properties.

Export


Module properties




• Macroflow and microflow supported processes

Deployment target

• HTM and BPEL enable



Business events


Business Admin


of 48


Import

• SCA imports

TopologyThis pattern creates a single cluster that is used as the deployment target for the business module. The queues for supporting SCA interactions are configured but since they are never used we choose the easiest deployment paths and locate them in the same cluster. The queues for supporting the BPC queues are also hosted in the same cluster and are partitioned.

We now look at the impact of the workload of these partitioned BPC queues.

When a macroflow moves from one activity to another (or group of activities as specified in the process flow) the next activity will be processed on the same cluster member.

Completing a human task is accomplished by interaction with the human task API (either directly or via the BPC explorer). How the work is distributed to claim the human task is not covered here. However, the cluster member that processed the completed work activity is the same cluster member that will process the next activity.

All responses from the asynchronous invocation of the partner will be processed on the cluster member with the active SCA queues.

Figure 16: Process Server cluster with macroflows

of 48


Use this cheat sheet to set up the design:


• Process Server





3. Create the cell.

• Create and the federate profiles.






5. Create the MEs for the CEI bus.

• Add the MEs to bus member.

• Create the HAManager policies.





Microflows and ad hoc business events queriesThe topology presented in this section adds the component of business events to a business module that includes microflows.

of 48

Module propertiesThe modules that are deployable with this design can take advantage of business events. The enterprise services (alias business modules) deployed into this environment have the following properties.

Export


Module properties

• Process with Microflow or no business process logic (No Macro flows)






Business events


Business Admin



Import

• No imports

Business events

• Ordering is not a requirement

TopologyThis pattern creates two clusters: one which is the deployment target of the business modules and a second which is the host of the CEI event server. The queues for supporting SCA interactions and those for supporting macro flows are configured but since they are never used we choose the easiest deployment paths and locate them in the same cluster. The queues for the CEI server are hosted on the same cluster that business module’s deployment target.

With this design, each partition of the CEI’s queue receives the events that are generated on the same cluster member. Each cluster member of the CEI server extracts messages from all of the partitions because of the designs of the SCA, SIB, WLM and connection components. (Read that to mean that this works because of the implementation rather than because the contracts of the interfaces assure the behavior.) When a new member is

of 48

added to the deployment target cluster then the CEI servers need to be recycled in order for them to connect to the new cluster member.

Figure 17: Microflows and business events

This topology requires four remote databases (ME, WPRCSDB, BPEDB and EVENT) to support the deployment target.

Use this cheat sheet to set up this design:


• Process Server

• Drivers for the database access.

2. Create most databases.



3. Create the cell.

• Create and the federate profiles.

4. Create the EVENT database.

• Modify the response.txt file and run script.

of 48

• Copy directory to database machine.

• Run the script.

5. Create the event cluster.

• Use the default server template.

• Run the script to create resources

• Run the script to install apps.

6. Create the App clusters.





7. Create the MEs for the Event bus.

• Add the MEs.

• Create the HAManager policies.





Designing an environment that is tolerant of changes to the size of the cluster require creating a separate cluster of MEs as described in the section “Locationtolerant Process Server cluster.”

Topology refactoring11. New cluster members

• Requires new ME and new HAMangaer policy

• Requires recycle of user of the enterprise service (user of the business module)

of 48

Location and cluster size tolerance, macroflows, and adhoc queries of events The topology presented in this section has been referred to internally as the ND7 environment. Although the label ND7 refers to an interaction pattern between a server and its queues, the term has been extended in some circles to mean the entire environment. Because of all of this confusion, we do not refer to this as ND7. One almost wants to call this the golden topology or standard topology design because it is the one that is most tolerant.

This topology design takes advantage of all of the functions in the Process Server product, and is tolerant of changes to the size of the cluster and is tolerant to the location of the users of the business module and of the location of the dependent business modules (import targets).

Module propertiesThe modules that are deployable with this design can take advantage of business events. The enterprise services (alias business modules) deployed into this environment have the following properties.

Export


Module properties

• BPEL with Macroflow

• Human task



Deployment target

• BPEL and HTM support



Business events

• Events not recorded in order they were generated

• Event processing not inline with request processing (asynchronous)

• Remote CEI server

• Business events consumer is adhoc queries to the default database

• No filtering of events

Business Admin

of 48

• Business administrator is isolated from the topology

• Administrator deals with business rules manager, BPC explorer, CBE Browser, relationship manager, failed event manager

• Human task operation is with the BPC Explorer

Import

• Asynchronous transports (Web services binding with SOAP/JMS transport, JMS bindings, SCA binding with asynchronous QOS, preferred interaction style asynchronous)

Business events

• Ordering is not a requirement

Topology

Figure 18: Complete Process Server environment with ad hoc queries for business events

Use the cheat sheet to set up the topology:


• Process Server

• IHS

of 48

• HTTP plug-in




• Create the BPC and Event databases (Copy ddl to database machine and run the ddl).

3. Create the cell.



• Configure as bus members.

5. Configure the MEs.

• For each cluster create the same number of MEs as cluster members.

• Create a HAManager policy for each ME.


Refactoring the environment1. Additional cluster members require additional HAManager policies.

2. Additional support for asynchronous invocation requires client analysis and design.

Reference patternThe design presented in this section is very similar to the design of the section titled “Location and cluster size tolerance, macroflows, and adhoc queries of events.” The difference is that the design in this section sends the business events to a queue where they can be processed, whereas the other section placed the events in a database that could be queried latter.

Module propertiesAny enterprise service (alias business module) deployed into this environment must have the following properties.

Export

• Asynchronous transports (Web services binding with SOAP/JMS transport, JMS, SCA asynchronous invocations)

• Messages do not need to be processed in order

• Modules are run Active/Active and the queues are run in active passive

Module properties

of 48

• BPEL with macroflow

• Human task





Business events

• Events not recorded in order they were generated

• Event processing not inline with request processing (asynchronous)

• Remote CEI server

• Business events consumer processes all events asynchronously

• No filtering of events

Business Admin

• Business administrator is isolated from the topology

• Administrator deals with business rules manager, BPC explorer, CBE Browser, relationship manager, failed event manager

Import

• Asynchronous transports (Web services binding with SOAP/JMS transport, JMS bindings, SCA binding with asynchronous QOS, preferred interaction style asynchronous)

Topology

of 48

Figure 19: Full featured, asynchronous exports, asynchronous event consumer


Use the cheat sheet to set up the topology:


• Process Server

• IHS

• HTTP plug-in

• Drivers for the database access.


• Create the WPRS and ME databases (simple DB command).

• Create the BPC and Event databases (Copy ddl to database machine and run the ddl).

3. Create the cell.

of 48



• Change the db of BPE ME.

• Change the schema name of BPE ME.


6. Set up the host alias.

7. Start the servers.

8. Install the application.


10. Start the application.

ConclusionThe 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. The companion articles provide a reference and a guide for you the first time you need to create a deployment environment.

AcknowledgementsThe following individuals provided great insight and knowledge that have been folded into this document: Karri Carlson, Stephen Cocks, Kyle Schlosser, Walid Danaf, Malcolm Aires, Graham Wallis.

Resources

• The WebSphere Application Server InfoCenter includes a section on the configuration and administration of clusters.

• Many of the availabilty concepts and setup information can be found in this availability redbook.

• A step-by-step guide for creating the reference topology can be found in this clustering article.

• WebSphere business integration zone

of 48

http://www.ibm.com/developerworks/websphere/zones/businessintegration

http://www.ibm.com/developerworks/websphere/techjournal/0604_chilanti/0604_chilanti.html

http://www.redbooks.ibm.com/abstracts/sg246688.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welcclusters.html

About the authorCharlie 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. You can reach Charlie at [email protected].

Karri Carlson-Neumann is a technology integration developer 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. You can reach Karri at [email protected].

Trademarks

• IBM and WebSphere are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both.

• Other company, product, and service names may be trademarks or service marks of others.

IBM copyright and trademark information: http://www.ibm.com/legal/copytrade.phtml

of 48

mailto:[email protected]

mailto:[email protected]

Deployment patterns for WebSphere Process Server and Enterprise

Documents

Transcript of Deployment patterns for WebSphere Process Server and Enterprise