Migration of Legacy Applications and Services to Service- Oriented Architecture (SOA)

Transcription

1 Migration of Legacy Applications and Services to Service- Oriented Architecture (SOA) Maher A. Al Sheikh 1 Hatim A. Aboalsamh 2 Ahmed Albarrak 3 maher.sheikh@gmail.com hatim@ksu.edu.sa albarrak@ksu.edu.sa Computer Science Dept. 1,2 Medical Informatics and E-learning Dept. 3 College of Computer and Information Sciences College of Medicine King Saud University King Saud University Riyadh, Kingdom of Saudi Arabia Riyadh, Kingdom of Saudi Arabia Abstract Service Oriented Architecture (SOA) is becoming a mainstream approach for designing and integrating enterprise applications. This paper presents a methodology for migration of legacy applications and services to Service-Oriented Architecture. In order to upgrade existing applications and services to SOA, the methodology should be used in a consistent functional and technological manner. In addition, we have proposed a specific SOA migration approach based on multi-tier architecture. This architecture brings clear differentiation of logical and technical components, allowing business process to be defined in a flexible and agile manner. The architecture highlights position and role of legacy application, fine and coarse grained services with the respect to their role in the business process. As a critical component in the overall architecture, Enterprise Service Bus acts as mediation and virtualization layer helping to separate business and logical view of the process from its technological implementation and reduce dependencies. Our approach is based on analysis of the legacy software in order to identify the business and presentation logic components. The next step is to redesign the legacy code by isolating the business logic and performing code stripping. Finally coarse-grained and loosely coupled SOA services in the medium and upper layer are created in order to achieve the benefits of SOA architecture. Keywords: SOA, EBS, legacy, multi-tier, loosely coupled, coarse grained, fine grained, virtualization 1. Introduction Computer systems have been an integral part of businesses, initially within large corporations, for many years. Due to corporations growth, frequent changes of business requirements and advancement in technology, the demand for improvement of legacy software systems and introduction of new has been constantly increasing. This has created a need for new solutions to support this processes [5]. Older and established systems, known as the legacy software, are proven and represent an important strategic component of companies that use them. However, their maintenance needs also increase as the time progresses. At some point the deficiencies of legacy systems outweigh the benefit they generate to organizations that own them. Hence computer resources must be modernized. One of the best known architectures for the software modernization is Service Oriented Architecture (SOA). SOA is the collection of services with well-defined API interfaces and a shared communications model. The main characteristics of SOA are loose service coupling, publishable and governed interfaces, and standard communication model. These features make SOA an excellent choice for modernization. Unlike SOA, legacy systems are typically not designed with these features, hence a significant effort is required to achieve that level. Furthermore, creating new services based on foundation of the existing systems in order to achieve the benefits of an SOA is a difficult task. This task can even be more complex when services are expected to execute within a constrained environment [4]. The growing interest in SOA is driven by expectations it will enable businesses to achieve significant interoperability of their software systems through service reuse and process efficiency [3]. SOA also allows existing legacy systems to expose their functionality as services, without making significant modifications to the systems themselves. This is one of the most compelling qualities of SOA for many organizations that cannot /11/$ IEEE 137

