Application 2 – Annotated Bibliography

COMMUNICATIONS OF THE ACM October 2007/Vol. 50, No. 10 79

Web services are rapidly becoming the defacto distributed enterprise comput- ing technology for realizing and man- aging multi-party business processes [5]. By now, most enterprises have gained some early experience in devel- oping internal Web services in a first attempt to leverage their legacy assets and to accelerate development and integration of their enterprise applica- tions. However, most of today’s enter- prises are still far from benefiting from the full-fledged potential of Web ser- vice technology embodied in its ability to mix-and-match internal and exter- nal services alike.

In fact, it is common practice for most enterprises to develop their Web services by simply placing a thin SOAP/WSDL/UDDI layer on top of existing enterprise applications or soft-

ware components. This is in no way suf- ficient for implementing and managing commercial-strength, service-enabled enterprise applications. While simple (internal) Web services may be con- structed that way, a development life cycle methodology is of crucial impor- tance to design, construct, monitor, and manage enterprise SOA applications supporting existent business process ecosystems that are highly complex and

BY MICHAEL P. PAPAZOGLOU AND WILLEM-JAN VAN DEN HEUVEL

An innovative roadmap brings together the worlds of business processes and Web services, harnessing their power to construct industrial-strength business applications.

BUSINESS PROCESS DEVELOPMENT

Life Cycle Methodology

80 October 2007/Vol. 50, No. 10 COMMUNICATIONS OF THE ACM

agile in nature. This article describes the insights of a methodology and roadmap that assists service providers and service aggregators in assembling multi- party business processes, such as invoicing and inven- tory control, from Web services.

METHODOLOGY ROADMAP The service-oriented business process development methodology is based on a roadmap that comprises one preparatory phase to plan development, and five distinct phases that concentrate on business processes: analysis and design (A&D), construc- tion and testing, provisioning, deployment, and execution and monitoring (see Figure 1).

The stepwise transition through these phases tends to be incremental and iterative in nature and should accommodate revisions in situations where the scope cannot be completely defined a priori. This allows an approach that is one of continuous invention, discovery, and implementation with each iteration, forcing the development team to drive the software development artifacts closer to completion in a predictable and repeatable manner. This approach considers multiple realization scenarios for business processes and Web services that take into account both technical and business concerns.

The basic functioning of the methodology is exemplified by means of an order management process that involves a client, a seller, and a trusted third party. This process is organized as follows. On receiving a purchase order from a client, five tasks are executed concurrently at the seller’s site: check- ing the credit worthiness of the customer, deter- mining whether or not an ordered part is available in the product inventory, calculating the final price for the order and billing the customer, selecting a shipper, and scheduling the production and ship- ment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between these tasks. For instance, the customer’s creditworthiness must be ascertained before accepting the order, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule.

DESIGN GUIDELINES Business processes developed on the basis of existing or newly coded services must rely on sound service design principles to ensure autonomous, self-con- tained and modular business processes with clearly defined boundaries and discrete service endpoints. Two key principles serve as the foundation for ser- vice- and business-process design: service coupling and cohesion.

Service coupling. Service coupling refers to the degree of interdependence between business processes or Web services. The design objective is to minimize coupling, that is, to make business processes as self- contained as possible by ensuring they need virtually no knowledge or service of any other business processes, thus increasing their maintainability and reuse potential. Similarly, services that are orches- trated inside a process should be loosely coupled to each other, avoiding interdependencies at the level of data or control logic. It is useful to distinguish between three ways to achieve service and process coupling:

1. Representational coupling: Business processes should not depend on specific representational or implementation details and assumptions underlying business processes. That is, business processes do not need to know the scripting language that was used to compose their underlying services. Representational coupling is useful for supporting:

Figure 1. Business process development life

cycle methodology.

Services that are orchestrated inside a process should be loosely coupled to each other, avoiding interdependencies at the level of data or control logic.

• Interchangeable/replaceable services: Existing services may be swapped with new service implementa- tions—or ones supplied by a different provider offering better performance or pricing—without disrupting the overall business process functional- ity;

• Multiple service versions: Different versions of a ser- vice may work best in parts of a business processes depending on the application’s needs. For example, a purchase order service may provide different detail levels; it may provide, for example, internal or external requisition details such as internal or external accounts, depending on the ordering options.

