Composing Web Services in an Open World: Issues of Quality of Service View Full Text


Ontology type: schema:Chapter     


Chapter Info

DATE

2008

AUTHORS

Albert Benveniste

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. More... »

PAGES

14-14

Book

TITLE

Formal Modeling and Analysis of Timed Systems

ISBN

978-3-540-85777-8
978-3-540-85778-5

Identifiers

URI

http://scigraph.springernature.com/pub.10.1007/978-3-540-85778-5_2

DOI

http://dx.doi.org/10.1007/978-3-540-85778-5_2

DIMENSIONS

https://app.dimensions.ai/details/publication/pub.1016428690


Indexing Status Check whether this publication has been indexed by Scopus and Web Of Science using the SN Indexing Status Tool
Incoming Citations Browse incoming citations for this publication using opencitations.net

JSON-LD is the canonical representation for SciGraph data.

TIP: You can open this SciGraph record using an external JSON-LD service: JSON-LD Playground Google SDTT

[
  {
    "@context": "https://springernature.github.io/scigraph/jsonld/sgcontext.json", 
    "about": [
      {
        "id": "http://purl.org/au-research/vocabulary/anzsrc-for/2008/0806", 
        "inDefinedTermSet": "http://purl.org/au-research/vocabulary/anzsrc-for/2008/", 
        "name": "Information Systems", 
        "type": "DefinedTerm"
      }, 
      {
        "id": "http://purl.org/au-research/vocabulary/anzsrc-for/2008/08", 
        "inDefinedTermSet": "http://purl.org/au-research/vocabulary/anzsrc-for/2008/", 
        "name": "Information and Computing Sciences", 
        "type": "DefinedTerm"
      }
    ], 
    "author": [
      {
        "affiliation": {
          "alternateName": "Institut de Recherche en Informatique et Syst\u00e8mes Al\u00e9atoires", 
          "id": "https://www.grid.ac/institutes/grid.420225.3", 
          "name": [
            "Inria-Rennes; Irisa, Campus de Beaulieu, 35042\u00a0Rennes cedex, France"
          ], 
          "type": "Organization"
        }, 
        "familyName": "Benveniste", 
        "givenName": "Albert", 
        "id": "sg:person.011174600625.42", 
        "sameAs": [
          "https://app.dimensions.ai/discover/publication?and_facet_researcher=ur.011174600625.42"
        ], 
        "type": "Person"
      }
    ], 
    "datePublished": "2008", 
    "datePublishedReg": "2008-01-01", 
    "description": "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\u2014improving 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.", 
    "editor": [
      {
        "familyName": "Cassez", 
        "givenName": "Franck", 
        "type": "Person"
      }, 
      {
        "familyName": "Jard", 
        "givenName": "Claude", 
        "type": "Person"
      }
    ], 
    "genre": "chapter", 
    "id": "sg:pub.10.1007/978-3-540-85778-5_2", 
    "inLanguage": [
      "en"
    ], 
    "isAccessibleForFree": false, 
    "isPartOf": {
      "isbn": [
        "978-3-540-85777-8", 
        "978-3-540-85778-5"
      ], 
      "name": "Formal Modeling and Analysis of Timed Systems", 
      "type": "Book"
    }, 
    "name": "Composing Web Services in an Open World: Issues of Quality of Service", 
    "pagination": "14-14", 
    "productId": [
      {
        "name": "doi", 
        "type": "PropertyValue", 
        "value": [
          "10.1007/978-3-540-85778-5_2"
        ]
      }, 
      {
        "name": "readcube_id", 
        "type": "PropertyValue", 
        "value": [
          "4e46c6440f5b97d77441a8dc672a87e4659d1ed083f7f7f9656aa299bd8910c3"
        ]
      }, 
      {
        "name": "dimensions_id", 
        "type": "PropertyValue", 
        "value": [
          "pub.1016428690"
        ]
      }
    ], 
    "publisher": {
      "location": "Berlin, Heidelberg", 
      "name": "Springer Berlin Heidelberg", 
      "type": "Organisation"
    }, 
    "sameAs": [
      "https://doi.org/10.1007/978-3-540-85778-5_2", 
      "https://app.dimensions.ai/details/publication/pub.1016428690"
    ], 
    "sdDataset": "chapters", 
    "sdDatePublished": "2019-04-15T11:17", 
    "sdLicense": "https://scigraph.springernature.com/explorer/license/", 
    "sdPublisher": {
      "name": "Springer Nature - SN SciGraph project", 
      "type": "Organization"
    }, 
    "sdSource": "s3://com-uberresearch-data-dimensions-target-20181106-alternative/cleanup/v134/2549eaecd7973599484d7c17b260dba0a4ecb94b/merge/v9/a6c9fde33151104705d4d7ff012ea9563521a3ce/jats-lookup/v90/0000000001_0000000264/records_8660_00000028.jsonl", 
    "type": "Chapter", 
    "url": "http://link.springer.com/10.1007/978-3-540-85778-5_2"
  }
]
 

Download the RDF metadata as:  json-ld nt turtle xml License info

HOW TO GET THIS DATA PROGRAMMATICALLY:

JSON-LD is a popular format for linked data which is fully compatible with JSON.

curl -H 'Accept: application/ld+json' 'https://scigraph.springernature.com/pub.10.1007/978-3-540-85778-5_2'

