![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The Patterns for e-business are a group of proven, reusable assets that can help speed the process of developing e-business solutions. IBM® published Patterns for e-business on the Web in 1999. Since then many have contributed to these patterns -- most notably, Jonathan Adams et al. (see Resources), who developed a conceptual framework that business analysts and system architects can use to determine the various patterns that serve their needs. The recipe in this article uses this conceptual framework.
In this article, we use many different patterns, all of which you can find on the IBM Web site IBM Patterns for e-business. For those that are not yet available on the Web site, we have provided the references. In some cases, we did not find an appropriate pattern. For those cases, we have introduced new designs with the potential of becoming patterns in the future:
- Business Process Composite pattern, allows a human to initiate a business process that requires collaboration and monitoring.
- Page Aggregation Application and Run-time pattern, an Access Integration pattern that provides a structure for giving access to multiple Web applications through a common interface that you can customize.
- Managed Collaboration Run-time pattern, allows users to collaborate in a pre- defined manner.
This article uses the OTMPS described in the overview article, (see On demand business process life cycle, Part 1), as the context scenario for demonstrating the use of Patterns for e-business in creating effective run-time architecture.
The Patterns for e-business recipe
The recipe has the following steps:
- Develop a high-level business description
- Develop a Solution Overview Diagram
- Identify Business patterns
- Identify Integration patterns
- Identify Composite patterns
- Identify Application patterns
- Integrate a package into the solution
- Identify Run-time patterns
- Map to products
Step 1: Develop a high-level business description
An OTMPS enables its users to initiate an order submission process. The users can translate validated and configured orders into a Bill of Materials (BOM) in manufacturing nomenclature and then submit them to manufacturing plants for fulfillment. In a successful case, the orders that the users submit go through various steps for grouping of order parts, validation of orders and configuration, and to the manufacturing process as a BOM and other instructions. There might be exceptions to this normal processing such as the handling of invalid orders, dealing with system exceptions, and other issues. This requires human involvement with varying roles, such as approvers to handle invalid orders and system administrators to deal with system exceptions in the workflow process.
Based on interviews with the owners of the OTMPS, the analysts specified the high- level requirements for the OTMPS listed in the Overview article (see Resources). We further refined the notification requirements as follows:
- System should start a new instance of a problem resolution workflow -- a managed peer-to-peer collaboration workflow -- when it discovers a problem.
For additional details and the specific use cases, see On demand business process life cycle, Part 1.
Step 2: Develop a Solution Overview Diagram
You can develop a Solution Overview Diagram by converting the text provided by the business description into a pictorial representation. We did this activity during the use case analysis (see Resources); we now derive the Solution Overview Diagram using the different use cases, as shown in Figure 1.
Figure 1. Solution Overview Diagram for OTMPS
Step 3: Identify Business patterns
The Executive Dashboard allows the owner to monitor the business performance by looking at the aggregated information from different systems. This indicates an Information Aggregation pattern.
An operator can:
- Place an order
- Look at the status of an order
- Cancel an order
- Change business rules
An administrator can:
- Start the order processes
- Stop the order processes
- Suspend the order processes
- Resume the order processes
These actions involve direct interaction between users and back-end systems (Order Processing system) and indicate a Self-Service business pattern. The OTMPS notifies operators, administrators, and owners of any operational, system, and business problems respectively, and then manages the corresponding problem resolution workflow, which involves peer-to-peer collaboration. These interactions indicate the Collaboration business pattern.
A supply chain OTMPS needs to send purchase orders to suppliers for further processing of orders and fulfillment. This interaction is across enterprise boundaries and indicates an Extended Enterprise business pattern.
Step 4: Identify Integration patterns
It is desirable to have a common look and feel for all users and role-based access with single sign-on across different applications. In order to provide this functionality, you need an Access Integration pattern (this is optional).
As evident from the Solution Overview Diagram in Figure 1, you need Process Integration patterns (a subset of the Application Integration pattern) for the links from OTMPS to the:
- Business Metrics application
- Notification Handler
- Rules Management application
- Supplier's system
- Manufacturing applications
- Business Metrics application to other systems
The Business Metric application aggregates the process information that it receives from OTMPS and other systems. In other words, you need a Data Integration pattern (another subset of the Application Integration pattern).
Note: Typically, the Data Integration patterns are thought of as pull patterns, that is, they are applicable only in situations when an application populates the data by reading the data sources of other applications. But a message queue or set of input arguments can also be thought of as a data source. Therefore, Data Integration patterns are also applicable in cases where the data is pushed to the population application by other applications using Process Integration patterns.
Step 5: Identify Composite patterns
Based on the patterns identified so far, we summarize the solution in Figure 2. We did not find a Composite pattern that meets the requirements of OTMPS. At a first glance, it seems that we might be able to use the Portal Composite pattern (see Resources). Yet, on a close inspection of the corresponding Application patterns, we find that it does not satisfy the requirements. For example, OTMPS has a requirement for managed peer-to-peer collaboration, which the Portal Composite pattern does not support. Similarly, Personalized Delivery and Population Application patterns are mandatory, but we do not have these requirements.
Figure 2. No existing Composite pattern for OTMPS
Step 6: Identify Application patterns
Since you are only looking at the Web channel that includes back-end integration, Directly Integrated Single Channel is the right pattern for the Order Entry, Rules Management, and Administration Console/Monitor applications.
In case of a notification, you should keep track of the actions that the Staff/Administrator/Owner take, and allow them to transfer the work. In other words, you require the Notification Handler to not only notify the users but also drive the corresponding peer-to-peer workflow. Therefore, Managed Collaboration pattern is the right one to use.
Step 6.3. Information Aggregation
Since you are interested in providing read access to the aggregated business performance, you need the User Information Access application pattern (see Resources). As of now, there are no requirements to allow the process owners to store a local copy of their results or to initiate changes to the source applications (for example, OTMPS). Therefore, the Basic pattern without a drill-through server is sufficient.
You need to integrate with different suppliers and to substitute a supplier with another, without changing the OTMPS, as long as their message formats are compatible. In other words, you need 1:N mapping with the request being forwarded to at most one target. The router variation of the Exposed Broker pattern (see Resources) is most appropriate for these requirements.
You want a common look and feel and role-based access with single sign-on across different applications. In other words, you want presentation and security services. Security service has been well captured by the Single Sign On application pattern(s). You can implement presentation service by using a variation of the Directly Integrated Single Channel (DISC) application pattern, which is a Self-Service application pattern. The primary driver for using this pattern is to provide real-time access to back-end applications and data from Web applications -- "back-end applications and data" being the key. But you can use it to provide access to multiple Web applications from a single Web application and thereby provide a common presentation layer. There is a reference to this variation in Figure 4-8 of the IBM Redbook A Portal Composite Pattern Using IBM WebSphere® Portal V5. Unfortunately, it is presented by merging the variation with the original DISC application pattern and still referred to as Directly Integrated Single Channel application pattern. In this article, we refer to this variation as the Page Aggregation application pattern (as shown in Figure 3), which represents the aggregation of Web applications only, that is, it does not include the Self-Service pattern.
Figure 3. Page Aggregation application pattern
Step 6.6. Application Integration
The Direct Connection application pattern is sufficient to capture the interaction between OTMPS and the Business Metric application, OTMPS and the Supplier's OTMPS and the Rules Management application, and between the Business Metric application and other systems.
An OTMPS is essentially a workflow application which takes an order through different checkpoints, interacts with manufacturing applications, and finally sends a BOM to the manufacturing plant. You also want the OTMPS to adapt to changes in business policies and processes. In other words, you require the workflow capabilities, along with the flexibility provided by the Broker or Router pattern. Therefore, a Managed Process application pattern is ideal. Since order processing is serial in nature, you should use Serial Process pattern instead of Parallel Process pattern (see Resources) to integrate OTMPS with the manufacturing applications.
The Direct Connection application pattern is sufficient for the integration between the Notification Handler and OTMPS.
Since the Business Metric application only aggregates the data that it receives from various sources, the Population application pattern (see Resources) is sufficient.
Step 6.7. Summarize all the Application patterns required
Figure 4 summarizes all the required Application patterns for the OTMPS.
Figure 4. Solution to Patterns for e-business mapping
Step 7: Integrate a package into the solution
You can use the Common Event Infrastructure (CEI) (see Resources) for aggregating the process events sent by OTMPS and other systems. CEI provides the Data Integration: Population application pattern and also supports the integration using the Process Integration: Direct Connection application pattern. CEI does not provide a direct access to the event database but it does provide the APIs to query the database. In other words, it can be viewed as a data service. Therefore, the patterns mapping shown in Figure 4 is still valid.
Step 8: Identify Run-time patterns
Step 8.1. Single sign-on (SSO) and Page Aggregation patterns
There is no requirement to use heterogeneous application servers, that is, your applications will be running on homogeneous application servers. Thus, for SSO, you can use the Homogeneous Application Server Run-time pattern, which is shown in Figure 5.
Figure 5. Access Integration:: Single Sign-On:: Homogeneous Application Server
For the Page Aggregation pattern, you can use a variation of the Directly Integrated Single-Channel::Run-time Variation 1, as shown in Figure 6, in which Application Server node has been replaced by Portal Server node.
Figure 6. Access Integration:: Page Aggregation:: Page Aggregation Run-time pattern
Step 8.2. User Information Access pattern
In this scenario, you do not have a direct access to the data source, but the User Information Access Run-time pattern (see Resources), shown in Figure 7, is still appropriate because you can view CEI as a data service.
Figure 7. Information Access - Read-Only:: BI application in internal network
Step 8.3. Directly Integrated Single Channel pattern
Given the proliferation of hacker attacks, Run-time Variation 1, shown in Figure 8, is the recommended pattern for the Directly Integrated Single Channel application pattern.
Figure 8. Self-Service:: Directly Integrated Single Channel:: Run-time Variation 1
Step 8.4. Managed Collaboration pattern
The only documentation on the Managed Collaboration pattern is the Application pattern in the Patterns for e-business book (see Resources). Therefore, we are introducing and using a potentially new pattern -- the Managed Collaboration Run-time pattern.
The Managed Collaboration Run-time pattern, shown in Figure 9, allows the Web clients to collaborate synchronously or asynchronously, that is, the receiver doesn't have to connect to the collaboration server, in a pre-defined manner. It achieves this by processing the incoming request through a pre-defined workflow and storing the response for a later retrieval by the receiver(s).
Figure 9. Managed Collaboration Run-time pattern
The Collaboration Server acts as a facade between the workflow and the clients. It maps a workflow message receiver (for example, a user, manager, group, role, and so forth) to the actual users, using the workflow meta-data information. It is also responsible for storing the workflow messages for the clients and allowing them to view and reply to those messages. Once a reply is received, the server forwards the reply to the workflow and deletes the original message.
The Workflow Manager is responsible for the execution of the pre-defined workflow. It maintains the state of the workflow till the workflow completes. It is also responsible for mapping an incoming message to a workflow instance.
Step 8.5. Direct Connection pattern
Since you plan to expose different components as services, the Simple Service Bus pattern (see Resources), shown in Figure 10, is most appropriate.
Figure 10. Direct Connection:: Simple Service Bus pattern
Serial Process Run-time pattern (see Resources), shown in Figure 11, allows the OTMPS to interact with different applications in a serial manner. The process manager manages this interaction.
Figure 11. Serial Process Run-time pattern
Step 8.7. Run-time pattern for Exposed Router application pattern
You need a Run-time pattern that corresponds to the Exposed Router application pattern for integration with the suppliers. This Run-time pattern should support the 1:N mapping, as well as the protocol transformation for access to existing systems. Either the Exposed Router Run-time pattern (Figure 12), or the Exposed Enterprise Service Bus (ESB) pattern (Figure 13), support that requirement (see Resources). Exposed ESB pattern is a better choice for you because you intend to build a SOA solution and Exposed ESB pattern provides the set of infrastructure capabilities that enable the integration of services in a SOA (see Resources).
Figure 12. Exposed Broker:: Router pattern
Figure 13. Exposed ESB Gateway composite pattern
Step 8.8. Summarize all the Run-time patterns
You consolidate the overlapping Run-time patterns. The Merged Run-time patterns, shown in Figure 14, give a complete picture of the logical run-time architecture. Note that the Simple Service Bus and CEI patterns are part of the ESB pattern. Similarly, the Process Manager and the Workflow Manager have been merged into a single Process Manager node because the Process Manager also has the workflow capabilities.
Figure 14. Merged Run-time patterns
Step 9: Identify Run-time and Product mappings
You can map Run-time patterns to different product configurations. For example, you can map the Process Manager to WebSphere Business Integration Server Foundation or WebSphere MQ Workflow (see Resources). You can also have the option of mapping ESB to WebSphere Business Integration Message Broker or WebSphere Business Integration Server Foundation, and so forth (see Resources). The choice depends upon many factors such as:
- Product capabilities
- Cost
- Existing skills
- Ease of development
- Industry direction
For the Process Manager, you can use the flow control in WebSphere Business Integration Server Foundation (see Figure 15) because it is based on open standards J2EE and Business Process Execution Language for Web Services (BPEL4WS). Similarly, for the Portal Server, you can use WebSphere Portal Express because it provides all the necessary features. At times, no existing product meets the exact requirements. You have to decide whether to accept the partial fulfillment of a requirement or to develop a tailored solution. For flexibility, you might prefer a loose coupling between the collaboration server and the Process Manager, but in the WebSphere Business Integration Server Foundation product, they are tightly coupled. Moreover, the default collaboration application that comes with WebSphere Business Integration Server Foundation, Business Portal, has the collaboration workflow embedded into the application. We decided to use it because its limitations are minor and the potential high cost of the alternative, that is, trying to externalize the collaboration server and the corresponding workflow.
Figure 15. Product mapping for OTMPS
Based on our experience with the OTMPS, we do see a new design -- Business Process, which could become a composite pattern after further validation. Figure 16 shows the use cases implemented by Business Process pattern and the Patterns for e-business patterns that implement those use cases.
Figure 16. Business Process composite pattern
(Potential) Business Process composite pattern
This pattern allows a person to initiate a business process, which integrates various applications/services and interacts with the person to fulfill his or her request. It also allows monitoring of the business and process performance.
The Business Process composite pattern consists of the following patterns:
- The Self-Service business pattern facilitates the interaction between a customer and the business processes. Activities such as order submission, claim submission, or account creation are performed using this pattern. It also helps the system administrators in managing the business processes.
-
The Collaboration business pattern facilitates the interaction between:
- A customer and operators
- Among operators
- Between business process and customers or operators
- The Information Aggregation business pattern provides a read-only access to the business process performance data. Optionally, you can use it to transform the process performance data into business performance metrics.
- The Application Integration patterns integrate the Self-Service, Collaboration, Extended Enterprise, and Information Aggregation business patterns. You can also use them to integrate the business processes with the existing applications/support systems, for example, integration between an OTMPS process and a manufacturing system.
Optionally, the Business Process composite pattern can also include the following:
- Extended Enterprise business pattern: This pattern interacts with business partners' applications (for example, provides interaction between the OTMPS, and a supplier's order submission application).
- Access Integration pattern: This pattern provides a portal interface, SOS functions, and personalization functions for the customer.
Patterns for e-business can be very useful to create an effective architecture that meets the needs of an On Demand Business. But given the number of patterns and the possible product mappings, using these patterns is not trivial. In this article, we've shown a recipe for how to choose and apply different patterns and products to create the system architecture for an OTMPS. You can use this architecture for other systems that have similar business and IT requirements.
The authors would like to thank Jonathan Adams and Dr. George Galambos for their help in reviewing this article.
-
Read all parts of the On demand business process
life cycle, and keep track as we add new installments.
- IBM Patterns for e-business provides valuable information on a variety of reusable e-business patterns that can help speed the process of developing Web applications.
- Find out more about Patterns for e-business in the book Patterns for e-business: A Strategy for Reuse by Jonathan Adams, Srinivas Koushik, Guru Vasudeva, and George Galambos (IBM Press, 2001, ISBN 1-931182-02-7).
- Read the following Redbooks for more information on SOA, Web Services, and on demand:
- Patterns: Serial and Parallel Processes for Process Choreography and Workflow, IBM Redbook SG24-6306-00
- Patterns: Broker Interactions for Intra- and Inter-Enterprise, IBM Redbook SG24-6075-00
- Patterns: Implementing an SOA using an Enterprise Service Bus, IBM Redbook SG24-6346-00
- Patterns: Custom Designs for Domino and WebSphere Integration, IBM Redbook SG24-6903-00
- Patterns: SOA and Web Services, IBM Redbook SG24-6303-00
- Access Integration Pattern Using IBM WebSphere Portal Server, IBM Redbook SG24-6267-00
- A Portal Composite Pattern Using WebSphere Portal V5, IBM Redbook SG24-6087-00
- Patterns: Information Aggregation and Data Integration with DB2 Information Integrator, IBM Redbook SG24-7101-00
- Learn more about the Common Event Infrastructure, IBM's implementation of a consistent, unified format for business, systems, and network events based on the Common Base Event (CBE) format.
- Get information about the On Demand operating environment from the following articles:
- The On Demand operating environment (developerWorks, August 2004)
- Operating environment essentials for an on demand breakthrough (developerWorks, August 2004)
- Architecting on demand solutions: Best practices for using the thirteen capabilities of the IBM On Demand Operating Environment (article series, developerWorks)
- Want more? The developerWorks Web Services and SOA zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
- Browse for books on these and other technical topics.
Naveen Sachdeva is an Advisory Software Engineer with the IBM Application Integration Middleware group. He has over 10 years of experience in large-scale system integration and the design and development of distributed computing systems. He currently helps IBM business partners with technical enablement and proof-of-concept using WebSphere products. You can contact Naveen at sachdeva@us.ibm.com.
Dr. German Goldszmidt is a Senior Technical Staff Member working with the IBM Software Group, with a focus on architecture of an integrated platform for delivering, customizing, and deploying on demand solutions. Previously, he was a researcher at the IBM T.J. Watson Research Center and led the design and implementation of several technologies, including Oceano, the first prototype autonomic computing eUtility and Network Dispatcher, the load balancer component of WebSphere. You can contact German at gsg@us.ibm.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
