architectural transformation and re- engineering for web service-based ...

IADIS International Conference on WWW/Internet 2005

ARCHITECTURAL TRANSFORMATION AND REENGINEERING FOR WEB SERVICE-BASED SYSTEMS Claus Pahl and Ronan Barrett Dublin City University, School of Computing Dublin 9, Ireland

ABSTRACT Software systems based on the Web Services Framework are examples of service-oriented architectures. The ubiquity of the Web will make this framework an important platform for future software systems. We investigate a re-engineering approach to enable the migration of existing systems to the new platform. Capturing and transforming the static and dynamic aspects of the system architecture are the central activities, which is supported by a layered architecture model and a calculus focusing on service processes in the architecture. Architectural and process patterns provide central elements of the re-engineering framework. We will present an architectural transformation calculus that forms the core of such an approach. KEYWORDS

Web Services, Service-oriented Architecture, Architectural Transformation, Software Re-engineering, Architectural Transformation Calculus, Re-engineering Methodology.

1. INTRODUCTION Service-oriented architectures (SOA) play an increasingly important role as an architectural organisation form for software systems. The Web Services Framework (WSF) with the WSDL description language and the SOAP service interaction protocol is a specific form of an SOA [1]. Due to the ubiquity of the Web platform, the WSF can be expected to play a major role as a software development and deployment platform in the future. Often, service-orientation is a business goal or stakeholder objective. Providing and charging for the use of services in an SOA such as the Web Services Framework can be a new revenue model. Other reasons to migrate to service technology include increased competitiveness, interoperability that is required to enable enterprise systems integration, or the reuse of software artefacts. The consequence the potential that SOAs and service provision offers in terms of technical and commercial benefits is that software developers and provider will consider the migration to an SOA. A substantial number of existing software systems will have to be re-engineered to satisfy the constraints imposed by SOAs. Simple adaptations, such as code wrappers, are often not sufficient to achieve the stakeholder goals. Provided services are reusable artefacts that need to be coherent, reliable, and clearly described in their functional and non-functional properties. Thus, the need to re-engineer these software systems and in particular their architecture arises [2]. We will focus our attention here on object technology software systems that have to be re-engineered and the problems that arise in the context of migrating towards an SOA. In the recent past, the migration of software to object technology has been in the focus [3]. Legacy systems that predate this era and how to re-engineer small-scale code is extensively dealt with in the literature [4, 5]. We therefore focus on the migration from object to service technology. Our solution is based on a layered architecture model that is embedded into a process model capturing the central re-engineering activities and which is made available to developers through a description notation and associated re-engineering techniques. As composition is a central activity in software development, we will focus in particular on composition and architecture issues in SOAs. Processes will turn out to be the essential form of composition in these types of architectures. At the core of our approach will be a calculus to support

299

ISBN: 972-8924-02-X © 2005 IADIS

the migration of legacy systems to service-based architectures through architectural description and transformation. The Web Service Framework will be the platform we will focus on.

