Uncovering Essential Software Artifacts through Business Process Archeology Ricardo Pérez-Castillo University of Castilla-La Mancha, Spain Mario G. Piattini University of Castilla - La Mancha, Spain
A volume in the Advances in Business Information Systems and Analytics (ABISA) Book Series
Managing Director: Production Manager: Development Editor: Acquisitions Editor: Typesetter: Cover Design:
Lindsay Johnston Jennifer Yoder Austin DeMarco Kayla Wolfe John Crodian Jason Mull
Published in the United States of America by Business Science Reference (an imprint of IGI Global) 701 E. Chocolate Avenue Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail:
[email protected] Web site: http://www.igi-global.com Copyright © 2014 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
Library of Congress Cataloging-in-Publication Data
Uncovering essential software artifacts through business process archeology / Ricardo Pérez-Castillo and Mario G. Piattini, editors. pages cm Includes bibliographical references and index. ISBN 978-1-4666-4667-4 (hardcover) -- ISBN 978-1-4666-4668-1 (ebook) -- ISBN 978-1-4666-4669-8 (print & perpetual access) 1. Reengineering (Management) 2. Data mining. 3. Knowledge management. 4. Industrial management--Computer programs. I. Pérez-Castillo, Ricardo, 1984- editor of compilation. II. HD58.87.U53 2014 658.4’038--dc23 2013025562 This book is published in the IGI Global book series Advances in Business Information Systems and Analytics (ABISA) (ISSN: 2327-3275; eISSN: 2327-3283)
British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher. For electronic access to this publication, please contact:
[email protected].
177
Chapter 7
Business Process Modeling with Services: Reverse Engineering Databases Youcef Baghdadi Sultan Qaboos University, Oman Naoufel Kraiem Sultan Qaboos University, Oman
ABSTRACT Reverse engineering techniques have become very important within the maintenance process providing several benefits. They retrieve abstract representations that not only facilitate the comprehension of legacy systems but also refactor these representations. Business process archaeology has emerged as a set of techniques and tools to recover business processes from source code and to preserve the existing business functions and rules buried in legacy source code. This chapter presents a reverse engineering process and a tool to retrieve services from running databases. These services are further reused in composing business processes with respect to Service-Oriented Architecture, a new architectural style that promotes agility.
INTRODUCTION Reverse engineering techniques have become very important within the maintenance process providing several benefits. Firstly, reverse engineering allows maintainers to retrieve abstract
representations to facilitate the comprehension of different legacy systems. For example, it focuses on relational databases (Baghdadi, 2006; Cleve and Hainaut, 2008), aspect oriented systems (Bernardi, 2008), or quality of the system design (Foutse, 2009). Secondly, abstract representations obtained
DOI: 10.4018/978-1-4666-4667-4.ch007
Copyright © 2014, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Business Process Modeling with Services
by reverse engineering from legacy systems can be refactored to improve their maintainability or add new functionalities to evolve legacy systems. To address the mentioned maintenance activities, reverse engineering techniques are nowadays well-supported by tools which often obtain artifacts at system design abstraction level (e.g., service, class or sequence diagrams from source code) (Baghdadi and Al-Bulushi, 2013; Canfora and Di Penta, 2007). However, Software Engineering industry is demanding additional reverse engineering techniques and tools to retrieve business-aware artifacts at higher abstraction level (Khusidman and Ulrich, 2007). The Software Engineering Institute (SEI) argues that business rules recovery is the cornerstone to evolutionary maintenance towards modern paradigms like Service Oriented Architecture (SOA) (Lewis et al., 2010). In fact, enterprises willing to move to SOA with web services to challenge changes in business requirements need to modernize their legacy applications (Al-Rawahi and Baghdadi, 2005). Indeed, 1. SOA is mainly about reuse of assets (Cummins, 2009); in this regard, legacy applications are running smoothly and performing critical tasks, 2. Most of the business functions are locked within them (Galinium and Shabaz, 2012), 3. Legacy applications were built at high cost; and we need to preserve these investments (Linthicum, 2004), and 4. Migration to SOA can give new life to legacy applications (Bhallahmudi and Telly, 2011). A solution consists in extending the critical business logic of the legacy applications while preserving the investments, through their migration to web services and SOA environments (Baghdadi and Al-Bulushi, 2013). This leads IT departments to select an appropriate modernization technique, which requires a guidance process to avoid any failure risk (Baghdadi and Al-Blushi, 2013).
178
The process would include analysis, selection of business functions, and wrapping. In addition, Business Process (BP) reengineering, innovation and improvement have always been given much attention in any organization (Davenport, 1993; Hammer and Champy, 993, Wekse, 2007; ver den Aalst, 2012). To meet these demands, Business Process Archeology (BPA) has emerged as a set of techniques and tools to recover Business Processes (BPs) from source code (Pérez-Castillo et al., 2011). BPA studies the BPs in an organization by analyzing the existing software artifacts. The objective is to discover the business forces that motivated the construction of the enterprise information systems. Maintenance benefits of BPA are that they preserve business behavior buried in legacy source code and it retrieves BPs providing more opportunities for refactoring (Pérez-Castillo et al., 2011). Some techniques in literature support BP recovery. For instances, Zou et al. (2006) recover workflows by statically analyzing source code and applying some heuristic rules to discover business knowledge. Paradauskas et al. (2006) retrieve business knowledge through the inspection of the data stored in databases. DiFrancescomarino et al. (2009) consider graphical user interfaces of web applications to discover BPs. Cai et al. (2009) combine requirement reacquisition based on use cases with dynamic and static analysis techniques. Finally, van der Aalst et al. (2009) focus on mining BPs from event logs registered during system execution. Recently service-orientation starts making its way in information systems by promoting BPs as compositions of loosely coupled services having separated concerns (Baghdadi, 2012). For instances, in (Baghdadi, 2004; Baghdadi 2005), the author showed how to integrate BPs, namely B2B with web services that are derived from a business model. Jaeger (2006) established the relations between workflow modeling and BP for service composition. He explains the differences
Business Process Modeling with Services
between BPs and workflow languages and why service compositions are used in this field. Cauvet and Guzelian (2008) proposed an approach for designing BPs in service-oriented way, where a service composition process organizes the discovery, selection and the assembly of business services to build dynamically BPs tailored to business designer’s requirements. In his thesis, Stein (2009) investigated how to extend Even-Process Chain (EPC) to come up with a new modeling language for service-oriented BP management. Cummins (2009) describes a process-driven service, where the focus is on the application of SOA principles to design an enterprise as a set of service units that provide services to BPs. Finally, it is worth to mention the service-oriented standards such BPEL and WS-CDL used to specify a static composition of web services; and execute it with engines such as BPEL4J. Van der Aalst et al. (2007) presaged a wide variety of process-aware information systems will be realized by using the powerful language that is BPEL though it is difficult to use. More importantly, the survey conducted by Indulska et al., (2009) shows that academics raised the importance of service-oriented as one of the top-three issues to deal within BPs, though it was not similarly perceived by practitioners and tool vendors. However, the authors argued that research takes a few years to be assimilated into industry and products. In academics world, the work is line in line with service-orientation findings that promote the use of different types of services to model BPs; and to extend BPEL with aspect-orientation in order to make the compositions more dynamic as suggested by (Charfi, A. and Mezini, M. 2007). To sum up, service-oriented approach provides a basis to redesign BPs for improving business competiveness (Baghdadi, 2013). In this chapter, we provide a reverse engineering process and a tool to retrieve services from running databases. These services are further reused in composing BPs with respect to SOA, a new architectural style that promotes agility.
The remainder of this chapter is organized as follows. In section 2, we present a business scenario as running case demonstrating the concepts introduced in the chapter, where we address a production process illustrated in the BPMN model. In section 3, we explain the relationship of BPA to business agility. In section 4, we show the role of SOA in modernizing BPs. In section 5, we present a state of art in modernizing legacy systems by using services, including the existing service-oriented approaches. Section 6 details a relational database reverse engineering process. Section 7 presentes the tool. Finally, a conclusion section summarizes our findings and present further development.
Business Scenario ‘YB’ enterprise sells items that are other enterprises such as ‘NB’ manufacture. ‘YB’ and ‘NB’ are both subject to regular (e.g., ‘Customer Order’) or disruptive (e.g., ‘Customer Last-Minute Order’) events, and hence, should act upon them promptly and efficiently. This means that both enterprises need to agree on the value to add to customers in terms of goods/services delivery, timely delivery, and the providers of services (or service units) that achieve this value, how to interact with these services, and how these services interact with each other. The actions that enterprises take are reported in dedicated BP such as ‘Order Entry’ as shown in Table 1. This table also shows an example of event and the service providers that both ‘YB’ and ‘NB’ agree upon. For instance, ‘Customer Order’ event will need response from ‘YB’ in partnership with ‘NB’. For this purpose, this BP uses different BOs such as ‘Customer’, ‘Order’, ‘Inventory’, and ‘Bill’ that provide the necessary activities such as ‘Filling Order’, ‘Picking Order’, ‘Packing Order’, ‘Shipping Goods’, ‘Tracking Shipment’, ‘Billing Order’, ‘Paying Order’, ‘Checking Availability’, ‘Checking Balance’, and ‘Getting Quotation’; and data such as ‘Customer Balance’, ‘Customer Ad-
179
Business Process Modeling with Services
Table 1. Summary of ‘YB’ and ‘NB’ BOs activities and data ‘YB’ Enterprise Event
BP
Customer Order
BOs
Order Entry
• Customer • Item • Order • Invoice • Supplier (‘NB’)
‘NB’ Enterprise: partner Activities/Data
BOs
• Filling Order • Tracking Shipment • Invoicing Order • Paying Order • Checking Availability • Checking Balance
• Stock • Customer (‘YB’) • Bill
dress’, ‘Order Total Amount’, ‘Item Price’. These activities and data are encapsulated within the BOs and provided as services to the BPs. In fact, BOs, implemented in the information systems of both ‘YB’ and ‘NB’ play the role of service providers as they provide their activities and data as services. For tracking purposes, we associate the progress of a BP with a multi-valued state (including initial and final states) that changes over time when the services complete. Each change in a state is indicated with a value and description. Table 2 shows ‘Order Entry’ BP and its possible state values and descriptions. The latter are decided at design-time of the BP. It is now possible to identify the activities that were performed and the activities that will be performed subject to satisfying some conditions. A state can be a precondition for triggering an activity or a postcondition for an activity. Each involved activity is a state transition.
Activities/Data • Picking Order • Packing Order • Shipping Goods • Billing Order • Get Quotation
Business Agility and Business Process Archeology This section introduces the role BP archaeologist plays in the Enterprise Transformation (ET) process and enterprise agility readiness. It also details how BPs are defined, approached, and modeled.
Enterprise Transformation The concept of Enterprise Transformation (ET) has become popular, as enterprises face changes both locally in their own context and in their environment (Purchase et al., 2011) These changes alter the business model, namely the BPs, including enterprise operations and interdependencies and interrelationships within and across the enterprise. These changes are mostly enabled, if not driven, by Information Technology (IT). Indeed, IT revolution has driven the speed of competition
Table 2. Elements related to the running example BP Order Entry
180
State Value
State Description
Triggered Activity/Requested Data using the state Pre-condition for
Post-condition of
0
Order received
Initial State
Check Credibility
1
Credibility checked
Checking Availability
Fill Order
2
Availability checked
Filling Order
Ship Order
3
Order filled
Shipping Order
Bill Order
4
Order shipped
Billing Order
Pay Order
5
Order billed
Paying+ Order
Close Order
6
Order paid
Final State
//
Business Process Modeling with Services
and rapid globalization. According to Rouse and Baba (Rouse and Baba, 2006), technologies can be both drivers and enablers of ET. More specifically, many people see IT as both the driving force behind change and as the enabler of change. Examples include BP management, collaboration technology, and increasingly social interaction technologies such as Social Networks. Nowadays the concern is how IT is changing the ways enterprises transform, not how to make IT work, or even how to align it with business. That is IT, mostly drives and enables the required agility for any ET process.
Enterprise Agility Agility is a critical quality that today’s enterprises should possess. An agile enterprise is the one that grasps business opportunities on the fly and adapts rapidly and efficiently to changing business requirements with limited impact on its operation (Cummins, 2009) To be agile, enterprises need to make sure that their BPs are conceived in a way that these BPs can respond to regular or disruptive BEs; and adapt to change in crossing business functions and rules. Therefore, one needs to question and understand: • • • •
What are BPs How to represent them How to mine and detect them How to reengineer and modernize them with new IT
The role to question and understand is mainly incumbent on BP archaeologists and designers.
Business Processes Although, this paper is concerned with reengineering, improvement and innovation of BPs by using BPA, it is worth providing some definitions within this scope and to position ours. A number
of definitions of BPs are reported in the literature (Basu and Muylle, 2011; Lindsay et al., 2003; Lodhi et al., 2011). Definitions that are oriented towards a management perspective are given by Weske (2007), Davenport (1993), and Hammer and Champy (1993). From a management perspective where the focus is on using organizational and technical resources for effective execution of BPs, Weske (2007) defines a BP as “a set of activities that are performed in coordination in an organizational and technical environment.” From an innovation perspective, Davenport (1993) defines a BP as “a structured, measured set of activities designed to produce a specific output for a particular customer or market”. From a reengineering perspective, Hammer and Champy (1993) define a BP as “a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.” Despite these multiple definitions, Jacobson (1995), notes that “the confusion surrounding BPs by their invisible nature that they are neither named nor described”. We consider an agility and responsiveness perspective to first provide a definition that treats a BP as an artifact that defines a dynamic composition of concrete activities and data, provided as services that add value to customers. Then we will build on this definition to provide a new service-oriented BP modeling. Agility poses new challenges to manage effectively BPs(Weske, 2007). To achieve this agility, selection of the approach that permits managing enterprises BPs is critical (Mendling et al., 2010). BP modeling is an important element to the successful management of BPs (Lodhi et al. 2011). It increases the ability to understand a BP in order to make rational decisions for organizing activities (Cumberlidge, 2007). Yet, BP modeling is a complicated task as shown by various modeling techniques, languages and hundreds of tools (Lu and Sadiq, 2007). Most of the surveys, comparative, analytical and
181
Business Process Modeling with Services
empirical studies that have been carried out (Aldin and de Cesare, 2009; Indulska et al., 2009; Recker et al., 2009; Recker et al., 2010; Skrinjar et al., 2013) indicate that: (i) BP management and modeling have different perspectives (Hull et al., 2012), and (ii) many challenges are still facing BP modeling (ver den Aalst, 2012). Nevertheless, two dominant approaches to BP modeling can be observed: (1) graphical models (e.g., Even-driven Process Chains (EPC), Business Management Process Notation (BMPN), and Unified Modeling Language (UML), and (2) rule specifications that are mostly used in workflow coordination like AgFlow or exception handling like AgentWork. Regardless of the approaches, the processoriented BP modeling that focuses on the control flow of activities is the most dominant, though, recently a business artifact-centric approach (aka as artifact-centric and dual to process-centric approach) proposes to model a BP as a set of interacting artifacts that exchange messages affecting their respective lifecycles (Cohn and Hull, 2009). Figure 1.‘Order Entry’ BP model using BPMN 2.0
182
To achieve optimal BP management, it is necessary to represent BPs, namely, control flow, data flow, activities, roles, actors, and goals by means of a notation easily understood by the different stakeholders involved in their management. The most important notations are UML and Business Processes Model and Notation (BPMN) (OMG). The Business Process Diagram (BPD) of BPMN is a well-known graphical notation and is easily understood by system analysts as well as business analysts. BPMN uses standardized graphical elements to model and represent BPs as diagrams. BPMN includes event, activity, gateway, sequence flow, message flow, association, pool, lane, data object, group, text annotation, and attributes. Figure 1 shows the ‘Order Entry’ BP with BPD. In these BP modeling approaches, the focus is on specific perspectives, features, and capabilities or the process-data duality (Kuraman et al., 2008). Unfortunately, the dynamic nature of BPs is not stressed out in these approaches; neither have they considered adopting Service-Oriented Architecture (SOA) principles when designing
Business Process Modeling with Services
BPs (Baghdadi, 2012; Erl, 2009). Therefore, we consider BPs modeled with the aforementioned approaches and enacted and executed by Workflow systems as legacy systems that need to be modernized.
Legacy Systems and Business Process Archeology (BPA) This section introduce how existing BPs are mined and detected through the concept BPA.
Legacy Systems Legacy information systems can be an obstacle to business process management, since these systems have evolved independently from the organization’s business processes (Heuvel, 2006). According to (Paradauskas and Laurikaitis, 2007), ‘‘a legacy information system is any information system that significantly resists modification and evolution to meet new and constantly changing business requirements’’. Hunt and Thomas (2002) go further to state that the ‘‘code becomes legacy code just about as soon as it is written’’. The independent evolution from the BPs is due to the uncontrolled maintenance of legacy information systems. Indeed, according to the study provided by Koskinenet al. (2005), changes in a BP is the third criterion (among a list of 49 software modernization decision criteria) to modify the information systems. Unfortunately, source code modifications usually do not have any effect on original BPs, which do not have the respective change. This fact means that legacy systems embed a significant amount of business knowledge that is not defined in the original set of BPs. In this scenario, BPA (Moyer, 2009; PérezCastillo et al., 2011) is necessary to obtain the current set of BPs.
Business Process Archeology (BPA) BPA is the engineering activity that studies the BPs in an organization by analyzing the existing software artifacts in that organization. The objective is to discover the business forces that motivated the construction of the enterprise information systems (EISs). Real archeologists investigate several artifacts and situations, trying to understand what they are looking at, i.e., they must understand the cultural and civilizing forces that produced those artifacts. In the same way, a BP archeologist analyzes different legacy artifacts such as source code, databases and user interfaces and then tries to learn what the enterprise was thinking to understand why the enterprise developed the IS. Table 3 makes the analogy between Traditional Archaeology (TA) and BPA. Any change in business requirements or IT innovations requires the enterprise new solutions that need re-engineering BPs. One of the most efficient mean is to follow the SOA. Indeed, the existing approaches for BPs have not emphasized their dynamic nature; neither have they considered how to mining, detect, and re-architect the enterprise BPs by applying new concepts, architecture, design, and technologies such as BPA, services, SO, SOA, and Web Services (WS).
From Legacy to Service: State of Art A BP archeologist would mostly wrap legacy applications. However, implementing a wrapper depends on how the legacy application will be accessed: session based, transaction based or data based. Therefore, we (Baghdadi and Al-Bulushi, 2013) have proposed three basic approaches to wrap legacy applications into web services: (1) Session Based Approach, (2) Transaction Based Approach and (3) Data Based Approach.
183
Business Process Modeling with Services
Table 3. Parallel between TA and BPA TA1
BPA
The Roman civilization emerges.
An enterprise has a BP such ‘Order Entry’, which may be formalized or not; this does not matter.
The Roman civilization produces monuments, writings, documents, etc. The monuments and other artifacts undergo maintenance and alterations over time
BPs such as ‘Order Entry’ are not automated, semi-automated or fully automated within the EIS. They may be represented by means of descriptions of BPs such as UML2 or BPMN diagrams, which also undergo maintenance and alterations over time.
The ancient Roman civilization disappears but the remains of the monuments, documents, etc. survive the test of time
In BPA, the description of the BPs may disappear (or may not).
The archeologists study the monumental remains together with documentation from that era to rebuild and understand the Roman civilization.
BPs archaeologists analyze software artifacts by means of reverse engineering and other techniques to reconstruct the BP. Software artifacts can already be in use, however the current use can differ of the original use for which those were conceived (i.e., BPs and legacy ISs are not aligned). In addition, actors who know BPs and legacy ISs could not be present in the organization at that moment (e.g., maintainers are seldom the same people who initially developed the information system).
The Session Based Approach
The Data Based Approach
The Session Based Approach is used when the legacy application is written in a way such that the business logic and presentation interface are not clearly separated. A graphical user interface (GUI) is required to be built on top of the legacy application. In this approach, only the presentation layer of the legacy application is modified, the logic and work flow remains unchanged. This approach offers a “one way” service because the legacy application can be exposed as a Web service, but it cannot consume other Web services.
The Data Based Approach is used when an access to operational and transactional data residing on databases without going through business logic. It requires a standard connectivity to the databases and data sources. It offers a “one way” service too. In the following section, we are interested in the data-centric approach to reverse engineer relational databases (RDBs).
The Transaction Based Approach The Transaction Based Approach is used in a well structured legacy application with separate and distinct layers for data access, business logic and presentation. The transactions are performed on the legacy application without disrupting the state of application. Unlike Session Based Approach, the Transaction Based Approach offers a “two- way” Web service because it allows the legacy application to expose its functionalities and consume other Web services.
184
Role of SOA This sections introduces SOA, its components that are services, namely WSs, and how they are shaped with SO.
SOA, SO, and Web-Enabled Services OASIS (OASIS, 2006) defines SOA as “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations”.
Business Process Modeling with Services
Actually SOA is originally an architectural approach for business (Cummins, 2009; Cater, 2011). However, it may also be considered as computational architecture (Bean, 2010; Davies et al., 2008; Erl, 2009) as it may be seen as an evolution of the component-based engineering and distributed computing paradigms and architectures such as RPC, CORBA, DCOM, RMI, and EJB. Originally, SOA involves three actors and three operations. The actors are: service provider, service consumer, and registry, whereas the operations are: publish, find, and bind as shown in Figure 2. SOA enables sharing of capabilities provided as services. Applying the principles of SOA to BPs promotes BPs to evolve from development from scratch to reverse engineering legacy systems by using BPA techniques (e.g., using wrapping mechanisms), and ultimately to design of software systems on-the-fly as software systems supporting new solutions are more and more required (Tang et al., 2010). With respect to BPs, SOA would fulfill the following:
d. Services are interoperable 2. Interaction and communication mechanisms are based on messages to exchange documents 3. Composition and service organization and management, including inventory and discoverability mechanisms, whereby a composition defines: a. The components involved as services b. The service relationships in terms of (co-)values creation c. The orderly execution of these services d. The controlling of their execution and their interactions, in terms of messages, that are publishing, finding, binding, and substituting services e. The dependability of the services f. The exceptions
1. Consumers, providers and registry are all services, where: a. Services have separated concerns b. Services have hidden implementation c. Services are loosely coupled
SO is defined in (Erl, 2008) as “a design paradigm comprised of a set of design principles, whereby a design principle is an accepted industry practice”. In this definition, the service is the most
However, for SOA to fulfill these requirements, its services need to be shaped with some principles by SO.
SO
Figure 2. SOA actors and roles
185
Business Process Modeling with Services
fundamental unit for building a service-oriented solution. However, to comply with SO and to be an element of composition, a service should exhibit some desirable principles (Erl, 2008) in addition to its fundamental properties, which enforces loose coupling and interoperability in addition to the well-known principles of separation of concerns and information hiding as shown in Table 4. These desirable properties are: Self-description, Self-containment, Standard Contract, Sharing and Reuse, Discoverability, Abstraction, Autonomy, Stateless, and Granularity (Erl, 2009). It is worth noting that the desirable service properties are related to each other; and individually or grouped support loose coupling, interoperability, separation of concerns and information hiding. There are several known SOA technologies such as: Java RMI, CORBA and DCOM, but the most efficient realization of SOA is Web Services.
Web-Enabled Services From (WC3, 2010), we can compile a set of properties to define a Web-enabled service as a computational resource that is identifiable by a
unique identifier. It performs one or more tasks through an agent (e.g., a provider agent that is a software unit); and is used by a requester agent. It has a description and an interface. The description is a machine-processable description of the service’s interface that shows the messages that are exchanged by the service. The interface defines the messages relevant to the service, that is, the different types of messages that the service sends and receives, along with the message exchange patterns that may be used. In addition, a service description may include one or more policies applied to it. Finally, a description is expressed in a service description language. In addition, services should: (i) define the semantics of their functional (e.g. capabilities), non-functional (e.g. quality of service), and policy requirements in a machine-readable standard and (ii) communicate through messaging protocols built on top of the Internet protocols (W3C, 2010). We extend these definitions to consider that Web-enabled service inherits the fundamental properties and principles of service considered as (co-)value creation, where the interface describes the contract between the (co-)value creator agents that interact via request and respond messages. A messaging style is used rather than a Remote
Table 4. How our approach relates to BPEL Our BP modeling
BPEL
BP is an abstraction
BPEL is a process-oriented web service compoistion language
BP is a definition of composition of services that constitute activities and data provided by BOs
BPEL specifies the exact order in which partner web services should be invoked
BP is represented by a state
BPEL has a set of variables
BP has controller web service
BPEL is a web service
BP has a set of worker services
BPLE has web service partners
BP conforms with SOA
BPEL conforms with SOA
BP is dynamic allowing flexibility and agility
BPEL is static
BP responds to disruptive event-centric
BPEL responds to well-defined clients
BOs are identifiable enterprise assets BOs play the role of service units or factories
BPEL does not specifies the source of the partners
186
Business Process Modeling with Services
Procedure Call (RPC) in order to enable loose coupling. Indeed, with messaging, loose coupling is achieved more easily since the focus is on the contract that the interface provides rather than the underlying implementation details.
E-Service An e-service is defined as “a collection of network-resident software services accessible via standardized protocols, whose functionality can be automatically discovered and integrated into applications or composed to form more complex services” (Cordosoet al., 2008).
Web Service (WS) A WS is “a software application identified by a URI, whose interface and binding are capable of being defined, described, and discovered as XML artifacts. A WS supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols” (W3C, 2010).
Data Service (DS) A DS is a kind of WS optimized for real-time data integration demands of SOA (Composite Software, 2008). DSs are software services that encapsulate operations on key data of relevance to the enterprise (Narayanan, 2009). WSs exchange information in a manner prescribed by its contract (interface) using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
Service-Oriented Approaches to BPs In service-oriented approaches, Cummins (2009) describes a process-driven service, where the focus is on the application of SOA principles to
architect an enterprise as a set of service units that provide services to BPs Although academics raised the importance of service-oriented as one of the top 3 issues to deal with, it was not similarly perceived by practitioners and tool vendors. Indulskaet al. (2009) argue that research takes a few years to be assimilated into industry. The authors in (Krai and Zemlika, 2005) note the lack of tools to support BP with service-oriented software systems. However, it is worth to mention the serviceoriented standards such BPEL and WS-CDL used to specify a static composition of WSs; and execute it with engines such as BPEL4J. As academics, our current work is in line with service-orientation findings (Charfi and Mezini, 2007; Erl, 2009; Erl, 2008; Papazoglouet al., 2008; Thomas and Broke, 2010) that promote the use of different types of services to model BPs; and to extend BPEL with aspect-orientation in order to make the compositions more dynamic. Indeed, The existing standards such as BPEL and WS-CDL specify a static composition of WSs. To achieve enterprise agility, we use a serviceoriented approach to model BPs by: 1. Adopting SO: SOA is expected to help address the complexity and flexibility issues of BPs and add value to BPs modeling (Zimmerman et al., 2005). 2. Using services and service units that play the roles of service providers (Cummins, 2009). The enterprise capabilities such as ‘Fill Order’, ‘Track Shipment’, ‘Invoice Order’, ‘Pay Order’, ‘Check Availability’, and ‘Check Balance’ would be candidate services provided by enterprise assets that are BOs such as ‘Customers’, ‘Product’, or ‘Bill’. Therefore, these BOs are service units. These services and service units become building blocks of BPs. 3. Using standards such as WSs technology (Papazouglou, 2008; W3C, 2010;), BPEL, or WS-CDL. Indeed, WSs technology is the
187
Business Process Modeling with Services
most suitable realization of SOA (Biancoet al., 2007), whereas BPEL and WS-CDL would abstract respectively a BP orchestration or choreography. A service-oriented approach that fully complies with SOA and SO would add value to BP modeling in terms of agility, flexibility, and support for dynamic adaptation to changes in business functions and rules. Abstracting and building a BP as set of specialized services having separated concerns, where the controller service reacts to the state changes by invoking the adequate worker services (interfacing the operations of the BO), makes the BP more flexible and reduces the complexity of its control. Indeed, any change in the business functions or rules is reflected in the state, and accordingly in the controller service, which allows a dynamic composition of software solutions supporting changing BPs. The BP modeler deals only with the state management. Therefore, we define a BP as an abstraction that is realized by using a state and a set of services provided by BOs playing the role of service units. Figure 3 shows the modeling of BPs. Table 4 shows how the modeling relates to BPEL. However implementing SOA with WSs requires BP archeologists to evaluate their systems architectures and determine how they will deliver WSs.
Figure 3.Concepts of BP modeling with services
188
One aspect of this great issue is to deal with legacy applications which are running smoothly and performing critical tasks, but were built without taking the advent of new technologies. These applications, built at high cost over years, have knowledge locked within them and need to be adapted to SOA
Reverse Engineering Databases into Web Services Many projects concern with reverse engineering. Van den Brand et al. in (1997) compiled an annotated bibliography grouped by topics including those related to reverse engineering data model, especially relational model in order to move to: (C1) new data model, paradigm, or even technology such as object-oriented data model or XML, or (C2) new system architecture such as multi-tier architecture or service-oriented architecture. Reverse engineering is a software engineering technique. This technique consists of extracting design specifications of an existing system in order to allow its maintenance (or building) taking into account: • • •
New architecture such as SOA or multitiered architectures New paradigm such as OO or SO New data model such as relational/object, object model, or XML
Business Process Modeling with Services
• •
New technology such as XML or Web services) Changes business requirements in terms of information and business rules
The interest and rationale of reverse reengineering come from the difficulty and the high cost to maintain large software systems or to build them from scratch (Van den Brandt et al., 1997). BP archeologists detect and use the past development efforts to reduce maintenance expense and improve software flexibility. Reverse engineering is applicable not only to diverse software such as programming code, but also to databases (DBs), where various reasons do exist for reverse engineering a DBs (e.g., from hierarchical/network to relational, from relational to object-oriented, from relational to XML). This chapter focuses on reserve engineering running RDBs (Baghdadi, 2006), the most successful DBs thanks notably to SQL, with respect to SO, in order to transform DBs applications supporting BPS into SOA. In SOA, the applications can access DBs through WSs instead of embedded, tightly coupled SQL statements. In this context, the reverse engineering process is intended to produce a sound and complete set of cohesive, loosely coupled, well-interfaced, basic WSs implementing common business logic and data manipulation. The resulting WSs allow an automated discovery, selection, and binding for
a dynamic composition of either coarse-grained WSs, or e-business applications. The reverse engineering process uses some architectural and design patterns.
Motivation: SOA as an Architectural Pattern The aim is to move from the current architecture of applications, which embed tightly coupled SQL statements and using middleware API such as ODBC (Open Database Connectivity) and JDBC (Java Database Connectivity) to access RDBs, to a SOA. In SOA, SQL statements,host by the applications running against the DBs, are insulated from the main logic of the applications to become loosely coupled and reusable. Thus, the applications will communicate with the DBs through WSs they select from a registry (e.g., UDDI) as shown in Figure 4 and instantiated in Figure 5. It is then the responsibility of the WS provider, not the applications, to implement factored SQL statements representing common logic and data manipulation. The advantages of the proposed approach based on WSs are: •
Insulation of the SQL Statement from the Logic of the Applications: The implementations of CRUD operations, some stored procedures, and triggers with SQL are hid-
Figure 4. Current and proposed applications architecture compared (Baghdadi, 2006)
189
Business Process Modeling with Services
Figure 5. WS-based SOA exemplified
•
• •
190
den to the applications. The applications will see only the interfaces of such CRUD operations. Fowler in (Fowler, 2003) quotes “it’s wise to separate SQL access from the applications logic”. The SQL statements used in different applications can be factored and implemented as a reusable WSs instead of repeating the same SQL code. Indeed, in many applications, the same SQL statement is implemented many times with different applications. For instance the implementations of the functions ‘getByType(String)’ or ‘getBalance(int)’ with SQL are used by different applications such as the one supporting the ‘Order Entry’ BP as shown in Figure 5, or ‘Customer Relationship Management’ and other applications needing customers’ information. The factoring will enhance the reuse of code, which is accessed as WS through well-specified interfaces with WSDL. Factored SQL statements become loosely coupled as they are specified with WSDL and implemented as WSs. The access to DBs is simplified through friendly discoverable interfaces than embedded SQL. Although almost all programming languages can host SQL, WSs are most suitable to fit within any pro-
•
•
•
•
gramming language due notably to their underlying standards that allow them to be loosely coupled. The application developers do not deal with the problems of defining effective SQL queries and commands, neither the optimization of the code. It is up to the providers of the WSs to deal with it. This will lighten the load of the developers who have difficulties with SQL. Improved data security and integrity by: (i) controlling indirect access to objects from non privileged users with security privileges, (ii) ensure that related actions are performed together in atomic transaction, or not at all. Improved performance by exploiting shared SQL, i.e. avoiding recompiling and testing same SQL statements for multiple users. Improved maintenance by upgrading or modifying SQL statements without affecting multiple applications
Design Patterns A pattern defines a recurring solution to a recurring problem in some context (Boochet al., 1999). That is, a design pattern represents a well-known
Business Process Modeling with Services
solution to common design problems in a given context. There are several categories of patterns. Generally, each category corresponds to a certain level of abstraction. For instance, the architectural patterns deal with the global properties and architecture of systems at a high abstraction level. The design patterns are widely used in lower levels of abstraction, for instance, they concern with the process of designing components based systems in which reusable units must be identified (Crnkovic et al., 2002). The most famous objectoriented design patterns collection of 23 design patterns is contained in the book of Gamma et al. (Gamma et al., 1995):. Therefore, the BPs will use an architectural pattern, where SOA presents a solution to cross boundary BPs as shown in Figures 4 and 5, and two well-known design patterns: the schema transformation pattern and the CRUD operation pattern.
Transformation Patterns In the context of reverse engineering RDBs, the schema transformation pattern helps in the identification stage of the services. The transformation pattern consists of mapping a normalized relational schema specified as a set of relation schemas and a set of constraints (domains, primary keys, and foreign keys) into a set of named, basic WSs. It transforms each relation schema into one basic WS. That is, the organization and interfacing of the WSs are based on the DB table descriptions in the data dictionary so that we get one service for each table. This transformation pattern: one table-one service ensures: •
A cohesion of the WS because the attributes of a normalized relation schema are already aggregated using functional dependency constraint. That is, these attributes generally undergo the same set of business events or use cases, which presage a set of
•
pre-defined, related operations as a unit of specification. Uniform interface to each table: the WS interface will form a uniform access to the DB table. For instance, the customer table will provide a WS whose interface is described in WSDL and used by all the applications that uses ‘Customer’ as shown in the Figure 8.
CRUD Operations Pattern The CRUD operations pattern helps in the specification stage of the abstract part of the named WSs. That is, the operations related to one table (one WS) are specified in terms of input, output or exception messages, and then aggregated into port types. First, the CUD (create, update, delete) part of CRUD constitutes a common set of operations. Each row of a relation instance (table) represents the state of an object or a relationship between objects: •
•
The create operation implements the instantiation and initialization of the state. For instance, the object ‘Order’ is initialized once, i.e. when the ‘New order’ event occurs. The update operation implements the different changes in the state. A state may change after an event has happened, i.e., a post-event change, or before the event occurs, i.e., a pre-event change. The pre-event change in the state generally triggers the event or assists its realization. For instance, the object ‘Order’ undergoes many events as shown in Table 1. The status ‘received’ is changed after the ‘New order’ event has happened, whereas the status ‘prepared’ is changed before the ‘shipment’ event occurs, it triggers and assists it.
191
Business Process Modeling with Services
•
The delete operation implements the drop operation. This operation is invoked whenever an object is no longer utile.
Then, this set is completed by many R (retrieve) operations in accordance with the context requirements because we need to know the state of the objects in order to trigger or to assist the realization of some events. That is all the preevent states must be provided by their respective objects as services. For instance, ‘Ship Order’ is an event, it cannot be triggered and realized if the object ‘Order’ cannot provide its state ‘Prepared’, likewise the ‘Pay Bill’ event cannot be triggered if the order status is not ‘shipped’. That is, retrieve operation is basically used to trigger BEs events, which constitutes a means to identify them. The CRUD operation pattern ensures: 1. A specification of the portTypes for each service, i.e. each CRUD operation is mapped into a portType operation. For instance, the portType of the ‘Customer’ service provided
in Figure 5 and Table 5 is made up of a set of CRUD operations related to the customer table in the DB. 2. A specification of each operation in terms of input message, output message, or exception (fault) message, i.e. the input and output parameters of a CRUD operation are mapped into parts (attributes of the input and output messages referenced by the operation as shown in Table 7. 3. Generation of the implementation of the CRUD operations provided by the service in term of generic SQL statements. The SQL statements that access the DB table are embedded into the services which are registered to become easy to find and used by the applications. The transformation pattern and CRUD operation pattern will be used as techniques to reverse engineering relational databases.
Table 5. Transformation of the tables of the running case into Web services Port type
Operation
Message in
Message out/Fault
Customer
Insert1_Customer
• tn: string (e.g. table Customer) • lv: complex data type (e.g. < 10, N1, BA1,SA1,T1, 0>)
• ack: Boolean or • Exception
Insert2_Customer
• tn: string (e.g. table Customer) • la: complex data type (e.g. (CID, NAME, BA, TY)) • lv: complex data type (e.g. )
• ack: Boolean or • Exception
Delete1_Customer
• tn: string (e.g. table Customer) • pk: complex data type (e.g. )
• ack: Boolean or • Exception
Delete2_Customer
• tn: string (e.g. table Customer) • wc: string (e.g. where cid = 20)
• ack: Boolean or • Exception
Update1_Customer
• tn: string (e.g. table Customer) • la: complex data type (e.g. BAL) • lnv: complex data type (e.g. ) • wc: string (e.g. where cid = 10)
• ack: Boolean or • Exception
getBalance_Customer
• tn: string (e.g. table Customer) • lt: list of tables (e.g. table Customer) • wc: string (e.g. where cid = 20) • at: list of attributes (e.g. NAME)
• res: Double or • Exception
192
Business Process Modeling with Services
Reengineering Process The process of identifying WSs is mainly a reverse engineering process, which is mainly based on transformation and CRUD patterns. Later on, a forward engineering process will reuse the resulting WSs to compose and implement more coarse-grained Web services, business processes, or any e-business solutions. The process consists of mapping running RDBs into a set of basic, fine-grained WSs as shown in Figure 6.
Reverse Engineering Steps The reverse engineering process is made up of three main steps to reverse the relational schema into a sound and complete cohesive, loosely coupled, well-interfaced, basic WSs. Step 1: The schema transformation pattern allows an identification of the WS according to the transformation of each relation schema into a WS. It consists of a mapping service that takes a relation schema as input, to provide just identified, named, basic WSs as output. At this stage, the abstract part, namely the
service portType has not been yet specified. For instance, the tables ‘Customer’, ‘Order’, ‘Product’ and ‘Item’ are candidate to provide WSs. Step 2: The CRUD operation pattern allows the specification of the abstract part i.e. the portType, including the aggregated operations and the referenced message, of the identified services obtained in the first step by identifying their respective set of operations, and the input and output messages for each operation. The CUD (Create, Update, Delete) part of CRUD constitutes a minimal set of operations. Then, this minimal set is completed by many R (retrieve) operations in accordance with application requirements Table 5 shows the WSs related to the customer table of the running case. Step 3: Implement and deploy the resulting WSs then publish their description.
Forward Engineering Process The forward engineering process allows reusing the resulting Web services in different types of compositions such as coarse-grained Web services, applications, business processes, or new e-business
Figure 6. Reengineering process (Baghdadi, 2006)
193
Business Process Modeling with Services
solutions. This process is no longer an issue today. For instance, each e-business solution may be specified in a Web service flow language such as BPEL4WS, which can invoke the repository to provide it with the required basic Web services for its implementation.
CASE Tool Specification The reverse engineering process is implemented as a CASE tool that assists identification, specification, and implementation of a sound and complete set of WSs that are basic, common business logic (Baghdadi, 2006). The resulting WSs are stored in a repository, which provides a means for discovery, selection, binding, composition, and management
of WSs. Figure 7 is a sequence diagram, which shows how the CASE tool assists users in specifying and generating their Web services, whereas the 3 snapshots in Tables 6-8 show the interface for any table (e.g. customer) is built. This interface constitutes the portType of the WSDL.
CONCLUSION AND RECOMMENDATIONS This chapter has presented a reverse engineering process to identify and specify basic Web services from an existing relational schema. The approach aims at moving to a service-oriented architecture for databases applications, whereby SQL state-
Figure 7. Interactions diagram (CASE tool-end user) (Baghdadi, 2006)
Table 6. Select a table from the data dictionary (e.g. customer) (Baghdadi, 2006)
194
Business Process Modeling with Services
Table 7. Select a CRUD operation (e.g. insert) (Baghdadi, 2006)
Table 8. Create the interface (e.g. customer interface) (Baghdadi, 2006)
ments, implementing business logic and data manipulation and embedded within applications are insulated from these applications, factored, and specified as Web services to be discovered and reused by a large number of applications. The approach is based on well-known architectural pattern that is the service-oriented architecture, and design patterns that are transformation and CRUD operations patterns. The process produces a sound and complete cohesive, loosely coupled, well-interfaced, basic Web services implementing business logic and data access. The reverse engineering process is implemented as a CASE tool that assists users in deciding the specification and design of their basic Web services. It also helps in generating the SQL code related to the CRUD operations.
The resulting set of basic Web services is intended to be reused, in a forward engineering process, to compose more coarse-grained Web services, or any e-business solution including internal or cross business processes. This is a very simple and interesting approach for organizations willing to move to a serviceoriented architecture by leveraging their most valuable assets. This work can extend to the management of the resulting Web services and the forward engineering with respect to a comprehensive reengineering process that steadily realizes the service-oriented paradigm.
195
Business Process Modeling with Services
REFERENCES Al Rawahi, N., & Baghdadi, Y. (2005). Approaches to identify and develop web services as instance of SOA architecture. In Proceedings of the IEEE-ICSSSM05 (Vol. 1, pp. 579-584). Beijing, China: IEEE. Aldin, L., & de Cesare, S. (2009). A comparative analysis of business process modeling techniques. In Proceedings of the U.K. Academy for Information Systems (UKAIS 2009). UKAIS. Baghdadi, Y. (2004). A business model for B2B integration through web services. [San Diego, CA: IEEE.]. Proceedings of the IEEE, CEC04, 187–194. Baghdadi, Y. (2005). A web services-based business interactions manager to support electronic commerce applications. In Proceedings of ACM 7th ICEC2005, (pp. 435-444). Xi’An, China: ACM. Baghdadi, Y. (2006). Reverse engineering relational databases to identify and specify basic web services with respect to service oriented computing. Information Systems Frontiers, 8(5), 395–410. doi:10.1007/s10796-006-9007-2 Baghdadi, Y. (2012). A methodology for web services-based SOA realization. International Journal of Business Information Systems, 10(3), 264–297. doi:10.1504/IJBIS.2012.047531 Baghdadi, Y. (2013). Service-oriented business process modeling: Towards agile enterprise. International Journal of Business Information Systems. Baghdadi, Y., & Al-Bulushi, W. (2013). A guidance process to modernize legacy applications for SOA. Service Oriented Computing and Applications, Online First Papers. doi:10.1007/ s11761-013-0137-3
196
Baghdadi, Y., & Al-Rawahi, N. (2006). An architecture and a method for web services design: Towards the realization of service-oriented computing. International Journal of Web and Grid Services, 2(2), 119–147. doi:10.1504/ IJWGS.2006.010804 Basu, A., & Muylle, S. (2011). Assessing and enhancing e-business processes. Electronic Commerce Research and Applications, 10, 437–499. doi:10.1016/j.elerap.2010.12.001 Bernardi, M. L. (2008). Reverse engineering of aspect oriented systems to support their comprehension, evolution, testing and assessment. In Proceedings of CSMR’08. IEEE. Bhallahamudi, P., & Telly, S. (2011). SOA migration case studies and lessons learned. In Proceedings of IEEE Int. Conference on Systems (SysCon), (pp. 123-128). IEEE. Bhattacharya, K., Hull, R., & Su, J. (2008). A data-centric design methodology for business processes. In Handbook of Research on Business Process Modeling. Hershey, PA: IGI Global. Bianco, P., Kotermanski, R., & Merson, P. (2007). Evaluating a service-oriented architecture (Technical Report CMU/SEI-2007-TR-015). Pittsburgh, PA: Software Architecture Technology Initiative, Carnegie Mellon. Cai, Z., Yang, X., & Wang, W. (2009). Business process recovery for system maintenance - An empirical approach. In Proceedings of ICSM’09. IEEE. Canfora, G., & Di Penta, M. (2007). New frontiers of reverse engineering. In Proceedings of Future of Software Engineering (FOSE’07). IEEE. Cauvet, C., & Guzelian, G. (2008). Business process modeling: A service-oriented approach. In Proceedings of 41st Hawaii International Conference on System Sciences, (pp. 98-104). IEEE.
Business Process Modeling with Services
Caverlee, J., Bae, J., Wu, Q., Liu, L., Pu, C., & Rouse, W. B. (2007). Workflow management for enterprise transformation. Information Knowledge Systems Management, 6, 61–80. Charfi, A., & Mezini, M. (2007). AOPBPEL: An Aspect-oriented extension to BPEL. World Wide Web (Bussum), 10, 309–344. doi:10.1007/ s11280-006-0016-3 Chesbrough, H., & Spohrer, J. (2006). A research manifesto for services science. Communications of the ACM, 49(7), 35–40. doi:10.1145/1139922.1139945 Cleve, A., & Hainaut, J. L. (2008). Dynamic analysis of SQL statements for data-intensive applications reverse engineering. In Proceedings of WCRE’08. WCRE. Cohn, D., & Hull, R. (2009). Business artifacts: A data-centric approach to modelling business operations and processes. A Quarterly Bulletin of the Computer Society of the IEEE Technical Committee on Data Engineering, 32(3), 3–9. Cordoso, J., Voigt, K., & Winkler, M. (2008). Service engineering for the internet of services. [ICEIS.]. Proceedings of ICEIS, 2008, 15–27. Cumberlidge, M. (2007). Business process management with jbossjbpm. Packt Publishing. Cummins, F. A. (2009). Building the agile enterprise with SOA, BPM and MBM. San Francisco, CA: The Morgan Kaufmann/OMG Press. Davenport, T. H. (1993). Process innovation: Reengineering work through information technology. Boston: Harvard Business School Press. Di Francescomarino, C., Marchetto, A., & Tonella, P. (2009). Reverse engineering of business processes exposed as web applications. In Proceedings of CSMR’09. IEEE.
Dietz, J. L. G. (2006). The deep structure of business processes. Communications of the ACM, 49(5), 58–64. doi:10.1145/1125944.1125976 Erl, T. (2008). SOA principles of service design. Englewood Cliffs, NJ: Prentice Hall. Foutse, K. (2009). SQUAD: Software quality understanding through the analysis of design. [WCRE.]. Proceedings of WCRE, 09, 303–306. Fowler, M. (2003). Enterprise application architecture: Mapping relational databases. Reading, MA: Addison Wesley Professional. Galinium, M., & Shabaz, N. (2012). Success factors model: Case studies in the migration of legacy systems to service-oriented architecture. In Proceedings of Int. Joint Conference on Computer Science and Software Engineering (JCSSE 2101), (pp. 236-241). JCSSE. Gamma, E. (2004). Design patterns: Elements of reusable object-oriented software. Reading, MA: Addison-Wesley. Hammer, M., & Champy, J. (1993). Re-engineering the corporation: A manifesto for business revolution. New York: Harper Business. Hull, R., Mendling, M., & Tai, T. (2012). Business process management. Information Systems, 37(6), 517. doi:10.1016/j.is.2011.10.008 Hunt, A., & Thomas, D. (2002). Software archaeology. IEEE Software, 19(2), 20–22. doi:10.1109/52.991327 Indulska, M., Recker, J., Rosemann, M., & Green, P. (2009). Business process modeling: Current issues and future challenges. Lecture Notes in Computer Science, 5565, 501–514. doi:10.1007/978-3-642-02144-2_39
197
Business Process Modeling with Services
Jaeger, M. C. (2006). Modelling of service compositions: Relations to business process and workflow modeling. In Proceedings of Service-Oriented Computing ICSOC 2006 (LNCS) (Vol. 4652, pp. 141–153). Berlin: Springer. doi:10.1007/978-3540-75492-3_13 Keramati, A., Reza, H., Golian, H. R., & AfshariMofrad, M. (2011). Improving business processes with business process modelling notation and business process execution language: An action research approach. International Journal of Business Information Systems, 7(4), 458–476. doi:10.1504/IJBIS.2011.040568 Khusidman, V., & Ulrich, W. (2007). Architecture-driven modernization: Transforming the enterprise. OMG. Kloppmann, M., & Diter, K. (2009). The dichotomy of modeling and execution: BPMN and WS-BPEL. In Handbook of Research on Business Process Modeling. Hershey, PA: IGI Global. doi:10.4018/978-1-60566-288-6.ch004 Koskinen, J., Ahonen, J. J., Sivula, H., Tilus, T., Lintinen, H., & Kankaanpää, H. I. (2005). Software modernization decision criteria: An empirical study. In Proceedings of European Conference on Software Maintenance and Reengineering. IEEE Computer Society. Krai, J., & Zemlicka, M. (2005). ‘Implementation of business processes in service-oriented systems. In Proceedings of the IEEE International Conference on Services Computing (SCC’2005). Orlando, FL: IEEE. Kumaran, S., Liu, R., & Wu, F. Y. (2008). On the duality of information-centric and activity –centric models of business process. Lecture Notes in Computer Science, 5074, 32–47. doi:10.1007/9783-540-69534-9_3
198
Lewis, G. A., Smith, D. B., & Kontogiannis, K. (2010). A research agenda for service-oriented architecture (SOA), maintenance and evolution of service-oriented systems. Software Engineering Institute. Lindsay, A., Downs, D., & Lunn, K. (2003). Business processes: Attempts to find a definition. Journal of Information and Software Technology, 45(15), 1015–1019. doi:10.1016/S09505849(03)00129-0 Linthicum, D. S. (2004). Leveraging SOA and legacy systems. Business Integration Journal. Lodhi, A., Koppen, V., & Saake, G. (2011). Post execution analysis of business processes: Taxonomy and challenges (Technical Report 9). University of Magdeburg. Lu, R., & Sadiq, S. (2007). A survey of comparative business process modeling approaches. In Business Information Systems (LNCS) (Vol. 4439, pp. 82–94). Berlin: Springer. doi:10.1007/978-3540-72035-5_7 Mendling, J., Reijers, H. A., & van der Aalst, W. M. P. (2010). Seven process modeling guidelines (7PMG). Information and Software Technology, 52(2), 127–136. doi:10.1016/j.infsof.2009.08.004 Moyer, B. (2009). Software archeology: Modernizing old systems. Embedded Technology Journal, 1, 1–4. Narayanan, V. (2009). Introduction to data service. Retrieved from http://www.infoq.com/articles/ narayanan-soa-data-services OASIS. (2006). A reference model for service oriented architecture. Billerica, MA: Organization for the Advancement of Structured Information Standards. OMG. (2009). Business process model and notation (BPMN) 2.0. Object Management Group.
Business Process Modeling with Services
Papazoglou, M. P. (2008). Web services: Principles and technology. Upper Saddle River, NJ: Pearson, Prentice Hall. Paradauskas, B., & Laurikaitis, A. (2006). Business knowledge extraction from legacy information systems. Journal of Information Technology and Control, 35(3), 214–221. Pérez-Castillo, R., de Guzmán, I. G., & Piattini, M. (2011). Business process archeology using MARBLE. Information and Software Technology, 53, 1023–1044. doi:10.1016/j.infsof.2011.05.006 Polo, M., Gomez, J. A., Piattini, M., & Ruiz, F. (2002). Generating three-tier applications from relational databases: A formal and practical approach. Journal of Information and Software Technology, 44, 923–941. doi:10.1016/S09505849(02)00130-1 Premerlani, W. J., & Blaha, M. R. (1994). An approach for reverse engineering relational databases. Communications of the ACM, 37(5), 42–49. doi:10.1145/175290.175293 Purchase, V., Parry, G., Valerdi, R., Nightingale, D., & Mills, J. (2011). Enterprise transformation: Why are we interested, what is it, and what are the challenges. Journal of Enterprise Transformations, 1, 14–33. doi:10.1080/19488289.201 0.549289 Recker, J. (2011). Opportunities and constraints: The current struggle with BPMN. Business Process Management Journal, 16(1), 181–201. doi:10.1108/14637151011018001 Recker, J., Indulska, M., Rosemann, R., & Green, P. (2010). The ontological deficiencies of process modeling in practice. European Journal of Information Systems, 19, 501–525. doi:10.1057/ ejis.2010.38
Recker, J., Rosemann, M., Indulska, M., & Green, P. (2009). Business process modeling- A comparative analysis. Journal of the Association for Information Systems, 10(4), 333–363. Reijers, H. A., Freytag, T., Mendling, J., & Eckleder, A. (2011). Syntax highlighting in business process model. Decision Support Systems, 51(3), 339–349. doi:10.1016/j.dss.2010.12.013 Rouse, W. B., & Baba, M. L. (2006). Enterprise transformation. Communications of the ACM, 49(7). doi:10.1145/1139922.1139951 Seidel, S. (2011). Toward a theory of managing creativity-intensive processes: A creative industries study. Information Systems and e-Business Management, 9(4), 407-446. Siurdyban, A., Svejvig, P., & Mølle, C. (2012). A design perspective on aligning process-centric and technology-centric approaches. International Journal of Business Information Systems, 11(2), 215–234. doi:10.1504/IJBIS.2012.048891 Skrinjar, R. S., & Trkman, P. (2013). Increasing process orientation with business process management: Critical practices. International Journal of Information Management, 33(1), 48–60. doi:10.1016/j.ijinfomgt.2012.05.011 Stein, S. (2009). Modelling method extension for service-oriented business process management. (PhD thesis). Christian-Albrechts-Universit¨atzu Kiel, Kiel, Germany. Thomas, O., & Brocke, J. V. (2010). A value-driven approach to the design of service-oriented information systems—Making use of conceptual models. Information System & E-Business Management, 8, 67–97. doi:10.1007/s10257-009-0110-z
199
Business Process Modeling with Services
van den Brandt, M. G. J., Klint, P., & Verhoef, C. (1997). Reverse engineering and system renovation: An annotated bibliography. ACM SIGSOFT Software Engineering Notes, 22(1), 57–68. doi:10.1145/251759.251849 van der Aalst, W. M. P. (2012). A decade of business process management conferences: Personal reflections on a developing discipline. In Business Process Management (LNCS) (Vol. 7481, pp. 1–16). Berlin: Springer. doi:10.1007/978-3-64232885-5_1 van der Aalst, W. M. P. (2012). What makes a good process model? Lessons learned from process mining. Software & Systems Modeling, 11(4), 557–569. doi:10.1007/s10270-012-0265-9 Van der Aalst, W. M. P., et al. (2009). ProM: The process mining toolkit. In Proceedings of 7th International Conference on Business Process Management (BPM’09). Berlin: Springer. van der Aalst, W. M. P., Benatallah, B., Casati, F., Curbera, F., & Verbeek, E. (2007). Business process management: Where business processes and web services meet. Data & Knowledge Engineering, 61(1), 1–5. doi:10.1016/j.datak.2006.04.005 van der Aalst, W. M. P., Hofstede, A., & Weske, M. (2003). Business process management: A survey. In Business Process Management (LNCS) (Vol. 2678, pp. 1–12). Berlin: Springer. doi:10.1007/3540-44895-0_1
200
van der Aalst, W. M. P., van Hee, K. M., Massuthe, P., Sidorova, N., & van der Werf, M. J. (2009). Compositional service trees. Petri Nets. Van der Heuvel, W. J. (2006). Aligning modern business processes and legacy systems: A component-based perspective. Cambridge, MA: The MIT Press. W3C. (2010). Web services architecture usage scenarios. Retrieved from http://www.w3.org/ TR/wsarch-scenarios Weske, M. (2007). Business process management: Concepts, languages, architectures. Berlin: Springer Verlag. WfMC. (1995). Retrieved from http://www.wfmc. org/Articles-White-Papers/ Zimmermann, O., Doubrovski, V., Grundler, J., & Hogg, K. (2005). Service-oriented architecture and business process choreography in an order management scenario: Rationale, concepts, lessons learned. In Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA’2005). San Diego, CA: OOPSLA. Zou, Y., & Hung, M. (2006). An approach for extracting workflows from e-commerce applications. In Proceedings of 14th International Conference on Program Comprehension. 2006. IEEE. 1Archaeological Institute of America, AIA Web Portal. , 2010 (01.28.10).
