1.2 How to use the Patterns for e-business

 < Day Day Up > 

1.2 How to use the Patterns for e-business

As described in the last section, the Patterns for e-business have a layered structure where each layer builds detail on the last. At the highest layer are Business patterns. These describe the entities involved in the e-business solution.

Composite patterns appear in the hierarchy shown in Figure 1-1 on page 5 above the Business patterns. However, Composite patterns are made up of a number of individual Business patterns, and at least one Integration pattern. In this section, we discuss how to use the layered structure of Patterns for e-business assets.

1.2.1 Select a Business, Integration, or Composite pattern, or a Custom design

When faced with the challenge of designing a solution for a business problem, the first step is to get a high-level view of the goals you are trying to achieve. A proposed business scenario should be described and each element should be matched to an appropriate IBM Pattern for e-business. You may find, for example, that the total solution requires multiple Business and Integration patterns, or that it fits into a Composite pattern or Custom design.

For example, suppose an insurance company wants to reduce the amount of time and money spent on call centers that handle customer inquiries. By allowing customers to view their policy information and request changes online, the company will be able to cut back significantly on the resources spent handling this by phone. The objective is to allow policy holders to view their policy information stored in legacy databases.

The Self-Service business pattern fits this scenario perfectly. It is meant to be used in situations where users need direct access to business applications and data. Let's take a look at the available Business patterns.

Business patterns

A Business pattern describes the relationship between the users, the business organizations or applications, and the data to be accessed.

There are four primary Business patterns, explained in Table 1-1.

Table 1-1: The four primary Business patterns

Business Patterns





Applications where users interact with a business via the Internet or intranet

Simple Web site applications

Information Aggregation


Applications where users can extract useful information from large volumes of data, text, images, etc.

Business intelligence, knowledge management, Web crawlers



Applications where the Internet supports collaborative work between users

E-mail, community, chat, video conferencing, etc.

Extended Enterprise


Applications that link two or more business processes across separate enterprises

EDI, supply chain management, etc.

It would be very convenient if all problems fit nicely into these four slots, but reality says that things will often be more complicated. The patterns assume that most problems, when broken down into their basic components, will fit more than one of these patterns. When a problem requires multiple Business patterns, the Patterns for e-business provide additional patterns in the form of Integration patterns.

Integration patterns

Integration patterns allow us to tie together multiple Business patterns to solve a business problem. The Integration patterns are outlined in Table 1-2 on page 8.

Table 1-2: Integration patterns

Integration Patterns



Access Integration

Integration of a number of services through a common entry point


Application Integration

Integration of multiple applications and data sources without the user directly invoking them

Message brokers, workflow managers

These Business and Integration patterns can be combined to implement installation-specific business solutions. We call this a Custom design.

Custom design

We can illustrate the use of a Custom design to address a business problem through an iconic representation as shown in Figure 1-2.

click to expand
Figure 1-2: Patterns representing a Custom design

If any of the Business or Integration patterns are not used in a Custom design, we can show the unused patterns as lighter blocks than those that are used. For example, Figure 1-3 on page 9 shows a Custom design that does not have a Collaboration business pattern or an Extended Enterprise business pattern for a business problem.

click to expand
Figure 1-3: Custom design with Self-Service, Information Aggregation, Access Integration and Application Integration

A Custom design may also be a Composite pattern if it recurs many times across domains with similar business problems. For example, the iconic view of a Custom design in Figure 1-3 can also describe a Sell-Side Hub composite pattern.

Composite patterns

Several common uses of Business and Integration patterns have been identified and formalized into Composite patterns. The identified Composite patterns are shown in Table 1-3 on page 10.

Table 1-3: Composite patterns

Composite Patterns



Electronic Commerce


  • www.macys.com

  • www.amazon.com


Typically designed to aggregate multiple information sources and applications to provide uniform, seamless, and personalized access for its users.

  • Enterprise Intranet portal providing self-service functions such as payroll, benefits, and travel expenses.

  • Collaboration providers who provide services such as e-mail or instant messaging.

Account Access

Provide customers with around-the-clock account access to their account information.

  • Online brokerage trading apps.

  • Telephone company account manager functions.

  • Bank, credit card and insurance company online apps.

Trading Exchange

Allows buyers and sellers to trade goods and services on a public site.

  • Buyer's side - interaction between buyer's procurement system and commerce functions of e-Marketplace.

  • Seller's side - interaction between the procurement functions of the e-Marketplace and its suppliers.

Sell-Side Hub


The seller owns the e-Marketplace and uses it as a vehicle to sell goods and services on the Web.

www.carmax.com (car purchase)

Buy-Side Hub


The buyer of the goods owns the e-Marketplace and uses it as a vehicle to leverage the buying or procurement budget in soliciting the best deals for goods and services from prospective sellers across the Web.

www.wre.org (WorldWide Retail Exchange)

