Aligning Modern Business Processes and Legacy Systems: A Component-Based Perspective (Cooperative Information Systems)

Aligning Modern Business Processes and Legacy Systems A Component-Based Perspective

Willem-Jan van den Heuvel foreword by Michael L. Brodie

Aligning Modern Business Processes and Legacy Systems

Cooperative Information Systems Michael Papazoglou, Joachim W. Schmidt, and John Mylopoulos, editors

Advances in Object-Oriented Data Modeling Michael P. Papazoglou, Stefano Spaccapietra, and Zahir Tari, editors Workflow Management: Models, Methods, and Systems Wil van der Aalst and Kees Max van Hee A Semantic Web Primer Grigoris Antoniou and Frank van Harmelen Meta-Modeling for Method Engineering Manfred Jeusfeld, Matthias Jarke, and John Mylopoulos Aligning Modern Business Processes and Legacy Systems: A Component-Based Perspective Willem-Jan van den Heuvel

Aligning Modern Business Processes and Legacy Systems A Component-Based Perspective

Willem-Jan van den Heuvel

Foreword by Michael L. Brodie

The MIT Press Cambridge, Massachusetts London, England

© 2007 Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. MIT Press books may be purchased at special quantity discounts for business or sales promotional use. For information, please email [email protected] or write to Special Sales Department, The MIT Press, 55 Hayward Street, Cambridge, MA 02142. This book was was set in Times Roman and Syntax by Windfall Software. Printed and bound in the United States of America. Library of Congress Cataloging-in-Publication Data Heuvel, Willem-Jan van den. Aligning modern business processes and legacy systems : a component-based perspective / Willem-Jan van den Heuvel. p. cm.—(Cooperative information systems) Includes bibliographical information and index. ISBN-13: 978-0-262-22079-8 (alk. paper) ISBN-10: 0-262-22079-2 (alk. paper) 1. Management information systems. 2. Information technology. 3. Reengineering (Management). I. Title II. Series. T58.6.H475 2006 658.4 038011—dc22 2006044923 10

9

8

7

6

5

4

3

2

1

To my wife, Karin, and to my parents, Lambert and Mies van den Heuvel, for their love and support.

Contents

Series Foreword ix Foreword by Michael L. Brodie Preface xv Acknowledgments xxi 1

2

3

4

xiii

Software Components 1 1.1 What Components Are (and Are Not) 1 1.2 Interfaces and Components 2 1.3 A Classification of Component Interface Models 4 1.4 Component Interoperability 9 1.5 Business Components 12 1.6 Web-Enabled Components: The Substrate of Web Services Leveraging Legacy Systems 21 2.1 Legacy Systems as Application, Data, and Time Stovepipes 2.2 Managing the Evolution of Enterprise Applications 22 2.3 Legacy Portfolio Analysis 28 2.4 Wrappers, Connectors, Mediators, Adapters 32 2.5 The Landscape of Legacy Wrappers 33 2.6 A Roadmap for Developing Wrappers 37 2.7 Modularizing Legacy Systems 38 2.8 Constructing WSDL/SOAP-Based Wrappers 40 2.9 Wrappers in Action: A Case Study 42

14

22

Developing Enterprise Applications 53 3.1 Loosely Coupled versus Tightly Coupled Networked Enterprises 3.2 Single Organizations 55 3.3 Networked Organizations 59 3.4 Toward a Methodological Framework 67 The Methodological Framework 71 4.1 Overview of the Methodological Framework 4.2 Running Example 74

72

53

viii

Contents

4.3 4.4 4.5 4.6 4.7 5

Forward Engineering 80 Reverse Engineering 88 Matching Phase 93 Adaptation Phase 100 Running Example 101

Matching Phase 103 5.1 Structural Matching 103 5.2 Semantic Matching 116 5.3 Metamodel-Driven Matching

131

6

Adaptation Phase 147 6.1 Component Adaptation 147 6.2 Parametric Contracts 153 6.3 Adapter Generation 161

7

Beyond the Methodological Framework 171 7.1 Alignment as a Continuous Process 171 7.2 Improving the Methodological Framework 174 7.3 Quo Vadis? 176

Appendix: Running Example Notes 189 References 191 Index 203

179

Series Foreword

The traditional view of information systems as tailor-made, cost-intensive database applications is changing rapidly. The change is fueled partly by a maturing software industry, which is making greater use of off-the-shelf generic components and standard software solutions, and partly by the onslaught of the information revolution. In turn, this change has resulted in a new set of demands for information services that are homogeneous in their presentation and interaction patterns, open in their software architecture, and global in their scope. The demands have come mostly from application domains such as e-commerce and banking, manufacturing (including the software industry itself ), training, education, and environmental management, to mention just a few. Future information systems will have to support smooth interaction with a large variety of independent multivendor data sources and legacy applications, running on heterogeneous platforms and distributed information networks. Metadata will play a crucial role in describing the contents of such data sources and in facilitating their integration. As well, a greater variety of community-oriented interaction patterns will have to be supported by next-generation information systems. Such interactions may involve navigation, querying, and retrieval, and will have to be combined with personalized notification, annotation, and profiling mechanisms. Such interactions will also have to be intelligently interfaced with application software and will need to be dynamically integrated into customized and highly connected cooperative environments. Moreover, the massive investments in information resources, by governments and businesses alike, calls for specific measures that ensure security, privacy, and accuracy of their contents. All these are challenges for the next generation of information systems. We call such systems Cooperative Information Systems, and they are the focus of this series. Cooperative information systems are serving a diverse mix of demands characterized by content, community, and commerce. These demands are origi-

x

Series Foreword

nating in current trends for off-the-shelf software solutions, such as enterprise resource planning and e-commerce systems. A major challenge in building cooperative information systems is to develop technologies that permit continuous enhancement and evolution of current massive investments in information resources and systems. Such technologies must offer an appropriate infrastructure that supports not only development but also evolution of software. Early research results on cooperative information systems are becoming the core technology for community-oriented information portals or gateways. An information gateway provides a one-stop-shopping place for a wide range of information resources and services, thereby creating a loyal user community. The research advances that will lead to cooperative information systems will not come from any single research area within the field of information technology. Database and knowledge-based systems, distributed systems, groupware, and graphical user interfaces have all matured as technologies. Further enhancements for individual technologies are desirable, but the greatest leverage for technological advancement is expected to come from their evolution into a seamless technology for building and managing cooperative information systems. The MIT Press Cooperative Information Systems series will cover this area through textbooks and research editions intended for the researcher and the professional who wishes to remain up-to-date on current developments and future trends. The series will publish three types of books: Textbooks or resource books intended for upper-level undergraduate or graduate courses;

.

Research monographs, which collect and summarize research results and development experiences over a number of years;

.

.

Edited volumes, including collections of papers on a particular topic.

Authors are invited to submit to the series editors book proposals that include a table of contents and sample book chapters. All submissions will be reviewed formally, and authors will receive feedback on their proposals. Michael Papazoglou [email protected] INFOLAB P.O. Box 90153 LE Tilburg The Netherlands

xi

Series Foreword

Joachim W. Schmidt [email protected] Software Systems Institute Technische Universit¨at TUHH Hamburg, Germany John Mylopoulos [email protected] Dept. of Computer Science University of Toronto Toronto, Ontario Canada

Foreword Michael L. Brodie

“There’s gold in them thar hills,” the assertion that begins many an ill-fated cowboy story, also applies to legacy information systems. Legacy components may contain genuine value. More often enterprises resist the investment to rewrite or migrate legacy systems, thus putting at risk the business that the systems support since the business is forced to align to the system and not vice versa. This barrier, previously insurmountable for many enterprises, is being overcome by methods such as those presented in Aligning Modern Business Processes and Legacy Systems: A Component-Based Perspective. In the early 1990s, when client/server was the hot IT trend, Michael Stonebraker and I did not believe the many claims of successfully migrating legacy mainframe systems to client/server. Determined to understand the challenges and successes, we investigated some very large migrations attempted in banking and telecommunications. As is often the case with hot IT trends, we found that the claims of easy legacy system migrations were exaggerated. Indeed, significant technical and cost challenges that we found then remain to this day. We reported our understanding of the problem and a migration strategy in 1995’s Legacy Information Systems Migration: The Incremental Strategy. At that time, the focus was on information systems interoperation, one-time migrations, and on three dominant challenges of database migration, semantic heterogeneity, and engineering idiosyncratic system interfaces. Now, a decade later, the emerging technology—Web services and serviceoriented architectures (SOA)—and the emerging development paradigm— continuous refinement of business processes via the composition of existing components—significantly increase the need to reuse legacy components. In Aligning Modern Business Processes and Legacy Systems, Willem-Jan van den Heuvel gives a comprehensive description of the new paradigm of continuous improvement of business processes using software components and provides a detailed methodology to achieve the objectives. The paradigm and the methodology will appeal to both practitioners and researchers. For computer scientists

xiv

Foreword

and those wishing to understand the deeper technical challenges, he identifies the core technical challenges and the solutions used in the methodology. These challenges place in perspective the current hype and exaggerated claims for SOA. Over the past decade, systems development, and the reuse of legacy systems, has been reformulated with some challenges overcome and some challenges remaining. This book reformulates the problems in the new paradigm and addresses the outstanding challenges. The focus of information systems development has shifted up from interoperation at the systems level to the development and continuous improvement of business processes. Van den Heuvel provides a methodology for mapping evolving business processes onto legacy and new components, which he illustrates with a running example, down to the code level. While database migration has become dramatically easier, semantic heterogeneity remains significant. A business process, defined in a business processing language, invokes functions in application components. In the new development paradigm if an existing applications component does not meet the requirement, a composite application is created by modifying and reusing existing application components. Hence, development requires the discovery of components to meet the requirement and the composition of the components to form the composite application. The author describes the relevant semantic challenges and provides a solution within his methodological framework. Finally, one of the most costly aspects of reusing legacy components is addressing the idiosyncratic aspects such as hand-coded interfaces, unique database designs, and very specific solutions, none of which are addressed by and which stand in the way of taking advantage of technology advances. The author reviews both these challenges and their solutions, and incorporates them into his methodology. As so clearly stated in the title, Aligning Modern Business Processes and Legacy Systems, systems must be aligned with evolving business processes. The book provides a methodology to achieve this alignment. It provides the practitioner and the researcher a comprehensive description of and methodology with which to align business processes with legacy systems, starting with business processes that are then mapped down onto existing software components in a continuous process as business requirements change, leading to continuous business process refinement and in turn reuse of existing, sometimes legacy, components. It provides researchers with a description of the key challenges and poses future directions. Van den Heuvel’s methodology is far more practical and useful than the legacy migrations of a decade ago. The book is highly informative.

Preface

We have embarked on a exciting era of developing enterprise applications based on assembling business components into electronic business processes that interact via the Internet. This contemporary paradigm for developing enterprise applications is rapidly gaining momentum in the business community. Enterprise applications built using earlier software-development paradigms focused almost exclusively on internal business processes. However, enterprise applications built using this emerging development paradigm are progressively encoding cross-organizational business processes. Coupled with the Internet, business component computing is believed to be able to create a class of enterprise applications that is flexible and relatively easy to maintain, upgrade, and integrate. This up-and-coming breed of enterprise applications brings a realm of tantalizing possibilities for highly competitive business models, for instance, integrated virtual supply chains that treat business software components as business processes, and vice versa. While trying to move to this arena, many brick-and-mortar companies are hindered by their heritage of stovepipe1 enterprise information systems, which are typically large, heterogeneous, and mission-critical systems. Unfortunately, it is commonplace that these inherited enterprise systems are strongly intertwined with existing business processes and policies. Although this allows efficient operations, it severely hinders their alignment with novel, integrated business processes. The replacement and renovation of these systems, most of which have become legacy systems with the passage of time, has proved to be a complicated, time-consuming, expensive, and risky endeavor (Brodie and Stonebraker 1995). These systems are tightly coupled to the business workflow and suffer from a rigid and contrived architecture that results from many years of ad hoc patching and fixing, and that offers very limited openness to other systems. Given this situation, organizations are facing an unenviable dilemma. On the one hand, they want to get rid of their legacy systems as soon as possible in order to be able to align their enterprise systems with new processes. On the

xvi

Preface

other hand, legacy applications and repository systems are considered important enterprise assets, harboring significant investments in enterprise data and policies already at hand. Business processes often critically depend on the permanent availability of these legacy systems. Hence, one cannot annihilate the investments and simply replace legacy systems with new business applications. Motivation for This Book

Since the client/server days of the 1980s, several legacy evolution strategies have been developed to overcome the legacy dilemma. The four most prominent ones are encapsulation/integration, data warehousing, “Cold Turkey” (replace at once, or rip and replace), and the gradual migration approach (Umar 1997; Brodie and Stonebraker 1995; Wilkes 1999). The encapsulation/integration strategy, sometimes referred to as the access/integration in-place strategy, is the strategy of choice when legacy systems hold valuable and up-to-date assets that should be leveraged in the next generation of enterprise information systems. This strategy is empowered by contemporary distributed software component technologies allowing legacy systems to be componentized. In particular, component wrappers, also called wrappers or legacy components, are used to encapsulate legacy systems in an interface layer exposing internal legacy programs, transactions, and data to external software components (Comella-Dorda et al. 2000). In this way, component wrappers enable sharing and conservation of the legacy systems and at the same time allow them to be aligned with new business process requirements. Despite the fact that existing legacy wrapper approaches and tools have been applied successfully in integrating existing legacy applications and repositories with new application components, they suffer from several major drawbacks: They are oriented toward legacy systems, but not business processes. In today’s practice, most component-wrapping approaches exploit programming logic and data that are encapsulated in legacy enterprise systems, largely neglecting requirements imposed by new business processes in the business domain. These approaches are typically oriented toward realizing technical integration between new applications and legacy systems with virtually no regard for the new business process requirements that the legacy systems are supposed to facilitate.

.

Legacy code and data cannot be reused as is. Existing component-wrapping solutions are typically based on the assumption that new processes and applications may be developed in terms of legacy systems with minor adjustments

.

xvii

Preface

to the legacy data and functionality to make them accessible to external resources. This assumption is not realistic because legacy systems are geriatric systems that implement partly outdated business processes and policies. In addition, their large-grained nature make them inappropriate building blocks for composition into consistent and cohesive business processes. Existing component-wrappting approaches usually seek to integrate legacy systems with new business applications in a purely bottom-up manner without taking into consideration alignment with new top-down engineered business process requirements.

.

Finally, and most important, any effective approach to aligning new business processes with componentized legacy systems must be methodologyoriented. A symmetric, component-based alignment methodology that combines bottom-up reverse engineering of legacy systems according to the encapsulation/integration strategy with top-down design of business processes is required.

.

Goals of This Book

The alignment of business processes with information technology has often been studied from a rather abstract vantage point that is believed to provide insufficient guidance to architects and designers of business processes and applications (Henderson and Venkatraman 1993; van Eck, Blanken, and Wieringa 2004). It is the main aim of the methodological framework presented in this book to offer a body of pragmatic methods and techniques to assist in aligning business processes and legacy systems. This methodological framework resulted from an extensive review of the scientific literature, and it has been tested in various experiments and realistic case studies, which are drawn from a large real-world project at the Dutch DoD. The methodological framework addresses the drawbacks of many contemporary techniques. In particular, it is designed to combine bottom-up reverse engineering approaches with top-down business process engineering methods, introducing a meet-in-the-middle approach that is capable of aligning new business processes with legacy systems. This alignment is facilitated by a sophisticated process of comparison and adaptation to ensure the processes and systems (continue to) fit. Hence, alignment starts with a thorough understanding of the relationship between business requirements and available information technology capabilities. One important aspect of alignment is to identify gaps and matches, after which new software may need to be constructed to fill gaps and to integrate

xviii

Preface

with reusable information technology resources. Both issues are addressed in the methodological framework. Ulrich (2002) discusses management-related issues in the alignment of legacy systems with new business processes, which concern governance and communications across line-of-business organizations and information technology organizations. The communication and governance techniques discussed by Ulrich may be used to embed the methodological framework into an organization. Another approach that is related to the methodological framework is outlined by Seacord, Plakosh, and Lewis (2003). This entails a risk-managed modernization approach, including activities such as defining a business case, understanding the legacy system and target technology, devising a deployment strategy, and working toward a modernization plan that helps to mitigate risks during the actual modernization activities. This approach is complementary to the methodological framework of this book in that it may assist in those activities that take place before the actual modernization and alignment of legacy systems and business processes. The global architecture underlying the methodological framework is depicted in figure 1. It is made up of three building blocks: reverse engineering, forward engineering, and alignment. Reverse engineering is concerned with gaining an understanding of legacy programs and repositories, and defining component wrappers that encapsulate them into a software layer so that they look and behave like components. Wrappers resulting from this phase are depicted as parallelograms in the bottom tier of figure 1. Forward engineering derives a set of business components from the requirements of new business processes. These components are depicted as chevrons in the top tier of the figure. Alignment of to-be business processes and as-is legacy systems implies that legacy components that have significant overlap with new business requirements (e.g., required services) are mapped to new business components, signifying that these business components reuse the functionality of the legacy components. Remaining legacy components can be ignored. In figure 1, mappings between business and legacy components are illustrated with dotted lines connecting components in the top and bottom tiers. The mappings often include some adaptation to make the interfaces of legacy components and business components compatible, for instance, overcoming a semantic interoperability problem. In the figure, harmonization of processes with systems is realized by aligning four out of six required business components with preexisting legacy components (dark gray chevrons in alignment layer). Business components that cannot

xix

Preface

Figure 1 Alignment methodology adopts a meet-in-the-middle paradigm.

be aligned with legacy systems may alternatively be supported by packaged software solutions or commercial off-the-shelf (COTS) components. For example, the white chevron in the alignment layer represents two business processes that were fused to allow implementation by a packaged software solution. In this case, alignment was achieved by changing the two business processes to meet the reality of the services provided by the packaged solution. Organization of This Book

This book covers a wide range of multidisciplinary topics from the fields of software engineering, component-based development, reverse engineering, information retrieval, and business process modeling. Chapters 1–3 establish the theoretical foundations of the methodological framework. Chapter 1 introduces component based development in general

xx

Preface

and business component development in particular. Chapter 2 elaborates the rationale of the framework, surveying existing legacy evolution strategies and technologies. It seeks to familiarize readers with legacy components, and it introduces a case study that is used throughout the book as a running example to illustrate and explore the methodological framework. Chapter 3 assesses integration problems for single-enterprise or cross-enterprise business processes and explains how integration is used to achieve alignment within the framework. Chapters 4–6 describe and develop the methodological framework. The main workings of the framework are illuminated in chapter 4. The next two chapters concentrate on two critical phases: matching enterprise models of to-be processes with models of as-is legacy wrappers (chapter 5) and adapting business components and legacy components to align them (chapter 6). Chapter 7 summarizes the main findings and remaining open issues regarding the methodological framework, and outlines a research agenda for the future.

Acknowledgments

This book in its present form would not have been possible without the participation of many friends and colleagues who helped me in debating and elaborating ideas, developing some prototypical case tools, and reviewing several early drafts. I thank Ralf Reussner (Oldenburg University) who contributed to several chapters in this book. His knowledge of component-based development and component adaptation proved of great value in the development of the final phases of the methodological framework. I gratefully acknowledge many colleagues who discussed, reviewed, and otherwise contributed to the book, including Frans Laurijssen (Tilburg University), Jian Yang (Macquarie University), Willi Hasselbring (Oldenburg University), Manfred Jeusfeld (Tilburg University), Jos van Hillegersberg (Twente University), Cory Casanave (Data Access Technologies), and Bernd Kr¨amer (Fern Universit¨at) and Bas van Gils (Radboud University). I am particularly indebted to the series editor, Mike Papazoglou, for getting me started. He guided and inspired me throughout the process of writing this book. Thanks to the following people for their reviews: Hans Weigand and Alea Fairchild (Tilburg University). Special thanks for the detailed comments of Howard Hess (IBM), who helped me tighten the writing. Also, thanks to anonymous reviewers whose comments helped to improve the quality of the manuscript. The case study used throughout this book was developed in close collaboration with the Dutch Department of Defense and its Telematics Agency (DTO). I would particularly like to express my thanks to Jeff van Leeuwen of DTO for opening many doors within the Department of Defense. Also, my thanks to Jacques Polack and Jur Huisman for their assistance in developing early versions of the case study.

xxii

Acknowledgments

A considerable part of the manuscript was written when I was a visiting professor during the winter of 2003–04 at Trento University, Italy. Thanks to Marco Aiello, Vincenzo D’Andrea, Paolo Traverso, and Maurizio Marchese for hosting my visit and kindly supporting my work on the manuscript while providing a highly creative and stimulating environment. Last but not least, I would like to express appreciation to everyone at MIT Press involved in the production of this book. Special thanks to my editor, Douglas Sery, for his patience and support throughout the writing process, and to Valerie Geary and Deborah Cantor-Adams for their professional assistance in preparing the manuscript for publication.

Aligning Modern Business Processes and Legacy Systems

1

Software Components

“Software components are for composition” (Szyperski, Gruntz, and Murer 2002). While the debate about what exactly constitutes a component is ongoing, this statement highlights the central quality of a component: it is a reusable asset to be composed with other prefabricated components. In fact, packaging software as reusable components and subsequently assembling them into applications has been a much sought-after goal of the software industry for many years. This software development model was first proposed by McIlroy during the conference on software engineering in 1968 (McIlroy 1969), but it was not until the end of the 1990s that software components started to be more widely used to assemble not only internal business applications but also prefabricated software for external customers. For instance, a growing market developed for Enterprise Java Beans (EJB) and .NET components (Traas and van Hillegersberg 2000). This chapter explores the concept of a software component, concentrating on component interfaces and contracts. In addition, it provides an overview of a special category of software components—business components—that make up the core of enterprise models produced during the forward engineering phase. 1.1

What Components Are (and Are Not)

Definitions of software components range from “anything which is reusable” (Hooper and Chester 1991) to “exchangeable parts of a framework” (Pree 1997). Others conclude that the concept of a component is indefinable (Czarnecki and Eisenecker 2000). Instead of providing yet another definition of a software component, this book adopts that of Szyperski and colleagues (which is widely accepted): components should be composable, simultaneously running software resources. With contributions by Ralf Reussner.

2

Software Components

Components are not equivalent to an object or a class. In fact, the essential characteristic of composability makes a component different from a class. Generally, classes are conceptual entities created to structure the system during the requirements and design phase of a software engineering project. Although they may also be used to implement the system, there exists no critical requirement that they be accessible from outside the system after delivery. Classes thus constitute design entities, whereas components are generally perceived to be physical entities for packaging, updating, reconfiguring, and billing (Szyperski, Gruntz, and Murer 2002). This means components should be accessible and pluggable entities that may be assembled and deployed into systems. Objects and classes do not have these characteristics unless special efforts are made to render them reusable. Nierstrasz (2004) articulates this crucial difference as follows: “Components are plugged, while objects are wired.” Unfortunately, an important technique to create and reuse classes, namely inheritance, does not support plugging mechanisms. A subclass usually has tight dependence on its superclass owing to attribute and code inheritance. This is the main reason that components implement interfaces but refrain from using code inheritance. However, inheritance as implemented in most objectoriented languages mixes several different concepts, such as substitutability, code inheritance, and specialization (Meyer 1997), so one dominant feature of class inheritance goes hand-in-hand with component plugging: substitutability (subtyping). From a reuse perspective, it is of vital importance to have at least syntactical means to denote that a component is substitutable by another. The notion of substitutability is crucial in the context of reusing (fragments of ) existing components for new systems. 1.2

Interfaces and Components

An important trait of component technology is its explicit separation of the interface from the implementation of a component. This separation of interface and implementation is also known as information hiding (Parnas 1972), where the interface specifies the public parts of a class and the implementation its hidden parts. Interfaces can exist and evolve independently from components. In particular, an interface can be associated with a component by two kinds of relationships. First, a component can implement an interface. In this case, the interface describes the abstract services provided by the component. This type of interface is often referred to as a provided interface, and the relationship between the component and the interface is called a provided relationship or an implements relationship.

3

1.2

Interfaces and Components

component Prognosis deterministicPlanning use deterministicPlanning

stochasticPlanning use stochasticPlanning

component MRP scheduleMasterProduction Figure 1.1 Provided and required interfaces of the component MRP.

Second, a component often requires an interface that is offered by another, potentially external component. This type of interface explicates which external services are consumed by a component. Such an interface is called a required interface, which is related to the component by a required relationship. An interface may act as the provided interface of one component and simultaneously as the required interface of another component. It may even happen that an interface acts as a required and a provided interface of one component at the same time. This can be the case for quality-of-service adapters, which increase service properties such as reliability and availability by using replication mechanisms. A component may advertise its interfaces, playing different roles in the relationship to other components. Roles allow a client component to invoke only those interfaces that are associated with a particular business process. In this way, complex interactions between components during the course of a business process may be streamlined, adopting the complexity-reducing principle of separation of concerns. For example, the component Inventory may implement a set of interfaces enabling the role Tracking and Tracing and another class of interfaces to support the role Ledger. Then a client component, let’s say Procurement, might only call interfaces associated with the role Ledger while executing this process. Similarly, a component can require different required interfaces that are grouped as a collection of required roles. UML 2 component diagrams account for this separation of components and interfaces by introducing special notation for rendering components and provided and required interfaces. Figure 1.1 depicts a simple component diagram modeling two components, Prognosis and MRP (Materials Require-

4

Software Components

ments Planning). The MRP component produces a materials-planning scheme that optimizes resource use and decreases delivery times and inventories. For planning future materials needs, it uses the functionality of the component Prognosis. Prognosis advertises two interfaces, deterministicPlanning and stochasticPlanning, which are two variants for planning materials requirements. These provided interfaces are graphically represented using a lollipop symbol (a circle or an ellipse). The MRP component implements one provided interface, scheduleMasterProduction, and defines two required interfaces that are synonymous with the two provided interfaces of the Prognosis component. This use dependence is represented using a realization relationship. The required interfaces are represented graphically using sockets (half circles). 1.3

