2004 ACM Symposium on Applied Computing
Migration to Web Services Oriented Architecture - A Case Study Jia Zhang
Jen-Yao Chung
IBM T.J. Watson Research
Carl K. Chang
Department of Computer Science Northern Illinois University DeKalb, IL 60115 01-312-718-2468
Yorktown Heights, NY 10598 01-914-945-3422
Department of Computer Science Iowa State University Ames, IA 50011 01-515-294-4377
[email protected]
[email protected]
[email protected]
ABSTRACT
development.
The rapid emerging of web-services technology is dramatically changing the scenario of web application design and development. This paper presents a web-services oriented architecture. As a case study, the paper reports on an on-going project on the design and development of a pass-through authentication web-services for on-line electronic payment applications. This is a first step towards an electronic payment web-service.
Categories and Subject Descriptors
D.2.11 [Software Engineering]: Software Architecture – Domain-specific architectures
General Terms
Design, Experimentation
Keywords
Web application development, software architecture, web services oriented architecture, case study
1. INTRODUCTION
Web engineering is a research area aiming to provide systematic, disciplined, and quantifiable approaches to assist the design, development, and maintenance of web applications [1]. The emerging concept of web-services is gaining considerable academic and industrial momentum in the recent months. Being a programmable web application accessible through standard Internet protocols [6], a web-service is normally self-contained with well-defined interface, and no deployment is compulsory. This rapid emerging paradigm opens a new way of web engineering to quickly develop and deploy web applications by integrating other independently published web-based software components to conduct new business transactions. As a result, software organizations are going through a transformation of their engineering models, aiming at achieving faster and cheaper web Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC ’04, March 14-17, 2004, Nicosia, Cyprus. Copyright 2004 ACM 1-58113-812-1/03/04…$5.00.
In web application development there are two essential issues incorporating with web-services: how to develop an application utilizing web-services as components, and how to build an application that exposes part or all of the functionalities as webservices. This paper describes the process of creating an architectural model as a solution to these two issues. As a case study, we report on an on-going project aiming at constructing a pass-through authentication (PTA) web-services to support online payment (e-Payment) applications: a first step towards an electronic payment web-service. Such a PTA service is at the moment acting as a web-service to our multiple e-Payment deployments with two functionalities: allows client administrator to register authentication criteria, and functions as a web-service front-end to our e-Payment back-end servers. Our previous research has suggested the use of an advanced architecture-based web-services oriented architecture and development process, which aims at providing a framework to construct web applications that exposes some functionality as web-services [11]. Here we extend the architectural model to include applications that encompasses web-services as components. This case study intends to examine how our web-services oriented architecture was formed through this project, and how it has benefited the web application development, in the aspects of reusability, fast development, and flexibility. The rest of the paper is organized as follows. In Section 2 we analyze the project domain and form the project requirements. In Section 3 we closely examine the case study. In Section 4 we discuss the results from the case study. In Section 5 we make a conclusion and discuss the future work.
2. CASE STUDY CONTEXT
We first introduce the context in which the case study was performed. Electronic payment (e-Payment) system is an on-line synchronous/asynchronous payment processing application, that is, it can perform real-time or batched payment transactions. The application handles credit card payment, e-check payment, A/R (account receivable) updates, payment processing and reconciliation, bill presentment and payment history presentation, etc. Originally, e-Payment system was designed as a stand-alone web application, which was customized and deployed at different organizations. The overall design and distribution of e-Payment application over organizations are illustrated in Figure 1. Two deployment options are provided to organizations. The first one is called an enterprise style, which means that an e-Payment system will be deployed at one server that is hosted at the organization
1624
needs to have a means to verify whether the transaction is originated at the site of the specific trusted organization.
2.1 Pass-through Authentication
As a result, we recognized the necessity of pass-through authentication. Pass-through authentication is a widely utilized concept in network computing, which enables users to logon to the network and access resources from computers or domains where they have no accounts. In this project we refer pass-through authentication (PTA) to a transitive trust authentication process that allows users to be seamlessly authenticated into the ePayment system from another trusted secure website, without visiting an e-Payment login page (i.e. to obtain the authorization to access). PTA process can convey either already authenticated user or detailed payment information to e-Payment system. Due to the fact that our e-Payment system is usually integrated into the organizations’ web sites as dedicated on-line payment processing engine, the pass-through authentication offers significant advantages to the e-Payment application, as PTA facilitates ePayment application to shift to an ASP model, where a central ePayment server will handle on-line payment from different organizations Figure 1. Original e-Payment system deployment site, as shown in Figure 1 for organization #2. The organization needs to maintain the server after deployment. The second option is a so-called ASP (Application Service Provider) style, that is, an e-Payment system for an organization is hosted at a central server place, as shown in Figure 1 for organization #1, #3, and #4. These e-Payment systems may reside on the same or different physical server machine; while different e-Payment servers are isolated applications within different processes. According to our experience, most of the organizations adopt the second option, as they benefit from no resource assumption on maintenance and future easier upgrade of e-Payment system. In either option, users of each organization are required to access the login page of the corresponding deployed e-Payment system before utilizing the application. Normally, an organization embeds a link in its own web site to point to its e-Payment server site. As we deploy the e-Payment application at more and more organizations, this design reveals several integration issues. First, a user must have different set of login id and password to access the e-Payment application and the original web site of the organization respectively. Therefore, organizations have to transfer batch files to the e-Payment system with sensitive information such as user names and passwords, which exposes a potential security problem. This issue becomes more severe when an organization adopts the ASP model, as the sensitive information needs to be conveyed through the public Internet to the central server place. Second, this design enforces users to go through the web pages of e-Payment systems in order to utilize any functionality of the application, which may not be so desired sometimes. For example, an organization may wish to utilize an ePayment system to process a transaction without walking through any web pages. That is, it is expected that the information of the transaction is conveyed to the e-Payment system over the Internet through an HTTP (Hypertext Transfer Protocol) request, and the result code is passed back through an HTTP response. This scenario requests that our e-Payment system expose some functionality for direct access. However, our e-Payment system
The pass-through authentication is realized by a process that ePayment system evaluates an HTTPS request sent by an organization. The detailed process can be found in other textbooks. There are two categories of data transferred by the HTTPS request string: data information and validation information. Data information contains a list of name/value pairs. Validation information contains two pieces of data: hash and timestamp. Hash is the value generated by some popular Internet digital signature algorithms, such as MD5 [4] and SHA1 [7], over the other parameter values contained in the HTTPS request and an agreed upon secret key string. Timestamp is the value generated by the sender when the HTTPS request is formed and sent, which is the epoch time that indicates the difference [2]. Followed is an example of HTTPS request string. The first part is the e-Payment server URL that accepts the request. There are two parameters defined in the request string: user id and payment method. Timestamp value and hash value are followed. https://epayment.com/institution/payer.do?userId=999999&p aymentMethod=ach×tamp=949924800&hash=b14ac94d296 0e53dbb2f061b236d7a0a Each request is validated on four criteria: request string, parameter name-value pairs, hash, and timestamp. The HTTPS request must be sent to the correct e-Payment URL and contain the required parameter name/value pairs. Each parameter value must follow its validation rules predefined. The value of the timestamp parameter will be compared with a timestamp generated by the e-Payment server when the HTTPS request is received. The request will not be authenticated if the absolute value of the difference of the two timestamps is greater than a predefined threshold. The hash value is compared with a hash generated by the e-Payment server using all the other parameter values conveyed by the HTTPS request and an agreed upon secret key string. The order of the parameter values on which to perform the hash algorithm is imperative and is predefined. The secret key is a non-transferred string pre-agreed-upon by e-Payment and the organization. The request will not be authenticated if the two values differ.
1625
2.2 Pass-through Authentication Service
easily reused for different e-Payment applications.
As more and more organizations request pass-through authentication function, including the organizations where ePayment was already deployed, we decided to start a project that aims to construct pass-through authentication (PTA) services. The goal of this project has two folds: one is to integrate a PTA service into each deployed legacy e-Payment applications; the other is to design a PTA service in order for it to become a synergistic integrated part of future e-Payment applications. The empirical study reported in this paper is a case study, which was designed at the beginning of the project. This case study intends to investigate how to transform from an application-oriented architecture towards a web-services oriented architecture. The authors were observing the study while shaping the architectural models.
3. CASE STUDY 3.1 Stage 1: End-to-end Integration
The project started at adding the PTA service to legacy e-Payment systems. Each of the deployed e-Payment projects is a customized self-contained application, as shown in Figure 2 on the left. Internal modules may expose their functions in low-level application programming interfaces (APIs). Therefore, we adopted two ways to add the PTA service, as illustrated in Figure 2. The first one is to integrate the corresponding code into the original packages and re-deploy the incorporated new system. The second way is to construct a PTA service component, with the original e-Payment system as its back-end supporting system. This end-to-end integration is accomplished through direct calls from PTA service component to the low-level function APIs defined in the e-Payment system. The second strategy leaves the original ePayment system completely intact. However, due to the fact that every PTA service is tightly coupled with the e-Payment system, and every deployed e-Payment system is different, this strategy lowers down the reusability of newly constructed PTA services. Another issue with this architecture is the flexibility. As we discussed in the previous section, to invoke a PTA service, each client generates an HTTP request string that contains a hash value. The order of the parameter values on which to perform the hash algorithm is imperative. This order and the list of the parameter values are normally predefined and hard-coded into the PTA service. As a result, even the separated PTA service cannot be
3.2 Stage 2: Web-services Enabled Stage
To increase the reusability and flexibility, the concept of webservices was adopted. The paradigm of web-services mainly embraces three categories of supporting facilities: communication protocols, service descriptions, and service discovery [3]. Each category possesses its ad-hoc standard, as Simple Object Access Protocol (SOAP) [8], Web Service Description Language (WSDL) [10] and Universal Description Discovery and Integration (UDDI) [9], respectively. Therefore, we utilized SOAP, WSDL, and UDDI in our project. As a result, the architecture was correspondingly altered as illuminated in Figure 3. Every deployed e-Payment system is wrapped with a PTA service, which is referred to as the term PTAenabled e-Payment application. The integration between an ePayment system and its PTA service wrapper vary from each other, depending on the different e-Payment systems. However, the distinction between PTA service wrappers in this architectural model from that in the first stage is that, PTA service wrappers all exhibit the same web-service registry and invocation interfaces to the SOAP/UDDI bus, and they are only accessible through the SOAP/UDDI bus. The SOAP/UDDI bus is introduced as a common communication channel for PTA-enabled e-Payment applications. A simple PTA administration web-service is constructed, and shared by all PTA-enabled e-Payment applications. This administration web-service intends to enable users to adjust the authentication criteria after they are set. For example, one organization may decide to change the order of the parameter values the hash algorithm is performed upon. Due to the page limitation, the definition of the web-services using WSDL will not be discussed in this paper. With the introduction of the administration web-service, this enforcement of the order of the parameter values does not need to be hard-coded into the PTA service; therefore the reusability of PTA service is largely improved. Meanwhile, the single administration web-service is shared by all PTA-enabled e-Payment applications through common SOAP/UDDI bus, thus new PTA-enabled e-Payment applications can be plugged into the bus and use the administration web-service. Therefore, the scalability of the administration web-services is guaranteed. Furthermore, in this
SOAP/UDDI Bus
e-Payment
w
PTA service 1
system integrated
simple web-service
e-Payment
administration
system
PTA service 2
e-Payment
system 1 e-Payment
system 2
e-Payment
system
PTA service 3
PTA service
Figure 2. Stage 1: end-to-end integration to legacy systems
e-Payment
system 3
Figure 3. Stage 2: web services enabled to legacy systems
1626
architecture, the PTA service is actually a web-services façade attached to the existing e-Payment applications. These façades reveal the same web-services interfaces over the diverse ePayment legacy systems. Whilst the compatibility with the emerging web-services standards can be claimed by this architecture, limited benefit is derived from such a solution. First, each PTA service still implements proprietary version of common services, such as logging and notifications. Second, since each PTA service is built on top of each individual e-Payment system, the reusability of PTA service remains limited. Third, no central management of services is provided, such as monitoring and load balancing.
Although based upon the traditional three-tier architectural model in distributed computing [5], it is worth noting that the architectural model presented here introduces some significant changes. First, the model provides guidance on not only the application development utilizing web-services as components, but also the application development serving as web-services components. Second, this architecture as well implies that the system design starts from the system requirements analysis and transformation into web-services tier design. Third, this model implies a web-services centered approach, which will benefit organizations with accumulating web-services component repository for future usage.
3.4 Stage 3: Web-services Oriented Stage
3.3 Web-services Oriented Architecture
The case study from the first two stages shows the necessity of rethinking of the overall web application architectural model. In our project, there are two generalized issues: how to develop an application utilizing web-services as components, and how to build an application that exposes part or all of the functionalities as web-services. We present an architectural model as a solution to these two issues, as illustrated in Figure 4. A web-services based web application is organized as a three-tier structure: frontend, web-services integration, and component-repository. The front-end tier presents the interface of the application to clients. The component repository tier contains software components that are needed for the application, either exposed with web-services interface or not. One web-services integration tier is used as a separate layer where components are integrated and plugged-in. Our previous research yields a web application architecture oriented to exposing web-services [11]. The overall architecture of a web-service component is in turn divided into three layers: front-end tier, web-services tier, and back-end tier. The back-end system contains the business logic tier or normally called middletier, and the persistent tier. One web-services layer is introduced into the architecture as a joint point that integrates the front-end tier and the back-end tier to become a self-contained system with well-defined web-services interfaces. WSDL [10] is used to define the web-services interface, and SOAP is adopted as the information exchange tool between the web-services layer and the front-end tier and back-end tier respectively, as shown in Figure 4.
The architectural model is then applied to redesign the project architecture as illuminated in Figure 5. A SOAP/UDDI bus is still used as the common communication channel for all applications. Each monolithic e-Payment application is dissolved into selfcontained and well-defined business services. More specifically, each future e-Payment system will expose functional web-services interfaces to the SOAP/UDDI bus; and each legacy e-Payment systems will be wrapped with a web-services interface. In other words, in the new architecture, all e-Payment systems will expose the same set of web-services interfaces and be accessible through the SOAP/UDDI bus. As a result, only one PTA web-services is necessary and will be shared by all e-Payment web-services. An administration web-services is separated from the PTA webservice, in order to not only enable clients to dynamically adjust the authentication criteria for each e-Payment service, but also implement some common services, such as notification and logging services, for PTA service. This service largely simplifies the interactions between services, for example by leveraging single sign-on capability across all PTA-enabled e-Payment applications. Another critical component of this stage is a central service management that provides infrastructure services such as thread management to the web-services. The central management of services provides a common access point to systems management functions across heterogeneous applications. The service management component can also provide additional services like message broker functions that assist in the translation between
SOAP/UDDI Bus
requirements
front-end
front-end
web-service integration
webservice
PTA webservice
component repository
middle-tier
back-end
Wrapper
e-Payment
system 1
web-service
e-Payment
administration
web-services
thread
e-Payment
management
web-services
Figure 5. Stage 3: web-services oriented architecture
Figure 4. web-services oriented architecture
1627
application-specific data format. As a result, this central component facilitates the applications towards an ASP model. Meanwhile, this architectural model offers extensive extensibility. New e-Payment systems can be plugged in the SOAP/UDDI bus and automatically reuse the PTA service. Legacy e-Payment systems can as well be plugged-in, as long as corresponding wrappers are attached. Moreover, any upgrade at the PTA service will automatically be applied to all e-Payment applications, which is a significant improvement compared to the model in the second stage. Furthermore, the central thread management service can provide load balancing therefore guarantee scalability.
4. CASE STUDY RESULTS 4.1 Use Case Analysis
In this section we report the analysis of our observations of architectural model through three stages in the aspects described in details as follows. Service Assembly: As the PTA service is migrated from being embedded in an e-Payment application to being an independent web-service, the assembly is easy and simple. In addition, PTA service can be considered as a reusable asset that can be combined with other components in ways not conceived by the originators.
Developer Roles: Our architectural model enforces layered development; therefore, the development is distributed to multiple teams, each has a set of specific developer roles requiring different skills. The organization benefits by not having to rely on highly experienced generalists for the complete application development. Lower-level developers can be assigned to focus on specific development tasks. Testing: In our case study, we compare the feasibility to perform testing in different stages. As the PTA service is separated and become self-contained, its test cases can be utilized and reused for new applications. Therefore, web-services oriented architecture and engineering process facilitates the testing process so as to obtain higher overall level of quality of the web applications. Maintainability: As PTA services have lower coherence, the maintenance becomes much easier. In addition, by focusing on the service layer as the location for your business logic, maintainability increases because developers can more easily locate and correct defects. Reusability: Self-contained web-services provides high reusability. Run-time service reuse is as easy as finding a service in the directory, and binding to it. Developers do not have to worry about compiler versions, platforms, and other incompatibilities that make code reuse difficult. Parallelism in Development: The benefit of multiple layers means that multiple developers can work on those layers in parallel and independently. Developers should create interface contracts at the start of a project and be able to create their parts independently of one another. Scalability: Web-services oriented architecture allows new e-
Payment systems to be plugged in as long as they expose same service interfaces. This feature promotes scalability largely for future usages. Return on Investment: The separation of a service layer has the benefit of a better return on the investment made in the web application development. As the PTA is developed as a separate component and used as a service, it is likely to outlive the original application life cycle.
5. CONCLUSION AND FUTURE WORK
In this paper, we present a case study over an on-going project concerned with the design and development of a pass-through authentication web-services for on-line electronic payment applications. This case study examines how our web-services oriented architecture was formed through the three stages of this project, and how it has benefited the web application development. However, as time goes people are realizing that web services encompass aspects such as reliability, application-level security, trust, orchestration, and semantics. Since this case study was conducted at our first step towards a web services oriented stage, we only consider the functionality of web services. We plan to continue to enhance our web-services oriented architecture. Our future work will be focused on pursuing an engineering process on the basis of our architectural model, and constructing a system environment where all the aspects of our architecturebased development are supported. The goal of our future work intends to provide efficient production of web-services supported web applications.
6. REFERENCES
[1] Deshpande, Y., Murugesan, S., Ginige, A., Hansen, S.,
Schwabe, D., Gaedke, M., and White, B.: Web engineering. Journal of Web Engineering, 1, 1 (2002), 003-017. [2] http://www.hpc2n.umu.se/doc/maui/epoch_time.html. [3] Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., and Weerawarana, S.: Unraveling the web services web: An introduction to SOAP, WSDL, and UDDI. Internet Computing, (March/April 2002), 86-93. [4] http://www.ietf.org/rfc/rfc1321.txt. [5] Robert, O., Dan, H., and Jeri, E. Client/Server Survival Guide. 3rd Edition, Wiley Computer Publishing, John Wiley & Sons. Inc. (1999). [6] Ryman, A. Simple object access protocol (SOAP) and web services. in Proceedings of the 23rd International Conference on Software Engineering, (Toronto, Ontario, Canada, 2001), 689. [7] http://www.w3.org/PICS/DSig/SHA1_1_0.html. [8] http://www.w3.org/TR/SOAP. [9] http://www.uddi.org/specification.html. [10] http://www.w3.org/TR/wsdl. [11] Zhang, J., and Chung, J.-Y. Architecture-based development of web service based applications. in Proceedings of The First International Conference on Web Services (ICWS’03), (Las Vegas NV, Jun. 23-26, 2003), 265-271.
1628