2. SERVICE-ORIENTED ARCHITECTURES AND WEB SERVICES A central aim of software architecture [2] is the separation of communication from computation. Architectures are about components (the loci of computation) and connectors (the loci of communication). This allows a developer to focus on structural architectures and the dynamics between components separately. In [6], a basic notional architectural model is presented that captures common concepts found in a variety of architectural description languages: components provide computation, interfaces provide access to blackbox components, and connectors provide connections between components. Behaviour is an essential part of modelling and understanding software system architectures [2]. Interaction processes are central for the understanding of a software system. For instance, [7] use scenarios – descriptions of interactions of a user with a system – to operationalise requirements and map these to a system architecture. We follow this approach here. We extend the notion of interaction and also consider system-internal interactions and allow interaction processes to be composite. Interaction process descriptions will help us to analyse existing systems and to formulate the target architecture. A service is made up of a coherent set of operations provided at a certain location. The service provider makes an abstract service interface description available that can be used by potential service users to locate and invoke the service. Services are often used ’as is’ in single request-response interactions [8], but more and more the composition of services to processes is important – the recent discussion about orchestration and choreography of Web services highlights this development [9]. Existing services can be reused to form business or workflow processes. The principle of architectural composition here is process assembly. During the 1980s and 1990s, object technology was the favoured implementation paradigm. In more recent years, open distributed middleware and service-oriented architectures have become more important. Consequently, a need to migrate from object to service technology arises. Object technology systems are similar to service-oriented architecture in that they are formed by components that interact through operation activation [5]. Middleware platforms such as CORBA certainly encompass a notion of services. The main difference is that the principle of distribution and the clear separation of user and provider is not part of object-orientation. Often, existing systems have evolved in undocumented steps, making it necessary to reconstruct their architecture explicitly before software migration can take place. Architectural reconstruction is a part of the re-engineering of a software system. It is usually not an automatic process [2]. Pattern recognition and their explicit description are central activities. Architectural re-engineering is the core task of a migration from object to service technology.

3. ARCHITECTURAL RE-ENGINEERING AND TRANSFORMATION Our architectural re-engineering framework is based on three elements (Fig. 1): a process model capturing reengineering activities, a description notation and re-engineering techniques, and a layered architecture model.

3.1 Layered Architecture Model More than connections and interactions along the connections of a software architecture have to be considered for SOAs: flow patterns and interaction processes need to be modelled, design and architectural patterns – defining structural and interaction constraints – need to be identified, and domain-specific reference architectures need to be employed. These aspects form the layers of abstraction of our architectural model (Figure 1). This model forms the basis for re-engineering activities for the migration process. The activities are complemented by a repository of workflow and architectural design patterns.

300

IADIS International Conference on WWW/Internet 2005

Re-engineering Activities architecture reconstruction

re-engineering service identification

Notation and Techniques

pattern-preserving transformation

annotation and implementation support activities

modelling and analysis techniques architectural description notation provide notation

Architectural Layers of Abstraction flow patterns

architectural design patterns

reference architectures

Figure 1. An Architectural Re-engineering Framework.

3.2 Re-engineering Activities The following activities define a process model for architectural re-engineering for service-oriented architectures (Figure 1). The first step is the capture of current architectural properties through a semiformal description. Reconstructing the system architecture is usually necessary since most software systems will have evolved since their initial design. Re-engineering of the system architecture is the second step. This involves two activities: firstly, a remodelling as a service-oriented architecture, and, secondly, an adaptation or transformation of the serviceoriented architecture. The following aspects need to be addressed in the first activity: Reference architectures should be used to remodel the system architecture and to identify services. Architectural design patterns need to be identified – these will act as invariants for further transformations. Workflow patterns need to be identified to structure interaction processes within the architecture. This step might lead to architectural changes. The transformation step needs to consider architectural invariants expressed in terms of patterns. The remodelling step is usually done by hand, whereas the transformation step can be (semi-)automatic. Annotation and implementation is the final step. Abstract specification and annotation of services supports re-engineering for reuse. Two aspects need to be specified: abstract computation, e.g. pre- and postconditions for individual operations, and interface processes and workflows for services as a whole. Implementation of the converted architecture is the last activity. This includes WSF notations such as the interface description format WSDL (Web Service Description Language) and choreography and orchestration languages such as WS-BPEL (Business Process Execution Language or Web Services).

3.3 An Architectural Description and Transformation Calculus We introduce a calculus for architectural description and transformation that has features of an abstract architectural description language at its core. We do not use a full-scale ADL here; our objective is to identify features of an architectural re-engineering language using the calculus. Two elements define our calculus. Firstly, a description notation is needed to capture architectural properties of a software system. Secondly, the notation is complemented by modelling and analysis techniques for transformation. The calculus is defined in terms of the π-calculus [10] for two reasons – a simulation notion allows us to capture transformation and mobility is similar to changes in context. We follow here other process calculus-based approaches [16,17,19]. However, we add a richer set of combinators to express workflow and design