2 afford or simply do not want for any reason to abandon their investment in legacy systems or re-create the same capabilities as services from the beginning. The main element at the SOA foundation is service, which is reusable, discoverable and self-contained entity that interacts with applications and other services in a loosely coupled fashion that can be either synchronous or asynchronous. One of the main challenges is to understand issues that may occur in the migration process, in order to make SOA successful. Computer systems as an organizational asset must follow the business environment changes to be able to achieve their objectives. The goal of the software engineers is to create computer systems that can be deployed efficiently, quickly adopt the changing business conditions, and have minimum maintenance needs across broad enterprises. This paper aims to address development of a realistic strategy for performing migration to SOA. In order to achieve that it is necessary to take into account both the business needs of the organization and the technical architecture of the organization s existing systems assets. 2. Principles of SOA: Service Oriented Architecture (SOA) is an architectural framework that focuses on service based solutions as a way to improve the efficiency of an enterprise. In this architectural style, the business and technical processes are implemented as services [6]. The added value of SOA is that these services can be used as building blocks to build larger, more complex processes in order to realize a company s strategic goals. However, just having a bunch of services does not mean that they will be used efficiently or even be aligned with company strategy. In addition to having services, a major part of SOA is to provide an environment which aligns these services with the enterprises long term goals. Lastly SOA defines the various lifecycles that these processes go through from inception to retirement. This architecture aims to provide enterprise business solutions that can extend or change on demand as well as provide a mechanism for interfacing existing legacy applications. It is, therefore, being seen as an approach to provide a closer alignment between a business and its IT systems. A service is an independent software unit that has been designed to carry out a specific function, logical unit of work, through a well-defined service contract. A service has to be independent from other services. Usually the communication used between the service provide and service consumer is through a web service using SOAP (Simple Object Access Protocol), REST (Representational State Transfer). An example of a service is obtaining an exchange rate. The service accepts the From Currency & To Currency then based on some logic outputs the Exchange Rate. Well-designed SOA services typically show the following characteristics: 1- Modularity Services exist as self-contained modules which can be bunched together to form other services. For example, the exchange rate service can be combined with another service that obtains the price of a barrel of oil. The resulting service would provide the price of a barrel of oil in any currency you choose. Such a service that is a composition of other services is called a Composite Service. 2- Services are distributed over a network [6], but are not dependent on location or platform. As long as the service contract and web service protocol is respected, the service is potentially accessible from anywhere (providing that the necessary security access is in place). 3- Services are reusable. The service is designed with a specific business objective in mind. The context in which it is use should not impact the service itself. For example if our currency conversion service is being used to show the price of a barrel of oil in Riyals or calculate the salary of an employee in Euro, the currency conversion service does not change. 4- Services are loosely coupled. The service contract is not dependent on who is using it. If the service is being used by ten consumers and three of them decide not to use it any more, the service contract itself should not change. 5- Services are governed. Governance forms a large part of an SOA and becomes essential as more and more services are added. Governance defines policies of how service providers provide a service and how consumers are allowed to use that service. Design time governance ensures that services meet the business objectives that they are meant to serve. Runtime governance ensures that services are being provided and consumer in a consistent fashion. The ESB provides the implementation layer that enable the services to be expose as web service or using any other protocol and distributed throughout the network, /11/$ IEEE 138

3 with this paradigm is becomes easy to add new features and create services or change the existing services. 3. Motivation for Service Oriented Architecture: From the perspective of business stakeholders, it is necessary for enterprises to protect the previous investments in existing solutions, despite the need for new applications that incorporate changing technologies and business requirements. From a technology perspective as well, it is a requirement to provide a scalable architecture that allows for reuse of business services and processes implemented in the existing solutions. Also,organizations and companies require an approach to plan an enterprise wide strategy that leads to well integrated IT systems within their organization. Enterprises have made substantial investments in largescale applications software to support their business processes. The infrastructure is often heterogeneous across a number of platforms, operating systems and applications written in different languages. There is often a redundancy and overlapping of functionality and services resulting in a waste of valuable resources and inadequate response times. More and more, the business and IT managers are being tasked to deliver improved functionality of services by using existing IT investment and provide continuous improvement in processes, enable new channels of business,business agility, as well as organic business architecture in nature. In order to address all of these issues, one solution is to develop architectures that allow easy integration of the existing and new enterprise applications. One of the options to address these requirements is the recommendation of SOA [8] 4. Service Oriented Architecture Benefits: SOA provides an excellent opportunity to achieve large scale interoperability while maintaining flexibility to adapt to rapidly changing business processes and requirements.soa aspires to bring the following benefits as listed by Zaigham Mahmood [9]: 1. Loosely coupled applications 2. Physical location transparency 3. Protocol virtualization 4. Seamless connectivity of applications and interoperability 5. Alignment of IT with business needs 6. Increased business agility 7. Enhanced reuse of existing assets and applications 8. Process-centric architecture 9. Parallel and independent development 10. Better scalability, flexibility, ease of maintenance and graceful evolutionary changes 11. Reduced costs of application development and integration 5. Related Work The demonstration of how legacy code can be reused to help construct a web services represented by [1]. The author shows how the legacy code can be wrapped behind an XML shell allowing individual functions within the programs, to be offered as web services to any external user.the technique used is to transform each entry into a method and to transform each parameter into an XML data element Both the methods and the parameters will be built into an XML schema with a SOAP framework. he argues that the Web Services offered within the framework of a Service Oriented Architecture promise to make applications more flexible, easier to compose and cheaper to develop. The process for migration of legacy components to services based on the case study experience has been described by [2], The authors developed an approach for gathering the necessary information and identifying the risks for the migration effort in a more systematic way based on his experience that illustrated in the case study. This method is the Service-Oriented Migration and Reuse Technique (SMART). He consider SOA migration tasks from the service provider perspective by describing an approach for making migration decisions. Also, Grace present a case study in migration of legacy components to services, as well as an introduction to the reuse and migration analysis process that was derived from this experience.[5] provide methodology for migrating legacy systems towards Service-Oriented Architectures. The approach is based on source code analysis for identifying the contribution of code fragments to architectural elements and graph transformation for architectural migration allowing for a high degree of automation. Carlos and Reiko proposed to reengineering business applications, based on the integration of legacy components after separating application logic from presentation /11/$ IEEE 139

