the Web at the center of software experience both in terms of data location and where the software is [5]. Web 2.0 takes us to a deeply service-oriented world.
A Mashup-Based Strategy for Migration to Service-Oriented Computing 1,2
1,2
2
2
Semih Cetin , N. Ilker Altintas , Halit Oguztuzun , Ali H. Dogru , 1
2
Ozgur Tufekci and Selma Suloglu 1
Cybersoft Information Technologies 2
Department of Computer Engineering, Middle East Technical University {semih.cetin, ilker.altintas, ozgur.tufekci}@cs.com.tr {oguztuzn, dogru, selma.suloglu}@ceng.metu.edu.tr
Abstract Service-Oriented Computing holds great promises to realize the vision of on-demand services available anytime and anywhere. It is still not clear, however, when and how the existing systems will benefit from this new wave. The problem is particularly acute for the software embedded in myriad devices. This work charts a roadmap for migration of legacy software to pervasive service-oriented computing. A key idea is to achieve integration even at the presentation layer, not only at backend layers like application or data. This requires re-inventing the popular mashup technology for the enterprise level. Domain-Specific-Kits, which has been originally introduced within the context of software factory automation, has been reshaped as another enabling technology towards migrating to the service harmonization platform.
1. Introduction Today’s computing necessitates emerging services available as quickly as possible but this is not so easy to achieve since enormous amount of functionality is somehow buried in billions of dollars worth of existing code. Service-Oriented Computing (SOC) may help tackle this problem by decomposing monolithic legacy systems into loosely coupled parts wrapped by service adapters. This is quite challenging since such legacy systems have mostly single tier architectural designs, which complicates service partitioning and assuring the Quality of Service (QoS) attributes such as durability, maintainability, security, and efficiency. Another difficulty stems from the fact that service pervasiveness essentially requires the content-oriented harmonization rather than the data or behavior-oriented
one, which is common today. Known as the “mashup” technology, this new trend adds more value to existing services but such services are expected to be REST services rather than the classical Web services [17]. This makes even today’s state of the art Web services legacy as well. All these challenges reveal that a generic migration strategy to SOC may not scale well for miscellaneous business requirements. Alternatively, domain specific approaches will tackle the low-level details more effectively but with a certain surcharge. Therefore, a compromise is needed for the effectiveness of domain specificity at the cost of generality. This paper puts forth such a strategy for migrating legacy solutions to SOC by mashing them up in a harmonization platform: “MigrAtion to Service Harmonization compUting Platform (MASHUP)”. MASHUP provides a six-step roadmap to mash existing binaries in a generic Mashup Server where domain specific wrappers are plugged in to wrap existing logic either as B2B or B2C services.
2. Legacy software, Web 2.0 and Mashup Services are actually engineered with the purpose of composing them with different applications. They are “components” whose coupling with many different systems is inherently facilitated. Legacy software, on the other hand, constitutes frequently monolithic, big sized applications. The philosophy had been to write code for the given system specifications, but now it turned out to “compose” existing services – even “on the fly”, in the age of ubiquitous / pervasive services. The Web 2.0 designation was originally coined by O'Reilly's Dale Dougherty to describe the Web experiences that fundamentally engage users by: (a) allowing them to participate in sharing information and
enriching data freely; (b) readily offering their core functionality as open services to be composed or "mashed up" into new services and sites; (c) placing the Web at the center of software experience both in terms of data location and where the software is [5]. Web 2.0 takes us to a deeply service-oriented world where we can exploit everyday services such as news, instant messaging, and blogging. These services seem re-writing of the existing services but they are smart compositions (mashups) of the existing services with new ones. Also known as Web application hybrid, this smart way of combining the content from more than one source into an integrated experience is called “mashup” technology. Further convergence of Web 2.0 and SOA creates a new trend of applications so-called Enterprise Web 2.0, which embraces the union of Web 2.0 technologies such as Ajax with legacy systems, and Web services to enable deploying robust, reliable, and secure business applications over the Web.
3. Existing migration approaches to SOA Migrating a legacy system to SOA by wrapping with Web Services may be relatively straightforward. However, certain characteristics of legacy systems like platform, language, architecture, and the target SOA may complicate the task. Table 1 classifies the existing SOA migration strategies.
7]. Such context sensitive attempts, however, are not practical enough for enterprise legacy applications and they cannot be generalized easily.
4. The MASHUP migration strategy The proposed MASHUP migration strategy has six steps to address both the behavioral and architectural aspects of the migration as shown in Fig. 1: Model Target Enterprise Business Requirements (MODEL)
Analyze Existing Legacy Systems (ANALYZE)
Map Target Enterprise Model to Legacy Components and Identify Services Design Concrete Mashup Server Architecture with Domain Specific Kits
Define Service Level Agreements (SLAs) (DEFINE)
Implement and Deploy Services (IMPLEMENT & DEPLOY)
Table 1. SOA migration strategies
SMART [6]
SWA * [3]
EMDMA ** [7]
IBM [8]
ORACLE [9]
MICROSOFT [10]
SAP [11]
Figure 1. Migration activities
Provides a Roadmap
√
√
?
√
√
√
√
Platform/Vendor/Tool Independent
√
√
√
√
√
√
√
?
√
√
√
√
√
√
?
?
√
√
√
√
Web 2.0 Enablement
?
?
√
?
Mashup Enablement
?
?
Quality of Services
√
?
?
?
Scales to Different Domains Process/Service Integration Content Integration
√ ? * **
√
√
Fully match Partly match Salvaging & Wrapping Approach Enterprise Model Driven Migration Approach
Existing migration approaches propose merely the back-end integration with reverse engineering and architectural reconstruction of source codes [1, 2, 3, 4,
Step 1 (MODEL) is modeling the target enterprise business requirements. The business requirements are modeled for understanding the functional requirements of the target system. The business domain model might be expressed using a semantic notation similar to Business Process Modeling Notation (BPMN) [12], which is a methodology independent and unambiguous notation to express any business process. Step 2 (ANALYZE) is analyzing the existing legacy systems. The analysis of existing systems reveals the important data for designing domain specific kits and reference architecture and for investigating reuse potential of existing legacy components. The results of this step include information on system architecture, system components, infrastructure details, interfaces, presentation characteristics, QoS attributes, level of maintainability, level of complexity and coupling, etc. Step 3 (MAP & IDENTIFY) is mapping business requirements to system components and identifying services. System components might be reused legacy components or freshly developed ones. Thus, this step uses the results of business modeling and legacy analysis activities.
The iterative mapping process is as follows: (a) if a business requirement can be satisfied by one of the existing legacy components, then simply wrap it by considering the QoS attributes; (b) if there is a gap with the existing legacy component and requirement, and the gap can be filled during service wrapping, then accustom the legacy component into a new service; (c) if the gap cannot be fulfilled, then develop a new service for the requirement. The new service need not be implemented in any specific language as Mashup Server reference architecture can utilize any component (implemented in any language) using appropriate Domain Specific Kits (DSKs). Continue this step as the services can be broken down into further sub-services and those can be mapped using the above mappings (either into legacy components or new ones). A successful mapping might use Commercial-Off-The-Shelf (COTS) components as service sources since those COTS components can be plugged into reference architecture with proper DSKs that can utilize component orientation techniques [13]. As part of this activity, investigate any implicit dependencies. The implicit dependencies can occur at data level, platform level, service quality level, etc. For instance, if there are two services from two different systems but they need a common data set, then mapping process should introduce suitable data feeder services. At the end of this step, the business requirement to service (BR2S) and service-to-service (S2S) breakdown has been determined at the conceptual level. Step 4 (DESIGN) is for designing a concrete Mashup Server Architecture with DSKs. The design of Mashup Server Architecture (MSA) has been adapted from the architecture modeling approach already employed for software factory automation [15]. Architecture modeling relates architectural aspects and quality targets to running DSKs and choreography rules. The “symmetric alignment” technique [14] is assisted by a methodical approach to identify components (Domain Specific Engines – DSEs), and connectors (composition of DSEs) in the solution domain. Identification of architectural properties facilitates the definition of contextual information, which contains the stateful/stateless information to connect individual DSEs, and is needed for independent design and implementation of these individual DSEs through a standard communication schema across Domain Specific Languages (DSLs). Defining DSLs under the governance of a service meta-model enables the exposition of service from different sources with varying attributes. This step results in MSA with a set of specific pluggable DSEs, contextual information, internal requirements of DSEs and a runtime model.
Step 5 (DEFINE) is defining the Service Level Agreements (SLAs). At the end of Step 3, the service mappings are finalized; and the MSA (from Step 4) is ready to execute those services. SLA is defined in a common service repository and contains information on: a) contextual information; b) QoS characteristics of the service. QoS characteristics are basically inherited from the provider system and managed by the DSE serving the service, but the service implementation may introduce additional quality concerns. The Mashup Server manages both the contextual information and QoS definitions. Step 6 (IMPLEMENT & DEPLOY) is implementing and deploying the services. This includes wrapping of existing legacy components, customization of existing legacy components with some additions, development of new services, and introduction of COTS components as services. The development of new services does not require that those new services need to be implemented using a common language on a common platform since they are abstracted by appropriate DSEs at the Mashup Server level. The reference architecture model for the Mashup Server, depicted in Fig. 2, highlights the generic reference architecture that enables plugging specific DSEs for different systems (service sources). Mashup reference architecture depends on a meta-model for specifying DSLs for different service sources, a common service repository, and a policy for managing contextual information. The reference architecture enables the integration of another Mashup Server using a particular DSE (see DSE5 in Fig. 2).
Figure 2. MASHUP reference architecture The reference architecture employs a choreography engine that manages the DSEs. Dynamic plugging and context-awareness of DSEs are crucial for the runtime execution model. The choreography engine enables
this communication and coordination among DSEs. It ensures state coordination, communication, messaging, nested processes, context management, and serviceoriented exception handling. The corresponding DSLs are required to comply with a certain meta-model to be plugged into the Choreography Engine. DSLs are declarative, context-free and loosely coupled to each other; hence we can readily apply the golden principle of separation of concerns for different domains. The DSEs can perform specific tasks for different systems. Consider, for instance, a Web 1.0 system without an API. It heavily mixes presentation with content and makes it hard to sift out meaningful data from the rest of the elements used for formatting, spacing, decoration or site navigation. In such a situation the DSE can employ “Screen Scrapping/Web Reading” techniques by analyzing the page structure and wrapping out the relevant records. In some cases the task is even more complex than that: The data can be scattered over more pages. Then, triggering of a GET/POST request may be needed to get the input page for the extraction or authorization that might be required to navigate to the page of interest. The situation may be even more complex if there are workflows running in the provider system and if tight security policies are applied. In case the legacy code is provided by a mainframe, screen-scrapping techniques are essential to simulate the working of the mainframe terminals. Using screen scrapping, the data would be retrieved from the host and also posted onto the host. The mashed up services are accessed through Web 2.0 clients supported with AJAX, Flash, Flex, JavaScript, and other XML-based rendering [16] technologies. Even smarter clients can be used to access several Mashup Servers from a single client with core Mashup Choreography abilities.
4. Conclusions This paper introduced a migration strategy to SOC, based on one of the Web 2.0 challenges, namely the mashup technology. The six-step MASHUP roadmap propounded here aims to overcome many difficulties; especially QoS related ones, in the migration process by means of architecture-driven designs with DSEs. The MASHUP approach is already being tried to create a Service-Oriented Business Application through the mashup of financial gateway services; almost all of them are legacy and out-of-organization services. In order to have such a pervasive service providing a single interface to customers but managing a variety of resources at the backend, the approach should be capable of mashing up in a harmonized platform. This harmonization can be achieved due to the generality of
Mashup Choreography engine, which enables plugging multiple legacy service adapters implemented within a domain specific perspective. Having enormous amount of legacy systems without the source code, MASHUP approach will facilitate their migration to SOC as well.
5. Acknowledgement This work has been partly supported by TUBITAK within the context of METU-ISTEC project.
6. References [1] Sneed H.M., “Encapsulation of Legacy Software: A Technique for Reusing Legacy Software Components”, Annals of Software Engineering, 2000, Vol. 9, 293-313. [2] Papazoglou M.P. and Georgakopoulos D., “ServiceOriented Computing”, Communications of the ACM, Vol. 46 No: 10, October 2003, 25-28. [3] Sneed H.M., “Integrating Legacy Software into a Service Oriented Architecture”, CSMR’06, IEEE CSP, 2006. [4] Benatallah B. and Nezhad H.R.M., “Service Oriented Computing: Opportunities and Challenges”, SWDB, 2005. [5] Hinchcliffe, D., “i-Technology Viewpoint: Is Web 2.0 the Global SOA?”, SOA World Magazine, 2006. [6] SEI, “SMART: The Service-Oriented Migration and Reuse Technique, (CMU/SEI-2005-TN-029), 2005. [7] Ziemann, J., Leyking, K., Kahl, T. and Dirk, W.: "Enterprise Model driven Migration from Legacy to SOA", Software Reengineering and Services Workshop, 2006. [8] Channabasavaiah, K and Holley, K., "Migrating to a service-oriented architecture", IBM White Paper, 2004. [9] Oracle, "Oracle IT Modernization Series: The Types of Modernization", Oracle White Paper, 2006. [10] Microsoft Corporation, “Enabling Real World SOA through the Microsoft Platform”, 2006. [11] SAP, “NetWeaver Open Integration Platform”, https://www.sdn.sap.com/irj/sdn/developerareas/netweaver [12] BPMI, “Business Process Management Initiative”, http://www.bpmi.org/. [13] Dogru, A. H., and Tanik, M. M., “A Process Model for Component-Oriented Software Engineering”, IEEE Software, Volume 20(2), 2003. [14] Cetin, S., Altintas, N. I., and Sener C., “An Architectural Modeling Approach with Symmetric Alignment of Multiple Concern Spaces”, ICSEA 2006, IEEE CSP, 2006. [15] Altintas N. I., Cetin S., and Dogru H. A., “Industrializing Software Development: The ‘Factory Automation’ Way”, TEAA-2006, LNCS, 2006. [16] Altintas, N. I. and Cetin, S., “Integrating a Software Product Line with Rule-Based Business Process Modeling”, TEAA 2005, LNCS 3888, pp. 15-28, 2005. [17] Vinoski S., “REST Eye for the SOA Guy”, IEEE Internet Computing, 2007.
