Andy Seaborne, Eric Stammers, Fabio Casati, Giacomo Piccinelli, Ming-Chien Shan
Today, the Internet is not only being used to provide information and perform e-commerce transactions, but also as the platform through which services are delivered to businesses and customers. More and more companies are rushing to provide all sorts of services on the Web, ranging from more "traditional" on-line travel reservations and directory services to real-time traffic reports and even outsourcing of entire business functions of an organization, such as IT or human resources departments.
Business composition is the ability for one business to compose e-services (possibly offered by different companies) to provide value-added services to its customers. Composition of e-services has many similarities with business process (workflow) automation. An e-service virtualises the customer interaction aspects of the business processes implementing a service. In order to specify how services should be composed, we must define the interaction process associated with a service as well as the flow of service and inter-service invocations. In this paper we refer to a business process that composes e-services as e-process.
We first outline the trend to business composition and e-processes, and then set out some requirements on standards to be developed to support e-processes.
E-processes are typically designed, developed, and deployed by enterprises that want to compose internal capabilities with third-party capabilities, either for internal use or to expose them as (complex, value-added) e-services to customers. Note that, while the e-services involved in an e-process may belong to several companies, the e-process is company-specific. Its definition is typically known to and controlled by a single company. For both e-processes and e-services, we do not envision the need for companies to expose internal details of how they run their business. Still, companies should be able to express in a standard format the interaction aspects for their service offer as well as for their service needs. A common language is crucial for the assessment of the compatibility between the interaction processes offered by an e-service provider and those expected by the designer of an e-process.
The effectiveness and efficiency of business processes impact directly the profitability of a company. It is in the best interest of e-service providers as well as e-service consumers to understand the operational requirements for their cooperation. An e-process defines the interactions between the company owning the process and the e-service providers involved in its implementation. In particular, an e-process defines the orchestration activity needed to enable the cooperation between the e-service providers. As traditional processes were designed around the operational model of customised business applications, e-processes should be designed around e-services. A clear understanding of the business interaction model of an e-service is paramount.
Phase 1 : integration of existing internal assets
Today, enterprises are automating their processes to reduce costs and improve process execution quality and speed. Process automation and management technologies enable the separation between business logic, resource logic, and application logic. Process can be controlled, managed, and evolved separately from the applications. Still, in this phase, resources are internal to the enterprise.
Phase 2 : static integration with partner processes on a case-by-case basis
By incorporating e-services provided by business partners into an e-process, an enterprise can create processes that utilize external resources. However, in this phase, service selection and invocation is still performed in an ad-hoc way, and require preliminary agreements (from a business, legal, and technical perspective) between the cooperating companies.
Phase 3 : dynamic integration with negotiation, with companies
Beyond such static use of external services, fully dynamic e-processes make decisions each time they are executed in order to invoke the best available service that can fulfill the customer's needs. The tradition design-deploy cycle of phases 1 and 2 has changed to a per-instance set of decisions.
In the remainder of the paper we focus on dynamic e-processes, since these are the ones that can provide the best value and are in line with the philosophy of the e-service environment. In particular, which aspects of e-services should be standardized in order for users to define e-processes that compose e-services and execute them in a fully dynamic and efficient way.
We now focus on dynamic e-processes, since these are the ones that can provide the best value and are in line with the philosophy of the e-service environment. In particular, which aspects of e-services should be standardized in order for users to define e-processes that compose e-services and execute them in a fully dynamic and efficient way. Some of these standards are under development by industry consortia or standardization bodies, while others still need to be developed.
In order to stay competitive, service providers should offer the best available service in every given moment to every specific customer. Similarly, e-processes should be able to compose the best services available when the process is executed. Hence, when defining an e-process, we need to be able to describe the type of service we want, and let the system discover which specific e-service can satisfy the e-process needs. In order to be able to select e-services and understand their characteristics, a standard for service description is needed. This standard should allow the definition of the e-service properties, so that the e-process can determine its suitability for satisfying the business needs.
We also note that we do not envision the definition of a common, global ontology that can fit every e-service description. In fact, while businesses will certainly want to use standard ontologies when available, they will often need to define attributes faster than allowed by standardization bodies. Hence, the standardization effort here should allow the definition as well as the discovery of ontologies.
The description of an e-service should include the specification of the e-service interface. In order to support e-processes, a standard way of defining this interface is required, so that the e-process execution engine can determine which operations are available on the selected e-services and how to invoke them. It is also desirable to have a description of the semantics of each operation, to understand, for instance, whether the invocation of an operation commits the invoker to a payment or to send a registration form.
Note that services are typically complex entities, offering several methods (operations) to be invoked as part of their interface. For instance, an e-music service may allow users to browse or search the catalog, to listen to songs, or to buy songs. The service provider may want to impose constraints on the order in which these operations are invoked. Hence, a simple, IDL-like definition of the interface may not be sufficient to specify how the interaction with a dynamically discovered service should be conducted. We refer to the set of interactions (i.e., invocation of operations) with an e-service as conversation. In order to be able to correctly interact with a selected service, a standard description of the supported conversations is also required.
A desirable feature in workflows as well as in service composition is the ability to execute parts of the process in an atomic fashion, i.e., so that all of it is executed or the effect of partial executions can be (semantically) "undone". A typical example is the reservation of a trip, where the customer would like to "atomically" book the flight and the hotel. If, for instance, the flight could be booked but no hotel room is available, then the flight reservation needs to be "cancelled" or "undone". A standard description of the transactional properties of an e-services would give the e-process engine the ability to perform such atomic executions and to identify how to interact with services when performing "commits" and "rollbacks".
Advanced service composition systems may provide facilities for negotiating with the discovered e-services before accessing them, and for reverting to other services if the negotiation fails. A standard for negotiation is required so that service composition tools may have embedded negotiation capabilities. In this way, the benefits of negotiations could be made easily available to e-process designers and users.
Many services may require security credentials before allowing interactions. A standard need to be defined so that e-process definition languages allow the definition of the appropriate security certificates to be used, and e-process engines know how to authenticate and get authorizations for service executions.
A contract forms the basis of an e-process between businesses. The contract identifies the roles and responsibilities of the parties, the obligations and deliverables. With dynamic integration, it become important to explicitly represent services. In earlier phases, when there was an explicit integration phase, the issues in a contract would have been dealt with. With contract choices being made during the execution of an e-process, the agreements entered into will need to be recorded.
The previous subsections have discussed mechanisms to enable interaction with an e-service once it has been discovered. However, mechanisms to discover e-services are required, so that the e-process can dynamically look for e-services during each execution. Hence, standards for identifying and querying service directories in order to retrieve information on e-services and their properties are needed.
In the previous section we have stated some requirements for dynamic e-processes. In this section we want to state a non-requirement because we believe it to be unnecessary.
There is no need to provide an explicit representation of the business network dynamically generated to deliver the value of a service. In other words, the services and processes used by one service are not exposed to the service clients. The dynamic nature of e-services means that the exact choices of which other services to use may not have been made at the time a contract is entered into.
The service client neither knows nor is concerned about the internal details about how a service meets its obligations. Each service has a partial view of the business network, no single point having a global view of the entire network.
The service provider is free to search and invoke other services that best meets its needs. Companies do not expose their internal operations or be constrained to do business as prescribed by some "global" process definition. Instead, companies want to expose services, but be free to implement such services the way they want.