Introduction

This example illustrates how to use the 2010 revised P4eb patterns. We will take the example described here and show how to enhance it.

This earlier solution was not designed using SOA principles, so the background integration (such as the integration between the e-Commerce application and the financial institution) was implemented as an asynchronous background task using either Data Integration or Process Integration. This therefore led to a response time of hours or even days, which is no longer acceptable to the customers.

For the enhanced scenario, we need to improve this so that the customer gets a response to the loan request in real-time. This will greatly decrease the response time and thus lead to increased customer satisfaction. In addition, the e-Commerce application will be extended in a way that would enable a future programmatic order entry channel to reuse many components.

Different architects will use the P4eb in different ways. Time will often be a key factor in deciding the level of detailed analysis that can be achieved. The list below suggests some possible alternative levels of detail:

1. A basis for a business scenario decomposition into Subsystems - and a summary of the Subsystems required for the scenario in priority order
2. A preliminary list of product requirements (Step 1 / Iteration 1)
3. Review of alternative high-level designs for each End-to-End Subsystem and a revised list of product requirements (Step 2 / Iteration 2)
4. Review of alternative high-level designs for each Integration Subsystem and a revised list of product requirements (Step 3 / Iteration 3)
5. A basis for a product fit-gap analysis and client-specific migration planning

Applying Step 1: Scenario decomposition

Before you start, you need a logical application component model that shows the logical application components of the system to be implemented. This model doesn't need to be highly detailed; it simply should outline all the necessary logical application components and their interactions with each other. An example of a logical application component model can be found in the picture below.

In this scenario, we have a simple e-Commerce application which is accessed via a browser. The application allows the user to select a product, check whether the product is in stock , obtain a loan from a finance company to help purchase the goods, and then place an order for them. In future a customer will also be able to order products programmatically.

These new business requirements result in a new logical application component model:

The pattern abstractions available for the scenario decomposition are shown in the picture below.

The next task is to decompose the scenario into Subsystems and pick the Business patterns which characterize each Subsystem best. To do this, take the logical application component model and look for end-to-end business interactions within the business scenario. This is typically done using a graphic representing all the Business patterns.

The following graphic shows that we can identify two different business patterns: Foundation E2E Self-Service business pattern which characterizes the FECS User Order Entry Subsystem and the Foundation E2E - Extended Enterprise business pattern which characterizes the FECS Financing Subsystem. The Foundation E2E Self-Service business pattern is chosen because the user can select and order a product, discover its stock status, and request credit using the self-service nature of the application. The Foundation E2E - Extended Enterprise business pattern is chosen because the financial institution is an external company. So the e-Commerce company communicates with the financial institution in order to request a credit offer for the customer; confirmation of the loan will then be sent back to the user after it has been approved.

In addition, the business pattern for planned future requirements needs to be identified as well. Here we too have a Foundation E2E - Extended Enterprise business pattern because the FECS Automated Order Entry Subsystem can programmatically use the FECS store to order goods. This subsystem contains the components Programmatic Product Selection, Order Entry, Inventory Control and Customer Financing, because we want the users of the automated order entry system to be able to reuse order entry, and inventory control as well as our financing service. This can be seen in the following dotted rectilinear polygon:

Refining the Business patterns

The next step is to identify the Application patterns, Runtime patterns and possible product mappings. To do this, you inspect each of the Business patterns and choose the Application pattern that fits the requirements for the subsystem best.

An examination of the topology requirements indicates that each of the components can be supported with least complexity by a Foundation E2E Self-Service::Router application pattern. In addition we find out that because of the need for service reuse we need a [SOA]Foundation E2E Runtime pattern which can be realized with WebSphere ESB.

The same procedure applies to the FECS Automated Order Entry Subsystem. We find out that the Extended Enterprise::Exposed Direct Connection application pattern fits our purposes best, because we connect two distinct systems of two distinct companies together using a direct connection. To provide the backend connectivity of the two systems, we use a [SOA]Exposed Direct Connection runtime pattern which can be implemented using WebSphere ESB.

The last subsystem to inspect is the FECS Financing Subsystem which fits with an Extended Enterprise::Exposed Serial & Orchestrated Processes application pattern. The reason for this is the kind of communication between the e-Commerce store and the financial service provider. Because there are many rules which need to be obeyed, external service reuse is required, and because of the need for a highly secure transaction this application pattern is chosen. This application pattern is supported by the [SOA]Exposed Serial & Orchestrated Processes runtime pattern. To implement this runtime pattern WebSphere Partner Gateway and WebSphere Process Server are required.

After identifying the Application patterns and the matching Runtime patterns we get a list of candidate products and related assets which may be of use in implementing all the subsystems.

After this step, the different candidate products can be combined and synthesized, compared with the existing product inventory, and this results in a list of products actually required (Iteration 1).

Download the complete worked example description here