![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In the first two articles in this series we introduced a semantic framework and applied techniques from the IBM Patterns for e-business to develop a method of analyzing why and where web services might play a role in e-business applications. Our approach has been to look at various business problems posed to us by real IBM customers and explore the solutions that have been developed to solve these problems using the semantic and organizational framework provided to us by the IBM Patterns for e-business. In this installment, we focus on a customer who is looking to incorporate web services technologies into their solutions to better enable integration of business applications with their partners. They also want to address their partner's requirement to minimize direct user involvement with application interfaces from multiple systems.
A key challenge for many developers and application architects seeking to apply web services is that very little direction about how to best apply new technologies such as SOAP, WSDL and WS-Security within real business scenarios currently exists. This article's objective is to take a real world business example and analyze it against the concepts laid out in our earlier articles; and in doing so, to derive some lessons as to how the promise of this new technology and the reality of using it to solve real problems come together. Specifically, we will analyze the example scenario against the following set of questions:
- What is the business objective of the solution?
- What is the general e-business pattern the solution implements?
- What is the logical architecture of the application?
- How, where, and why were web services technologies used in the building of the application?
- What specific benefit was realized from the use of web services in the application?
- What was learned (positively and negatively) about the technologies and methodologies used?
On a side note, it needs to be mentioned that one of our goals when putting this series of articles together has been to use actual customer scenarios in which the IBM Emerging Technologies jStart team and the IBM Global Services team have worked to implement web service or web service-like applications. The analysis given here and in subsequent installments is based directly upon those scenarios. However, in order to protect the confidentiality and integrity of IBM's relationship with the customer, fictitious names will be used. The key point to keep in mind here, however, is that these projects are real, not hypothetical exercises. The best practices we derive are based on the reality of trying to get things done, rather than on theory or what we think should be done.
PeoplesFuture Company (PFC) is an insurance and financial services company that offers property/life insurance, investment management and retirement savings plans. PFC has many lines of business that offer their services to strategic business partners who sell their financial and information products to corporations and consumers. The services are offered today to the partners through traditional channels such as call centers and Web sites that access to registered business partner participants. The exchange of information to and from the services is often confidential and is critical for the execution of the business processes between PFC and its partners.
Today, field sales agents and telemarketers access information from various sources on the Internet or through a PFC call center as part of their sales process. It's not uncommon for the agent to have multiple user accounts at separate Web sites requiring them to manage multiple user IDs and passwords, not to mention having to navigate through the sites to retrieve information pertinent for working with their clients. The business partners who employ the sales agents want to retrieve the information on their behalf from the distributed applications/sites with the goal of optimizing their sales processes and managing how the information is viewed and utilized by the agents.
PFC wants to improve their operational efficiencies with their business partners by integrating their applications and reducing integration costs while also increasing the use of their existing internal assets. Likewise, PFC wants to enhance their business partner relationships. Their goals are to enable their partners to communicate better with their back-end systems and to provide the interfaces and controls that allow their partners to totally manage their employee's experience in presenting and using the information retrieved from PFC. By meeting these objectives, PFC is looking to lower their overall costs by reducing call center resources and reusing existing assets to offer new services.
One business objective that overlays those itemized above which PFC views as being crucial to their overall success in migrating their business partners to a service oriented architecture is that the integration solution must minimize the effort, complexity, and cost required by partners to take advantage of the new capabilities that PFC offers.
The technical requirements that PFC outlined to address their business objectives include the use of open standards technologies that better enable interoperability and ensuring the broadest set of technology vendor alternatives for their partners. Their primary technical concerns were that the integration solution needed to be platform independent (operating system and programming language), enable centralized monitoring and control, allow for network transport independent exchange of information, allow for network transport independent enforcement of security policies, enable existing authentication and authorization systems to be leveraged, and use readily available industry tooling for the implementation and deployment of solution components. To meet these objectives and requirements, PFC chose web services, allowing them to address all of their needs.
Looking to the future, PFC also placed requirements on the solution's infrastructure to support outbound web services requests so that when new business requirements for PFC's business applications to initiate interactions with other business partner applications are identified in the future, they will have the foundation to build upon.
The applicable Patterns for e-business: Exposed Business Services and Aggregator
From the stated business objectives and technical requirements, we have been able to manage the overall needs of the solution to expose existing business functions securely to registered participants through a centralized point of control where we can achieve management and monitoring of processes and functions.
In Table 1 below, which you should recognize from our previous articles, we've mapped business requirements to specific Patterns for e-business. We can use this table to help determine the specific e-business pattern that will help us to identify the fundamental components of the solution that we need to build for PFC. In the table, we've highlighted the requirements that are applicable to the current scenario with the most applicable shown in blue. Even though we'll not be discussing the architecture and design of the business partner's solution, the pattern highlighted in pink indicates those requirements that the business partner must address.
Table 1. Selecting an e-business pattern
| Business and IT drivers | Business patterns | Integration patterns | ||||
| Self Service | Collaboration | Information Aggregation | Extended Enterprise | Access Integration | Application Integration | |
| The end users and customers need to directly interact with business processes and/or data. | X | X | X | Â | X | Â |
| The business process needs to be integrated with existing business systems and information. | X | Â | Â | Â | Â | X |
| The business processes need to be integrated with processes and information that exist at partner organizations. | Â | Â | Â | X | Â | X |
| Business activity needs to aggregate, organize, and present information from various sources within and outside the organization. | Â | Â | X | Â | X | X |
| The business process must be reachable in a common, consistent, and simplified manner through multiple delivery channels. | X | Â | Â | Â | X | Â |
| The business activity demands and fosters collaboration and the sharing of information among its participants. | Â | X | Â | Â | Â | Â |
This table presents a few different options for PFC. However, based on the key business driver, the Extended Enterprise business pattern is the obvious choice for PFC, as the primary scenario involves interactions between partners from a public process. The Extended Enterprise business pattern (also known as the Business-to-Business or B2B pattern) addresses the interactions and collaborations between business processes in separate enterprises. This pattern is often used in solutions that implement programmatic interfaces to connect inter-enterprise applications. The popular example of this Business pattern, which maps directly to PFC's scenario, is as follows: Partner B invokes a public process that in turn invokes a specific private internal process flow within Partner A (or PFC). Partner B is not concerned with the details of how Partner A does its processing from within. Partner B is only interested in the results it expects in response to the invoked public process. See also Figure 1.
Figure 1. Public vs. private process flows
Considering the nature of PFC's scenario where requests from partners are independent from one another (not needing to be correlated) and involve the processing of multiple PFC applications or the retrieval of information from multiple PFC datastores, the Exposed Business Services is an excellent application pattern that addresses their current requirements. This pattern is shown in Figure 2.
Figure 2. Exposed Business Services pattern
PFC wants to position itself not only to support B2B with web services open standards, but also to support Enterprise Application Integration (EAI) of its back-end systems with those of its various internal applications and partners. The Application Integration pattern is also applicable as it serves to either integrate multiple Business patterns or to integrate applications and data within an individual Business pattern (the latter in our case). The requirements that give rise to this pattern call for the reuse of PFC's existing assets, and for the solution to leverage existing authentication and authorization system applications. Since PFC's main objective is to support public processes that the business partners initiate, it is necessary to internally integrate existing security systems to support the public processes. In reviewing the application patterns for Application Integration, the Aggregator pattern (shown in Figure 3) is the best choice as PFC had to disperse multiple internal requests to both business and infrastructure applications when processing an external request.
Figure 3. Aggregator pattern
The key feature of this Application pattern is message routing and transformation processing with de-composition / re-composition. For a one-to-many integration flow, the initiator's (or Partner B's) request must be decomposed into multiple requests to target applications (with associated message transformation) and then, upon receiving responses, must be aggregated back into a single response to the initiator. For PFC, a business service request from one of their partners results in multiple infrastructure applications being invoked (user identify mapping, authentication/authorization) prior to the business application functions that make up the Process entity, as illustrated above. In combining the Exposed Business Services and Aggregator application patterns, the entities labeled Process on the right side of the above diagram would include 1) the Exposed Business Services Tier that front-ends the business applications and 2) the common system applications that are being aggregated in response to the business partner's requests. Even though the infrastructure applications do not provide direct input used in building the response, their services are needed for authorization and in building the request that is sent to the business processes, thus this application pattern can be applied. Figure 4 shows the basic run-time architecture for the Exposed Business Services and Aggregator patterns.
Figure 4. Basic run-time architecture for the Exposed Business Services and Aggregator patterns
The logical solution architecture
Now that we have established the fundamental business objectives, selected specific application patterns, and have a general idea of what the end solution will look like, we can start to evaluate the architecture of the solution. In the solution architecture, the Message / Integration Broker entity is implemented using the J2EE programming model and connector architecture together with the emerging set of web services standards. The approach we used with regards to the web services infrastructure was to maximize the use of middleware components that exploit web services technologies, to leverage the capabilities of existing system components, and to take advantage of integration points for integrating existing software assets. Likewise the interfaces for both the Business Applications and System Applications are exposed internally as XML web services on J2EE platforms so that PFC can leverage them now and in the future on other Enterprise Application Integration projects. Figure 5 shows the logical application architecture.
Figure 5. The logical application architecture
The public component of the solution that supports the public process consists of WebSphere Business Connection (includes WebSphere Application Server V4 and Web Services Gateway) and provides a centralized point of control for exposing the business services that acts as a service proxy enabling message routing, monitoring, logging, control of both inbound and outbound requests, and overall systems management of the web services solution. The Web Services Gateway component of WBC provides much of the operational support for web services, enabling filters to be invoked before and after the invocation of the business services. For PFC, infrastructure services are invoked prior to the business service to map asserted user identities to local identities, which are then used to retrieve user privileges for use in the authorization of the services.
The Java components that represent the web service interfaces of the applications reside on the 2nd tier of WebSphere Application Servers and support the native interface to the back-end business applications and the system applications. Exposing the interfaces as web services internally, inside the firewall, positions PFC for asset reuse. By leveraging and extending functions built into WebSphere Studio and the Web Services Gateway, PFC enabled the support of digital signatures and encryption at the SOAP layer for message exchange making their solution transport independent. They also implemented a federated identity model to pass user assertions and security context tokens to support single sign-on between the business partners and their applications.
In addition to allowing functions of internal applications to be exposed externally as web services, the Web Services Gateway allows internal applications to access web services provided by external partners while still leveraging the common set of infrastructure services. Highlighting this bi-direction support of web service invocations is important to illustrate how the defined architecture allows PFC to meet all of their stated requirements.
The applicability of web services
In article 2, we introduced a general rule that said "Web services will impact 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." In the case of PFC's scenario, both the public component of the solution and the interfaces of the internal business applications were based on web services technologies.
Specifically, the solution takes internal application components, which have proprietary interfaces, and exposes them both externally and internally as web services. Using the vernacular laid out in article 1 (see Figures 6 and 7), we would categorize the web services that are exposed as XML web services due to the use of WSDL, SOAP, and HTTP as the description, messaging, and transport protocols, respectively. We do this to allow the greatest level of interoperability between the external and internal processes.
Figure 6. Service-oriented application protocols
Figure 7. Domain of web service protocols
Even though PFC uses Java components to front-end their legacy systems, they have chosen during their initial phase to use SOAP over HTTPS to ensure interoperability with other internal applications for Enterprise Application Integration. However, since the Java components are EJBs, they could also create the WSDL for the J2EE APIs, enabling the Web Services Gateway to utilize their Native RMI interface. Over time, PFC will perform evaluations and based on the optimal performance, PFC might also expose the business applications as Enterprise Web Services to enable the Web Service Gateway and other J2EE-based applications to leverage the potential benefits of the web service implementation's native protocols (for example, RMI for synchronous operations and JMS for asynchronous operations).
XML Web Services are primarily implemented to ensure interoperability across heterogeneous runtime and development environments (Microsoft .NET and J2EE for instance). Enterprise Web Services, on the other hand, are implemented to take advantage of loosely coupled integration points between applications. SOAP and HTTP are widely accepted and interoperable messaging and transport protocols that are supported in a variety of environments; they are also standardized or are in the process of being standardized. This makes their use for interoperability purposes ideal. JMS and RMI are not supported on platforms other than Java platforms and are not necessarily the best protocols to ensure interoperability, but they do form an excellent framework for integrating applications running within J2EE environments. Because both the public and private components in the Message / Integration Broker are based on J2EE technologies, use of JMS and RMI is highly appropriate and could prove to be much more efficient than SOAP and HTTP.
When building the solution architecture and initial implementation of this scenario, we learned several important lessons about the technologies, standards, and business concepts involved:
- Industry tooling is essential for enabling the efficient reuse of existing applications (for example, automatically generating WSDL descriptions from Java components).
- Leveraging existing infrastructure applications and services requires detailed analysis in order to:
- Identify specific functionality to be utilized
- Determine and optimize interfaces to be exposed
- Identify where best to the integrate the capability to ensure loose coupling, which maximizes overall solution flexibility.
- Trying to leverage a common infrastructure component or a current industry standard that successfully supports browser based interaction with HTTP isn't always possible or a good idea for B2B where transport independence is a requirement (for example, SAML - Security Assertion Markup Language with existing binding definitions).
- Moving from prototype to production requires an honest assessment of the operational staff's skills and will probably require education and training on web services (for example, deployment, configuration, monitoring).
- Interoperability of WS-Security is not a given at this time, but independent studies have successfully demonstrated interoperability between Microsoft and IBM (see Resources section for a report).
In summary, PFC's web services initiatives have lead them though an aggressive learning process enabling them to provide access to their back-end systems to strategic business partners, giving them the ability to enable their agents to better sell and service PFC's financial and information products. Moving from the concepts of a Federated Identity model that enables single sign-on for B2B integration to integrating proprietary authentication and authorization systems further emphasized for PFC the value of the web services technology in bringing together and ensuring interoperability between disparate programming environments.
- Participate in the discussion forum.
- For more information on patterns, visit the IBM Patterns for e-business Web site.
- Also visit Patterns for e-business for more information on the Extended Enterprise business pattern and the Application Integration business pattern.
- Find more Patterns for e-business Redbooks from IBM.
- The IBM Patterns for e-business lead architects have reviewed the impact of web services. Check out their documented findings (PDF).
- Read our previous installments, starting with "Part 1, Back to the basics" (developerWorks, October 2002).
- Other presentations, whitepapers, and information on IBM Patterns for e-business are available in the Patterns for e-business resources, including a WebSphere Studio Technical Exchange presentation (ZIP, PDF) discussing the relationship of web services to the Patterns for e-business.
- Read "An introduction to Web Services Gateway" (developerWorks, May 2002) and begin experimenting with the Web Services Gateway by downloading the technology preview from alphaWorks.
- The Web Services Gateway is a featured component of the WebSphere Business Connection.
- Visit the CBDI Web site for a report on a WS-Security interoperability demonstration.
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 concept, 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.
