Workshop on Cross-Organizational Workflow Management and Co-ordination (WACC'99),
San Francisco, Feb. 1999, available at
http://SunSITE.Informatik.RWTH-Aachen.DE/Publications/CEUR-WS/Vol-17/.
Full Paper (htm).
In the CHAIMS project we have developed an access protocol for distributed services that is specifically targeted at composing services of autonomous modules. We refer to that protocol as CPAM (CHAIMS Protocol for Autonomous Megamodules). Like some related protocols, e.g. SWAP [Swenson:98], it allows the asynchronous invocation of remote services. However, CPAM offers more than invocation primitives.
Because we assume remote services to be autonomous, and assume that the programmer does not have reliable information about performance, CPAM allows the client to get performance estimates before invocations take place, and to check the status of an ongoing execution. We assume that the services we compose by using CPAM are large, remote, and autonomous. Remote services can be offered by servers within the same organization, or by servers of other organizations. The location of the service is unimportant as long as the servers and the client are connected by some distribution system on which CPAM is implemented. We assume that the services offered by servers in other organizations are autonomous. Autonomy implies that the implementation, execution and maintenance is under the control of the organization owning the service. The only control the client has is to select another service, or to negotiate improvements, easier done when the service is being paid for. Changes to the servers and their services can be made any time as long as the services still cooperate with their interface posted in a generally accessible repository. Autonomy also means that the person doing composition has no control over the resources made available to the services by the organization providing the services. Yet availability of resources has a great influence on the performance of services.
Of course, we could require that performance characteristics of the services are posted along with the interface definition in a repository. Yet this approach has several weaknesses: 1) performance does not only depend on resources but also on the specific input data, 2) static performance information cannot take into account dynamic fluctuations in the performance of services, and it might only give an average or an upper bound for the performance, 3) static performance information can help in deciding if a certain service is to be used or not, but does not give any possibility to monitor the execution and performance of the service at run-time. Therefore we have introduced into CPAM the capability to obtain estimates about the performance of services prior to the invocation from the module offering the service.
We also enable the monitoring of the performance of a service during its execution. This allows to make educated decisions prior and during service invocations, and allows various novel optimization possibilities specific to the composition of large, remote, and autonomous services.