In the first two articles in this series we introduced a semantic framework and applied techniques from the IBM Patterns for e-business to come up with a method of analyzing why and where Web services may play a role in e-business applications (see Resources) . Our approach has been to look at various business problems posed by real IBM customers to explore solutions using the semantic and organizational framework of the IBM Patterns for e-business. In this installment, our focus will be on a customer in the global financial services industry whose desire is to develop a framework built on Web services infrastructure that will enable delivery of internal business processes to both the bank’s customers and third-party business partners. The pilot projects herein focus on leveraging this framework and serve as a reference implementation that demonstrates smooth integration between partner business applications, while minimizing direct user involvement through disparate application interfaces in multiple systems.
A key challenge for many developers and application architects who are seeking to apply Web services is that there is currently very little direction about how to best apply new technologies such as SOAP, WSDL, and WS-Security within real business scenarios. The objective of this article 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, we should mention that one of our goals for this series is to use actual customer scenarios from IBM Emerging Technologies jStart and IBM Global Services team projects. The analysis given here and in subsequent installments will be based directly upon those scenarios. However, in order to protect the confidentiality and integrity of the relationship of IBM 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 will derive are based on the reality of trying to get things done, rather than on theory or what we think should be done.
Country-Wide Chartered Bank (CWC Bank) is a global banking organization serving in both the retail and wholesale banking industry, offering financial products to end-consumers in savings, deposit and portfolio accounts, investments management and retirement savings plans, credit card, and consumer loans either directly or through a network of business partner affiliates and has been utilizing a mixture of traditional information technology and manual processes to accomplish these tasks. Propelled by strong business and IT drivers to build a new, standards-based information delivery and application-integration platform for use by both internal and consumer facing information systems, CWC Bank decided it was time to begin exploring the application of emerging Web services technologies. The enterprise-scale infrastructure they needed to build had some very strong requirements that were critical to the bank’s business needs and were driven by the various lines of business.
The current set of CWC Bank’s applications are built across traditional platforms spanning mainframe-based CICS applications, MQ Series-based middleware, a heterogeneous RDBMS environment mixing Oracle and Informix databases, and a broad client/server and Web applications portfolio. As reflected by the disparate and heterogeneous set of platforms and application development environments, developmental and operational inefficiencies have been driving up the costs of maintaining and extending their existing environment. The IT division of CWC Bank was challenged with the task of providing a more flexible and much more efficient approach through the application of standards-based technologies and platforms enjoying widespread industry and vendor adoption, a high degree of platform independence, and a model that provides an easier implementation of business-to-business interactions. In addition, this infrastructure must also be designed as an evaluation center for third-party products that CWC Bank may choose to implement in the future.
To answer this challenge, CWC's IT division decided to rollout two individual pilot projects, one known as the Custom Promotions Program (CPP) targeted at allowing customers to look up redeemable promotion balances, eligible promotional deals based on the customer’s portfolio, managing customer redemption preferences and transaction tracking; and the other application providing their business partners access to application functions they could turn around and provide as a part of their information delivery systems to their end-consumers and business processes.
The CPP application was implemented using an Internet browser-based interface combined with a smart card reader, leveraging CWC Bank’s standardized authentication and authorization functionality provided by the organizations Security Services division. Customers of the bank could access the application either through the CWC Portal or through third-party partner Web sites managed by CWC's business partners. Those third-party applications leveraged the second half of CWC's pilot project to directly integrate with CWC's CPP application to provide the end user complete access to the customized portfolio and redemption management functions while allowing the partner to extend and integrate those functions into their own business processes.
The overall set of requirements emphasized on the following:
- vendor support and platform independence
- seamless integration with the existing security services infrastructure
- extensibility towards an internal host-to-host integration platform within CWC Bank
- support for infrastructure-level security implementation without changing the existing CWC network
- infrastructure ability to scale both functionally and vertically to deliver to a wide variety of third-party business partners
- and provide a model for eliminating low-level programming activities for exposing future Web services
Other key objectives include the overall ability for CWC Bank to extend processes to customers as well as third-parties with greater speed and efficiency than what they were able to manage in the past using their highly diversified and non-integrated infrastructure.
Choosing the applicable e-business and application patterns
Now that we understand a bit about what was required, we can begin to analyze how the solution should be delivered. In Table 1 below, which you should recognize from previous installments of this column, we map business requirements to specific patterns for e-business. We have used this table to help determine the specific e-business pattern that would help us identify the fundamental components of the solution that we needed to build. In the table, we've highlighted the requirements that are most applicable to our scenario.
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 exists at partner organizations. | - | - | - | X | - | X |
| Business activity has a need 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 | - | - | - | - |
Composite e-business pattern: self-service + extended enterprise
In the process of applying the patterns layered asset model to the stated business objectives from CWC Bank, we realize that there is a mixture of patterns that apply to the stated requirements. In real-world scenarios, this is a very typical case that further translates into complex solution architectures. In this particular case, the short-term objectives matched the characteristics of a combined self-service and extended enterprise business pattern; self-service because the CWC portal is expected to deliver functionality directly to customers. Extended-enterprise because business partners are expected to programmatically integrate and extend with those functions. Alternatively, if the business partners were not expected to provide any additional business functionality and used the exposed CWC application functionality as-is, this would have been categorized only as a Self-Service pattern, with a variety of applied Access Integration patterns to support the implementation.
Beyond the immediate objectives of the CPP application, CWC Bank was also looking to leverage this Web services-based infrastructure for internal application and host-to-host integration. This involves the Information Aggregation pattern as an integral part of the overall solution when those components are built into the solution. This fact highlights key best practices for any application architecture, regardless of whether or not it is one built on Web services technologies: it is vital to remain cognizant of any architectural and/or design decisions necessary to cater to future needs and the laws of unintended use. Too frequently business applications are built as monolithic silos incapable of being adjusted or tweaked to fit new usage patterns or business objectives. In this scenario, however, we see a distinct and vital requirement that the solution be flexible and adaptable. Support for this objective must be designed into the system from the outset of the project.
Application pattern: Managed public processes
The overall solution, both for the end-consumers accessing the CWC Portal directly and for business partners extending those services through their own sites, was designed to offer both existing and new functionality as large-grained application services deployed within the CWC IT infrastructure. After a thorough analysis of the applicable application patterns, the Extended Enterprise Managed Public Processes pattern satisfies the given solution strategy and overall business objectives. The solution specifically exploits three major logical tiers: Partner, Public Process Rules, and Backend Applications.
In this pattern, partner applications interact with backend applications through an intermediary where a variety of processing rules are applied. In the CPP solution, these rules involve the application of filtering rules, security validation, and request routing functions as well as validation of the business protocols that would be agreed upon by business partners and CWC in the future. While the pilot project was focused on exposing application services to just a single partner organization, the infrastructure must be expandable to address all of CWC's current and future business partners for the long-term.
Furthermore, the backend applications are accessed by exposed Web services through an evolving open-standards based middleware technology, which was anticipated to provide a future generation of this Web services infrastructure. This middle-tier isolates the exposed business processes from the legacy applications and helps protect the bank’s information assets. This model also provides continuity in other business processes that are dependent on the backend applications while offering the flexibility the bank needs to explore additional channels of doing business. See also Figure 1.
Figure 1. Managed Public Processes application pattern
The key business and IT drivers that aided in the selection of the Managed Public Processes were:
- Improve the organizational efficiency.
- Reduce the latency of business events.
- Support a structured exchange with business partner.
- Support partner real-time access to/ from applications.
- Support partner real-time access to/ from business service.
- Leverage existing skills.
- Leverage legacy investment.
- Backend application integration.
- Minimize application complexity.
- Minimize enterprise complexity.
- Avoid partner-mandated infrastructure.
- Reduce partner dependency on specific application.
- Reduce partner dependency on specific business protocols.
Figure 2 illustrates the three logical tiers implemented in CWC's solution. If we took future requirements into account, we would see a more finely-grained segregation of the Processes Rules tier into Private and Public processes.
Figure 2. Basic architecture overview
The logical solution architecture
As previously described, the components of this solution have been distributed across a variety of public processes and backend applications to cater to the immediate needs of the pilot programs driven by short term business goals. In the model, there are opportunities to leverage at least some of the Web services technologies used in the public CWC-to-business partner and CWC-to-end-customer processes in the private middle-tier components deployed within CWC's own IT infrastructure.
Now, before we get too deep into the solution architecture, a small note regarding IBM products used in the design. We mention them only to illustrate how the solution was actually built. We shall provide advice on how to architect the overall solution allowing you to decide on the actual products that will help you put it all together.
Sitting between the public and private tiers of this solution is an IBM WebSphere Application Server running both the WebSphere Business Connection and WebSphere Web Services Gateway software acting as a gateway through which requests and data flow.
This design provides a central point of control for exposing business services through a proxy enabling message routing, load balancing, metering of requests and responses, logging, and security measures to be plugged into the process. This gateway component also provided a key deployment node for implementing custom filters with other systems management behavior in this layer, along with much of the operational support for Web services to be invoked before and after the invocation of the business services running in more traditional J2EE and CICS environments.
The Java components that represent the core implementation of the applications reside on a second tier of WebSphere Application Servers deployed within CWC's firewall and support platform-native interaction with back-end business application and system processes. Exposing the interfaces internally as Web services positions CWC for asset reuse making it easier to do new or different things with those services in the future. By leveraging and extending functions built into WebSphere and the Web Services Gateway, CWC enabled the support of digital signatures and encryption at the SOAP layer for message exchange making their solution transport independent. 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-directional support of Web service invocations is important to illustrate how the defined architecture allows the CWC to meet all of their stated requirements.
For future applications leveraging this Web services infrastructure, CWC intends to expose business processes that are built using non-Java technologies in custom applications, packaged solutions, and CICS-based host applications. When that time comes, this architecture will move closer to being a true implementation of the "Managed Public and Private Process" application pattern. The private processes will providing basic choreography of the various internal services, and would extend the current middle-tier integration point into a comprehensive enterprise application integration model. In its current incarnation, however, the middle-tier serves primarily as an abstraction of the custom application components exposed by the CICS-based applications, and is generally a point-to-point integration. Continued evolution of this hub will enable reuse and consistency of the implementation of these business process components across the enterprise thus fulfilling the primary objective of this new, strategic IT infrastructure. See also Figure 3.
Figure 3. The logical application architecture
The applicability of Web services
The general rule that we pointed out in the second article in this series said "Web service 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", we see that in the case of CWC Bank’s proposed architecture, both the public components of the solution and the interfaces exposed by internal applications all leveraged Web services technologies (see Resources).
Backend application services built primarily on proprietary technologies and native protocols, are exposed internally as Web services, proxied through a middle-tier gateway where additional Web service constructs are applied, then ultimately out to business partners and customers. Using the vernacular laid out in the first column in this series (see also Figures 4 and 5), we would categorize the Web services are exposed externally as XML Web services due to the use of WSDL, SOAP, and HTTP as the description, messaging, and transport protocols, respectively. This is done to allow the greatest level of interoperability between the external and internal processes. The boundary between the internal services and the gateway, however use a variety of protocols to communicate. These exposed Java components developed as EJB componets utilize MQSeries for asynchronous, assured delivery between the CICS client applications on the mainframe, but the other packaged applications in the backend platforms migrated to using SOAP/HTTP in some cases. Using our established terminology, these internal services would be considered Enterprise Web services.
Figure 4. Service-oriented application protocols
Figure 5. Domain of Web service protocols
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 broad 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 the Java platform and are not necessarily the best protocols to ensure interoperability, but they do form an excellent framework for integrating applications running within J2EE environments. With this consideration along with the need to continue providing assured message delivery the Integration Hub retained the MQSeries based communication to the CICS application on the mainframe.
This initiative involved the development of a very extensive enterprise-wide effort as well as being a very challenging emerging technologies initiative. The IT demands were strong enough to compel CWC into taking multiple leaps forward involving an IT infrastructure development and at the same time roll-off two business-ready pilot applications leveraging this platform. This allowed mitigation of multiple risk and new platform uncertainty elements, and at the same time showed the business immediate benefits and applicability of these technology directions. The key point to note here was that it is essential to have valid business drivers for undertaking such major initiatives to tie back to business value.
When building the infrastructure architecture and pilot implementations of this scenario, several other important lessons where learned about the technologies, standards and business concepts involved:
- Existing standards provide the mechanisms to support the types of asynchronous operations required by this scenario, but asynchronous operation is not yet an integral part of today's standards. The Business Process Execution Language for Web Services (BPEL4WS) is a step toward the required support, but much more work needs to be done.
- Industry tooling is essential to enabling the efficient reuse of existing applications (for example, automatically generating WSDL descriptions from Java Connector Architecture resource adapters).
- Interoperability is not yet a given at this point with Web services. There are still a broad number of open issues that we will address in a future installment of this series (focusing specifically on interoperability issues and some best practice suggestions on how to get around them).
- Participate in the discussion forum.
- Check out the entire Best Practices column series.
- Find more information on the IBM Patterns for e-business.
- Find more information on the Extended Enterprise business pattern.
- Find more information on the Managed Public Process.
- You can find more Patterns for e-business Redbooks 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 the IBM Patterns for e-business are also available, including a WebSphere Technical Exchange presentation (ZIP, PDF) discussing the relationship of Web services to the Patterns for e-business.
- You can also find an introduction to the IBM Web Services Gateway and begin experimenting with it by downloading the technology preview from alphaWorks.
- The Web Services Gateway is a featured component of the WebSphere Business Connection.
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.
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
- The business objectives
- Choosing the applicable e-business and application patterns
- Composite e-business pattern: self-service + extended enterprise
- Application pattern: Managed public processes
- The logical solution architecture
- The applicability of Web services
- Lessons learned
- Resources
- About the authors
- Comments
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