A Classification of Component Interface Models

The prime goal of component interfaces is to guarantee interoperability between components. Interoperability refers to the ability of components to collaborate with each other, assuming compatibility not only of their interfaces but also of their run-time behavior and nonfunctional properties. Based on their ability to overcome potential interoperability conflicts, we may conceptualize interface models in a layered architecture comprising three layers, including signature lists at the lowest level, protocols at the intermediate level, and quality-of-service interfaces at the highest level of abstraction. The architectural model underlying the classification of component interface models is depicted in figure 1.2. The interface models are organized in such a way that metadata defined in an interface of a lower level should be guaranteed before metadata captured in the adjacent higher level are checked. 1.3.1

Level 1: Signature List-Based Interface Models

Interfaces implemented in middleware platforms or programming languages have in common that they enumerate signatures of services. A signature describes an abstract function, which may be either offered or required by a component. In particular, signatures typically encompass the following elements: .

Name

.

Return type

Ordered list of parameter types (or just parameter names in case of an untyped language)

.

A Classification of Component Interface Models

d Interfa ase ce

M od

el

Pro to c

Signature Based Interface Models

Quality Based

od

In te

eM

sed Ba odel

Interf ac e

erface Model Int d se Prot el oc od M

B

Interfa ce

M

ol

Based

el

Q

lity ua

c rfa

1.3

ol

Qua li t y

Ba

5

Figure 1.2 Three levels of interface models.

Set of possibly thrown exceptions (if such an exception construct exists in the language)

.

.

Precondition and postcondition (if supported by the language)

A signature list-based interface model thus defines interfaces as a list of signatures. An example of a signature list-based interface is given in the following excerpt, which contains a Java interface defining two signatures, DebitClientAccount and DebitCreditCard: interface Payment { void DebitClientAccount (ClientAccount ca, Invoice inv) throws InvalidClientAccountException, LowClientAccountException; void DebitCreditCard (Client c, Invoice inv) throws InvalidClientException, RejectedCreditCardTransactionException; }

Signature list-based interfaces make up the oldest category of interfaces, which were used in the 1970s by Parnas (1972) and implemented in older languages including ALGOL or Modula. More recent examples of languages adopting this interface model include the CORBA interface description language, Java, C#, and .NET. Ignoring pre- and postconditions for a moment, note that elements of signatures pertain to functional properties of one single service. In case of a provided

6

Software Components

interface, this implies that a signature specifies how to call a service by prescribing its function name and allowed (types of ) parameters to which client components should adhere. In addition, the signature defines the return type, typifying the expected result, and exceptions. Hence, signatures are not capable of capturing any relationship between signatures. Because interfaces often contain several interrelated signatures, a description restricted to single signatures tends to fall short at specifying the semantically richer, dynamic aspects of the interface. This impediment is addressed by the next level of interfaces. 1.3.2

Level 2: Protocol Modeling Interface Models

Protocol models of interfaces state protocol dependencies between individual signatures in order to avoid run-time interoperability conflicts. Protocol dependence refers to a logical dependence affecting the availability of signatures according to prior calls to signatures, or it may command the use of signatures according to prior signature calls. This implies that these dependencies restrict the sequences in which the services of a provided interface can be called. Alternatively, protocol dependencies stipulate the sequence in which services of a required interface may be called. In case of provided interfaces, the sequence of service calls complying with all protocol dependencies is called a valid sequence. For required interfaces, this is called a possible sequence. The set of all valid sequences is called a provided protocol; the set of all possible sequences is called a required protocol. Practically speaking, the specification of these protocols has to deal with situations in which these protocols are infinite sets. In fact, this occurs in many real-world contexts because often there exist infinitely many valid sequences of signatures to be executed. As an example of infinitely many valid sequences, consider a product catalog component in which one may either search (for products) or read (product descriptions): open-read-close is as valid as open-read-read-close, and so on. Therefore, any protocol-modeling notation must be able to specify an infinite number of sequences with a finite representation and must allow algorithms to check inclusion of protocols within finite time. Different formal notations can be used for protocol specification: Finite state machines (FSMs) are good candidates for protocol specification. They formalize protocols by taking the language, defined as a set of words and recognized by the state machine, as a set of sequences, where a method call refers to a symbol of the word. In contrast to most other automata models, FSMs have the advantage of allowing the inclusion of protocols to be checked in

.

7

1.3

A Classification of Component Interface Models

finite polynomial time. For that reason, finite state machines were successfully used for protocol specification in general (Holzmann 1991) and for modeling component protocols in particular (Nierstrasz 1993; Reussner 2000; de Alfaro and Henzinger 2001). Because this technique is both simple to understand and formal, we apply FSMs to illustrate protocols in the remainder of this book. Petri nets are designed to model concurrent sequences, for example, workflows or distributed processes. Compared to finite state machines, the state space may be represented in a more compact manner. However, only restricted versions of Petri nets can be translated into finite state machines and checked for inclusion. Nevertheless, they have been successfully deployed for protocol modeling (van der Aalst et al. 2002; Ling, Schmidt, and Fletcher 1999).

.

Process calculi originally were designed to model the interactions between concurrently operating processes (Hoare 1985). Nowadays, process calculi is also applied to specify component interactions (Bracciali, Brogi, and Canal 2002). However, regardless of which of several versions is used, process calculus does not allow efficient checking of inclusion, being rather poor for interoperability checks.

.

Equipping each signature with a precondition and a postcondition, as proposed by Meyer’s (1992) design by contract principle, allows an implicit specification of protocols. The precondition of a signature is a predicate explicitly stating the assumptions that a service can make about its caller (e.g., which services have been called before). A postcondition denotes a predicate stating on which effects of a service execution the caller can rely (Zaremski and Wing 1997).

.

FSMs may be applied for modeling both provided and required protocols. Abstractly speaking, input symbols (strings that can trigger changes to a state) are derived from signature names. If, after having executed a signature call, the set of executable services (signatures) of the component changes, the FSM changes its state. In other words, each state of the FSM reflects the set of callable services. For example, for a product catalog, there are two sets of callable services: {open} and {read, find, close}. Figure 1.3 depicts the corresponding states and transitions of this state machine. Two states are defined: q0 = {open} and q1 = {read, find, close}. After instantiation of the catalog, one can only call open, so q0 is the start state. If open is called in q0 , all other services get enabled. Hence, whenever the transition (q0, open, q1) ∈ T occurs, the FSM moves to state q1. Calls to either read or find in q1 do not cause any changes in the set of executable services, and the FSM stays in state q1. Finally, a call of close

8

Software Components

Provided Protocol Product-Catalog

read,find open q0 = {open}

close

q1 = {read, find, close}

Figure 1.3 The provided protocol of a product catalog.

from state q1 brings the FSM to a state of the catalog where only open can be executed; hence the FSM moves to state q0. Even if an interface model is capable of specifying both the signatures and the (provided and required) protocols, vital information is lacking. For components to interoperate successfully, it is critical that quality-related information about components be explicitly declared in the component’s interface. 1.3.3

Level 3: Quality Interface Models

Quality of software manifests itself in many facets. Most often, quality attributes are synonymous with nonfunctional properties that define the restrictions of software functionality. Hence, quality-related properties may be seen as metadata about functionality. One may distinguish between quality attributes that are externally visible, such as reliability, performance, and availability, and those that are internal, such as reusability of code or designs, maintainability, and readability. In a component interface model we are concerned with externally visible quality attributes. They can constrain the behavior of a single service or a set of services. The first category is also referred to as quality of service, for instance, the reliability or performance of a service. The quality attributes pertaining to a set of services are collectively determined by single services, resulting in emergent behavior. Such quality attributes are difficult to quantify and thus are not incorporated in the component interface. Quality attributes modeled in interfaces thus have the following characteristics. They are externally visible, concerned with services, and quantifiable. In some cases, quantifiability is lifted to allow fuzzy attributes, for instance, cardinal values characterized as high, medium, low. A prominent language for modeling quality attributes is QML (qualityof-service modeling language), introduced by Frølund and Koistinen (1998).

9

1.4

Component Interoperability

QML suggests a syntax for defining quality dimensions, or contract types (e.g., response-time in μsec), and quality contracts (e.g., response time below 250 msec.), and for binding such contracts to specific services. 1.4

Component Interoperability

Interoperability refers to the ability of components to cooperate regardless of the platforms on which they are executed, the distribution of the network nodes, the network infrastructure, or the languages in which they are programmed. For components to be composed, it is of critical importance to avoid any potential interoperability error. This implies that interoperability needs to be ensured not only at the level of required and provided interfaces and protocols but also at the level of the middleware platforms. The latter level of interoperability is typically referred to as technical interoperability, whereas the first level tends to deal with semantic interoperability. Unfortunately, the terms syntactic or technical versus semantic are heavily overloaded and used with varying meanings. Historically, any specification beyond the signature level was often considered semantic because signatures were specified in programs and were analyzed by a type checker, and no syntax was available for specifying protocols and quality attributes. As research progressed, new languages like QML and PROCOL (van den Bos and Laffra 1989) offered additional syntactical constructs for specifying quality of service and protocols. This has blurred the boundary between what exactly constitutes syntactic and semantic information. 1.4.1

Technical Interoperability

Technical interoperability is the capability of components to interact despite the fact that they are running on different hardware and software platforms. Technical interoperability problems may arise from the following causes: Different hardware encoding formats Different hardware platforms can encode data differently (e.g., little endian versus big endian for integers, or sevenbit ASCII versus unicode for characters). Usually, hardware-specific data formats are shielded from the application programmer by a layer of programming language libraries or middleware offering standardized access. However, in the rare cases when directly reading from memory or mass storage, one has to consider these different storage formats.

.

Different languages When integrating legacy systems with recent software products, one inevitably finds different programming languages that do not

.

10

Software Components

communicate. While newer programming languages such as Java offer the possibility of calling code written in the older C language if it follows certain conventions, older languages usually do not offer a standardized way to call code written in a newer language. Different middleware platforms From an abstract vantage point, different middleware platforms, including platforms supporting transaction management, database connectivity, message-oriented middleware, and communication brokers, pose the same kinds of problems that different languages do: code on one platform cannot invoke code running on another. In practice, bridges exist to enable tunneling method calls of one platform to another, for instance, COM to CORBA (Rosen and Curtis 1998) or J2EE to CORBA (Harkey and Orfali 1998).

.

1.4.2

Signature Interoperability

Recall the definition of a signature given in section 1.3.1. A signature specifies name, return type, parameter types and ordering, and a set of possibly thrown exceptions. Signature interoperability problems may occur because of syntactic or semantic incompatibility of parameter or result types. Whereas semantic interoperability refers to the ability of components to interpret each other’s vocabulary used in the interface, syntactic interoperability of signatures signifies compatibility of the data types of input parameters and result types. For exploring signature interoperability errors, I consider here a hypothetical required interface of a component A declaring the signatures of another component B that it imports. The following classes of syntactical signature interoperability errors are distinguished: Wrong return type The result returned by the service of B cannot be processed isomorphically by component A.

.

Missing return type This class of interoperability error includes a special case of a wrong return type (void is the bottom element in the type hierarchy). A expects a function, whereas B provides a procedure. Either B has a call-byreference parameter returning the result, or another service of B can access the result.

.

.

Wrong parameter type A fills a parameter of B’s service with a wrong type.

Missing parameter vided by A.

.

B’s service requests an additional type that is not pro-

11

1.4

Component Interoperability

Wrong parameter order the wrong order.

.

Additional exception by A.

.

1.4.3

A provides all parameters as requested by B but in

The provided service can throw exceptions not caught

Protocol Interoperability

As discussed in section 1.3.2, a component’s provided protocol is the set of all valid sequences of calls to services provided by the component. Correspondingly, a component’s required protocol is the set of all possibly emitted sequences of calls to external services. Protocol interoperability refers to the ability of two components, A and B, to cooperate, given the provided interface of component B and the required interface of component A. A protocol interoperability error occurs when the request of at least one call sequence declared in the required protocol of component A is not allowed according to the provided protocol of component B. The request for a nonsupported call sequence s may arise from various causes: Missing service calls The sequence s contains a call to a service not provided by B. Informally, A expects B to provide more. This kind of error is a consequence of a signature interoperability error.

.

Superfluous service calls The sequence s describes the right order of service calls to B, but B expects additional calls to be able to process the service calls of A according to its provided protocol. Hence, B expects A to call more.

.

Reversed service calls The sequence s contains at least two service calls s1, s2 (in that order), which B’s provided protocol specifies should be called in reversed order. .

1.4.4

Quality-Related Interoperability

Quality-related interoperability errors occur if component A depends on specific quality attributes of external services, and these services fail to deliver the requested functionality. Based on this definition, interoperability errors can occur for the following two reasons: Different quality dimensions The required interface of component A regards the quality dimension “reliability” as the success probability of a service call, whereas component B adopts another definition, measuring “reliability” as Mean Time Between Failures (MTBF).

.

12

Software Components

