1.3 Patterns

< Day Day Up >

What is a pattern?

A pattern is a structured and formal approach for describing a reusable solution to a reoccurring problem. Patterns should be concise and specific, but not inflexible. A successful pattern not only is reused in addressing the same reoccurring problem, but is flexible enough to be customized to meet a slightly different but relevant challenge. Patterns are typically a collection of documented best practices and lessons learned from tackling similar problems.

The concept of using well-defined patterns originated in the building architecture and construction industry. A Pattern Language: Towns, Buildings, Construction by Christopher Alexander et al., published in 1977, has largely been credited with introducing the concept of patterns.

Buschman et al., the authors of Pattern-Oriented Software Architecture—A System of Patterns, identified patterns for system architecture at a higher level than the original design patterns. Their patterns are related to the macro design of system components such as operating systems or network stacks. Information technology architects, encouraged by the success of design patterns, and facing challenges in systematic and repeatable description of systems, have also explored the idea of architectural patterns.
Why patterns?

Deployment of pattern type standards has contributed to rapid advancements in the computer hardware industry. This success and the need for reusability and rapid software development gave rise to object-oriented software, design patterns, and component-based development.

The idea of design patterns has gained acceptance by software designers and developers because it enables efficiency in both the communication and implementation of software design, based upon a common vocabulary and reference. Design patterns:
1. Extend reach and value to field
2. Reflect important configurations for IBM products
3. Enable architects to demonstrate IBM thought leadership
4. Provide SWG ITAs with tools to facilitate…
  - "Top-down" industry solution design with clients
  - Skills transfer and assimilation related to Industry solutions as well as IBM products
  - Comparison and positioning of solutions and products
5. Document and communicate value of IBM intellectual capital
How can patterns help me?

Understanding the Patterns for e-business and specifically the Composite patterns is not always a straightforward process. In interpreting how to use the Patterns for e-business, it is best to start with how people in different roles might leverage these to explain and/or justify a particular solution.

Patterns leverage the experience of IBM architects to create solutions quickly, whether for a small local business or a large multinational enterprise. As shown in Figure 1-5, customer requirements are quickly translated through the different levels of Patterns assets to identify a final solution design and product mapping appropriate for the application being developed.

Figure 1-5: Product versus solution space
Who uses patterns and how?

In a portal implementation, the Portal composite pattern is the logical starting point. It identifies the Business and Integration patterns that make sense for the typical portal implementation. These roles are common in the IT industry, and each type of role will use and leverage patterns in a different manner.
1. The sales role describes a person who is making the initial relationship with those organizations that might benefit from using and understanding patterns. This role can be filled by a person within an organization or someone from an external vendor ^[12] who has the expertise to understand the business problems and issues that must be addressed. The salesperson will use the patterns to begin the analysis discussion with the business-level stakeholders to understand the business drivers. They will start with the Business and Integration patterns and likely continue to the Application and Runtime patterns, showing how you can move from Business patterns to Application patterns to Runtime patterns.
  
  During discussions with the business stakeholders, the initial team identifies high-level goals of the business and makes a determination that no specific Business or Integration pattern will address all the business drivers. At this point a Composite pattern makes sense. Especially when information-aggregation and other requirements are fulfilled by a portal, the Portal composite pattern is a good starting point. Refer to Applying Pattern Approaches ^[13] for more details on how to use the Patterns for e-business in a sales role.