2. Identity coupling: Connection channels between services should be unaware of who is providing the service. It is not desirable to keep track of the targets (recipients) of service messages, especially when they are likely to change or when discover- ing the best service provider is not a trivial matter.

3. Communication protocol coupling: The number of messages exchanged between a sender and addressee in order to accomplish a certain goal should be mini- mal, given the com- munication model, such as one-way, request/response, or solicit/response. For example, a one-way form of communica- tion, where a service endpoint receives a message without hav- ing to send an acknowledgment places the lowest possible demands on the service performing the operation. The service that performs such an operation assumes nothing about the consequences of send- ing the message. Service cohesion defines the degree of strength of

functional relatedness between operations in a service or business process. The service aggregator should strive to offer cohesive (autonomous) processes whose services and service operations are strongly and gen- uinely related to one another. The guidelines by which to increase cohesion are as follows: 1. Functional service cohesion: A functionally cohesive

business process should perform one and only one problem-related task and contain only services nec- essary for that purpose. For an order management business process, such services include get-product-

price, check-product-availability, and check-credit- worthiness

2. Communicational service cohesion: A communica- tionally cohesive business process is one whose activities and services use the same set of input and output messages. Such business processes are cleanly decoupled from other processes as their activities are hardly related to activities in other processes.

3. Logical service cohesion: A logically cohesive business process is a one that performs a set of independent but logically similar functions (alternatives) that are tied together by means of control flows, such as mode of payment.

PHASE 1. THE PLANNING PHASE Planning sets the scene for all ensuing phases by ana- lyzing the business case for all feasible combinations of development approaches and realization strategies (see Figure 2). Fundamentally, business case analysis embraces two activities: gap analysis and scenario

analysis. Gap analysis com-

mences with comparing planned services with avail- able software service imple- mentations that may be assembled within the enclo- sures of a newly developed business process. Four cate- gories of existing service resources are discerned: legacy systems, commercial off-the-shelf (COTS) com- ponents, enterprise resource planning (ERP) packages,

and existing Web services. We collectively refer to these categories as the Web services landscape. Gap analysis matches high-level descriptions of new services that collectively make up a business process against the available resources in the Web service landscape.

Scenario analysis. Gap analysis is intertwined with a scenario analysis, which considers costs, risks, bene- fits, and return of investment of the following options to develop new business processes:

1. Green-field development: Follows a classical devel- opment model covering specification down to devel- opment. With this option we assume that the business processes must be developed from scratch without any reuse of existing process chunks or service specifica- tions.

2. Top-down development: Usually a blueprint of business use cases provides the skeleton specification for business services. The top-down process decom-

COMMUNICATIONS OF THE ACM October 2007/Vol. 50, No. 10 81

Figure 2. Scenario analysis.

poses the business domain into its functional areas and subsystems, including its flow or process decom- position into processes, sub-processes and high-level business use cases.

3. Bottom-up development: Starts from existing enterprise applications and repositories and trans- forms them to new services by wrapping.

4. Out-of-the-middle development: Combines top- down and bottom-up development by allowing ser- vice aggregators to select those fragments of enterprise resources that best satisfy new business process requirements. Fragments are then retrofitted using services.

If gap analysis results in high functional fit, this points toward a bottom-down approaches for the remainder of the development process, whereas green-field or top-down development approach are best in cases of low functional fit. Out-of-the-middle development may be preferred in those cases where legacy assets have considerable overlap with new ser- vice requirements and lack substantial business value.

One of the issues with current top-down and bot- tom-up development is that they are rather ambigu- ous regarding which business processes an enterprise should start from and how these business processes can be combined to form business scenarios. To address this problem, service development solutions must target specific focal points and common prac- tices within the enterprise, such as those specified by its corresponding sector reference models. Reference models—a typical example of which is RosettaNet— address a common large proportion of the basic “plumbing” for a specific sector, from a process, oper- ational function, integration, and data point of view. Such a verticalized development model presents the ideal architecture for supporting service development and will be used throughout this article to explicate elements of the services development methodology.

Each development option we have discussed thus far comes equipped with one or more of the four real- ization strategies:

• Reuse existing (internal) Web services or business process logic;

• Develop new Web services or business processes

