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.
| Business Patterns | Description | Examples |
|---|---|---|
| Self-Service (User-to-Business) | Applications where users interact with a business via the Internet or intranet | Simple Web site applications |
| Information Aggregation (User-to-Data) | Applications where users can extract useful information from large volumes of data, text, images, etc. | Business intelligence, knowledge management, Web crawlers |
| Collaboration (User-to-User) | Applications where the Internet supports collaborative work between users | E-mail, community, chat, video conferencing, etc. |
| Extended Enterprise (Business-to-Business) | 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.
| Integration Patterns | Description | Examples |
|---|---|---|
| Access Integration | Integration of a number of services through a common entry point | Portals |
| 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.
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.
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.
| Composite Patterns | Description | Examples |
|---|---|---|
| Electronic Commerce | User-to-Online-Buying |
|
| Portal | Typically designed to aggregate multiple information sources and applications to provide uniform, seamless, and personalized access for its users. |
|
| Account Access | Provide customers with around-the-clock account access to their account information. |
|
| Trading Exchange | Allows buyers and sellers to trade goods and services on a public site. |
|
| Sell-Side Hub (Supplier) | 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 (Purchaser) | 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.
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.
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.
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.
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.
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 > |
|
EAN: N/A
Pages: 139