Web Services provide a powerful access channel to business capabilities. Inside the company, resources can be shared and costs reduced. Outside the company, the interaction with customers and suppliers can be streamlined and business opportunities extended. A major issue with the current Web Service model is the problem of composition and the difficulties that arise as Web Services are assembled, typically in a bottom-up manner. We briefly discuss this issue, and propose a lightweight solution based on automated consistency checking of Web Service interfaces

Finkelstein, A.

Nentwich, C.

Piccinelli, G.

City Research Online

              City, University of London Institutional RepositoryCitation: Piccinelli, G., Finkelstein, A. ORCID: 0000-0003-2167-9844 and Nentwich, C. (2002). Web Services Need Consistency. Paper presented at the 17th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, 4-8 Nov 2002, Seattle, USA. This is the accepted version of the paper. This version of the publication may differ from the final published version. Permanent repository link:  https://openaccess.city.ac.uk/id/eprint/26565/Link to published version: Copyright: City Research Online aims to make research outputs of City, University of London available to a wider audience. Copyright and Moral Rights remain with the author(s) and/or copyright holders. URLs from City Research Online may be freely distributed and linked to.Reuse: Copies of full items can be used for personal research or study, educational, or not-for-profit purposes without prior permission or charge. Provided that the authors, title and full bibliographic details are credited, a hyperlink and/or URL is given for the original metadata page and the content is not changed in any way. City Research OnlineCity Research Online:            http://openaccess.city.ac.uk/            publications@city.ac.ukWeb Services Need ConsistencyGiacomo PiccinelliHewlett-Packard LaboratoriesStoke Gifford ParkBristol BS34 8QZ, UKgiacomo_piccinelli@hp.comAnthony Finkelstein & Christian NentwichDept. of Computer ScienceUniversity College LondonGower Street, London WC1E 6BT, UK{a.finkelstein|c.nentwich}@cs.ucl.ac.ukAbstractWeb Services provide a powerful access channel tobusiness capabilities. Inside the company, resources can beshared and costs reduced. Outside the company, theinteraction with customers and suppliers can bestreamlined and business opportunities extended. A majorissue with the current Web Service model is the problem ofcomposition and the difficulties that arise as Web Servicesare assembled, typically in a bottom-up manner. We brieflydiscuss this issue, and propose a lightweight solution basedon automated consistency checking of Web Serviceinterfaces.IntroductionSince their appearance in 1998, the main expectations forWeb Services were for an evolutionary approach to theaccessibility of business assets. Companies could alreadycount on considerable data-processing capabilities. Thechallenge was to make available such capabilities withinthe company, as well as to business partners.Web Services leverage the experience built in technicalcommunities ranging from distributed systems to softwareengineering. For example, significant influences come fromthe RM-ODP (Reference Model for Open DistributedProcessing). Technical and business requirements aredistilled into a simple but effective model, which appliesuniformly to different types of resources. The main roles inthe Web Service model are service provider, serviceconsumer, and service registry. The main artefacts areservices and service descriptions. The operational model isbased on the find-bind-use approach. The consumer looksfor the provider of a given service in the registry. If thesearch is successful, consumer and provider establish aconnection and the service delivery process can beperformed. From a technical perspective, open standardsare instrumental for the success of Web Services. Initiativessuch as UDDI (Universal Description, Discovery andIntegration) and the W3C Web Service Activity arenoticeable examples. A more complete overview of theWeb Service landscape can be found in [2].Considering the current stage of evolution for model,standards, and technology, the Web Service initiativereveals a solid bottom-up approach. The emphasis has beenon connectivity and access to resources, which is thefoundation for the development of concrete businesssolutions. The downside of the bottom-up approach is thatthe gap between the business and the technical notion ofservices is still open. A business service is concerned withthe end-to end delivery of a meaningful business outcome,a much coarser grain than that of the typical Web Service.There is a significant amount of work and infrastructurerequired on top of the Web Service layer in order to create abusiness solution.In this paper, we propose a lightweight approach to thereconciliation of business services and Web Services. Theapproach is based on checking the conformance of, orconsistency between, a set of Web Service interfaces and abusiness service policy. These business service policiesconstrain the valid compositions of Web Services. Toperform the checking we use xlinkit [1], a consistencymanagement framework. We first outline the lifecycle of aWeb Service, and discuss consistency issues with respect tobusiness services. We then describe a framework forconsistency management, which is based on xlinkit.Web Service LifecycleThe current scope of the Web Service model influencessignificantly the lifecycle of a Web Service. As a veryrough approximation, one Web Service can be compared toone method in more traditional software contexts. A serviceprovider is represented by a set of ports (one port for eachWeb Service) that the service consumer connects to inorder to request a service instance (invoke the method). Theinteraction between provider and consumer substantiates inone request-response exchange of information. Conceptssuch as the identity of a service instance or the aggregationof multiple services into higher-level entities (e.g. theequivalent of objects for methods) are not currentlysupported by the more established part of the Web Servicemodel.The lifecycle of a Web Service starts with the definitionof a capability with a suitable granularity. Examples ofWeb Service used inside a company are the printing of adocument, specific queries to databases (e.g. list ofavailable places on a training course), and the notificationof specific events (e.g. process completion). Examples ofWeb Service used by a company for external interaction arethe submission of an order, the notification of payment, andthe request of product information. The businesscapabilities are already implemented by the IT system of acompany. The creation of the Web Service layer mainlyconsists of the specification and publishing of the servicecontent. The service specification is formalised usingWSDL (Web Service Description Language). Using theanalogy with methods, a WSDL description captures thesignature for a Web Service. The description of the WebService is then categorised and added to the informationbase of a UDDI registry. Assuming the back-endintegration is in place, the Web Service is ready for use.The Need for ConsistencyWeb Services provide an effective access route toindividual business capabilities. Still, one of the issues thatsolution developers are left with is the gap betweenindividual capabilities and a complete business service.Even simple business services usually require thecoordinated usage of a number of different capabilities. Forexample, submitting orders is only one aspect in the overallservice logic involved in a direct-sale service. Moreover,the interaction involved in a business service usually goeswell beyond one request-response exchange. In the direct-sale example, the flow of communication may start with aproduct enquiry to end with a payment confirmation. Thebusiness conversation is driven by different roles atdifferent stages.The requirements for a business service translate intorequirements for the implementation infrastructure, whichincludes the Web Service layer. A coherent view of thevarious components involved in the implementation isessential for the realisation of the overall service. The WebService model brings technological homogeneity into thepicture but does not address this coherence.A Lightweight ApproachOur proposal for the management of consistency among adynamic set of Web Services finds concrete instantiation inthe use of the xlinkit framework.xlinkit is a framework for checking the consistency ofdistributed, heterogeneous documents. It comprises alanguage, based on first order logic, for expressingconstraints between such documents, a documentmanagement mechanism and an engine that checks thedocuments against the constraints. A full description ofxlinkit, including a formal specification of its semantics,its scalability and an evaluation can by found in [1]. Aninteractive tutorial is available at http://www.xlinkit.comThe infrastructure of xlinkit is especially geared towardsthe processing of XML-encoded documents, and thelanguage provides specific capabilities for expressing directrelations between   documents.We propose to apply xlinkit to the WSDL documentsdescribing the Web Services related to a business service.The xlinkit  rule language will be used to describebusiness service policies that must be adhered to by theWeb Services from which the business service isconstituted.This is best seen by way of a simple example. A businessservice policy might be “every time a message deals withspecial offers a transaction ID has to be used”. Such apolicy is required to support auditing of special price deals.The following are data type definitions in a WSDL file(s):<types> <schema targetNamespace="http:// freightmixer.com/specialoffers.xsd"xmlns="http://www.w3.org/1999/XMLSchema"> <element name=“SpecialOffersAvailableForDestination">       <complexType> <all>          <element name=“departureCity" type="string"/>          <element name=“destinationCity" type="string"/>          <element name=“deliveryMonth" type="string"/>          <element name=“loadWeight" type=“integer"/>          <element name=“transactionUniqueIdentifier"  type=“integer"/>      </all> </complexType> </element> <element name=“SpecialOffers">        <complexType> <all>            <element name="price" type="float"/>             <element name=“transactionUniqueIdentifier"  type=“integer"/>         </all> </complexType> </element></schema></types>The following is the part of the WSDL file(s) where themessages are defined.<message name=“RequestForSpecialOffersInput">     <part name="body" element="xsd1:SpecialOffersAvailableForDestination "/></message><message name=“RequestForSpecialOffersOutput">     <part name="body" element="xsd1: SpecialOffer"/></message>The policy can be defined simply:<forall var="m"in="./freightmixer/wsdl/message[contains(@name,'SpecialOffer')]">  <forall var="y" in="./freightmixer/wsdl /types/xsd:schema/xsd:element">    <implies>      <equal op1="substring-after($m/part/@element,':')"             op2="$y/@name"/>      <exists var="e" in="$y/xsd:complexType/*/xsd:element">        <equal op1="$e/@name" op2="'transactionUniqueIdentifier'"/>      </exists>    </implies>  </forall></forall>The evaluation of xlinkit rules by the check enginegenerates hyperlinks that link consistent and inconsistentelements as defined by the rule. If the policy above wereviolated, it would link together the message element andthe xsd:schema element that is referenced by the message.The user could infer that the schema element needs asubelement transactionUniqueIdentifier in order to be usedwith this message.ConclusionsWe believe that the expressive, declarative and formallydefined xlinkit rules are well suited to expressingbusiness service policies by way of constraints acrossWSDL descriptions. In this style policies are specifiedonce, and they can be automatically applied to evolvingsets of Web Services related to one or more businessservices. The semantic domain for a policy can range frombusiness-level requirements (e.g. always send the customera contact reference) to more technical requirements (e.g.concerning the use of appropriate XML schemas). Thexlinkit  framework is lightweight and itself readilydeployable in as a Web Service. The implicit compositionalconstraints seem to be well aligned with bottom upconstruction of business services.The approach outlined above must however, be treated withsome caution. It has only been briefly sketched and is inneed of systematic evaluation. Such an evaluation forms thenext step in our research programme.References[1] Nentwich C., Capra L., Emmerich, W. and Finkelstein, A. “xlinkit: aConsistency Checking and Smart Link Generation Service” ACMTransactions on Internet Technology, 2(2), May 2002, pp. 151-185.[2] Piccinelli G., Emmerich W., Zirpins C., and Schütt K. “Web serviceinterfaces for inter-organisational business processes: an infrastructurefor automated reconciliation” Conference on Enterprise DistributedObject Computing (EDOC), Lausanne, Switzerland, 2002.

Web Services Need Consistency

https://openaccess.city.ac.uk/id/eprint/26565/1/wsconsis.pdf

Web Services Need Consistency

Abstract

Similar works

Full text

Available Versions

City Research Online