Migration to Web Services Oriented Architecture - A Case Study

2004 ACM Symposium on Applied Computing Migration to Web Services Oriented Architecture - A Case Study Jia Zhang Department of Computer Science Northern Illinois University DeKalb, IL 60115 01-312-718-2468 jiazhang@cs.niu.edu Jen-Yao Chung IBM T.J. Watson Research Yorktown Heights, NY 10598 01-914-945-3422 jychung@us.ibm.com Carl K. Chang Department of Computer Science Iowa State University Ames, IA 50011 01-515-294-4377 chang@cs.iastate.edu ABSTRACT The rapid emerging of s technology is dramatically changing the scenario of web application design and development. This paper presents a s oriented architecture. As a case study, the paper reports on an on-going project on the design and development of a pass-through authentication s for on-line electronic payment applications. This is a first step towards an electronic payment. 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 atic, disciplined, and quantifiable approaches to assist the design, development, and maintenance of web applications [1]. The emerging concept of s is gaining considerable academic and industrial momentum in the recent months. Being a programmable web application accessible through standard Internet protocols [6], a 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. development. In web application development there are two essential issues incorporating with s: how to develop an application utilizing s 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) s to support online payment () applications: a first step towards an electronic payment. Such a PTA service is at the moment acting as a to our multiple deployments with two functionalities: allows client administrator to register authentication criteria, and functions as a front-end to our back-end servers. Our previous research has suggested the use of an advanced architecture-based s oriented architecture and development process, which aims at providing a framework to construct web applications that exposes some functionality as s [11]. Here we extend the architectural model to include applications that encompasses s as components. This case study intends to examine how our s 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 () 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, was designed as a stand-alone web application, which was customized and deployed at different organizations. The overall design and distribution of 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 will be deployed at one server that is hosted at the organization 1624

Figure 1. Original 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 for an organization is hosted at a central server place, as shown in Figure 1 for organization #1, #3, and #4. These s may reside on the same or different physical server machine; while different 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. In either option, users of each organization are required to access the login page of the corresponding deployed before utilizing the application. Normally, an organization embeds a link in its own web site to point to its server site. As we deploy the 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 application and the original web site of the organization respectively. Therefore, organizations have to transfer batch files to the 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 s 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 e- Payment 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 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 expose some functionality for direct access. However, our 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 e- Payment from another trusted secure website, without visiting an login page (i.e. to obtain the authorization to access). PTA process can convey either already authenticated user or detailed payment information to. Due to the fact that our is usually integrated into the organizations web sites as dedicated on-line payment processing engine, the pass-through authentication offers significant advantages to the application, as PTA facilitates e- Payment application to shift to an ASP model, where a central e- Payment server will handle on-line payment from different organizations The pass-through authentication is realized by a process that e- Payment 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 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&timestamp=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 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 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 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 and the organization. The request will not be authenticated if the two values differ. 1625

2.2 Pass-through Authentication Service As more and more organizations request pass-through authentication function, including the organizations where e- Payment 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 applications; the other is to design a PTA service in order for it to become a synergistic integrated part of future 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 s 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 s. Each of the deployed 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. The second way is to construct a PTA service component, with the original as its back-end supporting. This end-to-end integration is accomplished through direct calls from PTA service component to the low-level function APIs defined in the. The second strategy leaves the original e- Payment completely intact. However, due to the fact that every PTA service is tightly coupled with the, and every deployed 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 easily reused for different applications. 3.2 Stage 2: Web-services Enabled Stage To increase the reusability and flexibility, the concept of webservices was adopted. The paradigm of s 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 is wrapped with a PTA service, which is referred to as the term PTAenabled application. The integration between an e- Payment and its PTA service wrapper vary from each other, depending on the different s. 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 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 applications. A simple PTA administration is constructed, and shared by all PTA-enabled applications. This administration 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 s using WSDL will not be discussed in this paper. With the introduction of the administration, 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 is shared by all PTA-enabled applications through common SOAP/UDDI bus, thus new PTA-enabled applications can be plugged into the bus and use the administration. Therefore, the scalability of the administration s is guaranteed. Furthermore, in this SOAP/UDDI Bus w integrated simple administration PTA service 1 PTA service 2 1 2 PTA service PTA service 3 3 Figure 2. Stage 1: end-to-end integration to legacy s Figure 3. Stage 2: web services enabled to legacy s 1626

architecture, the PTA service is actually a s façade attached to the existing applications. These façades reveal the same s interfaces over the diverse e- Payment legacy s. Whilst the compatibility with the emerging s 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, the reusability of PTA service remains limited. Third, no central management of services is provided, such as monitoring and load balancing. 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 s as components, and how to build an application that exposes part or all of the functionalities as s. We present an architectural model as a solution to these two issues, as illustrated in Figure 4. A s based web application is organized as a three-tier structure: frontend, s 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 s interface or not. One s 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 s [11]. The overall architecture of a component is in turn divided into three layers: front-end tier, s tier, and back-end tier. The back-end contains the business logic tier or normally called middletier, and the persistent tier. One s 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 with well-defined s interfaces. WSDL [10] is used to define the s interface, and SOAP is adopted as the information exchange tool between the s layer and the front-end tier and back-end tier respectively, as shown in Figure 4. front-end requirements integration component repository 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 s as components, but also the application development serving as s components. Second, this architecture as well implies that the design starts from the requirements analysis and transformation into s tier design. Third, this model implies a s centered approach, which will benefit organizations with accumulating s component repository for future usage. 3.4 Stage 3: Web-services Oriented Stage 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 application is dissolved into selfcontained and well-defined business services. More specifically, each future will expose functional s interfaces to the SOAP/UDDI bus; and each legacy s will be wrapped with a s interface. In other words, in the new architecture, all s will expose the same set of s interfaces and be accessible through the SOAP/UDDI bus. As a result, only one PTA s is necessary and will be shared by all s. An administration s is separated from the PTA webservice, in order to not only enable clients to dynamically adjust the authentication criteria for each 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 applications. Another critical component of this stage is a central service management that provides infrastructure services such as thread management to the s. The central management of services provides a common access point to s management functions across heterogeneous applications. The service management component can also provide additional services like message broker functions that assist in the translation between PTA webservice administration SOAP/UDDI Bus Wrapper s 1 front-end webservice middle-tier back-end thread management s Figure 4. s oriented architecture Figure 5. Stage 3: s 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 s can be plugged in the SOAP/UDDI bus and automatically reuse the PTA service. Legacy s 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 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 application to being an independent, 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, s 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 s 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 s 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 s for on-line electronic payment applications. This case study examines how our s 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 s oriented architecture. Our future work will be focused on pursuing an engineering process on the basis of our architectural model, and constructing a environment where all the aspects of our architecturebased development are supported. The goal of our future work intends to provide efficient production of s 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