Web services are rapidly becoming the defacto distributed enterprise computing technology for realizing and managing multi-party business processes [5]. By now, most enterprises have gained some early experience in developing internal Web services in a first attempt to leverage their legacy assets and to accelerate development and integration of their enterprise applications. However, most of today’s enterprises are still far from benefiting from the full-fledged potential of Web service technology embodied in its ability to mix-and-match internal and external 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 software components. This is in no way sufficient for implementing and managing commercial-strength, service-enabled enterprise applications. While simple (internal) Web services may be constructed that way, a development life cycle methodology is of crucial importance to design, construct, monitor, and manage enterprise SOA applications supporting existent business process ecosystems that are highly complex and 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 inventory 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), construction 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: checking the credit worthiness of the customer, determining 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 shipment 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.
Services that are orchestrated inside a process should be loosely coupled to each other, avoiding interdependencies at the level of data or control logic.
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-contained and modular business processes with clearly defined boundaries and discrete service endpoints. Two key principles serve as the foundation for service- 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 orchestrated 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:
- 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:
- Interchangeable/replaceable services: Existing services may be swapped with new service implementations—or ones supplied by a different provider offering better performance or pricing—without disrupting the overall business process functionality;
- Multiple service versions: Different versions of a service 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.
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 genuinely related to one another. The guidelines by which to increase cohesion are as follows:
- Functional service cohesion: A functionally cohesive business process should perform one and only one problem-related task and contain only services necessary for that purpose. For an order management business process, such services include get-product-price, check-product-availability, and check-creditworthiness
- Communicational service cohesion: A communicationally 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.
- 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 analyzing 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 commences with comparing planned services with available software service implementations that may be assembled within the enclosures of a newly developed business process. Four categories of existing service resources are discerned: legacy systems, commercial off-the-shelf (COTS) components, 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, benefits, and return of investment of the following options to develop new business processes:
- Green-field development: Follows a classical development model covering specification down to development. With this option we assume that the business processes must be developed from scratch without any reuse of existing process chunks or service specifications.
- Top-down development: Usually a blueprint of business use cases provides the skeleton specification for business services. The top-down process decomposes the business domain into its functional areas and subsystems, including its flow or process decomposition into processes, sub-processes and high-level business use cases.
- Bottom-up development: Starts from existing enterprise applications and repositories and transforms them to new services by wrapping.
- Out-of-the-middle development: Combines top-down and bottom-up development by allowing service aggregators to select those fragments of enterprise resources that best satisfy new business process requirements. Fragments are then retrofitted using services.
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.
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 service requirements and lack substantial business value.
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. To address this problem, service development solutions must target specific focal points and common practices 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, operational 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 realization 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 artifacts 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 implementation 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 services.
Risk analysis weighs benefits and costs in the provisioning scenarios and verifies feasibility before a particular 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 development option as the ratio of net benefits over costs. After calculating the ROI for each scenario and assessing 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 interacting Web services. This step is logically succeeded by service design, during which conceptual processes 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 shipping service. By applying the dominant cohesion criterion, namely functional cohesion, this service is decomposed into service operations like “select shipper” and “check product availability.
In case reference models are available (such as the XML common business library, xCBL, or RosettaNet), business functions can be derived on their basis. For example, the order management business process in Figure 2 could be derived on the basis of RosettaNet’s partner 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 language (WSDL) [3] for this purpose. This process basically comprises four steps: describing the service interface, specifying operation parameters, designating 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 literature [1].
Identifying processes. The objective of this step is to identify services that may be aggregated into a business 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 protocol coupling with the material requirements process. In case of top-down development, reference models are given that standardize processes and correlated services 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 activities 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 composition: orchestration and choreography. Orchestration describes how Web services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single endpoint. (For an example 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 executable 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 public (globally visible) message exchanges, rules of interaction and agreements that occur between multiple business process endpoints, rather than a specific business process that is executed by a single party. Choreography is more collaborative in nature than orchestration. It is described from the perspective of all parties (common view), and defines the complementary observable behavior between participants in business process collaboration.
Orchestration is the preferred composition style for internal business processes with tightly coupled internal 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 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 orchestration [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 particular, 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 handle 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 scheduling agency.
4. Identify non-functional business process concerns.
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-functional concerns that are captured in an SLA.
SLAs provide a proven vehicle for not only capturing non-functional requirements but also for monitoring 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 reference (conversation atomicity).
Another important ingredient of an SLA is security policies to protect multi-party collaborations. Knowing 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 messages, 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.
Service provisioning is central to operating revenue-generating Web services between organizations. The provisioning requirements for Web services impose serious implications for the business processdevelopment 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 validated 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 programming 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 business process is revamped as a coarse-grained asynchronous 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 development life cycle methodology. Tasks executed during this phase involve making choices for service governance, 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 following three steps:
- Publish the service interface. The publish operation is an act of service registration or service advertisement, 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 runtime 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 supporting 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 organizational considerations, such as the leasing costs of Web services and organizational issues, making them unsuitable for constructing industrial-strength business 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 scenarios. 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.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment