Network Working Group Rezaur Rahman Internet-Draft Rama R. Menon Expires: May 2002 Intel Corporation Lee Rafalow IBM Corporation Enabling OPES to Use Web Service for Callout Service draft-rrahman-web-service-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Open Pluggable Edge Services architecture (OPES) defines an open standards based framework for providing services on intermediaries to operate on client requests and server responses. One of the key elements of this framework is the notion of callout services. Currently proposed remote callout service implementations interact with an OPES intermediary through specially designed callout protocols like iCAP[11]. Web services are beginning to emerge as new way of providing services on the Internet. Web Services provide standard methods of exposing and using the services available to anyone interested in using them through open standards like UDDI and WSDL. This document describes how the OPES framework can make use of these standards in implementing callout services. Rezaur [Page 1] Internet Draft Web Services as Callout Service November 2001 Table of Contents Status of this Memo.................................................1 Abstract............................................................1 1. Introduction.....................................................3 1.1 Requirement Language............................................3 1.2 Relationship to other standards work............................3 2. Terminology......................................................4 3. Content Encapsulation............................................4 4. WebService URI Scheme............................................6 5. Security Considerations..........................................8 6. Intellectual Property............................................8 7. Acknowledgments..................................................8 8. References.......................................................8 9. Disclaimer.......................................................9 10. Author's Address................................................9 11. Full Copyright Statement.......................................10 Appendix A: Web Services Execution.................................11 Appendix B: Performance Issues.....................................16 Appendix C: Automated Service Invocation Rules.....................17 Rezaur Expires May 2002 [Page 2] Internet Draft Web Services as Callout Service November 2001 1. Introduction One of the core benefits provided by the Open Pluggable Edge Services architecture is to allow a standard way for the content provider and/or third parties to provide value added services to be performed on the requests and responses going through the OPES intermediary. Proposed solutions to deploy these services include developing call- out services on a protocol like [11] or creating locally executed proxylets to provide these services. Web Services are becoming the prominent service infrastructure for the web, based on more publicly accepted standards like SOAP, UDDI, WSDL etc. Due to their openness the web services tools are becoming the infrastructure of choice for publishing various services ranging from language translation to temperature conversion to local airport weather forecast; also, the number of these services are increasing at an explosive rate. The use of these various web services is limited only by the imagination of the clients and content/service providers. Since OPES is aiming at making the Edge Services Platform open and easy to use, it makes sense to provide sufficient architectural support in its framework to leverage the existing web services tools to develop the services platform for OPES. This draft outlines a method of using web services as a callout service deployed in an OPES environment. The appendix near the end of this draft provides implementation notes on enabling OPES with web services. 1.1 Requirement Language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in RFC2119. 1.2 Relationship to other standards work With the standardization of XML in World Wide Web Consortium (W3C) there has been a flurry of development in the IT industry to provide services for distributed applications using XML as the foundation. These activities resulted in services based on web technologies that are available to distributed applications and are known as web services. A web service includes various components like service description, discovery, registration, data transport etc. Recently W3C has taken up the protocol activities like SOAP and trying to develop the technologies that standardize the protocol used by the web services. It is expected that more similar efforts will follow from W3C and other standards organizations to standardize the web services components. Rezaur Expires May 2002 [Page 3] Internet Draft Web Services as Callout Service November 2001 Since not all components needed to build web services are standardized yet, it is expected that this draft will be modified in future to use more and more of the standardized components of the web services infrastructure. 2. Terminology WSDL “ Proposed Web Services Description Language is an XML format for describing network services [1]. UDDI “ Universal Description Discovery and Integration specification provides a way to describe, discover and integrate services on the Internet. [2] SOAP - Simple Object Access Protocol is an XML based protocol for exchange of information in decentralized, distributed environment. [3] tModel “ In the context of UDDI registry a tModel describes a service interface definition [4]. It defines the abstract interface rather than a specific implementation of the service. tModelKey - Each tModel is given a unique identifier (uuid) known a tModelKey. 3. Content Encapsulation The services performed in the OPES framework will have to deal with various types of entities in a data format other than XML like HTTP header, body, images, etc. These SOAP packages MUST follow the following SOAP packaging in order to provide efficient processing of the contents. In order to provide efficient access to non-XML content, the web services SHOULD use SOAP with attachment [10] messages for non-XML content type. In addition the encoding MAY provide offset and length of each attachment in the ŸSOAP message package÷. Figure 3.1 below describes the XML schema we propose to enhance the SOAP message access. With the help of the elements defined in this schema, a ŸSOAP message package÷ can be accessed randomly to improve service operation. The ŸManifest÷ element in this schema MAY contain any of the request, response header and body component information. These tags make it easier for the web services to access the data elements. Rezaur Expires May 2002 [Page 4] Internet Draft Web Services as Callout Service November 2001 OPES Manifest Schema Fig 3.1. Example 3.1 below shows an HTTP message containing SOAP message package including attachment. The SOAP body also contains the ŸManifest÷ element described above to provide direct access to the SOAP attachment components. In this example the namespace prefix †onsË is tied to an OPES defined target namespace. Ÿreqhdr÷ and Ÿreqbody÷ elements in this namespace provide the means to specify the offset and length of request header and request body components from the end tag of the SOAP envelope. POST /bookOrder HTTP/1.1 Host:www.bookstore.com Content-type:Multipart/Related;Boundary=MIME-Boundary;type=text/xml; Start=÷÷ Content-length: xyz SOAPAction: http://schemas.bookstore.com/newbook Rezaur Expires May 2002 [Page 5] Internet Draft Web Services as Callout Service November 2001 --MIME-Boundary Content-type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: --MIME-Boundary : Content-ID: : req-header entries : : --MIME-Boundary : Content-ID: : req-body --MIME-Boundary Example 3.1. 4. WebService URI Scheme For the proxylet based web services (Appendix A) the rule description SHOULD follow standard proxylet URI scheme defined in [7]. The support for the Web Services execution through discovery requires a way to tie a rule to a specific web service. A new URI naming convention is defined for this purpose. This follows the syntax of Proxylet URI scheme defined in [7]. Syntax: The ABNF grammar syntax for the web services URI is as follows: Rezaur Expires May 2002 [Page 6] Internet Draft Web Services as Callout Service November 2001 Uri = Ÿwebservice:÷ Ÿ//÷ [server] [Ÿ/÷ resource-path] server = // as specified in RFC2396. resource-path = an XML document path within the server. Here resource-path points to an XML document describing the web service. The resource contains the following information items, A ŸType÷ whose value is either ŸWSDL÷ or ŸUDDI÷. If the type is WSDL, the record contains a URI for the WSDL repository (the server where the WSDL document is located) otherwise the file contains a tModelKey. The file MUST contain the operation name (e.g., checkVirusInfection) to invoke the service. For interoperability, the OPES callout MUST use document-oriented SOAP binding for its automated operation. This is necessary since the automated system needs to know the entry point to the webservice that describes the top level call to process the source document. The following XML Schema describes the XML content model for a web services resource file. Rezaur Expires May 2002 [Page 7] Internet Draft Web Services as Callout Service November 2001 5. Security Considerations The Web Services for Callout Protocol SHOULD provide a sufficient standard for securing the web services. As of this writing the work in developing an industry standard for securing web services is under way by various companies. We shall follow the industry development on this aspect of web services and provide recommendation in a future draft. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments Thanks to Christian Maciocco for his valuable feedback on the draft. 8. References [1] Eric Chrsitensen, Francisco Curbera, et al.,"Web Services Description Language(WSDL) 1.1", W3C Note, 15th March 2001. [2] UDDI Org, ŸUDDI Technical White Paper÷, 6th September 2000. [3] Editors: Martin Gudgin, Marc Hadley, et al., ŸSOAP Version 1.2 Part 1: Messaging Framework÷, 2nd October 2001. [4] UDDI Org, ŸUsing WSDL in a UDDI Registry 1.05÷, UDDI Working Draft, Best Practices Document, 25th June 2001. [5] UDDI Org, ŸUDDI version 2.0 API Specification÷, UDDI Open Draft Specification, 8th June 2001. Rezaur Expires May 2002 [Page 8] Internet Draft Web Services as Callout Service November 2001 [6] UDDI Org, ŸUDDI Version 2.0 Data Structure Reference÷, UDDI Open Draft Spec, 8th June 2001. [7] Maciocco, C., Hofmann, M., "OMML: OPES Meta-data Markup Language", draft-maciocco-opes-omml-00.txt [8] Tomlinson, Orman, Condry, et al., " Extensible Proxy Services Framework", draft-tomlinson-epsfw-00.txt [9] Yang, L., Hoffman, M., ŸOPES Architecture for Rule Processing and Service Execution÷, draft-yang-opes-rule-processing-service- execution-00.txt [10] Barton, Thatte et al., ŸSOAP Messages with Attachments÷, W3C Note, 11th December, 2000. [11] The ICAP Protocol Group, ŸICAP, the Internet Content Adaptation Protocol÷, draft-elson-opes-icap-02.txt 9. Disclaimer The views and specification herein are those of the authors and are not necessarily those of their employer. The authors and their employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. 10. Author's Address Rezaur Rahman Intel Corporation MS JF3-202 2111 NE 25th Ave. Hillsboro, OR 97124 Phone: +1-503-264-0417 E-Mail: rezaur.rahman@intel.com Rama R. Menon Intel Corporation M/S JF3-206 2111 NE 25th Ave. Hillsboro, OR 97124 Phone: +1-503-712-1438 E-Mail: rama.r.menon@intel.com Lee Rafalow IBM Corporation, BRQA/502 3039 Cornwallis Road Research Triangle Park, NC 27709 E-mail: rafalow@watson.ibm.com Rezaur Expires May 2002 [Page 9] Internet Draft Web Services as Callout Service November 2001 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it maybe copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other then English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Rezaur Expires May 2002 [Page 10] Internet Draft Web Services as Callout Service November 2001 Appendix A: Web Services Execution +----------------------+ | OPES | +-----------+ | Controller | +-----------+ | User |----->|----------------------|----->| Content | | Agent |<-----| Service |<-----| Server | +-----------+ | Execution engine | +-----------+ +----------------------+ A | | |Callout Protocol | V +----------------------+ | Callout | | Service | +----------------------+ Fig A.1 - OPES System Architecture Components Fig A.1 shows a typical OPES system architecture with a callout service in use. The service execution engine communicates with the callout service though a callout protocol. This section looks at ways of integrating the web services with OPES service execution engine such that the web services become callout services and the webs service protocol becomes a callout protocol in the above diagram. There are two ways of accomplishing this task: (1) a manual method that involves custom development of a Ÿproxylet-like÷ shell for each web service or (2) an automated integration mechanism that involves discovery and invocation of a web service. The first alternative requires a portion of the web service invocation process to be manually developed, integrated and executed before the service can be used by the OPES controller box. This scenario is suitable for services that involves complex programmatic interfaces requiring coding on the part of web service client. This mode of operation closely resembles existing proxylet version of the service execution performed in the existing OPES framework. The other alternative is where the particular endpoint of a web service instantiation is discovered before making a service call. In this scenario, the web services discovery and invocation is mostly automated. This second procedure provides greater flexibility in maintaining and migrating web services from one server to another. Rezaur Expires May 2002 [Page 11] Internet Draft Web Services as Callout Service November 2001 Direct Call to a Web service from a Proxylet The web services in this scenario works as a proxylet service for the service execution environment [8]. As shown in Fig A.2 below, this type of proxylet has two components- (1) interface to the service execution engine through proxylet APIs and (2) the web service proxy which executes on behalf of the remote web service on the local platform. The web service component MAY make use of more than one web service to complete its operation. In this scenario the proxylet developer uses UDDI to select a web service provider and retrieves the interfaces for a given service. This interface is exposed as WSDL document. In some scenarios the developer may get access to the WSDL document for a service from a separate WSDL server or some other means. The developer chooses proper binding and end points for the web service and generates necessary code for web services proxy. The web services proxy code and execution logic is exposed as a proxylet for the service execution engine. ---------- | Client | ---------- | A V | |------------------------| ------------- Web Protocol------------ |OPES Service Execution |->|Proxy| Web |---------->|Web Service | | OPES Controller |<-|-let |Service|<----------| | ------------------------- | | Proxy | |------------| | A -------------- V | |---------| | Server | |--------_| Fig A.2. Web Services Client as a Proxylet in an OPES Framework Fig A.2 above shows a generalized model of a web service invocation by a Service Execution engine using proxylet API. In this scenario, the web service description SHOULD be retrieved and a web service proxy MUST be generated off-line with human intervention. The web service proxy MUST implement appropriate interface (like proxylet interface) to integrate with the OPES service execution module. Rezaur Expires May 2002 [Page 12] Internet Draft Web Services as Callout Service November 2001 The proxylet SHOULD be installed on the Service Execution environment in the OPES Controller, as part of the system installation/configuration. After this is done, it becomes possible to invoke the web service through the proxylet (Fig A.3). | rule module A V | +--------------+ | | Rule Parser | |[Rule Parsing and | & Validation | | compilation] +--------------+ | | | V | +--------------+ | | Rule | | | Base | V +--------------+ | | | V +---------+ +----------+ +---------+ +--------+ -->| Message |--->| Rule |-->| Service |------->|Proxylet| | Parser | | Processor| |Execution| |WebServc| +---------+ +----------+ +---------+ +--------+ <----------------------------------------------------------------> [Rule Processing and Service Execution] Fig A.3. Service Execution within an OPES Device [9] A rule match described through rule module [9] causes the Service Execution to invoke the proxylet (Fig A.3). Upon invocation, the proxylet gathers data and transforms the request and/or response messages and associated data through web service interface. The protocol details and message formats exchanged between the proxylets and the web services are defined in documents [3] and [1]. Rezaur Expires May 2002 [Page 13] Internet Draft Web Services as Callout Service November 2001 Automated Web Service Execution through Discovery This method is intended for the automated invocation of web services in an OPES framework. In this scenario, the rule engine provides a hint as to the service to be executed and the service engine performs the rest. There are two parts to this process. Offline process: is where the hints provided by rule author is used to discover and auto generate the web services proxy as dynamically loadable modules. The interfaces for these dynamically loadable modules will be implementation specific since these modules will be auto generated by the system. Runtime process: is where a rule match triggers a specific web service invocation and the web service proxy is loaded and tied to the resources (message headers and bodies) to be processed by the remote web service. By its nature, automated web service discovery and execution is applicable where the web service involves simple method execution as shown in Fig A.4. ---------- | Client | ---------- | A V | SOAP |------------------------|WEB Protocol |-----------| |OPES Service Execution |------------> |Web Service| | OPES Controller |<-------------| | ------------------------- |-----------| | A V | |---------| | Server | |--------_| Fig A.4. Web Service Execution from the Service Execution Engine The SOAP message to the web service (Fig A.4) can be document oriented where the whole document is sent to the Web service for transformation (example: language translation service that works on an HTML document). Or it can be RPC oriented where parts of the document are converted by invoking remote procedures (example: converting temperatures in a document from Celsius to Fahrenheit). For automated web service proxy generation, the web services that Rezaur Expires May 2002 [Page 14] Internet Draft Web Services as Callout Service November 2001 support document-oriented SOAP messaging protocol SHOULD be used. This requirement is imposed due to the nature of Edge Services in the OPES framework and the suitability of the web services to automated code generation and invocation. (See section 4 and Section 7.) For RPC oriented Web Services, see the method described in 3.1. Automated web service discovery and invocation enables the service execution unit to make policy driven selection between different service providers by looking up the UDDI registry entries. The process is as follows: A. The service execution engine is setup with a list of UDDI registry URIs to be used for service discovery. B. The rule module specifies the service though a list of tModelKeys[4] and a method name. C. The service is discovered and invoked. The process of selecting a given service provider who supports a given service interface is as follows. The item numbers in the list corresponds to the numbers associated with the arrows in figure A.5. Service UDDI WSDL Web Service Execution Server Server Host | 1 | | | | -------> | | | | 2 | | | | <------- | | | | | 3 | | | ------------------------> | | | 4 | | <------------------------- | | 5 | |----------------------------------------->| | 6 | |<-----------------------------------------| Fig A.5. Web Service Discovery and Execution Sequence 1. The OPES Service Execution engine makes a Ÿfind_Service÷[5] UDDI API call to locate all services that are defined by the given tModelBag. The tModelBag contains the tModelKey for the WSDL Interface we are interested in and other criteria. 2. This call returns a businessList on success. Assuming a non“empty list, the execution engine drills down the list using UDDI API calls to evaluate and select a business that satisfies the service policy requirements at the edge (see browse pattern[5]). Once a Rezaur Expires May 2002 [Page 15] Internet Draft Web Services as Callout Service November 2001 business service is discovered that matches the policy requirement, the appropriate bindingTemplate is retrieved from the business service. The selection of binding template depends on the various attributes of the bindingTemplate structure[6] like accessPoint, tModelInstanceDetails etc. The tModelInstanceInfo is traversed to retrieve the WSDL URL containing the WSDL service interface document. 3. The service execution module requests (this should be through the dynamically loaded proxylet) the WSDL document for a given service from the WSDL server retrieved in step 2. 4. The server returns the WSDL document that describes the endpoints of the requested web service. 5. Service Execution unit selects a particular implementation of a service based on policies at the OPES controller. The binding SHOULD be a SOAP binding. 5.1 The steps up to this point will be performed when the rule engine compiles a rule describing the web service. 5.2 On a rule match, using the interface definition described in the WSDL file and the operation name described in the rule file, the web service enabled service execution engine makes service request to the web services host at the end point. The service execution engine will be responsible for sending the Ÿrequest÷ and Ÿresponse÷ modification requests together with the data to the web service. The service request MUST follow the content encapsulation guideline described in section 4. 6. The server performs appropriate service requested on the document or data element and returns the result. For the cases where the service requester knows the location of a WSDL document, one can start from step 3 enumerated above. Appendix B: Performance Issues This section is non-normative. The performance issues will be addressed by specific implementation. This section makes some suggestions regarding how to overcome the overhead related to the web service discovery. In order to speed up the service execution performance, the UDDI registry search or the WSDL registry search MAY be performed statically when the rule base is loaded into the system and processed. When a rule match happens at run time, the ServiceExecution module would load appropriate precompiled code to communicate with a web service. Preview Operation: A preview operation MAY be provided by the web services to check ahead part of the content to determine further action from the web services on the content. Rezaur Expires May 2002 [Page 16] Internet Draft Web Services as Callout Service November 2001 Appendix C: Automated Service Invocation Rules The web service end points described by WSDL can operate on messages containing either document-oriented or procedure oriented information [1]. A document-oriented message lends itself to simplified programming model, capable of being generated computationally with tractable complexity. The web service automation as described in section 3.2 is applicable for simple method invocation where the web service call semantics require a single top level method call that operate on a document sent as a SOAP attachment or as part of the SOAP body. Rezaur Expires May 2002 [Page 17]