Dissimilar quality values When it is assumed that A and B adopt equivalent quality dimensions, incompatibilities can arise if B’s service implementation does not deliver the quality A needs. For example, A requests a service f to have a reliability of 10−5, but B only specifies f as having a reliability of 10−4 (given in both cases as failure probability). .

1.5

Business Components

A specific breed of components, called business components, is generally perceived as being ideal building blocks for implementing business applications and leveraging new business process requirements. Before giving an overview of business components, I give a brief description of the precursor to business component technology. 1.5.1

The Business Object Heritage

Business objects embody a distinct category of objects conveying business semantics, such as invoice, bill, purchase requisition, and purchase order. Hence, business objects are still objects. This implies that business objects exhibit, just as other objects do, characteristics such as encapsulation, polymorphism, and inheritance. However, business objects do not tend to support peripheral tasks, including support for distributed communication (e.g., communication protocols) and security (e.g., encryption). Instead, this class of objects implements core processes that support the existence of enterprises. Business objects are equipped with dynamic and static properties, reflected in their methods, attributes, and relationships. The attributes of business objects reflect their key properties and can only be accessed, modified, and removed through a shell of business methods. Attributes thus constitute the main static, or structural, properties of a business object. This does not mean that these properties do not change. On the contrary, they are constantly checked and updated by associated business objects. The attributes a business objects can only be modified through their operations, which are also called their methods. Methods implement the capabilities of a business object, and all together they constitute its behavior. The behavior of an object can be modeled as a set of finite state machines that define how an object behaves when receiving an event from another object and moves from one state to the next. State transitions are subject both to pre- and postconditions, as well as invariants, to ensure proper operation. The collection of state transition rules of a business object, its protocol, denotes its life cycle. Traditionally, only the provided protocol of business objects is considered, neglecting the required side.

13

1.5

Business Components

Business objects may be conceptual (analysis objects, design objects) as well as implementation constructs (e.g., Java classes (Eeles and Sims 1998)). Conceptual business objects can be perceived as the main fabric of enterprise models because they are able of faithfully reflecting business artifacts and processes. Enterprise models capture business processes, recourses, people, goals, policies, and constraints within an enterprise. Hence, these models aim to specify the business rather than a software artifact. Chapter 4 investigates enterprise models in more detail. Implementation-oriented business objects are usually isomorphically derived from conceptual business objects, which means that they are ideally mapped on a one-on-one basis from the enterprise models to their implementations. Typically, the implementation of a business object comprises two other logical tiers while promoting a separation of concerns, namely, the view and control layer. This architecture is known as the model-view-control pattern. In that respect, the concept of a business object seems more closely related to that of a software component than to that of a normal object. From the perspective of interoperability, business objects are autonomous, neutral as to programming language and network protocol. Typically, they are implemented as distributed objects that rely on a middleware infrastructure for interobject communication. They are typically programmed in an objectoriented (OO) programming language, but this is not a strict requirement, given that contemporary middleware platforms can wrap modules programmed in some non-OO language so that they mimic object behavior. Just like normal objects, business objects have an interface in which their services are advertised. However, the technology of business objects takes the concept of classical interfaces a step further by supporting interface evolution in a way that allows the interfaces of classes to evolve without necessarily affecting the clients of the modified classes. This is made possible by minimizing the links between business components. Client and server classes are not explicitly bound to each other; instead, messages are trapped at run-time by a semantic data object that enforces the binding at the level of parameter-passing semantics (Eeles and Sims 1998). The core of this mechanism is that messages are selfdefining; the message name is maintained in the request, and the parameter names are defined in semantic data objects that can be attached. 1.5.2

From Business Objects to Business Components

Recall that component technology builds on object technology, extending the object-oriented paradigm with design principles that allow large-scale use of components for business application development. Also, the component-based

14

Software Components

development paradigm emphasizes packaging, selling, and deploying components together with the classical software development concerns about design and implementation. The past decade has witnessed the emergence of the concept of business components as distinct from other software components, such as network, utility, memory management, and security components. Business components form a special category of third-party, self-containing, autonomous, conceptual and software components with a well-defined plug and socket, and meaningful and understandable business semantics (Herzum and Sims 2000; Eeles and Sims 1998). In that sense, business components constitute the logical successor of business objects. Many authors argue that the autonomy of business components is an important feature of business component technology (Herzum and Sims 1998; 2000; D’Souza and Wills 1999), which clearly distinguishes them from business objects. Autonomy is related to granularity: components are believed to be coarser-grained than objects (Eli¨ens 2000; Herzum and Sims 2000; Hopkins 2000). This implies that the semantic concepts supported by a business component tend to be relatively autonomous with respect to the business domain. Combining the principles of autonomy and granularity allows business components to be loosely coupled, implying that both functional and technical dependence is minimized. Accordingly, a business component is defined as follows. A business component encapsulates both conceptual and physical (software) artifacts, which express some business semantics, and offers them as third-party products to prospective customers by using an explicit interface specification comprising a limited set of plugs. Components can be assembled into a system or subsystem by parameterizing their plugs to other components. 1.6

Web-Enabled Components: The Substrate of Web Services

The advent of the Internet has substantially changed the way in which software components are designed, developed, packaged, and marketed. It has made available novel ways of conducting business between distributed and potentially unknown business partners, possibly for the duration of one single business transaction. This vision in captured in the service-oriented computing (SOC) paradigm. Currently, the SOC vision is only partially realized by using Web services, which comply with Internet standards and overarch design and implementation considerations. A Web service is a self-contained, Internet-enabled application capable of performing simple business tasks on its own and possessing the ability to engage other Web services in order to complete higher-order business transactions.

15

1.6

Web-Enabled Components

Examples of such services include catalog browsing, ordering products, making payments, checking order status, scheduling shipments, and supporting human resources or customer relations management. Web services may be thought of as Web-enabled business components that perform enterprise-related activities and transactions over the Internet. The SOC vision assumes that each Web service provider describes the types of business services offered, their interfaces, and other information. The types of services and their interfaces can vary among business providers, although a group of businesses or a marketplace may adopt common conventions. For example, in a vertical industry such as the travel or the automotive industry, companies may come to an agreement about the interface of service offerings. More important, service providers may reach consensus about the way in which the business is conducted, standardizing business processes and scenarios rather than individual services. Well-known examples of such standards are the Open Travel Alliance1 and Standards for Technology in Automotive Retail (STAR).2 1.6.1

The Service-Oriented World

Principally, the SOC paradigm stipulates a set of core guidelines and principles, which are captured in the service-oriented-architecture (SOA). As the name implies, SOA prescribes an architecture, not a technology. A common misconception about SOA is that it is equivalent to Web service technology. This is fostered by the marketing campaigns of large software vendors that promote SOA as a set of universally accepted standards, provisioning broad interoperability among different platforms by Web service standards such as SOAP (Simple Object Access Protocol) (Box et al. 2000), WSDL (Web Services Description Language) (Christensen et al. 2001) and UDDI (Universal Description, Discovery, and Integration protocol) (UDDI 2004). However, SOA’s principles may be equally well implemented with other (older) programming languages or middleware platforms such as CORBA, DCOM, and CICS. Core elements of SOA include the following (Papazoglou and Georgakopoulos 2003; Endrei et al. 2004; Arsanjani 2004): Services are logical entities that may be implemented using coarse-grained, distributed, Web-enabled components, which leverage large-scale customization and allow low-cost composition. The specification of a service is described in a standard manner, stating its global purpose, capabilities, and other metadata, including contact information.

.

Service providers are enterprises that implement service specifications. While services are typically advertised via a service broker, they are invoked via

.

16

Software Components

the Internet, being deployed locally at the supplier’s site. Decoupling service specifications from implementations implies that multiple service providers may implement and offer the same service, albeit with different quality-ofservice elements (e.g., price, reliability, availability). Service consumers are clients that are capable of invoking a service offered by a service provider. Service consumers may be either other services or end-user organizations requesting some information or processing.

.

Service brokers are capable of creating a market for bringing together service providers and service consumers. Service brokers leverage providers by providing facilities for advertising services and easing discovery, based on a standard service invocation channel. Service consumers benefit from facilities that assist them in finding appropriate services, given their specifications for best price and quality of service, and by invoking services providing run-time support facilities.

.

SOA embraces the principle of loose coupling to separate the participants in distributed computing interactions, so that modifying the interface of one participant in the exchange does not affect the other, allowing interface evolution. This means that enterprises can implement Web services without having knowledge of the consumers of those services, and vice versa. 1.6.2

Web-Enabled Components

Web services may be recursively designed and implemented as Web-enabled components, shortly Web components, whose physical end points may be invoked over the Internet. Hence, physical end points of Web components are linked to abstract services (port types) defined in the Web services interface. This may require mapping component interfaces based on remote procedure calling (RPC) to messages, and vice versa. Tools like the Java application program interfaces (APIs) for XML-based RPC (JAX-RPC) help perform this mapping for Java components. Web components are executed in Web containers, taking care of middlewarelike services such as concurrency, distributed transaction management, persistence, life cylce management, and intercomponent communications. In principle, Web components may be implemented using any component model supporting this functionality, such as J2EE and .NET. The application of Web components for Web services is shown in figure 1.4. This architecture is derived from work reported by Yang, van den Heuvel, and Papazoglou (2001) and Yang (2003). As the figure illustrates, a Web service encompasses several Web-enabled components that realize its functionality. In

17

1.6

Web-Enabled Components

Web Service Invoice Creation Private Required ports

getVendor Info

Provided Interface Protocols

Vendor

getPurchase OrderID

Public Required Services (Ports)

S ervice meta-da

getSales Agent

Purchase Order

Private Provided ports

Invoice

Newinvoice

Remove invoice

FindInvoice

Web-component

Service metadata (e.g., Product Category, Contact Info, etc.)

Public Provided Services (Ports)

Figure 1.4 Anatomy of Web services.

this case, the Web service Invoice Creation is realized by one large-grained Web component encapsulating three subcomponents, Vendor, PurchaseOrder, and Invoice. In particular, through the interface of the Web service Invoice Creation, the Web components Invoice and PurchaseOrder implement the ports that are advertised by the Web service in its interface. This is shown by the dotted arrows from the provided interface of internal Web components to that of the Web service. In order to ensure that only parties within a trusted zone may invoke their operations, Web components explicitly distinguish between public and private ports. Private interfaces may only be invoked by trusted internal components, whereas public interfaces are exposed via the Internet and may be called by external components as long as the conditions expressed in the specification of the port are fulfilled. An unique feature of Web service interfaces, in contrast to those of Web components, is that all Web service interfaces are public and must be written in a standard XML-based language, representing the signatures, the locus of execution, and the communication protocol. The way in which the Web component interfaces are declared remains transparent to the client of the Web service and may in fact range from a de facto standard to a proprietary specification language.

18

Software Components

The global XML standard for defining the signature of Web services is the Web Service Definition Language (WSDL), which is standardized by the W3C. At the most abstract level, a WSDL specification outlines operations, messages, types, and protocol information. Its structure looks basically as follows. The element entails the root element of a WSDL specification, containing one or more elements, each of which may actually encompass a set of operations. An defines an operation name and a sequence of typed input messages, followed by one or more typed output messages, which are produced by executing the operation. The data types of messages are specified with parts, which typically use XML Schema to declare simple elements. Port types, messages, and parts make up the abstract part of a WSDL document. The protocol information in a WSDL document constitutes the concrete part of the specification, outlining s that state the communication protocol (e.g., SOAP), type of communication (RPC or document style), and physical end points (also called ports) that indicate the network location (e.g., URI). Last, the concrete part defines services that may combine one or more port(s). Ports may be combined for basically two reasons: first, to offer two or more alternate ports for the same port type, and second, to synthesize various (related) port types in one service. If designed in the right way, only semantically related operations should be grouped into port types. For example, variants of a particular business operation, say, variants of the operation reserveTicket allowing reservations via fax, telephone, or e-mail, may be offered in a single port type. Once abstract operation signatures are defined, ports can be introduced to bind abstract port type definitions to physical network locations (end points) and protocols (e.g., HTTP, FTP, or SMTP). Just like operation interfaces, required and provided protocols may be defined publicly or privately. Figure 1.4 shows a simplified internal provided protocol for the Web service Invoice Creation. This provided protocol plots the control flow of the composite Web component, expressing the order in which provided ports of the internal Web components Vendor, Invoice, and PurchaseOrder may be invoked. In particular, the provided protocol spans a logical sequence of port invocations (represented as hexagons), including a split (shown as a diamond) and a join. The dotted lines from the hexagons to the ports are drawn to express that the steps in the provided protocol are associated with ports of the Web components. The protocols in this figure merely define the control flow, but in principle the data flow may also be explicated in other protocols. Standard service orchestration languages such as Business Process Execution Language (BPEL) (Andrews et al. 2003) may be used to specify this protocol.

19

1.6

Web-Enabled Components