The makeup of these patterns is variable in that there will be basic patterns present for each type, but the Composite can easily be extended to meet additional criteria. For more information on Composite patterns, refer to Patterns for e-business: A Strategy for Reuse by Jonathan Adams, Srinivas Koushik, Guru Vasudeva, and George Galambos.

1.2.2 Selecting Application patterns

Once the Business pattern is identified, the next step is to define the high-level logical components that make up the solution and how these components interact. This is known as the Application pattern. A Business pattern will usually have multiple possible Application patterns. An Application pattern may have logical components that describe a presentation tier for interacting with users, an application tier, and a back-end application tier.

Application patterns break the application down into the most basic conceptual components, identifying the goal of the application. In our example, the application falls into the Self-Service business pattern and the goal is to build a simple application that allows users to access back-end information. The Self-Service::Directly Integrated Single Channel application pattern shown in Figure 1-4 fulfills this requirement.

click to expand
Figure 1-4: Self-Service--Directly Integrated Single Channel

The Application pattern shown consists of a presentation tier that handles the request/response to the user. The application tier represents the component that handles access to the back-end applications and data. The multiple application boxes on the right represent the back-end applications that contain the business data. The type of communication is specified as synchronous (one request/one response, then next request/response) or asynchronous (multiple requests and responses intermixed).

Suppose that the situation is a little more complicated than that. Let's say that the automobile policies and the homeowner policies are kept in two separate and dissimilar databases. The user request would actually need data from multiple, disparate back-end systems. In this case there is a need to break the request down into multiple requests (decompose the request) to be sent to the two different back-end databases, then to gather the information sent back from the requests, and then put this information into the form of a response (recompose). In this case the Self-Service::Decomposition application pattern shown in Figure 1-5 would be more appropriate.

click to expand
Figure 1-5: Self-Service--Decomposition

This Application pattern extends the idea of the application tier that accesses the back-end data by adding decomposition and recomposition capabilities.

1.2.3 Review Runtime patterns

The Application pattern can be further refined with more explicit functions to be performed. Each function is associated with a runtime node. In reality these functions, or nodes, can exist on separate physical machines or can co-exist on the same machine. In the Runtime pattern this is not relevant. The focus is on the logical nodes required and their placement in the overall network structure.

As an example, let's assume that our customer has determined that his solution fits into the Self-Service business pattern and that the Directly Integrated Single Channel pattern is the most descriptive of the situation. The next step is to determine the Runtime pattern that is most appropriate for his situation.

He knows that he will have users on the Internet accessing his business data and he will therefore require a measure of security. Security can be implemented at various layers of the application, but the first line of defense is almost always one or more firewalls that define who and what can cross the physical network boundaries into his company network.

He also needs to determine the functional nodes required to implement the application and security measures. The Runtime pattern shown in Figure 1-6 is one of his options.

click to expand
Figure 1-6: Directly Integrated Single Channel application pattern--Runtime pattern

By overlaying the Application pattern on the Runtime pattern, you can see the roles that each functional node will fulfill in the application. The presentation and application tiers will be implemented with a Web application server, which combines the functions of an HTTP server and an application server. It handles both static and dynamic Web pages.

Application security is handled by the Web application server through the use of a common central directory and security services node.

A characteristic that makes this Runtime pattern different from others is the placement of the Web application server between the two firewalls. The Runtime pattern shown in Figure 1-7 is a variation on this. It splits the Web application server into two functional nodes by separating the HTTP server function from the application server. The HTTP server (Web server redirector) serves static Web pages and redirects other requests to the application server. It moves the application server function behind the second firewall, adding further security.

click to expand
Figure 1-7: Directly Integrated Single Channel application pattern--Runtime pattern- Variation 1

These are just two examples of the possible Runtime patterns available. Each Application pattern will have one or more Runtime patterns defined. These can be modified to suit the customer's needs. For example, the customer may want to add a load-balancing function and multiple application servers.

1.2.4 Review Product mappings

The last step in defining the network structure for the application is to correlate real products with one or more runtime nodes. The Patterns Web site shows each Runtime pattern with products that have been tested in that capacity. The Product mappings are oriented toward a particular platform, though more likely the customer will have a variety of platforms involved in the network. In this case, it is simply a matter of mix and match.

For example, the runtime variation in Figure 1-7 on page 14 could be implemented using the product set depicted in Figure 1-8.

click to expand
Figure 1-8: Directly Integrated Single Channel application pattern- Windows 2000 Product mapping

1.2.5 Review guidelines and related links

The Application patterns, Runtime patterns, and Product mappings are intended to guide you in defining the application requirements and the network layout. The actual application development has not been addressed yet. The Patterns Web site provides guidelines for each Application pattern, including techniques for developing, implementing, and managing the application based on the following:

  • Design guidelines instruct you on tips and techniques for designing the applications.

  • Development guidelines take you through the process of building the application, from the requirements phase all the way through the testing and rollout phases.

  • System management guidelines address the day-to-day operational concerns, including security, backup and recovery, application management, and so forth.

  • Performance guidelines give information on how to improve the application and system performance.

 < Day Day Up > 

Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net