Sankar Virdhagriswaran,
Dr. Gordon Dakin, Dan Leliberte, Crystaliz, Inc.
[sv, gad, liberte] @ crystaliz.com
Abstract: In this position paper, we propose a two level architecture for web service interactions such that the role of intermediaries can be dealt with in a consistent manner. At the bottom level are interactions between web services and intermediaries that are typically thought of as providing network services: caching, filtering, authentication, etc. At the top level are interactions oriented toward business processes and intermediaries that provide business services such as collection management, arbitration, mediation, etc. The bottom level interactions are more static than dynamic and the top-level interactions are more dynamic than static. Therefore, intermediaries should provide different types of interaction support. These suggestions are based on implementation of a distributed business process engine at Crystaliz, Inc.
As the World Wide Web consortium looks towards future standardization activities w.r.to web services, it needs to organize its activities in a framework such that different working groups produce results in a consistent manner. As was identified by the call for the workshop, web-services is a very large area encompassing many inter-related, but different fields in distributed application development. The call for the workshop enumerates several important areas, but does not pay much attention to the nature of any web services application, i.e., they are network applications. In this position paper, we present our experiences in developing a distributed business process application development system to illustrate issues of interaction between networked web services and intermediaries.
Application developers assembling network/distributed applications using web services have to perform two distinct sets of activities. The first is to “wire-up” web services such that they can interact with each other. The second is to execute business processes that users want. An important problem in wiring-up of web services is the provision of network services by intermediary network service providers who in turn provide their services as web services. Examples of such intermediaries include firewall services, caching services (e.g., Akami), authentication services, load balancing services (e.g., Loudcloud), etc. The XML protocol group at W3C is dealing with these types of intermediaries in the reference model under discussion.
However, there is a set of intermediaries who provide services at the process level who are typically different from the network service providers. These service providers may provide application services that a corporation would like to outsource. Examples include obvious ones such as credit validation, and non-obvious ones such as mediation, negotiation, arbitration, collection, etc.
Since web services can enable both of these types of interaction between corporations, the standards development has to deal with these two types differently. Below, we provide our experience at Crystaliz, Inc. to motivate discussion about these issues in the workshop.
At Crystaliz, Inc. we have been developing a distributed business process management system that deals each of these issues in an integrated, yet separable layer.
The bottom layer deals with static wiring between web service nodes and deals with issues of discovery and reflection, activation and execution, and data flow between web services. This layer is based on ideas that were invented in data flow computing and provides a uniform framework for dealing with network service intermediaries. The data flow framework allows introduction of state-full and stateless transducers in the flow of data between web services that may implement typical application services. These transducers may wire the network by rewriting and re-routing, replicating and merging, caching, or by setting up guardian filters on the data flow.
The top layer deals with organization of the business process network and management of execution of business processes.
In order to provide a uniform framework for dealing with organizational/administrative management issues that arise in including intermediaries, we provide different level of support for organization of web services. We consider web services to be either an individual agent, a group of agents performing a process, or an agency that exposes services performed by agents within its administrative sphere mediated by a gatekeeper. This organization allows for different types of intermediaries to be used in developing a business process. This metaphor of organizing web services is very similar to the way companies interact -- through named individuals or groups or through another company. Because these are agents, we assume that they need to support synchronous and asynchronous interactions. Accordingly, our system supports both.
Additionally, in the top layer we provide a way to introduce process execution intermediaries that can deal with developing and managing business process execution. These intermediaries can deal with dynamic nature of business process execution, transaction semantics between multiple distributed web services when a transaction fails, and monitor the execution of the processes.
Dynamic execution implies that intermediaries and web services need to be able to share context and need to support dynamic activation of an intermediary or service. The context needs to provide sufficient information such that the dynamic activation can perform its function correctly. Additionally, due to security reasons, a web service may not want to make available the context for inspection by some other web service or intermediary or may want to appoint an intermediary that makes anonymous the service that is being dynamically activated. Our system supports both these possibilities. Context of a dynamic “call” can be given to a service separately from the service identified or can be bundled together and passed or a reference to an intermediary node that makes anonymous the place where the execution will take place.
Dealing with transaction execution or transaction failure with distributed web services is a more complex issue than using simple two-phase commit protocols for managing transactions. Intermediaries may or may not have the ability to deal with errors in a long living transaction distributed across many different web services. They may want to delegate the error handling to some other web service or may want to back propagate the errors through all the web services that were involved in the execution of the transaction before the error occurred. Intermediaries may or may not have access to the context of the failure in order to deal with the failure. Our system allows for developing different kinds of web service intermediaries that may handle a transaction failure through mediation, arbitration, or negotiation. Each of these schemes leverage the organization support described in the above paragraph to signal and deal with errors in the execution of transactions.
Monitoring of execution of a business process that uses multiple web services has to deal with access control and visibility issues, as each web service (and intermediary) may not want to provide access to all its information to all the business processes. Furthermore, the monitoring system has to assemble the state of execution by interacting with distributed hosts in an asynchronous manger. Our system allows monitoring system to be built that can address these problems.
Finally, as a result of monitoring business processes, an organization may want to dynamically redefine the business process. The definition, monitoring, and re-definition support should be such that users who perform these activities can use the same metaphor for reorganizing the network service layer and the business process execution layer. In our system, we use a data flow based approach to addressing this need.
In this position paper, we argued that interaction between web services should be thought of as happening in two separate logical layers: a) The network service layer, and b) The business process layer. We argued that the network services layer consists of static connections between web services and network service intermediaries and the business process layer consisted of dynamic interactions between web services and business process intermediaries. We presented details of the system under development at Crystaliz, Inc. to support these positions. We hope that the workshop to shape the future evolution of web service standardization will use these implementation experiences in charting their course of action.