Besides interface and protocol specifications, Web services may be equipped with a standardized set of metadata, including metadata clarifying the kind of products and processes a particular Web component offers, and contact information. In particular, the UDDI specification (UDDI 2004) standardizes registration and localization of Web services, promoting a conceptual model for services consisting of White Pages information (business identifiers and contact information), Yellow Pages information (industry, type of product, and geographical location), and Green Pages information (information on interfaces). Clearly, these classes of information are not incorporated in more classical WSDL-like interfaces. For the purpose of aligning and integrating business processes to legacy systems, the main topic of this book, this overview of SOA suffices. The interested reader is referred two excellent books for more detals: Alonso et al. (2003) and Papazoglou and Ribbers (2005).

2

Leveraging Legacy Systems

Legacy systems constitute the enterprise’s heritage of software and hardware systems. Often, legacy systems are relatively old, mainframe-based systems that were optimized to accommodate the memory, disk, and other operational constraints of archaic software and hardware platforms. Most of them are older than 20 years and are written in COBOL, PL/I, or Assembly/370 using transactions management systems like CICS (Customer Information Control System), although this certainly does not have to be the case. Legacy systems pose a dilemma for enterprises. On the one hand, enterprises perceive them as obstacles to implementing new business processes because they are notably hard to adapt to new business requirements. On the other hand, legacy systems typically lock in valuable and indispensable business knowledge. This business knowledge comprises not only explicit knowledge about business processes, policies, and data that is codified in a shared formal language but also tacit knowledge that is employed to smooth daily business operations. Hence, disruptions to these systems, even those as short as a couple of seconds, may cause catastrophic losses. Devising a balanced strategy for handling legacy systems and realigning them with new process requirements has proved particularly challenging. Over the past decades, a number of strategies, methodologies, and tools have been hailed by industry as the next silver bullet to overcome the legacy dilemma, ranging from nonintrusive approaches such as screen scraping and legacy wrapping to more invasive ones like grafting new designs onto the outdated parts of the architecture of legacy systems. Before examining these approaches in more detail, I will first review the notion of legacy systems.

22

2.1

Leveraging Legacy Systems

Legacy Systems as Application, Data, and Time Stovepipes

Despite being outdated, legacy systems usually lie at the heart of missioncritical business operations, automating disparate, “vertical” business functions like those implementing procurement, sales, and inventory. Business functions entail logical groupings of enterprise resources that collaborate to perform a “wall-to-wall” task. Consequently, business functions are said to be contained in functional stovepipes, which are executed in isolation from other functions without any regard to the end-to-end business process in which they are used (Smith and Fingar 2003). The scope of each business function is restricted to successful completion of its own part in the overall business process. Similarly, the legacy systems supporting functional stovepipes are often referred to as application silos or data silos or as islands of automation/data. Probably even more problematic is the fact that many legacy systems operate in time silos (Smith and Fingar 2003), processing business functions at their own pace without regard to the velocity at which real-world business processes evolve. This data/functional latency is not acceptable in today’s global economy; customers expect Internet-enabled service-on-demand. Additionally, federal legislation in many cases mandates immediate access to information. For example, the Sarbanes-Oxley Act, section 409, requiures near-to-real-time reporting for material events. In contrast to business functions, business processes implement end-to-end business activities, starting with a customer request and ending after the request has been satisfied. Business processes are directed toward creating business value to customers, imposing on business tasks the requirement of successful completion in the context of the overall process. Modern business processes and their supporting enterprise systems are thus the antithesis of functionoriented legacy stovepipes, cutting across several business functions. This is exemplified in figure 2.1 by the two “horizontal” business processes Deliver Coffeemakers and Deliver Televisions, which encompass several “vertical” business functions. 2.2

Managing the Evolution of Enterprise Applications

Similar to other enterprise assets, including production plants, machinery, trucks, and other physical assets, enterprise applications are born as promising systems, full of potential. However, as these systems grow older, they tend to become misaligned with modern business processes with respect to both functional and quality-of-service requirements. Actually, like other enterprise assets, they are believed to progress through a sequence of life stages from their

2.2

Managing the Evolution of Enterprise Applications

Legacy “Stovepipes”

Business process-1 Business process-1

Deliver Coffeemakers

Business process-2 Business process-2

Deliver Televisions

Legacy system-2

Legacy system-3

Legacy system-4

Business Processes

Legacy system-1

23

Procurement

Inbound Logistics

Production

Sales and Promotion

Business Functions

Figure 2.1 Business processes versus business functions and legacy “stovepipes.”

introduction through growth, maturity, and decline. This sequence of stages is called the enterprise system life cycle. In the 1970s, Lehman and others derived a set of seven “universal laws” underpinning the life cycle of applications by observing and analyzing realworld cases (Lehman and Belady 1985). The discussion here is limited to the first two laws, which involve the enterprise applications themselves. The first law states that applications change continually to better meet customer requirements; if they do not, they become obsolete. The second law states that over time the structure of an application gets more complex (and more chaotic). The entropy of an application tends to increase over its lifetime. Let us now consider the application lifecycle in some more detail. During the first phase of its life cycle, an enterprise application is developed, deployed, and delivered (see cycle 1 in figure 2.2). Directly after the first version is taken into production, some initial corrective maintenance may be performed so that the application better satisfies undetected (minor) wishes of clients. These maintenance activities result in an improved version of the system. The second phase— the growth phase—is characterized by rapid growth of both functionality and adoption of the application. During this phase, the application is fine-tuned and extended to better match emerging or altered business requirements. When the application is mature, growth in functionality stabilizes. From a business perspective, the application is most profitable during the maturity stage of its life

24

Leveraging Legacy Systems

Required business functionality Provided functionality

Version 2.2

Version 2.3

Growth

Maturity

Decline

Version 2.1

Version 1.3

Maturity

Modernize

Cycle 3

Introduction

Version 1.2

Growth

First Modernization Round

Version 1.1

Development Cycle -1 Start Life cycle

Cycle 2

Introduction

Cycle 1

Functionality

Phase Out

End Life cycle

Time

Figure 2.2 Life cycle of an enterprise application. Adapted from Seacord, Plakosh, and Lewis (2003, 8).

cycle. At the same time, the entropy of the application typically increases: the system’s architecture gets polluted and more chaotic unless reengineering efforts are performed to renovate it allowing it to begin a new cycle. With its structure deteriorating, and without any modernization efforts, the enterprise system may morph into an application-, data-, or time silo and become technically obsolete or misaligned with new business requirements. The growth of implemented functionality in the first two cycles shown in figure 2.2 follows an S-shaped pattern, evolving toward the level of functionality required by end-users. In many cases, the lifecyle is not S-shaped but tends to follow a “scalloped” pattern that results from modernization efforts of the legacy system, extending the life of the system beyond that of one lifecycle. For example, consider the enterprise application in figure-2.2. The life of this enterprise application is divided in three cycles, each of which captures one lifecycle. The first two cycles in this figure follow the S-shaped pattern. System evolution during the first cycle was already articulated. During phase 2 the application was modernized and extended to support a broader range of business functionality. The last cycle looks like a flipped-S that reflects that the enterprise application is gradually

25

2.2

Managing the Evolution of Enterprise Applications

Big bang/ Cold Turkey

Evolution Strategies

A. Maintain

B. Modernize

Incremental/ Chicken Little

Revamp

Convert code Convert data

D. Retire (Phaseout)

C. Replace

White-box

Black-box

Retarget platform

Wrapper Adapters/ connectors

Figure 2.3 Evolution strategies for dealing with legacy enterprise applications.

phased out while its necessity from a business perspective rapidly crumbles away. To effectively cope with the specific requirements of each of the life cycle stages, each phase of the life cycle needs to be managed with a tailored evolution strategy, and the strategy must be continually revisited and reformulated in response to evolving needs at each phase. The following evolution strategies (figure 2.3) have been proposed during the past decade: maintenance, modernization, replacement, and phase-out (Brodie and Stonebraker 1995; Weiderman et al. 1997; Warren 1999; Ulrich 2002). The impact of these strategies on enterprise applications ranges from minimal to substantial: maintenance activities entail a contained type of evolution implying marginal changes and extensions, whereas phaseout is the most disruptive approach, involving retirement of (parts of ) legacy systems. 2.2.1

Maintenance

This evolution strategy is applicable in case a legacy system still functions relatively well. No intrusive changes accompany this strategy, so it is by far the preferred strategy from a cost and risk perspective.

26

Leveraging Legacy Systems

Maintenance involves nurturing the application without making fundamental changes to the code or breaking its underlying architecture. The strategy basically comes in three variants: adaptive maintenance, corrective maintenance, and perfective maintenance (Warren 1999; Weiderman et al. 1997). Adaptive maintenance pertains to making minor changes in the system’s functionality to ensure that it stays aligned with new business requirements. Besides this, maintenance activities can be directed toward eliminating errors in the code (corrective maintenance) or optimizing existing code so it better meets both functional and quality-of-service requirements (perfective maintenance) in a more efficient manner. 2.2.2

Modernization

The modernization strategy usually becomes desirable after several years of continued maintenance, which has likely weakened the technical quality and flexibility of the legacy system. Legacy system modernization can be achieved in two orthogonal ways. First, the legacy system may be renovated by encapsulating and subsequently integrating it with new applications or components. Some authors refer to this as access/integration in place (Umar 1997) or as black-box modernization (Weiderman et al. 1997). The second way of modernizing the legacy system is to transform it, adapting a white-box approach. Transformation requires a detailed understanding of the legacy system to allow legacy code and data to be converted, whereas black-box modernization merely demands abstract knowledge about the external services of a legacy system to integrate them with modern system components. Hence, white-box modernization is considered to be an invasive, and black-box modernization a noninvasive, strategy. Thus, transformation involves examining and reconstituting an information system. Transformation may be realized with a combination of several techniques, including source code translation, program and data restructuring, reverse engineering, and retargeting. Source code translation involves transforming old code into a new version that is written in a contemporary programming language or a newer version of the same language. For example, systems may be converted from COBOL-II into Object-Oriented COBOL (Levey 1996). Program restructuring refers to correcting structural flaws in the code (e.g., infinite loops), and data restructuring involves refreshing the data structure of legacy data files or databases. Reverse engineering entails the recovery and analysis of a legacy system (Chikofsky 1990) to extract an abstract description of the system components and their relationships. Last, retargeting involves transferring a legacy system to another platform. An in-depth treatment of these transfor-

27

2.2

Managing the Evolution of Enterprise Applications

mation techniques may be found in Arnold (1993) and Seacord, Plakosh, and Lewis (2003). To implement the encapsulation and integration (black-box) strategy, it suffices to recreate an understanding of the abstract services that are offered by a legacy system, database, or user interface. Particularly, legacy applications and database repositories may be encapsulated and accessed using adapters, which allow new application components to coexist with encapsulated legacy systems. Screen scrapers are an encapsulation technique to reface archaic, mostly textual, user interfaces. 2.2.3

Replacement

Replacement implies acquiring or constructing a new application and substituting it for a legacy system. Assembling third-party components, customizing standard packages (e.g., enterprise resource planning solutions), in-house development, or using a mixture of these development practices may realize this strategy. For example, Body Shop International decommissioned its legacy systems in 2004 in favor of one shared SAP for Retailing solution. Despite the fact that the replacement strategy may at first sight seem very attractive to management because it holds the promise of the newest technologies and leads to a fast discontinuation of redundant applications and repository systems, practice has taught that this strategy bears large risks and many unpredictable pitfalls. First, costly and complex data and code conversions have to made in order to save past investments in legacy systems. Avoiding expensive downtime of the existing enterprise application is often a difficult hurdle. Second, it is usually not possible to guarantee that the new system will outperform the existing application in terms of both functionality and extrafunctional properties such as security and robustness (transactions). Nascent technologies may at first seem to offer tantalizing possibilities but may not yet be ready for prime-time implementations. 2.2.4

Phase Out

The most extreme evolution strategy is to discontinue the enterprise application. This means that the supporting business process would also cease to exist. Legacy system modernization, replacement, and retirement may be accomplished according to various process models. Two extremes on the spectrum of process models are shown in figure 2.3: the Big-Bang, or Cold Turkey, model and the incremental Chicken Little model. The Big-Bang model is

28

Leveraging Legacy Systems

the most radical evolution model, implying that legacy systems are replaced, retired, or modernized at once. Clearly, this strategy brings immediate benefits, but it carries the most risk of failure. Alternatively, the incremental process model gradually introduces new technology into the legacy environment until the target environment is realized. This somewhat conservative approach can be executed without disrupting an organization’s business processes and carries a minimum risk of failure. On the other hand, for the incremental approach to be viable, it requires that the legacy system can be decomposed into fine-grained subsystems. In the DARWIN project, Brodie and Stonebraker (1992) explore the application of the Chicken Little approach in several projects aimed at replacing parts of legacy systems with modern components while employing gateways. In their landmark book, Migrating Legacy Systems (1995), they consolidated the results of the DARWIN project, introducing an 11-step methodology that is illustrated with two real-life case studies. As noted by the authors, the challenge of employing gateways lies in the capability of synchronizing data and logic between the legacy system and target system. To avoid this impediment, Wu et al. (1997) propose the Butterfly method as a gateway-free alternative to incremental legacy migration. 2.3

Legacy Portfolio Analysis

