Appeared in Proceedings of the 17th International Conference on Software Engineering and Knowledge Engineering (SEKE'05), Knowledge Systems Institute Graduate School, 2005. (Preprinted Version)
Service Identification and Packaging in Service Oriented Reengineering Zhuopeng Zhang, Ruimin Liu and Hongji Yang Software Technology Research Laboratory De Montfort University, Leicester, LE1 9BH, England {zpzhang, rliu,
[email protected]}
Abstract With the adoption to Web service technologies, more and more existing non-service-oriented software systems turn to be legacy systems. They require a service-oriented reengineering process in order to survive in serviceoriented computing environment. In this paper, we present an architecture-based service-oriented approach to support service-oriented reengineering. It integrates and reuses software components as services over Internet by wrapping underlying computing models with XML. Service identification and service packaging processes are described in details, which are the keys to serviceoriented reengineering. Target services are defined according to service identification, which is based on a comparison of analyses in both problem domain and legacy systems. Clustering techniques are applied in service identification process to analyse recovered architectural information and to identify related modules. Service packaging is benefit from architecture-based development and reuse. Keywords: Legacy System, Software Reengineering, Software Evolution, Hierarchical Clustering, Web Services, Service-Oriented Architectures (SOA).
1. Introduction Web service technology and Service-Oriented Architectures (SOA) are rapidly developing and widely adopted. Web service technology is to build complex Web-based systems fast, rapidly adopt changes and to provide effective inter- and intra- enterprise system integration. Web services have been born as a natural evolution of different technologies, approaches and demands from communities in business and technology compared to other integration technologies such as Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), and Distributed Computing Environment (DCE) – all
involved communication within different closed technologies. Web services are based on Service-Oriented Architectures (SOA), which is the keystone of serviceoriented computing. SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. The service implementation can evolve easily since it is hidden behind the service interface. The implementation is able to evolve without breaking applications that consume the service. SOA is particularly applicable when multiple applications running on varied technologies and platforms have to communicate with each other. It is an architecture evolution, and it affects the software life cycle from the software as a service point of view. Affected by this Service Orientation (SO) trend, many existing non-service-oriented software systems will become legacy systems. These legacy systems need service oriented reengineering, which can facilitate legacy evolution in service-based computing environment. From economic aspects, a business is constantly reorganising, changing its boundaries and reconfiguring its activities. Service-oriented reengineering enables legacy systems to adapt to continuous changes in business logic and market requirements. From technical aspects, application integration towards services and service choreography will become common in service-oriented computing. The rest of this paper is organised as follows. Section 2 presents some related work in software reengineering; Section 3 describes our proposed approach; the main steps and core techniques are elaborated in Section 4; Section 5 presents a case study. Finally, Section 6 concludes the paper with a summary of our experience to date.
2. Related Work A traditional legacy system can be characterised as a monolithic, single-tier, mainframe-based application. Considerable efforts have devoted to reengineer these typical legacy systems to a Web interface [2]. For
3. Overview of Proposed Approach Our approach is especially applicable to reengineering tasks, which have some of the following characteristics. A legacy system needs to be migrate into a network environment, and it can be wrapped and exposed as a Web service; There are some reusable and reliable functions embedded with valuable business logic in the legacy system. These functions are useful to be exposed as independent services from the requirement point of view; some reuse components from the legacy system are fairly maintainable compared to maintain the whole legacy system; some components of the target system run on different platforms and vendor products; the target system will operate over the Internet where reliability and speed cannot be guaranteed. Our approach is an architecture-based service-oriented re-engineering approach, which emphasises service
identification and packaging. This approach, which is illustrated in Figure 1, is described in the following steps. Step 1: Legacy system evaluation. This evaluation reveals the current status of a legacy system and specifies which phase it is in its lifecycle. A decision tree is used in the assessment in order to consider many aspects altogether. Techniques such as the Options Analysis for Reengineering (OAR) are used to guide the decisionmaking process. Reengineering decisions are made according to this assessment. Step 2: Architecture recovery. The goal of this step is to obtain design and architecture information as much as possible by reverse engineering techniques. The static and dynamic analysis techniques applied in this step will depend on the features of the legacy system. Various modularization criteria, such as coupling, cohesion, reliability, maintenance measures, are adopted to identify potential components and connectors. The results are the foundation of further reengineering work and the input of later service identification. Step 3: Service identification. On the one hand, it is to determine what business functionalities should be provided by the target service in the application domain. On the other hand, the business functionalities embedded in the legacy system should be identified in order to be reused in the target service.
Service-oriented Reengineering
Decisions-making Process
Recovered Architecture Information (representation in SADL)
Hierarchical Clustering Analysis
Legacy Functionalities (encapsulated in components)
Service-Oriented Applications (based on SOA) Service Publication & choreography
Architecture Recovery
Existing non-Service-Oriented Legacy Systems
on ati a lu Ev
example, INSIDE project [6] investigated the problems and possible solutions for the incremental evolution of the existing systems when building Web-based value-added services upon foundations derived from analysing and modelling existing legacy systems. [11] defines a reengineering environment that assists with the migration of legacy systems to distributed object environments. After the first migration which is from monolithic systems to Web-based systems, there is the second migration which is from Web-based systems to serviceoriented systems. [14] provides a balanced perspective of the business value and technical challenges of adopting Web services. They pointed out the adoption issues related to Web services are complex and multifaceted. [19] presents a framework to address the issues on migrating legacy systems into a Web enabled environment, which involves CORBA wrapper and SOAP/CORBA IDL translator. [4] explores a userinterface migration approach, wrapping browseraccessible Web-application interfaces with programmatically accessible specifications, which is syntactically and semantically close to WSDL. [7] describes a performance engineering approach for legacy systems to migrate to Web services, which investigate two performance metrics of Web services, latency and scalability. In the enterprise environment, Arsanjani [1] proposes to migrate enterprise architecture to a full service-oriented architecture by gradually externalising useful business services, which are implemented in largegrained enterprise components.
Ideal Services (including functional legacy code)
Service Rationalisation & Consolidation
Matching
Architecture-based Service Packaging
Functionalities in Desired Services
Service Identification
Figure 1. Overview of proposed approach Step 4: Service packaging. According to the results of service identification, legacy components and newly-built functional components are composed by connectors. This is an architecture-based integration process. Step 5: Service publication and choreography. After a Web service is created, it will be registered under Universal Description Discovery and Integration (UDDI). UDDI creates a standard interoperable platform that enables companies and applications to quickly, easily and dynamically discover and use Web services over the Internet.
Furthermore, the legacy system is renovated by service composition in service-oriented architectures. The services with legacy code inside may be composed with other Web services or Web-based applications in order to build more powerful coordination services. The final coordination services squeeze more value out of the legacy system.
4. Techniques 4.1. Architecture Recovery and Representation Our previous research on software reengineering [16, 17] provides a unified reengineering framework, which is based on the construction of a Reengineering Wide Spectrum Language (RWSL). RWSL, which enjoys a sound formal semantics, is defined to provide a spectrum of abstractions of the reengineered system, from source code to specification. RWSL uses Interval Temporal Logic (ITL) [9] to support Timed Guarded Command Language (TGCL), Common Structural Language (CSL), Object Temporal Agent Model (ObTAM) and Common Object-Oriented Language (COOL) with specificationoriented semantics. RWSL together with the reengineering framework and abstraction rules, which have been proved mathematically and applied successfully in program transformation and abstraction, is the foundation of our architecture recovery process. The recovered architecture information is represented in Simple Architecture Description Language (SADL), which is build according to our reengineering experience [10]. Most ADLs are either dedicated to a specific system or too complicated to be used to reengineering process [8]. SADL is a simplified architecture description language, which is designed to structure the outcomes of reverse engineering in an architecture view. Although UML has limitations for implementing a complete ADL, SADL representation has an equivalent UML profile due to the simplicity of SADL. This advantage of SADL makes it possible to integrate the recovered architecture with other UML/XMI compliant tools to achieve interoperability. The architecture recovery process is benefit from both RWSL-based abstraction and SADL representation. Firstly, initial modules in a legacy system are identified by system decomposition techniques introduced by [3, 5]. Then the sub-systems are translated equivalently into RWSL via universal translator and transformation rules are used to restructure the source code in RWSL. Thirdly, abstraction rules are applied on the restructured RWSL code to get the system architecture composed of interconnected components. Finally, the extracted
architecture information is represented in SADL, which can be converted into an equivalent UML profile.
4.2. Service Identification A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities [18]. To be used, a service must be realized by a provider agent. This provider agent is the concrete piece of software (or hardware) that sends and receives messages, while the service is the resource characterized by the abstract set of functionality that is provided. Service identification is to select related resources. Properly identifying services and determining reusable legacy components are a critical step in architecting a service-oriented reengineering task. Service identification process consists of the following three steps.
Figure 2. Service identification Step 1: Service identification in problem domain. It starts with a domain analysis. The goal of this domain analysis is to identify and document requirements on a set of systems in the same application domain. The domain analysis process can be carried out in two steps, subdomain identification and analysis of the selected subdomain. The results of the whole domain analysis are summarised as a domain model. This domain model can be represented by UML and processed by some modelling tools, such as Rational Rose. Based on this domain model, some business functions are identified to be valuable and reusable and needed to be provided as services. In this way, some logical services are summarized, which are mainly based on requirement analysis. Step 2: Service identification in a legacy system. There are some abstracted components in the legacy system, which encapsulate valuable functionalities and are reusable in the target service. The recovered architecture describes these components and their relationship.
Because configuration in architecture description is not adequate to determine a business level partition of components and connectors, clustering techniques are adopted to analysis the recovered architecture information, which is represented in SADL, in order to identify and reuse these legacy components. We adopted a requirement-driven agglomerative hierarchical clustering method with a complete linkage algorithm, which can provide the most cohesive clusters according to empirical evidence. Components and connectors, which are described in SADL files, are defined as the entities to be clustered. Features are defined to measure the similarity between entities. The weight of features is calculated according to the architectural configuration and the specification of components and connectors. A dendrogram is obtained after executing this clustering algorism on these SADL descriptions. This dendrogram is analysed according to requirements. In order to identify a functional business service from these architectural elements, a cutting point must be determined in the dendrogram. The architectural elements in sub-clusters, which are partitioned by the cutting point, are candidates for reuse in the target services. The selection of the cutting point is an elementary factor for determining the granularity of extracted code. So far, architects are responsible for making the cutting point and selecting subtrees manually according to other recovered design information. This clustering method together with human supervision provides a powerful analysis on recovered architecture, and restructures legacy systems into coarse-grained and loose-coupling modules. Step 3: Matching legacy functionalities to business functions in the logical service. Because the SADL representation has equivalent UML profiles and the logical service model is represented in UML as well, the comparison between legacy system architecture and logical service architecture enables to determine the selection of reusable legacy functionalities and the construction of unavailable functionalities. This service identification process is illustrated in Figure 2.
4.3. Service Packaging A software service is a computational or data serving process which has a well defined functional interface and can be easily discovered and accessed. It processes certain well-defined XML documents what it receives through some combination of transport and application protocols [15]. Service packaging is to deploy legacy components and other newly-built components in a service provider agent. It is a necessary step to bridge legacy service candidates into a functional software
service, because service-oriented architectures encourage individual services to be self-contained. Normally a service packaging process is including the following steps. Legacy code refinement. According to the recovered architecture information, reusable component and connectors are extracted for service packaging. Although these legacy code is independent and loose coupled, it may still has some coupled relationship with other software entities. This refinement eliminates unrelated interaction interfaces and specifies the interface details for service internal communication. In this refinement, dead code is detected and removed. New functional component development [13]. New business requirements found in service identification lead to construct some new components. These new components are designed according to the difference between the domain model obtained from domain analysis and the architecture recovered from the legacy code. They will be integrated in the target service to extend the business logic. Service interface and description development. A service interface is the abstract boundary that a service exposes. It defines the types of messages and the message exchange patterns that are involved in interacting with the service, together with any conditions implied by those messages. Furthermore, a service must have sufficient service descriptions which associated with the service to enable its use by other parties. Ideally, a service description will give sufficient information so that an automatic agent may not only use the service but also decide if the service is appropriate; that in turn implies a description of the semantics of the service. Because Web services are network-accessible interfaces to application functionality, built using standard Internet technologies [12], a Web service interface is applicable to most software services. If the target service is to provide as a Web service, a rigorous definition of the functionality of the service is provided in Web Services Description Language (WSDL). WSDL also describes the operations that a service can support, and the parameters each operation accepts and returns. Transport mechanism integration. Because a service is message-oriented, the transport mechanism is necessary for a service. To implement a Web service, a SOAP processor will be integrated. It supports message transfer on the Web in a firewall friendly way. Connector development. These connectors are designed to connect the fashioned legacy components and newly-built functional components. They intercept ingoing and outgoing calls and replace them by appropriate interaction. These connectors are mainly glue code and wrappers for service packaging.
Service complexity reduction. This reduction is focus on minimising inter-component communication within the service and improving the system’s maintainability and quality of the service. Software metrics and dependence analysis techniques are used in this step. …… Interface IProj{ Required: ProjCreation (); Provided: ProjEvaluation (); } …… Comp Project implements IProj { Spec ProjCreationSpec (ProjCreation){ Proj_Status=On ٨ ( StudentReg_Status=End ٨ ( DissForum_Status=On ٨ Date>15weeks)); …… Project_condition:=Enabled; } Spec ProjEvaluation (ProjEvaluation) { Proj_Result=Yes ٨ ( Proj_Status=On ٨ ( DissForum_Status=On ٨ Date