logic from scratch; • Purchase/outsource Web services or (parts of )

business processes; • Revamp existing (COTS) components or existing

(ERP/legacy) systems in Web services or business processes.

During scenario analysis, estimates for existing and expected operational costs, integration costs, service and process customization costs, service and process provisioning costs, and architecture costs are assessed. Architecture costs are associated with acquiring arti- facts for realizing the target architecture including hardware, software (OS), training, and network bandwidth. Service acquisition costs are based on a one-off or annuity-based payment for implementa- tion and usage of the software and are different from service provisioning costs. For complex business- related Web services, service providers may operate different charging alternatives, incurring various types of costs for the service aggregator, including usage costs, subscription costs, leasing costs, and free ser- vices.

Risk analysis weighs benefits and costs in the pro- visioning scenarios and verifies feasibility before a par- ticular option is chosen. During risk analysis, both the impact and probability of an event that may occur is estimated. This is expressed in terms of return on investment (ROI), which is calculated for each devel- opment option as the ratio of net benefits over costs. After calculating the ROI for each scenario and assess- ing the technical quality of available service resources, the most appropriate design option may be selected.

Essentially, the planning phase plots a strategy for realizing new business processes, given the risk that is involved, and adopts the best-fitting process model. High-risk projects may require a “chicken-little” approach advocating gradual migration, whereas low- risk projects allow a “big-bang” strategy.

PHASE 2. SERVICE AND PROCESS ANALYSIS AND DESIGN Service analysis aims at identifying, conceptualizing, and rationalizing business processes as a set of inter- acting Web services. This step is logically succeeded by service design, during which conceptual processes

82 October 2007/Vol. 50, No. 10 COMMUNICATIONS OF THE ACM

One of the issues with current top-down and bottom-up development is that they are rather ambiguous regarding which business processes an enterprise should start from and how these business processes can be combined to form business scenarios.

and services are transformed into a set of related, platform-agnostic interfaces.

Service analysis and design. Service interfaces are identified in the problem domain by carving out and grouping service capabilities based on service coupling and cohesion criteria. For example, consider the ship- ping service. By applying the dominant cohesion cri- terion, namely functional cohesion, this service is decomposed into service operations like “select ship- per” and “check product availability.

In case reference models are available (such as the XML common business library, xCBL, or Roset- taNet), business functions can be derived on their basis. For example, the order management busi- ness process in Figure 2 could be derived on the basis of RosettaNet’s part- ner interface process (PIP), “manage purchase order” (PIP3A4).

Service specification. Here, we will briefly examine the process of writing an interface specification for a Web service. We adopt the standard, XML-based Web service definition lan- guage (WSDL) [3] for this purpose. This process basi- cally comprises four steps: describing the service interface, specifying operation parameters, designat- ing the messaging and transport protocol, and finally fusing port types, bindings, and actual location (URI) of the Web services. These steps themselves are rather trivial and are already described in-depth in the liter- ature [1].

Identifying processes. The objective of this step is to identify services that may be aggregated into a busi- ness process whose interface has a high viscosity. Again, we can apply the design principles of coupling and cohesion to achieve this. For example, the order management process has low communication proto- col coupling with the material requirements process. In case of top-down development, reference models are given that standardize processes and correlated ser- vices and serve as a point of reference for new services.

Process identification could, for instance, start with comparing the abstract business process layout with RosettaNet’s “order management” partner interface process. This PIP encompasses four complementary process segments supporting the entire chain of activ- ities from purchase order creation to tracking-and- tracing, each of which is further decomposed into

multiple individual processes. A quick-scan of this PIP reveals that two of the activities, “quote and order entry” and “returns and finance” could be combined into the process “order management.”

Specifying processes. Once business processes are extracted and their boundaries are clearly demarcated, they need to be described in the abstract in four steps:

1. Determine style of service composition. The service designer may choose from two basic

types of service composi- tion: orchestration and choreography. Orchestra- tion describes how Web services can interact with each other at the message level, including the busi- ness logic and execution order of the interactions from the perspective and under control of a single endpoint. (For an exam- ple of this type of process flow, see Figure 3, where

the business process flow is designed from the vantage point of a supplier.) Orchestration refers to an exe- cutable business process that may result in a long- lived, transactional, multi-step process model. With orchestration, the business process interactions are always controlled from the (private) perspective of one of the business parties involved in the process.