Periodically, the portfolio of enterprise applications needs to be critically assessed and evaluated to ensure that the applications are still aligned with new business process needs and technical requirements. Deciding on an optimal evolution strategy for dealing with an enterprise application may be assisted by portfolio analysis. The best-known portfolio analysis approach was developed in the 1980s at Nolan, Norton & Co. (Verdugo 1988). Portfolio analysis methods that are derived from this approach are plentiful (e.g., Jacobson and Lindstr¨om 1991; Sneed 1991; Bennett, Ramage, and Munro 1999; Aversano et al. 2004). The Nolan Norton approach evaluates applications in a portfolio along two orthogonal dimensions: business value and technical value. Each dimension is demarcated in two segments, one reflecting relatively high values and the other relatively low values. By relating both segmented dimensions a portfolio matrix is created, encompassing four quadrants. Figure 2.4 depicts the resulting chisquare chart. Both the business value and the technical value are calculated as the weighted mean of quantifiable product or process metrics. Typically, the lower bound of the portfolio is 0 and the upper bound is 1. For each of these

2.3

Legacy Portfolio Analysis

high

Reassess

Maintain

Retire/Replace

Modernize

Technical Value

29

low low

Business Value

high

Figure 2.4 Portfolio analysis.

four quadrants, a legacy system evolution strategy is advised that is tailored to overcome the particular challenges to which systems residing in that quadrant are exposed. In particular, the business value dimension expresses the extent to which a legacy system contributes to value-adding business processes of an organization. Sneed (1991) explains that the contribution of legacy systems to the business value can be derived from their annual revenue accountable and their market value. According to Warren (1999), assessing business value should also take into account business criticality and expected lifetime. The technical value dimension conveys the quality of a legacy system in terms of technical properties such as flexibility, deterioration (e.g., mounting backlogs and defect rates), and maintainability (e.g., program size and cyclomatic complexity). Faithfully measuring technical attributes requires a coherent quality framework that defines quantifiable variables for each attribute and includes a solution for computing a weighted average score. We refer to Warren (1999) for a comprehensive list of quality attributes. Each quadrant in figure 2.4 demarcates a specific evolution strategy. Retire or Replace From a business perspective, it is not profitable to invest in legacy systems whose plots fall in this quadrant because they do not support any

.

30

Leveraging Legacy Systems

of the business-critical processes. Moreover, legacy systems in this quadrant fail to meet state-of-the art technical requirements, including performance, flexibility, security, and reliability. As explained in the previous section, such legacy systems should be either retired or replaced incrementally, or at once. As the business value of tasks supported by legacy systems in this quadrant is relatively low, system replacement is preferably implemented by procuring low-cost packaged software like an ERP (enterprise resource planning) system or COTS (commerical off-the-shelf ) components. Reassess Although the technical condition of the systems in this quadrant is considered relatively high, they generate limited value to the enterprise. Management should reevaluate them and determine whether they could be strategically repositioned to support the more value-adding business processes. Alternatively, these systems could be left intact and reassessed in due time.

.

Modernize Some studies claim that half of all legacy systems fall into this quadrant (Sneed 1991), capturing substantial business value but suffering from a poor technical condition. As you may recall, these legacy systems should either be transformed into technically superior enterprise systems or encapsulated and integrated with new, value-adding applications.

.

Maintain Enterprise systems whose values fall into this quadrant are crucial to the success of an organization, amortizing high business value and operating as technically sound systems. Consequently, they should be carefully nurtured.

.

Although an effective tool for decision making by management and technical staff (Weill and Broadbent 1998), Nolan Norton portfolio analysis and methods derived from it suffer from several serious shortcomings. First, estimating the technical health and business value of legacy systems is often a Herculean task because of a lack of hard quantifiable and validated data and metrics. Notably, it is hard to establish and calibrate threshold values for business value and technical value in the matrix. Choice of threshold values is a critical task, as they demarcate the quadrants that are associated with strategies to deal with the legacy systems. However, currently no guidelines for establishing them or industry-specific benchmarks are available. Second, portfolio analysis implicitly assumes that individual legacy systems can be treated as autonomous software assets. With borders between applications and repository systems diminishing, this assumption is becoming increasingly hard to defend. Third, Nolan Norton portfolio analysis and methods derived from it fail to take into account future organizational requirements. In particular, requirements that may be foreseen, such as new legislation, should be assessed and prioritized to judge whether investments in the legacy system are justified.

31

2.3

Legacy Portfolio Analysis

Ulrich (2002) presents an alternative to Nolan Norton portfolio analysis, a three-dimensional software option strategy matrix that adds organizational impact analysis to the original panes. Ulrich argues that legacy systems with high impact on the organization should be maintained in case of high technical quality and high business value. If both technical quality and business value are relatively low but the expected impact is high, the legacy system should be either consolidated or upgraded. For the same ranges of technical quality and business value but low anticipated impact, they should be maintained, migrated, or integrated. Organizational factors shaping organizational impact analysis include the following: Organizational structure and volatility Organizations are forced to continually redesign their structures to accommodate internal and external forces, for instance, new enterprise policies or cuts in funding. According to Mintzberg (1979), organizational structures fall into one of five archetypical configurations: machine bureaucracy, professional organization, diversified structure, simple structure (entrepreneurial start-up), and adhocracy. The last two structures are rather unstable and volatile, efflorescing in agile environments, whereas the others flourish in more stable environments. Black-box modernization strategies do not go well with adhocracies or simple structures because the legacy systems underlying the wrappers may not be altered.

.

Political context Decisions about a strategy to cope with legacy systems must fit with the political context of an organization. For instance, does modernization fit into a current context of heavy budget cuts and layoffs? If modernization of a legacy system is requested now, can the same be requested for other systems about two years down the road?

.

Training Modernizing legacy systems requires special skills that even the most seasoned software engineer or project leader may not have. The exact nature of these skills depends on the evolution strategy that is adopted. These skills might not be available in the company and could either be outsourced or acquired internally by training information technology staff. Consolidating an upgraded or revitalized legacy system also implies that users need to be trained.

.

Continuity of software providers Before embarking on a strategy, companies should assess the continuity of new software and hardware vendors.

.

These issues may be evaluated by weaving them into modernization scenarios, each of which stipulates a potential way to treat the enterprise’s legacy systems. Bennett, Ramage, and Munro (1999) suggest a two-phased decision model that combines business and technical scenarios. During the first phase,

32

Leveraging Legacy Systems

stakeholders evaluate business scenarios on their economic and organizational merit. The second phase probes technical solutions and associates them with business goals. Based on the findings, the business strategy may be adapted and technical solution routes may be devised. 2.4

Wrappers, Connectors, Mediators, Adapters

The use of wrappers for legacy modernization has developed into a flourishing integration market, with $5 billion in revenues in 2005 (Charlesworth, Jones, and Thompson 2005). Legacy wrappers are found in integration tools and technologies, application servers, integration brokers, and enterprise service buses (Papazoglou and van den Heuvel 2006b). Successful application of wrapper technology in industrial settings includes, for example, the use of wrappers in health care and banking (Erlikh 2002), the reuse of a legacy energy management system (Zhao et al. 2000), and wrappers that allow COBOL applications and object-oriented systems to interoperate (Flint 1997). Component wrappers are particularly useful for upgrading legacy systems that are in need of modernization with the encapsulation/integration strategy and for evolving legacy systems that are in need of replacement with a riskaverse, incremental strategy (see figures 2.3 and 2.4). Component wrapping entails modularizing and encapsulating non-component-based applications exporting callable and discrete interfaces so that they look to client components just like any other (business) component. In this way, legacy systems may gracefully coexist with applications delivering new, crossfunctional business processes (figure 2.5) (Wilkes 1999). A componentized application is sometimes called a wrapper (component) (Mecella and Pernici 2001), an adapter, or a legacy object/component (Noffsinger et al. 1998; van Deursen et al. 2000). These terms are used interchangeably in this book. Another issue of terminology should be raised here. In the literature, the term adapter is often used synonymously with connector (mediator). A connector encapsulates an interaction mechanism that transports data between components and propagates control from one component to the next (Mehta, Medvidovic, and Phadke 2000). The notion of a connector comes from the domain of software architectures, where it has been formally defined and explored in the context of architectural description languages (Shaw and Garlan 1996; Lopes, Wermelinger, and Fiadeiro 2003). Hence, an adapter serves to overcome an interoperability problem. Without the adapter, the components, which were designed in other contexts in isolation from each other, cannot collaborate. Connectors, on the other hand, may be

33

2.5

The Landscape of Legacy Wrappers

perceived as coarser-grained constructs, embracing the concept of adapters. Hence, an adapter may be seen as a particular type of connector (Mehta, Medvidovic, and Phadke 2000). 2.5

The Landscape of Legacy Wrappers

To effectively componentize legacy systems, wrappers must be able to guarantee transactional integrity, overcome semantic conflicts (translation), mediate between heterogeneous network protocols (e.g., TCP/IP and SMS), and allow for various modes of interaction between applications like remote procedure calling (RPC) and event-driven interaction (Cresswell 2002). In its most rudimentary form, the legacy wrapper’s application program interface (API) is responsible for binding the interface of a legacy wrapper to that of a client component. Based on these bindings, wrappers may redirect incoming calls to appropriate legacy applications or repositories that are shielded by the wrapper interface. Wrappers that only support basic mappings for data and application hiding are referred to as thin wrappers or thin adapters (Linthicum 2001). Figure 2.5 shows a thin wrapper that defines two mappings. The first mapping associates, once invoked, a provided service, S1, declared in the wrapper API, with underlying legacy code and data (see the dotted arrow in figure 2.5 from S1 to the wrapped module A). The second mapping defines the external logic and/or data that is consumed by the wrapped module B (see the outgoing dotted arrow from module B to required interface S3.)

Figure 2.5 Wrapped legacy systems coexist with new business components.

34

Leveraging Legacy Systems

More sophisticated wrappers, called thick wrappers, are capable of binding source to target interfaces, making transformations, guaranteeing transactional ACIDity,1 and taking care of message routing and exception handling. Most interesting for the purposes of the methodological framework presented in this book is that thick wrappers may convert the custom APIs of one or more legacy resources into one open XML-based wrapper API. For example, a simple data request to a wrapper may be converted into another data format or decomposed into multiple requests to underlying legacy code and data, which are possibly deployed on different platforms. Also, multiple responses of legacy code may be combined and translated into a format that is understandable by the requesting component. The anatomy of thick wrappers is nicely reflected in the adapter pattern introduced by Gamma et al. (1995). Transforming incoming or outgoing calls is greatly eased by expanding the wrapper API with a semantically rich domain model (Diskin 1996). For example, consider the thick wrapper in figure 2.6. The domain model in this figure is positioned between the wrapper API and the underlying legacy resources, taking care of sophisticated transformations, routing messages through various back-end systems, and composing/decomposing incoming and outgoing calls. Essentially, domain models contained in thick wrappers provide an abstraction of the internal organization of the encapsulated legacy resources, using semantic relations such as association, aggregation, and inheritance. In this way, legacy APIs may be upgraded to APIs containing business semantics that are easily understood by other business components. An early example of a thick wrapper is reported by Dietrich, Nackman, and Gracer (1989). Thick wrappers may be developed with tools such as IBM’s WebSphere Business Integration Adapter solution (Gavin et al. 2005), which uses domain objects to mediate between the WebSphere integration broker and legacy resources. The feasibility of thin or thick wrappers is largely contingent on the level of decomposability of the legacy source code. Three categories of decomposability are discerned (Brodie and Stonebraker 1995): decomposable legacy systems, semidecomposable legacy systems, and nondecomposable legacy systems. Decomposable legacy systems make up the most optimal category for wrapping, having a clear separation between user interfaces, database management systems, and business applications. Semidecomposable legacy systems have intermediate structures that are either data or program decomposable (Umar 1997). Nondecomposable systems present the worst-case scenario, in which the interface, programs, and data are highly interwoven and cannot be partitioned. These are the least desirable wrapping candidates. If we assume that legacy software is at least semidecomposable, a related design issue is the granularity of code and data artifacts that are encapsulated

35

2.5

The Landscape of Legacy Wrappers

Figure 2.6 Thick legacy wrapper.

by a wrapper. Wrappers may be defined at several levels: the data level, the function/procedure level, the module level, the subsystem level, and the system level. At the lowest level of granularity, legacy data or functions may be encapsulated. Thin wrappers can be safely used at this level because the legacy software does not have to be broken down into multiple interacting subcomponents, and bindings can be defined on a one-to-one basis. However, on coarser levels of granularity, thin wrappers are inappropriate because of the more intricate organization of legacy resources, typically requiring complex bindings and transformations. Here thick wrappers come into play. Thick wrappers are thus particularly useful for capturing legacy systems at the module, subsystem, and system level. The domain model that is encapsulated in the thick wrapper provides finer levels of granularity, laying the foundation for wrapper maintenance and potential future modernization (Diskin 1996). To implement connectivity between the encapsulated domain model and external application components, thick wrappers employ a wide arsenal of access

36

Leveraging Legacy Systems