301

ISBN: 972-8924-02-X © 2005 IADIS

patterns. A more foundational framework allows us to develop a basic calculus [19]. A simulation notion captures the idea of permitted structure and behaviour variations during transformation. The ultimate objective is, however, to map this calculus to a widely used standardised notation [18].

The Notation The basic element describing process activity is an action. Actions are combined to process expressions. Given a service x and data item a, actions can be divided into invocations inv x (a) of other services and activations receive rcv x (a) and reply rep x (b) through other services. The process combinators are: ƒ Sequences are represented by the ’;’-notation a;P, meaning that action a is executed and the system transfers to the remainder of the process P, where the next action of P is executed. ƒ Choice means that one ai from choice ai;Pi is chosen. ƒ Multichoice mchoice ai;Pi allows any number of the processes ai;Pi to be chosen and executed in parallel. ƒ Iteration repeat P executes process P an arbitrary number of times. ƒ Parallel composition par (P1,P2) executes processes P1 and P2 concurrently. Additionally, process abstractions shall be introduced. We cover the three layers of the conceptual architecture with our notation. Workflow operators are directly integrated as operators. An architectural design pattern can be formulated as an expression of a number of concurrently executing processes. Reference architectures can be modelled on the level of abstractions.

Techniques The description notation is complemented by modelling and analysis techniques that suit the architectural reengineering needs. A notion of satisfaction is needed to capture equivalence and refinement – an essential element of the modelling aspect. A simulation definition, adopted from the π-calculus, satisfies this requirement for the processes. A simulation needs to match all actions of the original process in the same ordering. Architectural transformation is one of the re-engineering activities. Simulation is the criterion that formalises the notion of property-preserving transformations. Interaction processes should not change and structural patterns should be preserved. A repository of patterns is part of the support. We distinguish workflow patterns [11] and architectural design patterns [12]. Workflow patterns relate to connector types that are used in the composition of services or components – they are actually provided as built-in operators of the calculus. An example is the Unix-style pipe, which resembles our sequence workflow pattern. Architectural design patterns are structural and behavioural constraints formulated on a number of components with particular roles. We join here design patterns [12] and architectural patterns [2] into one architectural design pattern concept.

4. CASE STUDY Our case study is a teaching and learning system called IDLE (Interactive Database Learning Environment). It is based on object technology with a Web-based interface. IDLE is architecturally characterised as follows: ƒ It is a multimedia system that uses different mechanisms to provide access to learning content, e.g. Web server and a (synchronised) audio server, ƒ It is an interactive system that integrates components of a database development environment (a design editor, a programming interface, and an analysis tool) into a teaching and learning context, ƒ It is a constructive environment in which learners can develop their database applications, supported by shared storage and workspace. Most of the business logic is coded in Java and standard Web technologies. While IDLE is not a large system in comparison with some industrial applications, it is a real-world system that is in use since the late 1990s and has been used by thousands of students since then. In particular the development history makes this system a good case study. The system has been developed over a period of eight years in several stages. The consequence of this growth is a system without a designed architecture – an architecture that is even not explicitly captured and documented. We will illustrate the re-engineering of IDLE to a service-oriented architecture – in this case the WSF – based on the process model activities.

302

IADIS International Conference on WWW/Internet 2005

Multimedia

Delivery

Behaviour

Interaction Context

Lo cat or Locator Catalog Info Learning Resources Query

Learning Content

Learner Entity

Evaluation

Learning Preferences se As

ent ssm

Coach Learner Info

Learner Info Learner Records

Figure 2. Reconstruction: an overview of the LTSA Reference Architecture – the reconstruction basis.

