![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Module design and your deployment
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.
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
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
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
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
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).
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.
The following individuals contributed great insight and knowledge to this document: Karri Carlson, Stephen Cocks, Kyle Schlosser, Walid Danaf, Malcolm Aires, and Graham Wallis.
| Description | Name | Size | Download method |
|---|---|---|---|
| Reference guide1 | 0611_redlin-deploypatterns.pdf | 800KB | HTTP |
Information about download methods
Note
- Contains the reference guide pdf file.
-
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, WebSphere Application Server Network Deployment V6: High Availability Solutions.
-
A step-by-step guide for creating the reference topology can be found in this clustering article, Basic steps for clustering WebSphere Process Server.
-
WebSphere business integration zone
- IBM WebSphere Developer Technical Journal
-
Browse the
technology bookstore for books on these and other technical topics.
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 is an Advisory 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.