technologies, such as screen scrapers, database gateways, and infrastructure level adapters. In particular, the following types of adapter technologies may be subsumed in thick wrappers: Packaged software adapters enable access to the APIs of packaged software, such as SAP’s BAPI, Siebel’s API, Oracle Applications interfaces, and PeopleSoft’s Java Message Agent Client (JMAC).

.

Databases adapters mediate and translate queries and update between the legacy database and a target database management system. Examples of database adapters compliant with Java Database Connectivity (JDBC) and Open Database Connectivity (OBBC).

.

Screen scrapers can be used to reface the I/O components in the domain model mimicking the conventional, graphical, or textual user interface of the legacy system. The changes for the legacy user are thus cosmetic and noninvasive in nature, allowing legacy interfaces to be emulated by a new Windows-like interface or a Web browser. .

Infrastructure adapters provide various ways of facilitating uniform access to network protocols, request brokers, messaging middleware, transactionprocessing managers, and heterogeneous middleware solutions. The following are four categories of infrastructure adapters:

.

Network protocol adapters are capable of mediating between heterogeneous network protocols. For example, a network protocol adapter may convert a TCP/IP protocol into SMS or MIME. .

Messaging adapters provide uniform access to messaging brokers, for instance, the Java Messaging Service. .

Transaction processing monitors tap transactional business processes from legacy transaction-processing monitors such as CICS, Bull TDS, IMS/TM, and Tuxedo, and expose them to external clients as ACID-compliant processes. .

Bridges denote a special type of meta-adapters that bridge different types of middleware, including request brokers (CORBA/COM), messaging brokers, integration brokers, application servers, and enterprise service buses. .

Basically, wrappers/adapters may be deployed in two different topologies. They may facilitate one-to-one integration between components, which is the classical way by which wrappers are attached to individual components. In this case, the wrapper mediates to overcome interoperability conflicts between two components, adopting the classical adapter, proxy, and facade patterns (Gamma et al. 1995). Increasingly, however, wrappers/adapters are offered by integration brokers and application servers to allow one-to-many styles of integration,

37

2.6

A Roadmap for Developing Wrappers

for example, adopting a hub-and-spoke architecture. These wrappers may be deployed centrally at the hub (integration server), distributed over the resources, or both. As explained previously, wrappers/adapters may be custommade or bought from adapter vendors such as IBM, Neon Systems, and iWay. Buying from vendors greatly simplifies and speeds up development and is therefore the preferred way of developing adapters. However, for most proprietary legacy systems, adapters may not (yet) be commercially available, requiring new wrappers/adapters to be developed from scratch. 2.6

A Roadmap for Developing Wrappers

Although wrapping is deceptively simple in concept, the reality of developing and maintaining wrappers can be extremely difficult. Often, wrapping involves several complicated tasks, such as semiautomatic code analysis, decomposition, restructuring, and abstraction (Comella-Dorda et al. 2000). Basically, the following steps are taken to develop a component wrapper (figure 2.7): 1. Identify the components in the legacy application or repository Identification of components may be performed by logically associating and packaging legacy data and functionality. Grouping may be performed around data, events, or functions.

Phase 1: Identifying Component Option 1: Thin Wrapper Phase 2: Carving Out Legacy Components

Phase 3: Wrapping Legacy Systems

Option 2: Thick Wrapper

Figure 2.7 Roadmap for wrapping legacy systems.

38

Leveraging Legacy Systems

2. Carve out the legacy components Once potential legacy components are detected, they may be physically extracted from the legacy system. Ideally, the result is a set of autonomous legacy components exhibiting high cohesion of data and functionality. This step usually involves decomposition and remodularization of legacy systems to lower their entropy. In Georgakopoulos and Tsalgatidou (1998) the authors present some heuristics to restructure legacy systems into fine-grained legacy system services. 3. Design and develop the wrapper Once the legacy components have been extracted from the legacy system, the wrapper itself may be designed and developed. This involves designing the wrapper API and software modules that support the wrapper in exception handling, control, message handling, and input/output emulation (Sneed 2000). Several scenarios to design and implement the wrapper may be scrutinized during this step, considering various alternate levels of wrapper granularity. 2.7

Modularizing Legacy Systems

Identifying and extracting legacy components (steps 1 and 2 in the preceding list) are collectively referred to as legacy modularization. As mentioned, identifying fragments of legacy code or data can be done by logically associating and grouping them based on criteria such as data-centric or event-centric cohesion. This process tends to be problematic because the legacy code is often scattered and intermingled with code that also addresses other concerns. Gaining an initial understanding by eliminating parts of the legacy code that are not relevant, thereby reducing complexity, is believed to be crucial during the identification step. Then the relevant code or data fragments can be isolated and carved out of the legacy system. Two elementary techniques to assist in the modularization process are code slicing and concept analysis. 2.7.1

Code Slicing

Code slicing is a program analysis technique to identify, extract, and combine program statements in a legacy system that are relevant for a particular computation (de Lucia 2001) while deleting parts that are irrelevant. Slicing involves carving out the minimal subset of program statements and variables that is needed to accomplish a particular computation. Typically, slices are extracted from the code up to a certain point of interest, referred to as a program point, in such a way that the original semantics of the legacy program are conserved.

39

2.7

Modularizing Legacy Systems

Programs can be sliced in two ways: statically and dynamically. Static program slicing was proposed by Weiser (1981) and may be employed to extract code based on the criterion C = (p, V ). This criterion implies that the value of a set of variables (V ) has to be the same in both the original legacy code and the carved-out slice at program point p. Static slicing aims at preserving code behavior on any input value. In his seminal paper Weiser formally proved that calculating the minimal set of code that satisfies this requirement is inherently undecidable. Instead, the minimal collection of code may only be approximated by mapping a set of data flow equations to control flow graphs, whose nodes represent program statements and whose edges denote the flow of control. Unfortunately, static slicing does not allow determining which particular execution paths in the legacy code yield correct and which ones anomalous results. Consequently, code slices may actually contain statements that are not relevant for successful completion of a program thread. Dynamic slicing overcomes this predicament by cautiously examining only those variables that are relevant in a specific program thread (Agrawal and Horgan 1990). Program slicing is a relatively well-understood technique and has been surveyed by various authors (e.g., Tip 1995; Hoffner, Kamkar, and Fritzson 1995). 2.7.2

Concept Analysis

Program slicing deals with two special cases of legacy modularization: function extraction and procedure extraction. Cluster and concept analysis allow modularization at a higher levels of granularity, particularly the class and module level. Cluster analysis is a well-known technique for grouping possible combinations of data attributes and methods into classes (Lakhotia 1997). It is concerned with grouping similar entities into constellations (clusters) with strong links among its members and weak links with entities belonging to other constellations. Similarity of entities in clusters can be determined in two ways (Wiggerts 1997). First, the relationships between entities may serve as an indication of their similarity. The closer the entities are with respect to some reference point, for instance, a certain point in space, the more similar they are. Second, a similarity coefficient may be computed for the entities based on multivariate analysis. In this way, cluster analysis may be applied to regroup legacy code into modules with a high internal cohesion and low coupling between modules. Wiggerts (1997) summarizes several clustering analysis algorithms for legacy remodularization, including graph theoretical algorithms, construction algorithms,

40

Leveraging Legacy Systems

optimization algorithms, and hierarchical algorithms. Wiggerts (1997) and Tilley et al. (2003) give an in-depth treatment of these categories of algorithms. A mathematical counterpart to cluster analysis has been developed under the name concept analysis (Lindig and Snelting 1997). Concept analysis is a technique for deriving collections of objects with common features that is based on a special branch of lattice theory. Formally, a concept can be specified as a pair of sets (one set of objects (O) and another set of attributes (A)) such that Y = σ (X), and X = θ (Y ), where σ (X) = {a ∈ A|∀o ∈ X : (o, a) ∈ R}, and θ(Y ) = {o ∈ O|∀a ∈ Y : (o, a) ∈ R}. Then σ (X) designates the common attributes of X, and θ (Y ) designates the common objects of Y (Siff and Reps 1997). Hence, a concept entails the maximal set of objects sharing similar attributes. 2.8

Constructing WSDL/SOAP-Based Wrappers

SOAP/WSDL/UDDI technology provides a contemporary distributed computing infrastructure on top of which wrappers may be defined, implemented, and deployed. By wrapping legacy systems in a thin WSDL layer, the functionality of legacy systems may be exposed over the Internet as a set of service end points. WSDL wrappers may be bound to SOAP or to alternative transport protocols like MIME and HTTP. SOAP (Simple Object Access Protocol) is the communication infrastructure of choice for enacting Web services that allow RPC-like, HTTP-based method invocations. It has been specifically designed to transmit XML data over the Internet. As such, it is particulary effective for Web-enabled legacy systems. In comparison to more conventional middleware systems such as CORBA, it is a particularly lightweight protocol that allows asynchronous calls cutting across the firewall of organizations. In contrast to CORBA, however, SOAP itself does not offer additional object services, for instance, for life cycle and transaction management. Instead, these services are offered in a ever-growing number of specification standards (referred to as the WS-* stack), some of which are supported by commercially available software, most as add-ons to application servers. As explained before, WSDL (Web Services Description Language) may be defined independently from any programming language, hardware platform, and location (end points) of legacy applications as long as a suitable (SOAP) protocol is technically available, for instance, a Java or .NET SOAP implementation. Several tools, such as Cape Clear’s CapeStudio, may help in defining WSDL. Once defined, the WSDL/SOAP components may be registered at a central UDDI repository, and access to legacy functionality by new application

41

2.8

Constructing WSDL/SOAP-Based Wrappers

Figure 2.8 Architecture for Web service–enabled legacy systems.

components can be obtained in exactly the same way as access to the logic of other business components. Business and legacy components may thus be intermingled, allowing existing applications to be retrofitted to accommodate new business processes. A run-time architecture for deploying legacy wrappers and new business components (implemented as Web services) is shown in figure 2.8. The legacy system is wrapped, then connected to a proxy that usually runs on a combined Web/application server. For this purpose, application servers like WebSphere and JBoss are equipped with legacy adapters. Before the advent of Web services, the boundary between Web servers and application servers was relatively clear. Web servers were used to connect application end points to the Internet, whereas application servers provided the deployment environment in which the actual business logic was executed. Application server vendors are now amortizing their products with Web server capabilities in order to support Web services in a more effective manner. This has led to a rather blurred boundary between application servers and Web servers. Consequently, both types of servers are combined in one tier in figure 2.8. Once the legacy system is wrapped and deployed on the Web/application server, it may be advertised in some internal or external UDDI repository. Subsequently, a client Web service may discover the Web-enabled legacy system and invoke the desired functionality over a SOAP pipeline. The method invocation travels through the firewall of the client organization, crosses the Internet, and penetrates the firewall of the node where the invoked web-enabled legacy

42

Leveraging Legacy Systems

system resides. Then the wrapper translates the incoming request into the proprietary format of the legacy system. This architecture may be used as a foundation of various implementation scenarios. For example, Kuebler and Eibach (2002) outline a scenario that can be mapped to it. A WebSphere application server, running on a J2EE platform, implements the Web/application server tier of the architecture. This application server deploys a firewall, Web server, SOAP router servlet, and several adapter EJBs (Enterprise JavaBeans). Adapters implemented as servlets spin off a logical unit of work as soon as a SOAP request is received by the application server using the built-in transaction-controlling mechanisms of EJBs. Alternatively, Yajaman et al. (2003) discussed several implementation scenarios, referred to as patterns, mostly involving Microsoft products such as the .NET framework, XML, Visual Basic, COM, and ADO. 2.9

Wrappers in Action: A Case Study

The author participated in developing wrappers for legacy systems at the Royal Airforce of the Dutch Department of Defense to modernize legacy systems responsible for storing, updating, and removing administrative information about the availability of fighter plane parts that are needed for maintenance purposes. This case study is elaborated as a running example throughout this book to illustrate the methodological framework. To keep fighter planes in peak operating condition, aircraft and avionics engineers perform scheduled and unscheduled maintenance to repair or replace parts or to complete inspections. Maintenance activities include preventive maintenance, such as inspecting worn parts and replacing plane tires and engine based on the number of hours flown, number of cycles of the aircraft engine, and the last date the plane was inspected. Corrective maintenance is carried out when a problem occurs. This type of maintenance activities involves identifying faulty equipment based on the pilot’s descriptions and then fixing the problem. Maintenance activities are organized into three logical lines, depending on the location where they are executed. First-line maintenance constitutes simple repair operations in the field. Second-line maintenance comprises complex repairs to the planes and revisions of parts. These activities are usually done at an airforce base. Third-line maintenance can only be performed by highly specialized maintenance engineers and covers complex tasks such as the overhaul of a fighter plane engine. Because of the complexity of these tasks and for economic reasons (they need to be performed rather seldom), this type of maintenance is not performed at the hangars on airforce bases but at a central location in the Netherlands.

43

2.9

Wrappers in Action

SAP-R3: Schedule for Plane Maintenance

VA-1: Inventory Administration

Inquire Part Availability

COBOL/ ADS

Inquire Part Availability

SAP R/3 SAP R/3

IDMS Processing: Online OS: MVS

ALVA: Order Parts

Request Prognosis

