Current WsXL process description proposals and systems lack sufficient dynamic service integration and process control capabilities for the implementation of the desired VEs.
Consider the application of ordering food from those restaurants found in waiter.com. One first gets a selection of restaurants. That can be one operation. Then a menu of available food to order. That is another operation. In fact, there is a sequence of operations that needs to be performed, typically including login, authentication, information gathering, and then decisions to be made based upon the results returned.
Such information is not explicitly represented in WSDL but is in WSCL, an HP proposal for integrating web services. One component of WSCL allows one to specify interactions, which allow specification of a message type that will transfer a specific XML document for a specific part of a conversation. An example is:
<Interaction interactionType="Receive"
id="LoginRegInput">
<InboundXMLDocument id="LoginRequestData"
hrefSchema=http://foo.org/LoginRequestData.xsd />
</Interaction>
This is very similar to an ACL. In this case, the Type
"Receive" is similar to an ACL performative
in that it is a pre-defined type of message. However,
unlike an ACL,
more of the semantics are defined by the associated application-specific
id "LoginRegInput". The ACL
content
of the message is similar to the InboundXMLDocument
with specific content of "LoginRequestData"
in this case.
The WSCL further specifies transitions, which specify which messages should be sent under different circumstances. In essence, the WSCL allows specification of any set of web services (WSDL operations) that can be defined as an acyclic graph with transitions dependent upon values returned from the operations. Thus automatic software could determine from a WSCL graph how to navigate from operation to operation and what messages to send. And these messages are a kind of an execution control language (ECL).
While it allows a important degree of dynamism, the WSCL does not allow the full dynamism of an ACL that allows, for example, negotiation. It would not allow a consumer to negotiate pricing or a supplier to negotiate terms of delivery. Because it is based on graphs, neither iteration nor recursion is allowed. Neither is there a method for abstracting services.
WSFL is an IBM proposal of a service flow description language, also consistent with WSDL, that is, at the time of writing, seems an early incomplete draft. Not only is it RPC-like, but even the examples are at best ambiguous and at worst inconsistent[WSFL Example Note]. The protocol is based upon IBM's workflow product and does not have an ECL, but rather takes a more database-like approach of specifying datalinks.
WSFL uses a Global Model to show the endpoints of services and WSDL operations. "Global" only means with reference to one WSFL service, including those external WSDL operations directly connected to that service. WSFL uses a Flow Model to show the ordering of the data flow, only for the "activities" (an IBM term for workflow steps) within the service, and thus only indicates the flow for the directly connected external operations.
WSFL has two desirable features. First, it allows services to be composed recursively. Second, it allows definitions of types of services that can be bound to concrete services at runtime. So for example, there could be several shipping services defined for a larger integrated service and a particular shipper could be selected at runtime.
But the workflow model is particularly ill-suited for the Internet. Most workflow systems depend strongly upon the early-binding approach in which a well-defined process model allows only the selection of set alternatives and particular actors in defined roles at runtime. This degree of dynamism still does not allow the dynamic planning and re-planning of service chains. WSFL requires the generation of a "global model" that dictates the interactions between all of the services prior to execution. And there is no provision for changing this global model during execution. Moreover, the initial formalism indicates that this would be difficult to do because there is no way to propagate the changes to service providers. (How and by whom the global model is shared is not specified.)
Most important, each concrete service that wants to "play" in an integrated service must write a special WSDL operation corresponding to some datalink in the Global Model. While this code could be conceivably reused in some other integrated service, in practice, this means that service integration is hard-coded with WSDL. Services can not be integrated at runtime. The graph-basis of all the WSxL specifications mean that new business partners and services cannot be integrated at runtime, thus eliminating the possibility of a real-time dynamic VE, though this is most apparent with WSFL's requirement for coding WSDL operations.
This is unchanged in BPEL4WS. Not only are the particular messages and partners defined prior to runtime, necessitating programming, but even message transport method is defined. If that changes, for example, from synchronous to asynchronous, new operations have to be defined between endpoint partners. Dynamic change is thus expensive and time-consuming, requiring continual human intervention.
As it was in WSFL and XLANG, it is unclear in BPEL4WS exactly how the process engine and the model it executes is to be shared and maintained by the process partners. It is very likely that this approach will not scale, and it certainly poses maintenance issues, unless a central partner controlling the process in each defined process.
In fact, if we look at the travel agent example popular with the WxFL approaches, including BPEL4WS, one can see that there are never more than binary connections made, with some actor being a central party. Unlike the bank case, the flow is not public and is based upon mutual agreement, but the flow model is still centralized. The travel agent is the likely candidate to control this flow as all of the connections are through the travel agent. There are, for example, no connections from the airline to the traveler. This means that, at least with this example, there is no real difference between the bank/centralized control model and the WxFL/workflow control model and many hard issues are not exposed.
For instance, there is no way for the travel agent to know when and how the airline will fulfill the itinerary request. The airline could in theory "shop out" the request to another airline. The travel example is chosen precisely because this does not happen in practice and the request is either granted or refused almost instantaneously. This example is also chosen because there is no notion of dynamic negotiation with the airline, although one can certainly imagine that discounts and coupons could be negotiated on the fly based on current business.
However, in principle, the specification allows the kind of data flow shown in the figure "Workflow-like Flow Control" in the main paper. The general case is not achievable with just WSDL because there may be multiple threads of data flow, which must be appropriately sequenced depending upon values from prior operations. A process model describes the transitions that can occur at execution time.
An important integration issue that we mention only in passing is transaction management and ensuring transaction atomnicity. There are standard techniques for distributed computations that can be brought to bear[Tygar]. One of these standards, the two-phase commit, is at the heart of the OASIS Business Transaction Protocol (BTP)1.
BPEL4WS improves on WSFL because it allows compensating transactions operation in case of failure. But such rollbacks are insufficient in a distributed process where the state of the world may have changed in unanticipated ways. Such problems may be addressed by Semantic Web-enabled Web Services (SWWS)2, a new WSxL-consistent project targeting flexible runtime mediation of process integration as well as discovery, using DAML-S as well as other technologies to be developed within the project.
1BTP 1.0 http://www.oasis-open.org/committees/business-transactions/
2 SWWS http://swws.semanticweb.org/
[Tygar] J.D. Tygar,
"Atomicity versus Anonymity:
Distributed Transactions for Electronic Commerce",
Proc. 24th
VLDB Conf., pp 1-12, New York, 1998.
See also
http://www.vldb.org/conf/1998/p001.pdf
[WSFL Example Note] : Critique of WSFL
Travel Example
http://snrc.stanford.edu/~petrie/fx-agents/xserv/icpaper/appendix-d.html