Choreography is typically associated with the pub- lic (globally visible) message exchanges, rules of inter- action and agreements that occur between multiple business process endpoints, rather than a specific busi- ness process that is executed by a single party. Chore- ography is more collaborative in nature than orchestration. It is described from the perspective of all parties (common view), and defines the comple- mentary observable behavior between participants in business process collaboration.

Orchestration is the preferred composition style for internal business processes with tightly coupled inter- nal actors, while choreography is typically chosen for developing cross-organizational business processes between loosely coupled partners. Orchestration and choreography may also be applied simultaneously. For example, in Figure 3 the client and supplier are shown to integrate their business processes. This figure assumes that the respective business analysts at both companies have agreed upon both the processes as well as the service level agreements (SLAs) involved for the process collaboration. Using a graphical user interface (GUI) and a tool that can serve as a basis for the collaboration, the client and supplier agree upon

COMMUNICATIONS OF THE ACM October 2007/Vol. 50, No. 10 83

Figure 3. Combining choreography and

orchestration.

their interactions and generate a choreography, such as a WS-CDL (choreography description language) representation [4]. This representation can then be used to generate an orchestration, such as a business process execution language for Web services (BPEL) workflow template for both the manufacturer and supplier. BPEL is the standard industry specification designed specifically for Web services based orchestra- tion [2]. The two BPEL workflow templates reflect the business agreement.

2. Determine objectives and derive the business process structure.

The private services of the client and supplier can then be scripted using BPEL. This language enforces the representational coupling requirement. In partic- ular, BPEL is a platform-agnostic, block-structured workflow-like language to define business processes that may orchestrate one or more Web services.

A key part of the BPEL document is the definition of the sequence of business activities required to han- dle an incoming purchase order request. The internal process flow of the supplier (see Figure 3, right side) includes an initial request from a client, followed by invocations of a scheduling service, credit service, and billing service in parallel, and ultimately a response to the client from the seller sending a invoice.

3. Describe business activity responsibilities (roles).

The third step during business process design is to identify responsibilities associated with business process activities and the roles that are responsible for performing them. Roles may invoke, receive, and reply to business activities. The result of this phase actually constitutes the foundation for implementing business policies, notably role-based access control and security policies. For example, the supplier may play the role of billing, credit checking, and schedul- ing agency.

4. Identify non-functional business process con- cerns.

A service development methodology must go far beyond ensuring “simple” functional correctness, and deal with non-functional process design concerns including performance, payment model, security

model, and transactional behavior. Here, we will briefly mention typical business-related, non-func- tional concerns that are captured in an SLA.

SLAs provide a proven vehicle for not only captur- ing non-functional requirements but also for moni- toring and enforcing them. SLAs are special legal agreements that encapsulate multiple concerns, and symmetrically fuse the perspective of service supplier and customer.

Mutual agreements can be partially realized by specifying transactional quality of service (QoS) akin to business interactions that contain business-related atomicity properties including payment atomicity, goods atomicity, (certified) delivery atomicity, and conversation atomicity [6]. For example, the purchase order business process adopts a multi-level atomicity protocol signifying that after the customer is billed, payment follows (payment atomicity); that producing the order and shipment results in the goods being delivered (goods atomicity) in the correct manner (certified delivery atomicity). Moreover, the terms of any negotiation sequence resulting in a purchase need to be transcribed and kept in storage for future refer- ence (conversation atomicity).

Another important ingredient of an SLA is security policies to protect multi-party collaborations. Know- ing that a new business process adopts a Web services security standard such as WS-security is insufficient information to guarantee successful composition. The client must know if the services in the business process actually require WS-security, what kind of security tokens they are capable of processing, and which ones they prefer. Moreover, the client must determine if the service should communicate using signed messages. If so, it must determine what token type must be used for the digital signatures. Finally, the client must decide on when to encrypt the mes- sages, which algorithm to use, and how to exchange a shared key with the service. For example, the purchase order service in the order management process may indicate it only accepts username tokens that are based on signed messages using an X.509 certificate that is cryptographically endorsed by a third party.

84 October 2007/Vol. 50, No. 10 COMMUNICATIONS OF THE ACM