2. A project manager will need an understanding of those patterns that have already been chosen so that a set of tasks can be derived. Priorities can be set because once the Business and Integration patterns have been chosen, the business and IT drivers are understood.
3. The architect is the bridge between the business and technology domains. Once the business drivers are understood from the discussions with the sales role and business stakeholders, the architect can decide on likely IT drivers—namely, those goals upon which IT must focus in order to fulfill the business drivers. Combined discussions with both the business and IT stakeholders are important so that all can participate in the process of determining the final set of Business and Integration patterns, then decide on the Application patterns, and finally decide on the set of Runtime patterns. Once this is complete, the architect can derive an initial architecture ^[14] for the implemented portal solution. Once design begins, it is the role of the architect to understand the "big picture" of the system and to make sure the proper components are given priority so that those business drivers that are most important are given top priority. A Composite pattern such as the Portal composite pattern saves the architect time by performing some initial "integration" work, bringing together various characteristics that are important to a typical portal implementation. Anything that speeds up the process (such as the Patterns for e-business assets) saves time and increases the chances for a successful implementation.
4. Although developers are generally tasked with very specific programming-level tasks, it's important for those in this role to understand the general thinking behind how the architecture was originally designed. This allows the team to leverage the focused technical knowledge of a developer (for example, an expert Java programmer) to understand how its tasks fit into the system and to alert it as to how its work might impact other components being designed. This role works to augment the architect role. The developer also uses the Application design and development guidelines provided by the Patterns for e-business to assist and speed up the application development cycle. These patterns are used to bring together the business and technical people in an organization. The intersection point of these two groups is the set of Runtime patterns that are detailed enough for developers and abstract enough for business people (because these Runtime patterns are far less complex than a portal or systems architecture diagram).
The Portal composite pattern is valuable because it performs some of the initial "integration thoughts" that lead to a typical portal implementation. Of course, the standard caution that "your mileage may vary" applies to the use of this Composite pattern, because each implementation will introduce some variation or implement a custom design. Using just one or two Business and/or Integration patterns might not address all the needs of both the business and IT drivers of the equation. The creation of the Portal composite pattern has brought together a combination of patterns that can jumpstart the design and analysis process. You can realize savings in time, people, and money by leveraging reusable assets such as the Patterns for e-business.
What is IBM's patterns for e-business?

The job of an IT architect is to evaluate business problems and design a solution based on the requirements and input of the customer.

The Patterns for e-business capture the experiences of IT architects by storing the knowledge gained in a repository of Patterns information publicly available on the Internet at http://www.ibm.com/developerworks/patterns.

The knowledge is further researched and tested to develop Business and lower-level patterns to save time and money on future customer engagements.

These approaches are further refined into useful, tangible guidelines. The patterns and their associated guidelines allow the architect to
1. Start with a problem and a vision
2. Find a conceptual pattern that fits this vision
3. Define the necessary functional pieces that the application will need to succeed
4. Build the application using coding techniques outlined in the guidelines
At the highest level, Business patterns define the possible business interactions required for a solution. The business function will typically fall into one or more of these defined Business patterns. A Business pattern describes the relationship between the users, the business organization or applications, and the data to be accessed.

Definition:
Patterns for e-business are a group of reusable assets that can help speed the process of developing Web-based applications.
What assets are associated with IBM's patterns for e-business?

The reusable assets represented by the Patterns for e-business are broken down into the following elements:
1. Business patterns— Used to identify the interaction between users, businesses, and data. Business patterns are used to create simple, end-to-end e-business applications.
2. Integration patterns— Connect other Business patterns to create applications with advanced functionality. Integration patterns are used to combine Business patterns in advanced e-business applications.
3. Composite patterns— Combinations of Business patterns and Integration patterns that have themselves become commonly used types of e-business applications. Composite patterns are advanced e-business applications.
4. Application patterns— Define the high level application components and flow for refining the Business pattern.
5. Runtime patterns— Used to define the logical middleware nodes used to implement the Application pattern.
6. Product mappings— Define the actual products used to implement Runtime patterns on target platforms.

What are Business patterns?

Business patterns highlight the most commonly observed interactions between users, businesses, and data. They are the fundamental building blocks of most e-business solutions and describe the interaction between the participants in an e-business solution.

Definition:

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

The four Business patterns documented are:

Self-Service business pattern—Also known as the User-to-Business or U2B pattern, this pattern captures the essence of direct interactions between interested parties and a business. These include customers, business partners, stakeholders, employees, and all other individuals with whom the business intends to interact. For simplicity, these interested parties are referred to as users. In this definition, business represents various types of organizations, including large enterprises, small and medium businesses, and government agencies.
Collaboration business pattern—Also known as the User-to-User or U2U pattern, this pattern enables interaction and collaboration between users. It can be observed in solutions that support small or extended teams that need to work together in order to achieve a common goal.
Information Aggregation business pattern—Also known as the User-to-Data or U2D pattern, this pattern can be observed in e-business solutions that allow users to access and manipulate data aggregated from multiple sources. This Business pattern captures the process of taking large volumes of data, text, images, video, etc., and using tools to extract useful information from them. These tools can personalize data to suit user preferences, distill summary information from large volumes of data, use algorithms to identify trends hidden in the data, or answer users' hypothetical "what-if" questions about potential business scenarios.