COBOL/ADS

COBOL/ ADS

Purchase Order

EDI EDIFACT

Purchase Requisition

IDMS IDMS Processing: Online+Batch OS: MVS

Processing: Online+Batch OS: MVS

Paper Order Purchase Order

Supplier

VA-2: Inventory Management and Control, Reverse Logistics

Figure 2.9 Legacy systems involved in requesting parts for airplane maintenance.

2.9.1

Legacy System Architecture

Inventory management is supported by a conglomerate of legacy systems. For simplicity, I consider here only legacy systems that are involved in processing requests about the availability of airplane tires. Requests for new tires usually arise after examination of tires by maintenance engineers in the context of preventive maintenance activities based on the number of years the tires have been used, flight time, and number of landings. Figure 2.9 depicts a simplified system architecture showing the legacy systems that are involved in requesting and ordering tires from a supplier. The dashed line at the bottom right corner represents the organizational boundary of the Department of Defense. The directed arrows denote messages, and the dotted boxes demarcate the boundaries of legacy systems, all of which comprise both an application tier and a database tier.

44

Leveraging Legacy Systems

The VA-1 application, Inventory Administration, was developed in 1986 in COBOL/CA-ADS. It uses a network database system (IDMS from Computer Associates) for storing data on the inventory level, master data, and consumed quantities of items. The Application Development System language (CA-ADS), also from Computer Associates, is a fourth-generation programming language that resembles COBOL and is specifically designed for supporting online transactions on IDMS repositories. The VA-1 application and repository run on an IBM OS-390 Z series mainframe in an MVS (Multiple Virtual Storage) environment. The VA-1 system allows maintenance engineers or any other authorized user to check inventory levels, consult master data, and read/enter data about the consumption of parts. The application runs approximately 20,000 transactions per hour, serving 2,000 users via 800 terminals. Figure 2.10 shows two screen shots of the VA-1 application. The screen shown in figure 2.10a is used to enter the part (here an airplane tire) whose stock level to check. The user interface allows various ways to enter this information. For example, a maintenance engineer may search for a part using a keyword (TREFWOORD). Alternatively, a part may be retrieved if its NATO stock number (NSN) is known. NSN is a 13-digit number that uniquely identifies a (stock) item, serving to facilitate exchange of logistical information between the defense information systems that collaborate in the context of NATO. After the item is found and validated, the user may press PF-9 to ask for stock levels. The result of pressing PF-9 is displayed in figure 2.10b. This screen summarizes the number of usable items (BRUIK-BAAR) as well as the number of items no longer usable (ONBRKB/HERST) or in repair (IN REP). The VA-2 application, Inventory Management, Control, and Reverse Logistics has been in use since 1989. It may be accessed by VA-1 to make projections about future use of parts in case a part is no longer available or falls below a certain stock level. In addition, VA-2 administratively processes returned goods. Like VA-1, it was programmed in COBOL/CA-ADS, uses an IDMS repository, and runs in an MVS environment. It processes roughly 32,000 transactions per day, serving approximately 2,000 users. After projected requirements for a tire have been produced, a purchase requisition is issued to the ALVA System. Its software and hardware environment are similar to those of VA-1 and VA-2. This system has been operational since 1976, running on average 750 transactions per day. Its main tasks are to support the process of issuing tenders to suppliers; to manage (umbrella) contracts; to validate, authorize, and create purchase orders; and to take care of the administrative changes in the ledger. It produces a purchase order that is converted to EDI/EDIFACT format, and delivered to a supplier.

45

2.9

Wrappers in Action

Figure 2.10 Screen shots of the VA-1 application.

46

Leveraging Legacy Systems

Figure 2.11 Revamped version of the VA-1 user interface.

The SAP R/3 implementation (see figure 2.9) is a human resources management application for scheduling maintenance engineers to preventive maintenance tasks. It runs in a UNIX (Solaris) environment. It requests information from VA-1 to check whether parts are available to schedule specific maintenance tasks. Wrappers were developed to Web-enable the VA-1 system and package it as a collection of Web services to be integrated more effectively with SAP/3 using SAP’s NetWeaver. In conjunction, VA-1’s graphical user interface was given a face-lift. 2.9.2

Screen Scraping

As a first pass at modernization of the VA-1 application, the look and feel of the archaic green screen were revamped using Seagull’s WinJa. The VA1 application was redeployed in a Windows environment, providing access to the back-end VA-1 application, which continued running in MVS. Hence, the enhancements were purely cosmetic. Figure 2.11 shows the new screen corresponding to the one in figure 2.10a.

47

2.9

Wrappers in Action

2.9.3

Legacy Data and Code

The business logic and data of the VA-1 application were unlocked using thin WSDL wrappers to provide access to external applications. This section discusses only one wrapper in detail. This wrapper provides access to functionality in VA-1 that is used by a maintenance engineer to find out whether parts that he requires are in stock at a particular depot. This information is stored in the IDMS repository. As outlined, this repository adopts a network model, which means that it organizes data as a network of set constructs that are interrelated by links. A set encompasses an owner record type and a member record type. Figure 2.12 depicts a fragment of an annotated Bachman diagram capturing the complex data structure of this network database. The top compartment in each box contains the name of a record. The next row describes the record ID, the record type (F = fixed, V = Variable), record length, and storage mode (CALC, VIA, or DIRECT) defining the storage location in the database. The third row contains a VIA set name or a CALC key, after it is indicated whether duplicates are allowed. The last row contains the area name. The directed lines between boxes indicate an owner/member relationship, the arrow pointing at the member(s). Triangles denote indexed sets. The following excerpt defines the element VRDCAT in figure 2.12: RECORD NAME........ VRDCAT-RS20 RECORD VERSION..... 0001 RECORD ID.......... 4157 RECORD LENGTH...... FIXED WITHIN............. ARTVRD-AS20

OFFSET

0 PCT FOR

DBKEY POSITIONS.... SET............. TYPE........ NEXT

100 PCT

PRIOR OWNER

S4156-4157-0S20

MEMBER

1

2

S4157-4158-0S20

OWNER

3

4

DATA ITEM............ USAGE....... VALUE.................. PICTURE........... 03 SORTKEY-R4157

DISPLAY

STRT

LGTH

1

2

SET CONTROL ITEM FOR --- S4156-4157-0S20 ASC DUP NOT ALLOWED 05 CATC-R4157

DISPLAY

X(02)

1

2

03 SWVCAT-R4157

DISPLAY

S9(06)

3

6

03 OP-TE-SLAAN-R4157

DISPLAY

9(08)

9

8

03 UIT-TE-SLAAN-R4157 DISPLAY

9(08)

17

8

03 FILLER-R4157

X(08)

25

8

DISPLAY

This excerpt defines the fields of record type VRDCAT, declaring the name of each field, its usage, value, picture (defining the data type and its maximum

48

Toelichting : Default suffix velden : Default suffix records : Default setnamen : Default suffix areas : Chained set :

ASSC

VWG

-Rnnnn -RS20 Snnnn-nnnn-0S20 -AS20

4152

F

20

CALCKEY

Indexed set :

SR7-4862-0S20 I MA ASC KLCAFL DL IX-ZDG

NPO OM ASC NSN DN

DN

SR7-4191-1S20 I MA ASC KLC DN IX-KLC

SR7-4191-2S20 I MA ASC KENLETTERS DL IX-KLC

F

KLC 476

4191

CALC DN

CALCKEY

F

REFGEG 44

CALC

2G SMV

NPO MA ASC SORT KEY2 DL N MA N

2F

ONDKLC

3K

OPSLAGOPDR

5H

F

60

VIA

S4155-4154-0S20

AUTART SAMENSTEL

NOTITIE

5A

2A

BSTADVIES

5C

2B SAMENSTEL

TOE

5B

2C

AWO

4E

2E

REALART

KWT 5D

4F

WAS

ART

SR7-4186-0S20 I OM ASC BANR DN IX-BST

4156

F

132

CALC

CALCKEY

DN

IND

BST F

88

4188

VIA

F

36

VIA

NP MA DSC SORTKEY1 DL

SR7-4192-1S20 I MA ASC KLCAFL/RNR DL IX-ZDG

1B

(naar)

362

CALC DN

ZDG 4192

F

NPO OM N SR7-4847-0S20 I MA ASC KLCAFZ/ KLCAFL DL IX-ZDG

BARCODE S4866-4192-0S20 NPO OM N

VERSTROPDR

S4156-4192-2S20 NPO MM L

F

CALCKEY

SR7-4192-2S20 I MA ASC KLCAFL/ KLCAFZ/RNR DL IX-ZDG

68

VIA

NPO OM ASC RNR DL

COLLO 4847

S4156-4192-0S20

CALCKEY

ZDG

ZDG

3A AANVRAAG

F

284

CALC DN

3E ZDGAVR

MPO MA N NP MA ASC SORT KEY DN

S4841-4185-0S20 NPO OM N

4862

DN

ZDG

SR7-4192-0S20 I MA ASC REFZDG DL IX-ZDG

S4156-4192-0S20 (van) NPO MA ASC SORTKEY DL

ARTVRD

ARTGEG

SR7-4185-1S20 I MA ASC KLCVZE/RNR DL IX-NAL

4186

VVB CALC

3H UITSLAGOPDR

ARTKLC

ARE 2D

60

HIST NP MA F

NPO MA ASC SORT KEY DN

NP MA DSC SORTKEY DL

F

CALCKEY

HIST

NPO MA ASC SOR TKEY DN

4154

4198

NPO MA L

DN

CALCKEY

ART

ARTIND

SR7-4862-1S20 I MA ASC KLCAFZ DL IX-ZDG

3i

UITSLAGOPDR

SR7-4185-0S20 I MA ASC WONRNAL DL IX-NAL NAL 4185

F

ARTKLCTEKST 60

VIA

4139

F

80

LOK VIA

4159

F

16

CALC

AANVRAAG 1A S4155-4186-0S20

S4155-4186-0S20

S4155-4185-0S20

S4156-4139-0S20

CALCKEY

BRIL

BRIL

BRIL

ARTKLCTEKST

ARTIND

DN

NP OA S4155-4186-0S20

F

DOCMOD

LAO

REP 4187

36

VIA

4189

F

40

VIA

4183

V

1368

VRDCAT VIA

4157

F

32

VCL VIA

NP MA N

4158

F

S4155-4186-0S20

S4155-4186-0S20

S4155-4183-0S20

S4156-4157-0S20

S4157-4158-0S20

BRIL

BRIL

DOCMOD

ARTVRD

ARTVRD

Figure 2.12 Database schema of the VA-1 IDMS repository.

68

VIA

Leveraging Legacy Systems

4155

CALC

CALC DN

ART 36

CALCKEY

48

ART

ARTIND

RFN F

F

CALCKEY

DN

NP OM ASC SORTKEY DL

4153

4822

CALC

49

2.9

Wrappers in Action

length), and the start of a field and its length. For example, the field UIT_TE_ SLAAN-R4157 is used in DISPLAY mode and is typed as an eight-digit number that starts at position 9 and may have a length of eight positions, ending at position 17 in the database file. The following routine was carved from the CA-ADS code as part of functionality for retrieving inventory information and checking whether stock is available for a particular article. If not, an error message is returned. 00012900

OBTAIN FIRST ARTKLC-RS20 WITHIN S4155-4156-0S20

00013000

ALLOW (DB-END-OF-SET).

00013100

IF NOT (DB-END-OF-SET)

00013200

DO.

00013300

WHILE NOT (DB-END-OF-SET)

00013400

REPEAT.

00013500

IF TRANSKLC-R4156 LE ZERO

00013600

DO.

00013700

IF SET S4156-4157-0S20 NOT EMPTY

00013800

DO.

00013900

GOBACK.

00014000

END.

00014100

END.

00014200

ELSE

00014300

DO.

00014400

GOBACK.

00014500

END.

00014600

OBTAIN NEXT ARTKLC-RS20 WITHIN S4155-4156-0S20

00014700 00014800

ALLOW (DB-END-OF-SET). END.

00014900

END.

00015000

MODIFY MAP TEMP CURSOR AT DFLD KLASSE-MVAMBC.

00015100

MOVE ’V084’ TO FOUTCODE-WVAW02.

00015200

MOVE ’V084’ TO FOUTCODE-WVAW02.

00015300

GOBACK.

2.9.4

Developing a Wrapper for the VA-1 System

The modernization team decided to implement a thin wrapper to directly access the legacy system’s functionality. An adapter tool from iWay, Application Explorer, was used to assist in identifying relevant code adopting a data-centric modularization strategy. CA-ADS functionality was extracted based on the access path needed to retrieve

50

Leveraging Legacy Systems

part stock information (a function-based cohesion criterion was adopted). This access path in the IDMS database is rendered as the large arrow in figure 2.12. Next, a wrapper was developed for exposing VA-1’s logic to allow maintenance engineers to inquire about inventory levels of specific parts. We employed a standard adapter of iWay, but in principle any similar adapter framework, such as IBM WebSphere Business Integration Framework, SAP Net Weaver XI, or Sonic ESB adapters, could have been used instead. The iWay adapter manager assisted in defining the following WSDL code: