Data Transport. Publisher's Note

Transcription

1 Data Transport Publisher's Note This document should be considered a draft until the message formats have been tested using the latest release of the Apache Foundation's SOAP code. When those tests are completed, the document will be incorporated into the Meteor specifications. The Meteor Project 1 October 2, 2001

2 Data Transport Business Messages and the Request Response Model Meteor's exchange of data is dependent upon a series of business messages over the Internet. Following the package of most real-time business messaging over the Internet, Meteor uses standard communication protocol and data specifications. The basic model is a request message from one "node," the SOAP sender, to another, the ultimate SOAP receiver. 1 This is followed by a response message. Generally the Meteor request message provides authentication and a request for information. This is followed by a response message that provides the requested information or an explanation of why the information was not provided. The business messages are in XML. For data transport, the SOAP protocol is used with Remote Procedure Calls (RPC). There is a SOAP "wrapper" around the XML message. Meteor implements SOAP using the World Wide Web's HyperText Transfer Protocol (HTTP). The SOAP Specifications Meteor uses the SOAP data transport protocol. 2 As one of the popular Web services, the protocol is being widely implemented to exchange business messages. Because the SOAP protocol can use the Web's HTTP protocol, SOAP messages can pass through most firewalls without changing the firewall configuration. 3 SOAP is implemented using XML. 4 The original SOAP specification was developed by Userland Software, Microsoft, IBM, and Develop Mentor. Version 1.1 was published by W3C as a note on 8 May Subsequently it was assigned to the XML Protocol Working Group for further development. Although the name originally meant Simple Object Access Protocol, now it is just a word that names the protocol. Although most of the XML related specifications begin with the letter X, the XML Protocol Working Group agreed "SOAP" is so well known that it should be used. A revised draft of the SOAP specification, Version 1.2, was published as a W3C note 9 July W3C describes the XML Protocol saying: 1 The SOAP protocol permits communications to have intermediate SOAP nodes. As used in Meteor, the message exchange is directly between an access provider and a data provider with no intermediate SOAP nodes. This is a true peer-to-peer implementation. 2 For the latest version of the SOAP protocol specification, see Ref For the http protocol specification, see Refs. 2 and 3. 4 For the XML language specification, see Ref. 4. The Meteor Project 2 October 2, 2001

3 The goal of XML Protocol is to develop technologies which allow two or more peers to communicate in a distributed environment, using XML as its encapsulation language. Solutions developed by this activity allow a layered architecture on top of an extensible and simple messaging format, which provides robustness, simplicity, reusability and interoperability. 5 Meteor uses a specific implementation of SOAP, the Remote Procedure Call (RPC). This is described in Section 7 of the SOAP specification. 6 Using HTTP Two examples from the SOAP 1.2 specification, examples 43 and 44, show the SOAP messages carried by HTTP. Listing 1 shows the request message for the stock quotation example. (The message contains the stock symbols of the desired quotation). Listing 2 shows the response. These two examples illustrate an HTTP implementation of SOAP. POST /StockQuote HTTP/1.1 Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: " <env:envelope xmlns:env=" >... </env:envelope> Listing 1 Example of a SOAP HTTP Post HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <env:envelope xmlns:env=" >... </env:envelope> The Meteor SOAP Envelope Listing 2 Example of the HTTP Response The SOAP message based on the January 2001 prototype of Meteor, as implemented now, is shown in Listing 3. This version was compliant with the SOAP 1.1 protocol and the Apache Foundation's implementation of SOAP. 7 5 Taken from the W3C Webpage on October 1, This use of SOAP was based on David Winer's XML-RPC specification. See Ref. 5 for the last version. 7 The Apache Foundation also has an implementation for the SMTP mail protocol. The Meteor Project 3 October 2, 2001

4 Although SOAP itself has many functions, these are not needed for this implementation. Security is provided by using TLS/1 or SSLv3 encryption of the connection between the two peer computers exchanging data. Encryption is required by the IFX specification. 8 The IFX Specification is designed to provide messages and data elements necessary to provide Application Level Security on top of an existing secure communications channel between the client and server. This Channel Level Security is not specified in this document, which is intentionally transportindependent. The mechanism used to provide this secure communications channel will be specified in each of the IFX Implementation Specifications associated with this document. 9 Most IFX implementations use SSLv3. 10 Authentication is handled within the IFX message. The nature of the application, only providing information, does not require assured delivery. Subsequent to the January 2001 Meteor prototype, W3C issued a draft specification for SOAP labeled version 1.2. The Apache Foundation's implemented SOAP 1.1 and has not yet announced a schedule for implementing 1.2. Version 1.1 will continue to be used until a final version 1.2 specification, due in 2002, is available. If version 1.2 were implemented, some name changes would be required, but the structure of the business message envelope would not change. Also, W3C issued the XML Schema specification as a recommendation the highest level of W3C endorsement. Implementation of the 2001 XML Schema would changes references to the schema and instance schema. Request Message The current SOAP implementation continues to use Apache Foundation code and supports SOAP version 1.1. A sample request message is shown in Listing 3. Comparing Listing 3 to the January prototype, the XML tag <IFXRequestEl> was removed as unnecessary. The method has been changed from getloanhistory to 8 See Ref. 6 for the current version. A new version is expected late October 2001 following the October 12-14, 2001 meeting of the IFX Forum. The changes and extensions of the specification do not effect any of the examples. 9 Ref. 6, page The SSL (Security Sockets Layer) specifications were developed by Netscape Communications, Inc. For the last specification, see Ref. 7. SSL was to be submitted to the Internet Engineering Task Force (IETF) for further development. More than three years later, IETF issued TLS/1, Transport Layer Security protocol as a Request for Comment (RFC). See Ref. 8. TLS/1 is deliberately backward compatible with SSLv3. TLS/1 has one significant advantage. Instead of reassigning the connection to another port because it is encrypted, it encrypts the current connection. Most recent server software is TLS/1compliant, but operates primarily as SSLv3 because of browsers and other software that only supports SSL. The Meteor Project 4 October 2, 2001

5 getawardinfo reflecting the broader scope of Meteor implementation. There is no functionality change for data transport. Similarly the server name was changed from ifxloan-server to ifx-finaid-server. The encodingstyle has been to changed to to incorporate changes made by the Apache Foundation since the January 2001 prototype. <!-- SOAP Envelope using SOAP Version > <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsd=" xmlns:xsi=" <SOAP-ENV:Body> <ns1:getawardinfo SOAP-ENV:encodingStyle=" xmlns:ns1="urn:ifx-finaid-server"> <!-- IFX business message here --> </ns1:getawardinfo> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listing 3 Meteor SOAP Envelope for SOAP Version 1.1 In the example in listing 3, the namespace references to the XML Schema and schema instance are to those existing in January 2001 when the prototype was demonstrated. Subsequently the XML Schema has been issued as a W3C recommendation. Current references to the XML Schema would be: The new URLs for the W3C version 1.2 of SOAP are: Response Message The response message, shown in Listing 4, is similar to the request message. The request method GetAwardInfo is returned as GetAwardInfoResponse following a SOAP convention. The boundaries of the returned message are denoted using the tag <return>, which is required by the SOAP specification. The Meteor Project 5 October 2, 2001

6 <!-- SOAP Envelope using SOAP Version > <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsd=" xmlns:xsi=" <SOAP-ENV:Body> <ns1:getawardinforesponse SOAP-ENV:encodingStyle=" xmlns:ns1="urn:ifx-loan-server"> <return> <!-- IFX business message here --> </return> </ns1:getawardinforesponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listing 4 Meteor Response Message The Meteor Project 6 October 2, 2001

7 References 1. "SOAP Version 1.2," W3C Working Draft, World Wide Web Consortium (W3C), Cambridge, Massachusetts, USA, 9 July Fielding, R. et al, "Hypertext Transfer Protocol HTTP/1.1, RFC 2616," The Internet Society, Reston, Virginia, USA, June Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication," RFC 2617, The Internet Society, Reston, Virginia, USA June "Extensible Markup Language 1.0 (Second Edition)," World Wide Web Consortium (W3C), Cambridge, Massachusetts, USA, 6 October Winer, David, "XML RPC Specification," Userland Software, Burlingame, California, USA, 16 October "Interactive Financial Exchange Business Message Specification Version ," Public Review Draft, IFX Forum, Inc., Alexandraia, Virginia, USA, 21 December Freier, Alan O., Pacul C. Kocher, and Philip L. Karlton, "The SSL Protocol Version 3.0," Netscape Communications Corporation, Mountain View, California, USA, March 4, Dierks, T., and C. Allen, "The TLS Protocol Version 1.0," RFC 2236, The Internet Society, Reston, Virginia, USA, January The Meteor Project 7 October 2, 2001