Abstract

Orchestrating Web services has become the method of choice for building new services on top of existing ones. One area of interest for this technology is business processes. Languages and methods have been developed and are now getting widely used, BPEL being the typical instance. When exposing the profile of a Web service, Quality of Service (QoS) must be specified. Besides security aspects, QoS involves a variety of parameters related to performance, query throughput, as well as quality of the returned data. How should QoS be handled in this context of Web Services Orchestrations? A number of novel and not so well identified issues occur that make this topic deviating from QoS for networks in a substantial way.Firstly, since Web services aim at hiding details for the external world, no information regarding the infrastructure or resources supporting a Web service is generally exposed. This prevents from using classical resource based performance models. Contracts are preferred instead. Contracts expose what a service offers, in terms of both function and QoS; in turn, contracts may or may not assume certain constraints on how the service should be invoked.A second important feature is that, unlike in networks, the control in orchestrations may depend on the carried data. Consequently performance and data interfere, which can cause orchestrations to become non-monotonic with respect to QoS—improving the QoS of some called service may degrade the overall QoS of the orchestration. Unfortunately, relying on QoS contracts implicitly assumes monotonicity.In a contract-based framework, a central question is to relate the contract that the orchestration can offer to its customers, to the contracts it has established with its subcontractors regarding the called services. This is not so simple when dealing with Web Services Orchestrations because actual QoS parameters vary a lot for different calls and are better described by means of a probability distribution. I shall discuss probabilistic soft contracts and how to compose them. Such contracts must be monitored by the orchestration for possible violations. I shall advocate using testing techniques from statistics for this purpose.Orchestration reconfiguration (e.g., to cope with breaching) is another important issue that is beyond the scope of my presentation, however.

Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.