N-Triples is a line-based linked data format ideal for batch operations.

curl -H 'Accept: application/n-triples' 'https://scigraph.springernature.com/pub.10.1007/978-3-540-85778-5_2'

Turtle is a human-readable linked data format.

curl -H 'Accept: text/turtle' 'https://scigraph.springernature.com/pub.10.1007/978-3-540-85778-5_2'

RDF/XML is a standard XML format for linked data.

curl -H 'Accept: application/rdf+xml' 'https://scigraph.springernature.com/pub.10.1007/978-3-540-85778-5_2'


 

This table displays all metadata directly associated to this object as RDF triples.

70 TRIPLES      22 PREDICATES      27 URIs      20 LITERALS      8 BLANK NODES

Subject Predicate Object
1 sg:pub.10.1007/978-3-540-85778-5_2 schema:about anzsrc-for:08
2 anzsrc-for:0806
3 schema:author N327d7ec621d047c0af46cb0313e01ecb
4 schema:datePublished 2008
5 schema:datePublishedReg 2008-01-01
6 schema:description 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.
7 schema:editor N8bdacf6fb3604bce9005e77a67cc400f
8 schema:genre chapter
9 schema:inLanguage en
10 schema:isAccessibleForFree false
11 schema:isPartOf Ned3d5369406d48f184780cb90ca378c6
12 schema:name Composing Web Services in an Open World: Issues of Quality of Service
13 schema:pagination 14-14
14 schema:productId N553dff08b59e4b138397ee2f3a258676
15 N5bf4735480c14bfab51441e76cbd6d86
16 N8567de15565c42a7a5ea2640ca80c73e
17 schema:publisher N06f3d437d7364933a7a494f4a06d6c21
18 schema:sameAs https://app.dimensions.ai/details/publication/pub.1016428690
19 https://doi.org/10.1007/978-3-540-85778-5_2
20 schema:sdDatePublished 2019-04-15T11:17
21 schema:sdLicense https://scigraph.springernature.com/explorer/license/
22 schema:sdPublisher N3133e5e7934c48409c5f326e3d35468a
23 schema:url http://link.springer.com/10.1007/978-3-540-85778-5_2
24 sgo:license sg:explorer/license/
25 sgo:sdDataset chapters
26 rdf:type schema:Chapter
27 N06f3d437d7364933a7a494f4a06d6c21 schema:location Berlin, Heidelberg
28 schema:name Springer Berlin Heidelberg
29 rdf:type schema:Organisation
30 N18945b7c9df143afb7f6432a80ebce78 rdf:first Ndc7794f4d3e84105b30976cc1f1ce86f
31 rdf:rest rdf:nil
32 N3133e5e7934c48409c5f326e3d35468a schema:name Springer Nature - SN SciGraph project
33 rdf:type schema:Organization
34 N327d7ec621d047c0af46cb0313e01ecb rdf:first sg:person.011174600625.42
35 rdf:rest rdf:nil
36 N553dff08b59e4b138397ee2f3a258676 schema:name dimensions_id
37 schema:value pub.1016428690
38 rdf:type schema:PropertyValue
39 N5bf4735480c14bfab51441e76cbd6d86 schema:name readcube_id
40 schema:value 4e46c6440f5b97d77441a8dc672a87e4659d1ed083f7f7f9656aa299bd8910c3
41 rdf:type schema:PropertyValue
42 N6829153198524cfbad1f78a9b9acf8e0 schema:familyName Cassez
43 schema:givenName Franck
44 rdf:type schema:Person
45 N8567de15565c42a7a5ea2640ca80c73e schema:name doi
46 schema:value 10.1007/978-3-540-85778-5_2
47 rdf:type schema:PropertyValue
48 N8bdacf6fb3604bce9005e77a67cc400f rdf:first N6829153198524cfbad1f78a9b9acf8e0
49 rdf:rest N18945b7c9df143afb7f6432a80ebce78
50 Ndc7794f4d3e84105b30976cc1f1ce86f schema:familyName Jard
51 schema:givenName Claude
52 rdf:type schema:Person
53 Ned3d5369406d48f184780cb90ca378c6 schema:isbn 978-3-540-85777-8
54 978-3-540-85778-5
55 schema:name Formal Modeling and Analysis of Timed Systems
56 rdf:type schema:Book
57 anzsrc-for:08 schema:inDefinedTermSet anzsrc-for:
58 schema:name Information and Computing Sciences
59 rdf:type schema:DefinedTerm
60 anzsrc-for:0806 schema:inDefinedTermSet anzsrc-for:
61 schema:name Information Systems
62 rdf:type schema:DefinedTerm
63 sg:person.011174600625.42 schema:affiliation https://www.grid.ac/institutes/grid.420225.3
64 schema:familyName Benveniste
65 schema:givenName Albert
66 schema:sameAs https://app.dimensions.ai/discover/publication?and_facet_researcher=ur.011174600625.42
67 rdf:type schema:Person
68 https://www.grid.ac/institutes/grid.420225.3 schema:alternateName Institut de Recherche en Informatique et Systèmes Aléatoires
69 schema:name Inria-Rennes; Irisa, Campus de Beaulieu, 35042 Rennes cedex, France
70 rdf:type schema:Organization
 




Preview window. Press ESC to close (or click here)


...