Business and Scientific Workflows

A Web Service-Oriented Approach

Wei Tan, MengChu Zhou

• Publisher: Wiley-IEEE Press
• Year: 2013
• Print ISBN: 9781118171332
• eBook ISBN: 9781118554623
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Engineering
• Index: Computer Science

Focuses on how to use web service computing and service-based workflow technologies to develop timely, effective workflows for both business and scientific fields

Utilizing web computing and Service-Oriented Architecture (SOA), Business and Scientific Workflows: A Web Service–Oriented Approach focuses on how to design, analyze, and deploy web service–based workflows for both business and scientific applications in many areas of healthcare and biomedicine. It also discusses and presents the recent research and development results.

This informative reference features application scenarios that include healthcare and biomedical applications, such as personalized healthcare processing, DNA sequence data processing, and electrocardiogram wave analysis, and presents:

• Updated research and development results on the composition technologies of web services for ever-sophisticated service requirements from various users and communities
• Fundamental methods such as Petri nets and social network analysis to advance the theory and applications of workflow design and web service composition
• Practical and real applications of the developed theory and methods for such platforms as personalized healthcare and Biomedical Informatics Grids
• The authors' efforts on advancing service composition methods for both business and scientific software systems, with theoretical and empirical contributions

With workflow-driven service composition and reuse being a hot topic in both academia and industry, this book is ideal for researchers, engineers, scientists, professionals, and students who work on service computing, software engineering, business and scientific workflow management, the internet, and management information systems (MIS).

Chapter 1

Introduction

With the emergence of service-oriented architecture (SOA), Web services are gaining momentum as key elements in enterprise information systems. Meanwhile, building business and scientific workflows using service composition has become an important method for system integration and process reengineering. Therefore, workflow-driven service composition is now a hot topic in both academia and industry. This book focuses on how to design, analyze, and deploy Web service-based workflows for business, scientific, and medical applications. This chapter discusses the state of the art in both technologies, that is, Web services and workflow management, with a focus on their impact on each other.

1.1 Background and Motivations

1.1.1 Web Service and Service-Oriented Architecture

In a 1996 report, Schulte and Natis of Gartner Inc. first used the term service-oriented architecture (SOA) to describe a style of multitier computing that helped organizations share logic and data among multiple applications and usage modes [1].

Thomas Erl, who is recognized as a major contributor in the area of SOA, describes it as an architecture that is open, agile, extensible, federated, and composable—one that is composed of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services [2]. He further summarizes the following eight principles of SOA [3]:

• Standardized Service Contract. Services should expose their interface and their level of service explicitly, in a standard way. That is the only information needed by a user.
• Service Loose Coupling. Services may collaborate with each other but their dependencies should be minimized such that in their communication, they only need to know the contract of others.
• Service Abstraction. Services should hide their internal workings from the outside world, except the contract. For example, a service should not expose its technical details, such as the programming language, operating system, and database used, to users.
• Service Reusability. Services should be designed in a granularity to promote reuse. If a service is only to be used by a single user, then there is no reason to expose it as a service.
• Service Autonomy. A service should have control over its behavior and respond to invocation requests. In a service system, a centralized control is not necessary.
• Service Statelessness. Services should minimize the state information exposed to peers and other users, to improve the loose coupling and scalability of the architecture. If a service is stateless, the server side does not need to maintain session or state information; more importantly, a request can be routed easily for the load balance purpose.
• Service Discoverability. Services are annotated with metadata such that they can be discovered by users.
• Service Composability. Services should be able to be composed to fulfill new and more complex requirements. This principle is closely related to reusability, that is, services are composable such that they can be reused in different applications.

Although Schulte and Natis created the term in 1996, the interest in it only revived in 2000s when Web service technology emerged and matured. In W3C's glossary, a Web service is a software system for machine-to-machine interaction over a network [4]. A Web service (or service for short) should have an interface description and be invoked in a way prescribed by this description and using HTTP (Hypertext Transfer Protocol) related protocols. W3C's recommendation is to use WSDL (Web Service Definition Language) to describe its interface, and SOAP (Simple Object Access Protocol) over HTTP to invoke it. All these specifications (WSDL, SOAP, and other Web-related ones) are XML (Extensible Markup Language)-based and can be understood and processed by computer programs. We introduce these related standards in more detail later.

The term service in the original definition [1] is abstract and does not tie in with any concrete technology. It is Web service technology that quickly makes SOA tangible and practical to many users. SOA principles provide guidance to Web service implementations and differentiate it with competing technologies such as CORBA, DCOM, and Java RMI [5]. Although SOA does not necessarily build upon Web services and Web service technology by itself is not equivalent to SOA, there is a tight relation between these two concepts. In this book we consider Web services as the best implementation technology for SOA, and SOA principles are applied in Web service practices. Therefore, from now on we do not explicitly distinguish between Web service and service unless otherwise mentioned.