4 6. Proposed solution The proposed solution will apply the following principles of service-orientation: 1. To separate the business logic from the presentation / end-user interfacing logic It is impossible to isolate SOA services directly while business logic is bundled with the presentation logic. Therefore, an appropriate restructuring and reorganization of the code is required such that business functions are isolated as candidate services or service components. This technological dimension of reengineering towards SOA represents an architectural transformation towards a multi-tiered architecture. Typically 3 tiers are used. 2. The loosely coupled relationship between services Service-orientation is based on an assumption that services ought to interact without significant, crossservice dependencies. Hence, a rearranging different functionality is required to provide a sufficient degree of independence. 3. The coarse-grained nature of services Legacy applications normally contain elements that are of a fine-grained nature, for instance components with operations that represent logical units of work. An example would be reading individual items of data. Object oriented class methods are an example of such fine-grained operations. The concept of service is of a more coarse-grained nature. SOA services represent logical groupings of fine-grained operations that work on top of larger data sets, and in general expose a bigger range of functionality Methodology of Architectural Migration: Changes are required along both the technological and functional dimensions. Both types of changes consist of common steps, such as code annotation, reverse engineering and redesign. 1. Technological restructuring It is used in the layering of software systems and will lead to a 3-tiered architecture, separating logic, data, and user interface (UI). This process addresses the principle of separation between business and presentation logic. The first step is code annotation that helps isolating methods, variables that belong to user interface, logic and data components. They require understanding of the programming language and code patters used. Next reverse engineering would produce metadata structure or relationship diagram giving visual representation of the code components. An example would be UML class diagram for object oriented languages. The redesign is the critical step that would isolate the logical function of the code and migrate to upper SOA architecture layers SOA service layer containing coarse grained services that combine atomic units of work or business process management layer. Moving the logic into higher layers, away from legacy applications would provide much bigger visibility, flexibility and reusability of business services. Removing the logic and unnecessary code (a.k.a. dead code ) from the legacy application layer is also known as code stripping, with intention of leaving only services that represent atomic units of work, essentially data interaction, in the legacy system. Such services would be further wrapped into web services, using common protocols such as SOAP or REST that expose this atomic functionality. This layer would represent fine-grained web services that have higher reusability from the technical perspective, but still need logical grouping to achieve meaningful business / logical functionality. The logical grouping is achieved in the next layer containing coarse grained services, that are essentially reusable, common SOA services, representing logical units of work that are recognized as basic business services. An example would be Customer address update or posting a bill payment. Fine-grained services are wrappers around atomic services exposed by legacy applications. When redesigning such services there is a need to make a balance between reusability and atomicity from one side and performance issues from the other side. The performance issues are result of a high atomicity where many service calls need to be made to perform a single meaningful logical unit of work. There are several communication models for fine-grained services interacting with legacy systems: Request/reply Publish and forget Event generation Two way request/reply, a.k.a. duplex Request/reply is a common model where a web service has input and output values that are returned from a legacy application in a synchronous manner. From the flow perspective the user of the fine-grained service (which is SOA coarse-grained service) is a consumer and the legacy system is a service provider. This is the most common pattern typically used for data retrieval, i.e. inquiry service. To implement such a service it is sufficient to create a web service wrapper that expose input and output service signature like any common method /11/$ IEEE 140