4.1 Reconstruction Reference architectures, if they exist, can play an essential role in the architectural definition of a software system. Reference architectures often emerge in an abstracted and standardised form from successful architectures. Reference architectures define accepted structures and processes that help to build maintainable and interoperable systems. In the context of educational software systems, the Learning Technology Standard Architecture LTSA provides a service-oriented reference architecture [13]. It captures common structural and behavioural features of learning technology systems. We can describe IDLE’s architectural characteristics using the LTSA. An abstract representation of the LTSA can be found in Fig. 2. The following is an LTSAbased specification of some IDLE adaptive delivery behaviour: LearnerEntity Coach

= =

Delivery LearningResources

= =

prefInfo = inv getPref (); inv setPref (alter(prefInfo)); learRes = inv multimedia () repeat ( choice ( rcv getPref(); rep getPref(prefInfo), rcv setPref(prefInfo), uri = inv locator (resource) ) ) rcv locator(uri); learnRes = inv retrvRes (uri); rep multimedia(learnRes) rcv retrvRes(uri); rep retrvRes(retrieve(uri))

Design patterns are recognised as important building blocks in the development of software systems [12]. Their purpose is the identification of common structural and behavioural patterns in these systems. A rich set of design pattern has been described, which can be used to structure a software design at an intermediate level of abstraction. Design patterns in Web services architectures are discussed in [14]. Usually, architectural patterns (such as client-server or model-view-controller) are distinguished from design patterns (such as factory, composite, or iterator). We see both forms of patterns as constraints on a system architecture, i.e. on services and on their patterns of interaction. An example of an architectural design pattern is the client-dispatcher-server pattern, see Fig. 3. In IDLE, a learner requests content from a resources server. This involves the learner (client), a coach (dispatcher), and the resources and delivery subsystem (server). The pattern is not identical to the structure found in the IDLE system. However, the client-dispatcher-server pattern is simulated by the composite process par (LearnerEntity,Coach,Delivery) of the IDLE reformulation in LTSA terminology, i.e. the pattern is a good abstraction of IDLE functionality that needs to be preserved during transformation. Abstracted pattern definitions such as client-dispatcher-server can act as building blocks in higher-level architectural specifications. Patterns are defined as process expressions and made available as process abstractions. These macro-style building blocks also form the pattern repository. Workflow patterns are small-scale process patterns. These are small compositions of basic activities. The multichoice pattern is an example: mchoice(Lecture, Tutorial, Lab) expresses that a selection of IDLE services Lecture, Tutorial, and Lab can be used concurrently. Workflow patterns and the problems they cause when implemented in Web services infrastructures are described in [15]. To identify these patterns is important since often not all of them are supported by the implementation languages. In this case, workarounds based on architectural transformations have to be found.

303

ISBN: 972-8924-02-X © 2005 IADIS

4.2 Service Identification A main goal of using a (service-oriented) reference architecture in our context is the identification of services in the original IDLE system: ƒ some of the components are already services – an SQL execution element, which is part of the lab resources and delivery subsystem, is an example, ƒ some components (implemented as Java objects) are not services – a feedback system is not encapsulated as a service; another example is the workspace function. We have decided to realise the workspace function, which could have been integrated into either learning resources or learner records, as a separate service in the converted system. The IDLE storage/workspace feature can be integrated as a service: WorkSpace = choice ( repeat ( rcv retrieve (resId); inv provide (res) ); repeat ( rcv store (resId, res) ) ) This explicit storage/workspace service would require for instance the services LearnerEntity and Delivery to be modified in their interaction patterns. Client

Server requestService

doTask sendRequest

acceptConnection return runService receiveRequest requestConnection

register acceptConnection

Dispatcher locateMap registerService unregisterService locateServer establishChannel getChannel

Figure3. Transformation: The Client-Dispatcher-Server design pattern acts as an invariant.