The triangle in Figure 1.1 lays the foundation of all Web service technologies, by describing the interplay of service client, service registry, and service provider. Consider the following scenario. Multiple service providers want to offer services but are not aware of their clients. Neither do the clients know where and how to access desired services. In SOA, every provider registers its service into a registry by providing its function, quality of service, provider information, and so on. The service registry acts like the yellow pages and search engine for services. It categorizes services based on different criteria such as functions, providers, quality of service, and offers a flexible search mechanism to be used by clients. Service clients look up the service they want, and obtain the reference to it from the registry. They then bind to the service's reference and invoke it. Currently, UDDI (Universal Description, Discovery, and Integration) is the standard designed for service registry. Service providers register service descriptions using WSDL. Once clients obtain the WSDL of a service from the registry, they use SOAP to interact with the service. This book introduces these standards in more detail in Section 1.2.

Figure 1.1 The Web service triangle.

1.1.2 Workflow Technology

As defined by Workflow Management Coalition (WfMC), a forerunner in standardizing the workflow technology, workflow is the computerized facilitation or automation of a business process, in whole or part. This book focuses on the automation aspect of a business process and thus will not distinguish between a workflow and a business process unless otherwise mentioned.

The Workflow Reference Model [6] published by WfMC in 1995 has laid the foundation in defining a vocabulary and architecture of a workflow system. Despite the drastic technology evolution over the years, this reference model is still applicable to most workflow systems in use today. Here, we use this vocabulary to go over the key concepts in a workflow system and introduce the reference architecture in Section 1.2.2. The reference model defines a common glossary to describe business processes (also known as, workflows) and various artifacts associated with them. It divides the function of a workflow management system into two aspects, that is, build time and run time. At build time, a process definition or workflow definition is designed, usually with the help of a modeling tool, as the representation of a business process to be automated. A workflow definition usually contains a set of activities and the sequence among them. An activity can be either a manual activity that needs human intervention or an automated workflow activity that will be executed by a software application. At run time, a workflow engine is the computer software that provides the execution environment for workflows. Given a workflow definition, the engine can start multiple workflow instances. For example, an order processing workflow definition can have multiple instances, each of which deals with one particular incoming customer order. There can be many concurrent instances in a workflow engine. In a workflow instance, each activity also has its corresponding activity instance.

The workflow technology originated from office automation (OA) area and initially handled the documentation flow among multiple persons or applications. In recent years, workflow has been evolved from a pure IT technology for business process automation, to a much broader concept called business process management (BPM) [7]. BPM is a holistic approach to align many aspects of an enterprise, such as organization, rules, resources, and quality management, in a process centric manner so as to optimize overall operational efficiency and customer satisfaction.

Figure 1.2 illustrates the life cycle of BPM. It starts with the design phase. In this phase, first the existing processes (also known as, as-is processes) inside an organization, both non-automated and automated ones, are identified. Afterward the to-be processes, that is, those to be managed by the BPM system are designed with different criteria. The criteria can be customer satisfaction, response time, or quality of service. A process includes not only a sequenced series of tasks, but also the organizational unit responsible for tasks and processes, the resources needed, and the business rules to control the behavior of tasks or processes.

Figure 1.2 The life cycle of BPM.

Second, in the automation phase, the business processes designed are translated into a format that can be understood by the underlying process engine (also known as, workflow engine) and become operational in a BPM system (BPMS). Through the BPMS backbone, a process in execution can invoke computer applications, command organizational units, and consume resources to achieve the goal defined in the previous design phase. Nowadays many BPMSs are based on SOA infrastructure. Business processes are translated into BPEL [8] and Web services are adopted as the communication interfaces among processes, applications, and even organizational units.

The designed and later automated processes are monitored in the monitoring phase. Usually in a BPMS, the status of running processes and activities are traced, the performance indicators measured, and anomalies reported. Besides the real-time aspect of business process monitoring, the historical data collected in this phase can be used in the subsequent improvement phase.

In the fourth phase, that is, improvement, the process model from the design and automation phases, as well as the performance indicator accumulated from the monitoring phase, are put together to provide a retrospect to a process. In 1990s, business process reengineering (BPR) [9 10] emerged. It states that managers need to fundamentally rethink their processes and change them in a dramatic way so as to offer processes with improved customer satisfaction and reduced operational cost. Later when business processes were better managed, a less radical approach compared to BPR, i.e., business process improvement (BPI), became more appealing [11]. The improvement phase in a BPM life cycle addresses the issue of process improvement by examining the process performance indicators, identifying the bottleneck as well as other potentials to improve, and providing guidance to the next iteration of process design.

Business processes are the nexus of many aspects in enterprise management, including quality management, rule management, enterprise resource planning, and business analytics. Here, we briefly discuss these aspects and their relations to BPM. Please note that because concepts such as quality management, enterprise pla...

Table of contents

• Cover
• Series Page
• Title Page
• Copyright
• Dedication
• Foreword
• Preface
• Chapter 1: Introduction
• Chapter 2: Petri Net Formalism
• Chapter 3: Data-Driven Service Composition
• Chapter 4: Analysis and Composition of Partially-Compatible Web Services
• Chapter 5: Web Service Configuration with Multiple Quality-of-Service Attributes
• Chapter 6: A Web Service-Based Public-Oriented Personalized Health Care Platform
• Chapter 7: Scientific Workflows Enabling Web-Scale Collaboration
• Chapter 8: Network Analysis and Reuse of Scientific Workflows
• Chapter 9: Future Perspectives
• Abbreviations List
• References
• Index