5 Publish and forget is a model where data is being pushed to the legacy system. The client is not concerned about the reply, as long as the target legacy system acknowledges the data has been received successfully. This approach is normally applied when the data is being updated in the legacy system or it is exposing queuing mechanism for communication where the reply, if exists, is sent separately through a different queue in an asynchronous manner. In order to implement such a service a web service wrapper is created around legacy service, which acts as a service provider. But, compared to the previous case, the reply contains no data or contains simple acknowledgement. Event generation is a model similar to publish and forget but in an opposite direction, where legacy system is acting as a service consumer and is pushing the data to the upper layer through a web service. This kind of notification mechanism can be used for data synchronization across enterprise where the initial data update happened in the legacy system, which may be a master of the data. Normally mainframe servers act in such a way, being the master, primary source, of the customer related information. Two way request/reply, duplex model of communication represents combination of 2-way request reply, or publish and forget, and event generation model, all of them described previously. This combination is used to complete a unit of work expected by the fine grained service, and hiding the communication complexity detail from SOA service. These services are made available to the Enterprise Service Bus (ESB) acting as a mediation, service and protocol virtualization, or just load balancing layer. This layer is accessed by the top level business process management and presentation applications / systems. Acting as mediation means ESB is a gateway to coarse grained SOA web services. It provides additional authentication, authorization, lifecycle management and proxy routing services. Client authentication can be made through various security protocols depending on the client capability or preferences. The client can be Business process management (BPM) application, user interfacing application, federated SOA system or any other client. They can be implemented using different technologies and using different security mechanisms. So the role of mediation layer is to be versatile and accommodate these various technological solutions. Also ESB is responsible for authorization, which means recognizing client privileges to access certain SOA services. Commonly these privileges are managed through user groups and ACLs (Access Client Lists). Physical location virtualization means that ESB is hiding the physical location details of the target service through a simple proxy or load balancing mechanism. This would allow additional ease of maintenance and system upgrades with minimum or no impact on end consumers. Lifecycle management in case of ESB means awareness of the lifecycle state if the service, from its launch until retirement and capability to manage different versions / releases of the same service. Service protocol virtualization can be also understood as protocol stripping where communication from one protocol type is changed to another on-the-fly. 2. Functional restructuring It separates components which, after having replaced their UI tier with an appropriate interface and being grouped according to specific parameters, represent services. This dimension addresses the properties of loosely coupled services and their coarse-grained nature. Comparing technical and functional restructuring there is a similarity between them regarding the code analysis. However differences emerge at the point of redesigning. The technical restructuring depends on application features which also have an effect on the strategy. On the other hand the functional code restructuring consists of operation identification and grouping of operations into services. Operation represents a functionality that is of a lower granularity to be considered as a service in an SOA context. But during the code redesign step, rules used in this phase are set so that operations are grouped into meaningful services. The services comply with the SOA principles of loosely coupled relationship between services and the coarsegrained nature of services. In the technological dimension there are mostly rules for decomposing code structures. However in this case there are also rules that compose/group code structures to perform logical units of work that can be described as a business asset. The diagram below illustrates the proposed architecture according to the discussion in this paper /11/$ IEEE 141

6 7. Acknowledgements I would like to take this opportunity to express our deep sense of gratitude and profound feeling of admiration of my supervisor Prof. Dr. Hatim A. Aboalsamh. 8. Conclusion SOA promises huge benefits as it is founded on a principle of coarse-grained, loosely coupled, standardsbased, interoperable and reusable services. The main contribution of this work is to propose a concept and practical solution to migrate the legacy applications and services to Service-Oriented Architecture and achieve SOA benefits such as rapid development, increased reusability, simplified maintenance, reduced costs and quicker time to market. We have defined specific multi-layer SOA architecture with definition of roles and responsibilities of each layer and how to generate them from the legacy applications in the course of migration and redesign. Also we have precisely defined the position and role of Enterprise Service Bus as mediation layer for functional services used by the process components, and given guidelines how to implement it. Finally, we have discussed the role of user interface / presentation components and how they best fit in SOA, aiming to achieve the maximum business value. 9. References 1) Harry M. Sneed, Integrating legacy Software into a Service oriented Architecture, Austria, 11 2) Dennis Smith, Migration of Legacy Assets to Service- Oriented Architecture Environments, , USA, 2 3) John Hutchinson, Gerald Kotonya, James Walkerdine, Peter Sawyer, Glen Dobson, Victor Onditi, Evolving Existing Systems to Service-Oriented Architectures: Perspectives and Challenges, 4) Grace Lewis, Edwin Morris, Dennis Smith, Analyzing the Reuse Potential of Migrating Legacy Components to a Service- Oriented Architecture, 5) Carlos Matos, Reiko Heckel, Migrating Legacy Systems to Service-Oriented Architectures, 6) Zaigham Mahmood, Synergies between SOA and Grid Computing, Communications of the IBIMA, Vol. 8, 2009 ISSN: ) Shanshan Yang & Mike Joy, SOA Services in Higher Education, WSEAS,2008,UK,6 8) Shankar Kambhampaty and Satish Chandra, Service Oriented Architecture for Enterprise Applications, WSEAS, 2006, India, 7 9) Zaigham Mahmood,Service Oriented Architecture: A New Paradigm for Enterprise Application Integration, WSEAS, 2007, UK, /11/$ IEEE 142