4.3 Transformation In our method, design patterns that can be identified in an existing system act as invariants of the architectural transformation. Previous investigations in this direction [16] have shown that design patterns that were identified for object-based systems will also occur in service-oriented architectures. Consequently, identified patterns in the original system should be preserved in the new, service-based system. In order to identify workflow patterns that need to be preserved, these can easily be identified due to their implementation as operators in the notation. The specification of architectural Client-Dispatcher-Server design pattern in Fig. 3 is based on workflow patterns. Learner Delivery

= =

Coach

=

304

repeat ( reqEducServ = inv reqCon ();res = inv reqEducServ (resId) ) inv rgstEducServ (id); repeat ( rcv acceptCon(c); rcv reqEducServ (s); rep reqEducServ (run(s)) ) choice ( choice ( rcv rgstEducServ(id); rcv unrgstEducServ (id) ) repeat ( rcv reqCon (); let c = getChannel () in par ( inv acceptCon (c); rep reqCon (c) ) ) )

IADIS International Conference on WWW/Internet 2005

with client ’Learner’, server ’Delivery’, and dispatcher ’Coach’ describes the educational service registration and provision based on Client-Dispatcher-Server pattern. The client is based on a sequence of activities. The dispatcher is based on choice in the first part, and a concurrent split and merge in the second part. The reconstructed architecture is the transformation basis. The integration of specifications of the identified existing or created services forms the transformed architecture.

4.4 Implementation for the Web Services Platform Implementation languages are accepted and tool-supported WSF-specific languages such as WSDL or BPEL4WS. Another architectural transformation – of workflow patterns – can take place when the final represenation is generated and the system is implemented on the target platform. For instance, choice ( A, B, C, par (A,B), par (A,C), par (B,C), par (A,B,C) ) is an equivalent workaround that is needed if the implementation language does not support the multichoice pattern mchoice(A,B,C). The multichoice pattern is typical, but is not supported by all BPEL4WS implementations [15]. The workaround simulates the multichoice pattern. Annotation, is as already pointed out, important in the context of re-engineering for SOAs, but is, however, beyond the scope of this paper.

5. CONCLUSIONS AND FUTURE WORK Migrating software to a new platform or paradigm is often desirable (e.g. for competitiveness reasons) or necessary (e.g. for interoperability reasons). The recent success of the Web – the Web Services Framework in particular – will see a large number of systems being re-engineered for service-oriented architectures. Our architectural re-engineering framework addresses the conversion from object technology to service technology. A layered architecture model that captures architectural structures at different levels of abstraction is at the core. A calculus – a notation with supporting techniques based on the architecture model – allows the behaviour in architectures to be captured. This is embedded into a process model of reengineering activities such as architectural reconstruction, service identification, architectural transformation, and implementation for a concrete platform. Interaction behaviour and composite processes within the architecture have turned out to be an essential aspect. Re-engineering for service-oriented architectures is, however, different from other re-engineering domains. The subject of re-engineering techniques are architectures. Re-engineering for reuse is an aim. The identification and implementation of services has often the purpose of making these services available to other users. Re-engineering for discovery is an important aspect in this context. In this paper, we have focussed on the technical process of migrating existing software systems to the new Web Services platform based on transforming the underlying system architecture. Re-engineering for discovery – although not covered here – explains one of the central motivations to migrate. It is also a major reason for our specific framework, since re-engineering for discovery has not been sufficiently addressed by other work on re-engineering. Making software available in form of services of broadens the applicability of reusable components and allows software providers to use software service provision as a new source of revenue. With our framework we have identified the core elements of a re-engineering methodology. A number of aspects remain to be addressed. ƒ Architectural (or component) mismatch is a problem that arises if components are assembled in an architecture. In particular if off-the-shelf components are used in the target system, this can be a problem. By using a process calculus notation instead of an architectural description language, the integration of these aspects is easier to address. The objective of this paper was to address the technical foundations of architectural transformation – a complete methodology will be accompanied by a description language based on standardised and widely used notations. We aim here at mapping our calculus a message sequence charts (MSC) notation. ƒ We have focussed on activities related to the architectural transformation by providing a notation for architectural description and calculus-based notions of invariants that implement a correctness criterion