Service provisioning is central to operating revenue-generating Web services between organizations. The provisioning requirements for Web services impose serious implications for the business process development life cycle methodology.

PHASE 3. THE CONSTRUCTION AND TESTING PHASE Once the service and process specifications have reached a steady state, they need to be transformed into service implementations, and subsequently val- idated and verified against business service and process specifications. Business process realization typically adopts a verticalized development model. This activity encompasses two broad steps: code Web services and code business processes.

Code Web services. Web services that were specified in WSDL may be programmed with any preferred pro- gramming language as long as the language is capable of supporting WSDL’s protocol bindings, including XML-RPC and SOAP.

Code business processes. Once the Web services have been codified, the flow logic that is comprised in the BPEL specification is compiled and injected into a BPEL execution engine. As a preparatory step, the busi- ness process is revamped as a coarse-grained asynchro- nous operation, which is, like any other service, defined in WSDL.

PHASE 4. THE PROVISIONING PHASE Service provisioning is central to operating revenue- generating Web services between organizations. The provisioning requirements for Web services impose serious implications for the business process develop- ment life cycle methodology. Tasks executed during this phase involve making choices for service gover- nance, service certification, service enrolment, service auditing, metering, billing, and managing operations that control the behavior of a service during its use. As such, they entail a complex mixture of technical and business aspects for supporting service client activities.

PHASE 5. THE DEPLOYMENT PHASE The tasks associated with the deployment phase of the Web service development life cycle include the fol- lowing three steps:

• Publish the service interface. The publish operation is an act of service registration or service advertise- ment, such as using the Universal Description, Discovery and Integration (UDDI) protocol. It acts just like a contract between the service registry and the service provider.

• Deploy the Web service and business process. The run- time code for the service and process and any deployment meta-data that is required to run it are deployed during this step.

• Publish service implementation details. The service implementation definition contains the definition of the network-accessible endpoint(s) where the Web service can be invoked.

PHASE 6. THE EXECUTION AND MONITORING PHASE During this phase, the business processes and sup- porting Web services are fully deployed and made operational. By doing so, a service requestor can find the service definition and invoke all defined service operations. Also, the progress of running business processes can be monitored. For the time being only reactive monitoring mechanisms are in place.

CONCLUSION Currently, enterprise applications constructed with Web services tend to be developed in a rather ad hoc fashion. This unavoidably leads to processes and enterprise systems with nonexistent architectures, or fragile ones that are hard to maintain, reuse, and extend. Even more importantly, these practices do not take into account important business and orga- nizational considerations, such as the leasing costs of Web services and organizational issues, making them unsuitable for constructing industrial-strength busi- ness applications.

The methodology presented in this article reflects an attempt in defining a foundation of development principles for Web services based on which real-world business processes can be assembled into business sce- narios. Currently, we are enriching the methodology with patterns, (design and coding) templates that are derived from empirical material. Next, we aim to develop an integrated toolset supporting the phases of the methodology.

References 1. Alanso, G., Casati, F., Kuno, H., and Machiraju, V. Web Services: Con-

cepts, Architectures and Applications. Springer, Heidelberg, 2004. 2. Andrews, T. et al. Business Process Execution Language for Web Ser-

vices, Version 1.1. 3. Chinnici, R., Gudgin, M., Moreau, J.J., Schlimmer, J., and Weerarana,

S. Web Srvices Description Language (WSDL), Version 2.0, (Mar. 2004); w3c.org.

4. Kavantas et al. Web Service Choreography Description Language, Ver- sion 1 working draft (Aug., 2004); w3c.org.

5. Papazoglou, M.P. and Georgakapoulos, G. Introduction to the special section on service-oriented computing. Commun. ACM 46, 10 (Oct. 2003), 24–29.

6. Papazoglou, M.P. Web Services: Principle and Technology. Prentice Hall, July 2007.

Michael P. Papazoglou ([email protected]) is a professor at Tilburg University in the Netherlands. Willem-Jan van den Heuvel ([email protected]) is an associate professor at Tilburg University in the Netherlands.

Permission to make digital or hard copies of all or part of this work for personal or class- room use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

© 2007 ACM 0001-0782/07/1000 $5.00

c

COMMUNICATIONS OF THE ACM October 2007/Vol. 50, No. 10 85