Extended Enterprise business pattern—Also known as the Business-to-Business or B2B pattern, this pattern addresses the interactions and collaborations between business processes in separate enterprises. It can be observed in solutions that implement programmatic interfaces to connect inter-enterprise applications. In other words, it does not cover applications that are directly invoked through a user interface by business partners across organizational boundaries. It would be very convenient if all problems fit nicely into these four slots, but in reality things are often more complicated. The patterns assume that when broken down into their most basic components, most problems 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.

Table 1-1: The four documented Business patterns
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.

What are integration patterns?

Complex e-business applications can be built by combining multiple Business patterns together. This is accomplished by using Integration patterns as the "glue" between Business patterns. Integration patterns differ from Business patterns in that they do not themselves automate specific business problems. Rather, they are used within Business patterns to support more advanced functions or to make Composite patterns usable by allowing the integration of two or more Business patterns.

Definition:

Integration patterns allow us to tie together multiple Business patterns to solve a business problem.

The two documented Integration patterns that tie multiple Business patterns together are:

Access Integration pattern—This pattern provides for front-end integration of multiple services and information through a common portal. It is responsible for handling multiple client device types, single sign-on, personalization, and providing a common look and feel for the application interfaces.

Application Integration pattern—This pattern provides for the seamless back-end integration of multiple applications and data without the user having to access them directly.

Table 1-2: The two documented Integration patterns
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.

What are custom designs?

Business and Integration patterns can be combined to implement installation-specific business solutions. A custom design can 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-6 on page 36 can also describe a Sell-Side Hub composite pattern.

Figure 1-6: Iconic view of a custom design

What are composite patterns?

Composite patterns combine Business and Integration patterns to create complex, advanced e-business applications. There are numerous potential combinations of Business and Integration patterns, but a solution design composed of these multiple building blocks is only considered a Composite pattern when it is recurrently employed to solve the problems of businesses across a wide range of industries.

Visually, the patterns shown in Figure 1-7 can represent either a custom design in a particular installation or a common Composite pattern.

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

Note

Recurring custom designs can become a composite pattern. 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.

Table 1-3: Composite patterns
Composite Patterns	Description	Examples
Electronic Commerce	User-to-Online-Buying	www.macys.com www.amazon.com
Portal	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 (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.

What are Application patterns?

Application patterns break the application down into the most basic conceptual components, identifying its goal.
What are 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 may co-exist on the same machine.
What are product mappings?

The last step in defining the network structure for the application is to correlate real products with one or more runtime nodes.
What are the steps for using IBM's Patterns for e-business?
1. Selecting the Business pattern. When faced with the challenge of designing a solution for a business problem, the first step is to take a high-level view of the goals you are trying to achieve. A proposed business scenario should be described and each element matched to an appropriate Business pattern. You may find that the total solution will require one or more Business patterns.
2. Selecting the Application pattern. Application patterns break the application down into the most basic conceptual components, identifying the goal of the application. They do not show middleware, files, or the databases where Web pages might be stored.
3. Selecting the Runtime pattern. The Application pattern must be underpinned by middleware functions. Each function is associated with a runtime node. In reality, these functions or nodes can exist on separate physical machines or co-exist on the same machine. In the Runtime pattern, this is irrelevant. The focus is on the logical nodes required and their placement in the overall network structure. For example, let's assume that our customer has determined that its business requirements fit one of the defined e-Marketplace composite patterns and that it's also selected the required Application patterns most descriptive of the scenario. The next step is to determine the appropriate Runtime pattern for the Application pattern.
4. Selecting the product mapping. The last step in defining the network structure for the application is to instantiate real product names and versions with one or more Runtime pattern nodes. The product mappings are oriented toward a particular platform, though it is more likely that the customer will have a variety of platforms involved in the network. In this case, it is simply a matter of mixing and matching.

^[12]For example, IBM Global Services

^[13]SG24-6805-00

^[14]In other words, operational architecture and general architecture overview

< Day Day Up >