305

ISBN: 972-8924-02-X © 2005 IADIS

for the transformation. Other formal correctness aspects in addition transformation and assembly/mismatch address the correctness between architecture descriptions and their implementations. The consideration of specific issues such as security or maintainability in the re-engineering process has been neglected in our framework. Patterns and reference architectures are already a first step towards maintainability, but software change can entail further problems.

ƒ

REFERENCES [1] World Wide Web Consortium, 2003. Web Services Architecture Definition Document. Web site http://www.w3.org/2002/ws/arch.

[2] L. Bass, P. Clements, and R. Kazman, 2003. Software Architecture in Practice (2nd Edition). SEI Series in Software Engineering. Addison-Wesley. Graham, 1995. Migrating to Object Technology. Addison-Wesley, R.S. Arnold, editor, 1994. Software Re-engineering. IEEE Tutorial. IEEE Press. Sommerville, 2001. Software Engineering - 6th Edition. Addison Wesley. R. Roshandel, A. van der Hoek, M. Mikic-Rakic, and N. Medvidovic, 2004. Mae – A System Model and Environment for Managing Architectural Evolution. ACM Transactions of Software Engineering and Methodology, 13(2):240–276. [7] R. Kazman, S.J. Carriere, and S.G. Woods, 2000. Toward a Discipline of Scenario-based Architectural Evolution. Annals of Software Engineering, 9(1-4):5–33. [8] J. Williams and J. Baty, 2003. Building a Loosely Coupled Infrastructure for Web Services. In Proc. International Conference on Web Services ICWS’2003. [9] C. Peltz, 2003. Web Service orchestration and choreography: a look at WSCI and BPEL4WS. Web Services Journal, 3(7). [10] R. Milner, 1999. Communicating and Mobile Systems: the π-Calculus. Cambridge University Press. [11] W.M.P. van der Aalst, B. Kiepuszewski A.H.M. ter Hofstede, and A.P. Barros, 2003. Workflow Patterns. Distributed and Parallel Databases, 14:5–5. [12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, 1995. Design Patterns: Elements of Reusable Design. Addison Wesley. [13] IEEE Learning Technology Standards Committee LTSC, 2001. IEEE P1484.1/D8. Draft Standard for Learning Technology - Learning Technology Systems Architecture LTSA. IEEE Computer Society. [14] N.Y. Topaloglu and R. Capilla, 2004. Modeling the Variability of Web Services from a Pattern Point of View. In L.J. Zhang and M. Jeckle, editors, Proc. European Conference on Web Services ECOWS 2004, pages 1–14. SpringerVerlag, LNCS 3250. [15] M. Vasko and S. Duskar, 2004. An Analysis of Web Services Flow Patterns in Collaxa. In L.J. Zhang and M. Jeckle, editors, Proc. European Conference on Web Services ECOWS 2004, pages 1–14. Springer-Verlag, LNCS 3250. [16] C. Pahl and R. Barrett, 2004. Towards a Re-engineering Method for Web Services Architectures. In Proc. 3rd Nordic Conference on Web Services NCWS’04. [17] F. Plasil and S. Visnovsky, 2002. Behavior Protocols for Software Components. IEEE Transactions on Software Engineering, vol. 28, no. 11. [18] S.J. Woodman, D.J. Palmer, S.K. Shrivastava, and S.M. Wheater, 2004. Notations for the specification and verification of Composite Web Services. In Proceedings 8th International Enterprise Distributed Object Computing Conference EDOC 2004, Monterey, CA. [19] A. Brogi, C. Canal, E. Pimentel, A. Vallecillo, 2004. Formalizing Web Service Choreographies. In Proc. of First International Workshop on Web Services and Formal Methods, Pisa, Italy. ENTCS.

[3] [4] [5] [6]

306