In the first article in this series, we offered a refined vocabulary to bring structure and clarity to a previously muddled topic. We examined different types of service-oriented architectures that use a combination of open and proprietary technologies, and we created a vernacular to classify them into subtypes of Web services or describe them as Web service-like implementations. With this new vernacular in hand, IT architects and business process owners can more easily map their unique requirements to established best practice design techniques and patterns.
Before diving in too deeply, we want to quickly reiterate what we mean by a service-oriented architecture (or SOA for short), as we are not just talking about Web services. An SOA is a method of designing and building loosely coupled software solutions that expose business functions as programmatically accessible software services for use by other applications through published and discoverable interfaces. A business can use an SOA to compose and organize applications from a collection of distributed services; thus they can use it to construct new applications and alter existing ones by reusing their own assets as well as the business functions of their partners. Web services represent one implementation of a service-oriented architecture, but not all SOA applications can be considered Web services. Additional information on service-oriented architectures can be found by following the appropriate links in the Resources section below.
Many e-business applications address a common set of requirements, such as integration, interoperability, security, reliability, scalability, and availability. Not too surprisingly, a common set of infrastructure concepts can support a variety of specific solution requirements, minimizing architectural efforts and operational costs. To promote best practices based on real-world experiences, IBM developerWorks has documented a set of patterns for e-business to allow solution architects to discover the essence and commonly used elements of solutions that have proven to be successful. Each pattern is described in the context of the problem it addresses, along with considerations that need to be taken into account in applying it. The patterns for e-business are a set of reusable assets that can help expedite the process of developing Web-based applications, including those that leverage Web services.
In this article, we explore the IBM patterns for e-business, and see how they relate specifically to Web services. As this series of articles continues, we will use these patterns and the new vernacular we developed in the first installment of this series to guide us in our explorations of specific real-world business scenarios that have utilized Web service technologies.
A quick look at IBM patterns for e-business
The IBM patterns for e-business are a collection of best practice patterns developed from the collective experience of IBM architects. Developers can use these patterns to build solutions quickly and effectively, leveraging commonly used concepts that have often proven to successful in real customer scenarios. The patterns themselves are broken down into four distinct categories (you can find more information by following links in the Resources section below):
- Business patterns are high-level constructs that can be used to establish the primary business purpose of any solution.
- Integration patterns bring together individual business patterns in order to satisfy the overall requirements of a full e-business solution.
- Application patterns help refine business patterns so that they can be implemented as computer-based solutions. These patterns help provide structure to the business patterns by identifying and describing the high-level logical components that are needed to implement the key functions identified in each business pattern.
- Runtime patterns are used to define the logical middle-tier structure used to support application patterns. Runtime patterns represent the major middle-tier nodes, their roles, and the interfaces between them. They also address how the processing logic and the data are placed on these nodes.
Often you will hear application and runtime patterns described as design patterns, as they reflect the concrete physical design of the application being built.
When reading through the patterns for e-business literature, you will also come across the term composite pattern. A composite pattern combines multiple business and integration patterns to address a larger set of common requirements. Composite patterns can apply to applications with a variety of purposes, including e-commerce, portal, and account access programs. (See Resources for links to all three.)
It is important to note that existing business, integration, and application patterns are not directly affected by the emergence of specific technologies such as Web services. However, such technologies do have a major impact on how integration patterns are implemented through the application of runtime patterns. Additionally, given the evolutionary nature of business models and their associated requirements, it is entirely possible that, through the successful application of Web services, new patterns will continue to emerge over time.
As this series continues, we'll discuss business scenarios in which we will outline how specific e-business patterns were used, and how the implementations of various integration patterns were affected by the use of Web services technology.
You can find a link to additional details of the IBM patterns for e-business in the Resources section below.
Mapping solution requirements to e-business patterns
Before we can gain a solid understanding of how Web services fit into these established patterns, we need to get a handle on how we map business requirements to individual patterns. Only then can we best understand how to apply Web services in a given situation to achieve our business goals. To do so, we'll examine some business drivers that are fairly common among businesses looking at e-business solutions. Then, using the tools available on the IBM patterns for e-business Web site, we can match the requirements to the appropriate patterns. In Table 1, the business drivers are explained in the leftmost column, and matched to the various patterns listed in the top row. To learn more about each pattern, click on its name.
Table 1. Matching business requirements with appropriate patterns
| Business and IT Drivers | Business Patterns | Integration Patterns | ||||
| Self Service | Collaboration | Information Aggregation | Extended Enterprise | Access Integration | Application Integration | |
| End-users and customers need to directly interact with business processes and/or data. | YES | YES | YES | no | YES | no |
| A business process needs to be integrated with existing business systems and information. | YES | no | no | no | no | YES |
| Business processes need to be integrated with processes and information that exist at partner organizations. | no | no | no | YES | no | YES |
| A business activity needs to aggregate, organize, and present information from various sources within and outside the organization. | no | no | YES | no | YES | YES |
| A business process must be reachable in a common, consistent, and simplified manner through multiple delivery channels. | YES | no | no | no | YES | no |
| A business activity demands and fosters collaboration and the sharing of information among its participants. | no | YES | no | no | no | no |
Each of the various business and integration patterns listed along the top of Table 1 has its relative strengths and weaknesses when it comes to meeting the various business requirements discussed. It is important to point out, however, that many business solutions will contain elements that match many of these individual patterns, and that no single pattern will ever completely describe any single solution. The patterns are designed to help guide the design process, not to constrain it in any way.
In order to illustrate how this all applies to Web services, let's take a moment to see how an implementation of the Self-Service pattern can help an organization open its business processes up to its partners. The obvious solution is for the organization to publish its business processes as Web services. In such a context, Web service technologies are used extensively to simplify the access, aggregation, and presentation of information. With such technologies, we can integrate various back-end services to provide a seamless front-end that can be accessed from multiple channels.
Along the same lines, we can also examine how Web services technologies simplify application integration to help organizations reuse existing business processes. Because Web services provide well-defined and programmatically accessible descriptions of their interfaces and behavior, it is possible to integrate them directly into other applications while still allowing for a loosely coupled and heterogeneous environment.
Again, the goal here is to simply provide a basic overview of how the patterns for e-business may be used to guide the design of a service-oriented application starting from an initial collection of business requirements. This discussion is not intended to provide complete coverage of the e-business patterns. We would highly recommend that you spend some time reviewing the developerWorks patterns for e-business Web site (see Resources), walking through the various patterns, understanding the business drivers for each, and becoming familiar with the types of solutions that each pattern is designed to model. Doing so will help you to get a much better handle on the role of Web services within an application.
How Web services influence runtime patterns
As we noted, Web services have very little impact on the existing set of business, integration, and application patterns. They do, however, greatly affect the implementation of those patterns. To understand how and why, let's first review the key benefits that Web services technologies are designed to realize:
- Web services help to reduce complexity by encapsulating business processes into reusable components.
- Web services help to improve interoperability by acting as a wrapper around legacy or platform-specific applications.
- Web services can be composed together to perform higher-level business functions.
- Web services help to hide back-end implementation details through the use of standardized or well-known interface definitions.
- Web services enable just-in-time integration by promoting loose coupling and late binding.
- Web services are platform and implementation neutral, thus promoting true interoperability.
- Web services leverage existing established Internet standards.
When reviewing the various higher-level e-business patterns, it becomes clear that in order to determine how Web services fit into a particular solution or pattern, we need to analyze the implementation or runtime patterns, and figure out where in the pattern Web services can be used to improve upon the benefits that existing technologies currently provide.
For example, a common application pattern used to realize the Self-Service business pattern is called the Directly Integrated Single Channel, illustrated in Figure 1. In this pattern, external business partners interact with multiple back-end business processes through a single front-end application.
Figure 1. The Directly Integrated Single Channel application pattern
There are a number of different ways to implement this pattern. In one option, illustrated in Figure 2, an organization can put up an Internet Web site that provides a graphical user interface where business partners can log on and access the various back-end processes. While this is a valid solution, it presents a significant challenge for business partners who wish to more tightly integrate the target organization's exposed services into their own business processes. Browser-based Web interfaces are great for interacting with people, but are not so helpful when integration needs to occur on an application-to-application level.
Figure 2. A traditional Web design for the Directly Integrated Single Channel application pattern
Applying the basic tools we have already explored, we can see that a better way to enable programmatic integration between our organization and its partners would be for the organization to expose its front-end application as a Web service, utilizing a composite pattern that brings together both the Self-Service and Extended Enterprise business patterns. Partners would then be able to plug those services directly into their own processes. By leveraging Web services technologies, that direct integration is easier to maintain, easier to evolve, and less costly overall. At the same time, the organization can continue to expose a browser-based, human-readable interface to the same business processes while leveraging the same Web services-based infrastructure.
Figure 3. A Web services-based design for the Directly Integrated Single Channel application pattern
As a general rule, Web services will affect the implementation of business, integration, and application patterns whenever there is a boundary -- between businesses, between applications, between logical components of a solution, etc. -- across which information must be exchanged. Web services technologies are designed to add specific interoperability and flexibility benefits to those information exchange boundaries. The extent to which Web services technologies should be applied at those boundaries, however, depends entirely on the individual requirements of each solution, as we will see realized in the specific real-world scenarios that we'll explore in subsequent articles in this series.
The behaviors of Web service runtime patterns
A key point to keep in mind: while the various application and runtime patterns are agnostic to specific programming models, they will generally indicate a preference for either synchronous or asynchronous implementations, and for either RPC or document exchange style. Such decisions have a significant impact on how the business objectives may be realized.
Web services have always been designed to be applicable to at least two fundamental programming models: remote procedure calls (RPC) and document exchange. RPC implies a client/server model in which the client requests that a specific activity be performed by the server and the results of that activity be immediately returned to the client. Communication in the RPC model is most often synchronous, and requested operations generally represent fine-grained, individual work items (for example, checking on the status of an order). Document exchanges are typically asynchronous and involve moving business documents (a purchase order, for example) between peer partners. (For more information on the distinction between the two, see the Resources section below.)
Unfortunately, the distinction between document- and RPC-style Web services is becoming extremely blurred through poor usage and corruption of the terminology. What many Web services implementations currently call document-style Web services are actually RPC-style Web services that use one particular mechanism for defining and validating the content of the Web service messages exchanged. We will explore this issue in much greater detail in a future article.
The combined goal of this article and the one prior to it has been to lay a basic semantic and organizational foundation upon which we can begin to analyze real-world business applications within which Web services play a key role. The end result of that analysis will be a collection of general best practices for Web services architecture and design. In the articles to come, we will begin our exploration of those real-world applications, starting with an example of an e-business application requiring application integration in the financial services industry. We'll examine in close detail the specific requirements, patterns, design, and implementation decisions that were made -- and see how Web services technologies played a role.
Applied experience gained from an client in the consumer packaged goods industry has directly influenced this article. The contributors on that project were William A. Brown, Raghu Varadan, and Martin J. Burns. The authors also acknowledge the assistance of the IBM patterns for e-business lead architects for providing feedback for this series of articles.
- Participate in the discussion forum.
- Read the first article in the Best practices for Web services series for a refined definition of Web services.
- Check out all the Best practices for Web services columns.
- Visit the IBM patterns for e-business Web site for a wealth of information and details on the patterns reviewed here.
- At the IBM patterns for e-business Web site, you can find out more about the e-commerce,
portals, and
account access patterns discussed in this article, as well as the Extended Enterprise business pattern.
- To learn about service-oriented architecture, read "The Tao of e-business services," Steve Burbeck (developerWorks, October 2000).
- For more information about how the patterns for e-business work, read Patterns for e-business: A Strategy for Reuse, by Jonathan Adams, Srinivas Koushik, and Guru Vasudeva, George Galambos (IBM Press, 2001).
- For more information on the Directly Integrated Single Channel, read the IBM Redbook
"Patterns: Connecting Self-Service Applications to the Enterprise."
- Explore the plethora of Redbooks on patterns available from IBM.
- The IBM Patterns for e-business lead architects have reviewed the impact of Web services and have documented their findings (PDF).
- Other presentations, whitepapers and information on IBM's Patterns for e-business are available, including a WebSphere Technical Exchange presentation (ZIP, PDF) discussing the
relationship of Web services to the patterns for e-business.
- For more on document and RPC style, read "Reap the benefits of document style," James McCarthy (developerWorks, June 2002)
Holt Adams is currently a senior-level IT architect supporting IBM's jStart program, working with customers and business partners to adopt emerging technologies such as Web services. After graduating from the University of Tennessee in 1982 with an electrical engineering degree, he joined IBM in Research Triangle Park, N.C. His experience includes hardware and software development of communication and networking products, technical marketing of mobile and wireless solutions, and architecture and integration of Internet-based solutions. For the past two years he has been focused on promoting Web services as IBM's strategic integration technology, working with customers to initially develop proofs of concepts, but more recently in developing solutions for production environments. Holt can be reached at rhadams@us.ibm.com.
Dan Gisolfi is an engagement manager and solution architect for IBM's jStart emerging technologies team. He keeps his hands dirty in both the business and technical aspects of customer engagements. He gets to wear many hats, from business development manger and evangelist to solution architect and contract negotiator. Dan's current focus is to help IBM drive the adoption of Web services through real business solutions. You can contact Dan at gisolfi@us.ibm.com.
James Snell is an architect and strategist for the emerging Internet technologies team within IBM's software group, where he plays an active role in the evolving architecture and implementation of Web service technologies. He is a coauthor of the book Programming Web Services with SOAP, published by O'Reilly & Associates. James can be reached at jasnell@us.ibm.com.
Raghu Varadan is a Consulting IT Architect with The Architecture Center of Excellence from IBM Global Services. He has over 14 years of experience in software consulting, demonstrating the broad business application of technology, strategic technology planning, and systems architecture. He has extensive experience in developing large-scale, complex enterprise-wide architectures, OO and client-server architectures and development, and has been involved in both business and technical aspects of full life cycle of software development. Raghu can be reached at rvaradan@us.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
