Scribd Logo
Upload

Welcome to Scribd!

  • 34 views

    A Restful Approach: Clean Upnp Without Soap

    Uploaded by

    m.bandu
    This document discusses criticisms of using SOAP for UPnP and proposes an alternative based on REST principles. It summarizes that SOAP is an inappropriate technology for UPnP that is overly complex and layered. In contrast, a REST-based approach would provide simpler, lightweight UPnP systems by using standard HTTP methods to access addressable resources directly through URLs.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    A Restful Approach: Clean Upnp Without Soap

    Uploaded by

    m.bandu
    34 views6 pages
    This document discusses criticisms of using SOAP for UPnP and proposes an alternative based on REST principles. It summarizes that SOAP is an inappropriate technology for UPnP that is overly complex and layered. In contrast, a REST-based approach would provide simpler, lightweight UPnP systems by using standard HTTP methods to access addressable resources directly through URLs.

    Original Title

    soap_rest

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses criticisms of using SOAP for UPnP and proposes an alternative based on REST principles. It summarizes that SOAP is an inappropriate technology for UPnP that is overly complex and layered. In contrast, a REST-based approach would provide simpler, lightweight UPnP systems by using standard HTTP methods to access addressable resources directly through URLs.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    34 views6 pages

    A Restful Approach: Clean Upnp Without Soap

    Uploaded by

    m.bandu
    This document discusses criticisms of using SOAP for UPnP and proposes an alternative based on REST principles. It summarizes that SOAP is an inappropriate technology for UPnP that is overly complex and layered. In contrast, a REST-based approach would provide simpler, lightweight UPnP systems by using standard HTTP methods to access addressable resources directly through URLs.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 6

    A RESTful Approach: Clean UPnP without SOAP

    Jan Newmarch
    School of Network Computing
    Monash University
    [email protected]

    Abstract SOAP, and in section 5 suggest a simpler alternative based


    on REST principles. Section 6 gives a comparison of the
    UPnP is middleware designed for network “plug and two methods.
    play”. It uses technologies developed specifically for
    UPnP but also borrows technologies such as SOAP from 2. SOAP
    Web Services for remote procedure calls. SOAP has been
    criticised as inappropriate for Web Systems and this paper
    A remote procedure call (RPC) is a mechanism whereby
    shows that these criticisms are equally applicable for
    an application can make calls on a remote, networked ser-
    UPnP. It shows how mechanisms built on REST princi-
    vice by making what appear to be local procedure calls. The
    ples can produce smaller, faster and simpler UPnP systems.
    RPC layer translates this local call on a client-side proxy
    into TCP or UDP packets that are forwarded to a server-
    Keywords: Middleware, UPnP, network protocols
    side stub where it executes a procedure on the server. The
    result is returned back to the proxy where it is presented as
    the result of the local call.
    1. Introduction There are many RPC systems, from Sun’s RPC (renamed
    as IETF ONC) [7], DCE [8] and COM+ [9] through to
    UPnP (Universal Plug and Play) is an industry standard Object-oriented versions such as CORBA [10] and mobile
    to allow devices to be added seamlessly into a small net- object versions such as Java RMI [11]. SOAP (Simple Ob-
    work such as a home network [1]. The technologies un- ject Access Protocol) is neither simple nor object-based and
    derlying UPnP have been developed steadily since 1998, corresponds to Sun’s RPC in nature.
    and SOAP [2] is included in this as a remote procedure call The WWW Consortium has standardised SOAP and has
    (RPC) mechanism. also defined a protocol transport, namely SOAP over HTTP
    SOAP has been borrowed as an RPC mechanism from [2]. This uses HTTP POST messages to convey a SOAP
    Web Services [3]. However, there is a strong community procedure call (which is an XML document) and uses the
    who have criticised SOAP on technical grounds in the arena HTTP response to return another XML document contain-
    of Web Services [4, 5]. The general opinion within this crit- ing the procedure call results.
    ical group is that SOAP is a poor implementation of twenty-
    year old technology, and is neither done well nor in a man-
    3. REST critique of SOAP
    ner fitting the intended application area, and offers no novel
    features to justify its adoption.
    This paper considers these criticisms as applied to using REST was invented by Fielding as a term to describe
    SOAP within UPnP. It comes to a similar conclusion: SOAP the “ideal” architecture of the Web as a means of delivering
    is not appropriate for UPnP and represents a poor techni- documents over HTTP [6]. It uses this description to help
    cal solution to RPC for UPnP control points and devices. explain the success of the web, and how this has guided
    It presents a solution based on REST principles [6] that is work on protocols such as HTTP 1.1. The key concepts of
    substantially more lightweight for devices and is generally REST are:
    a simpler and “cleaner” model. • It describes a simple stateless protocol (no hidden state
    The next section reviews SOAP as an RPC technol- as in cookies).
    ogy. We follow that with a critique of the technology from
    the viewpoint of REST. Next we examine how UPnP uses • Every resource is addressable.
    • Uniform addressing scheme: every resource is ad- CONTENT-TYPE: ...
    dressed in the same manner. SOAP-ACTION: ...
    • Small number of operations, with distinct semantics. <Envelope>
    The criticisms of SOAP include [4, 5] <Body>
    <CUSTOMERS>
    • SOAP documents have their own protocol of proce- </CUSTOMERS>
    dure calls, which is layered over HTTP. This increases </Body>
    the complexity of SOAP procedure calls compared to </Envelope>
    simple document fetches using GET and POST. It is
    also more highly layered than other RPC protocols, with response:
    which typically sit directly above TCP or UDP, which
    HTTP/1.0 200
    may increase the possibility of system errors
    CONTENT-TYPE: text/xml
    • The semantics of GET versus POST are that a doc- CONTENT-LENGTH: ..
    ument request using GET is not intended to make
    state changes on the server, whereas a request using <?xml version="1.0"?>
    POST is expected to do so. SOAP requests must use <Envelope>
    POST since they are uploading an XML document, <Body>
    but there is no requirement that a SOAP request be a <CUSTOMERS>
    state-change request. This blurs the meaning of POST. <CUSTOMER>
    While apparently trivial, this removes a weapon from <ID>11</ID>
    the armory of firewall controllers who have been able <FIRSTNAME>Julia</FIRSTNAME>
    to distinguish the intent of a request by its HTTP type ...
    </CUSTOMER>
    • A SOAP response may be a complex data type repre- ...
    senting several “objects”. Alternatively, it could be a </CUSTOMERS>
    simple data type or a URL representing a SOAP server </Body>
    (which is not a SOAP object). That is, a SOAP re- </Envelope>
    ply could be of three different types, but these types
    do not include other addressable objects! This differs In this, no customers have addresses. They cannot be
    from other RPC systems which (rightly) claim an ob- accessed individually; they cannot be passed to other clients
    ject base: a CORBA call can return a CORBA refer- as either objects or addresses since they have no defined
    ence to other objects; a Java RMI call can return a Java existence outside of the return document.
    object or a proxy object for a remote object. There The REST version is to issue a request:
    is no “type-safety” concept for the URL’s from SOAP GET http://host/CUSTOMERS
    replies with response consisting of addresses:
    • Still on this issue, the Web has thrived on the ability to <resources
    make links between documents. In order to do this, ev- xmlns:xlink="http://www.w3.org/1999/xlink">
    ery entity must have an address as a URI. This require- <resource
    ment is lost when SOAP can return nested data struc- xlink:href="http://host/CUSTOMER/0/">0
    tures representing entities without addresses and has </resource>
    no mechanism to return addresses of SOAP address- <resource
    able objects (since there is no such concept in SOAP). xlink:href="http://host/CUSTOMER/1/">1
    Other middleware systems allow calls to return objects </resource>
    with the same middleware addressing scheme so that <resource
    calls can be made to these in turn xlink:href="http://host/CUSTOMER/2/">2
    </resource>
    By way of example, consider a database query on per- <resource
    sons. A SOAP request might look like (simplified): xlink:href="http://host/CUSTOMER/3/">3
    </resource>
    POST url HTTP/1.1 </resources>
    HOST: ...
    CONTENT-LENGTH: ... Further requests are then made of addresses such as:

    2
    GET http://host/CUSTOMER/1/ accessible through URLs. Access to device/service infor-
    with response: mation is through a standard HTTP GET, and this returns
    an XML document. There are no issues with this.
    <resources xmlns:xlink="http://www.w3.org/1999/xlink"> The initial specification of UPnP data-types adopts the
    <ID>11</ID> XML data-type specification of primitive types, but with no
    <FIRSTNAME>Julia</FIRSTNAME> aggregation types such as arrays or records. The types in-
    ... clude integers, booleans, floats, dates and strings. There is
    </resources> no possibility of unaddressed internal data structures in this.
    which consists of primitive values. But the audio-visual specifications break this data-type re-
    striction and use the complex MPEG-21 hierarchy of data-
    types [15]. This issue is considered in more detail later.
    4. UPnP and SOAP However, if the UPnP organisation is prepared to allow
    new UPnP services to break with established specifications
    UPnP consists of a number of components [12], just then it will need to place some limits on this. It will also
    like other discovery systems such as Jini [13] and Saluta- need to place limits on vendor extensions to data-types to
    tion. (The IETF Service Location Protocol does not have ensure that each data element can be addressed.
    an equivalent of SOAP, since it expects each service to have The first two criticisms of SOAP (extra protocol layer
    its own communication protocol.) The components are: and blurring of semantics) are applicable to UPnP. UPnP
    has “actions” which are generally expected to change state
    • A format for service/device description. UPnP uses and “queries” which ask for the values of state variables
    XML. and are not expected to change state. Using SOAP, both
    • A mechanism for advertising services/devices. UPnP actions and queries must be called using POST, whereas
    uses a new multicast protocol called HTTPMU (HTTP REST would say that actions should use POST and queries
    multicast over UDP) [14], based on HTTP syntax but should use GET. In general, SOAP just supplies a “noise”
    (of course) not HTTP semantics. This protocol intro- layer that increases traffic and obscures semantics without
    duces new verbs such as NOTIFY and M-SEARCH to adding anything to functionality.
    replace GET, POST, etc. For example, the Device Architecture 101 contains an
    example query for the value of a state variable in a service
    • A mechanism for searching for devices/services. This (we simplify it a bit):
    also uses HTTPMU
    POST controlUrl HTTP/1.1
    • Devices/services in the first place are accessed by their HOST: ...
    address as a URL. At that address is a detailed descrip- CONTENT-LENGTH: ...
    tion of the device or service. This is an XML docu- CONTENT-TYPE: ...
    ment. SOAP-ACTION: ...
    • A device description includes vendor-related informa-
    <Envelope>
    tion, a list of services and a URL address for each ser-
    <Body>
    vice.
    <QueryStateVariable>
    • A service description contains names of methods and <varName> vblName </varName>
    the data types to be passed as “in” parameters and re- </QueryStateVariable>
    turned as “out” parameters. </Body>
    </Envelope>
    • Finally, UPnP specifies that SOAP is to be used for
    method calls and return of results.
    which under REST could simply be:
    5. UPnP with REST GET controlUrl/vblName HTTP/1.1
    HOST: ...
    Most of UPnP is in accordance with REST principles. A
    fairly small set of verbs is used for service advertisement In a similar manner, actions can be encoded
    and discovery (NOTIFY and M-SEARCH). An appropriate as POST requests with the parameters as an
    protocol is used: an adaptation of HTTP for a multicast en- application/x-www-form-urlencoded string.
    vironment. All devices and even their nested services are For example, a SOAP encoding of an action as:

    3
    POST controlUrl HTTP/1.1 because the tasks were time-sharing, each using about 40%
    HOST: ... of the CPU, whereas in the second case each task was using
    CONTENT-LENGTH: ... over 90% of the CPU on each machine.
    CONTENT-TYPE: ... The results are presented in Table one. It can be seen
    SOAP-ACTION: ... that the REST-based solution is about twice as fast as the
    fastest of the SOAP versions, and this includes overheads
    <Envelope> (presumably similar for both) of networking, task switch-
    <Body> ing, etc. There is also a difference in packet sizes. For
    <actionName>
    <argumentName> value </argumentName> SOAP/Xerces Soap/KXML REST
    </actionName> standalone 196 137 67
    </Body> network 165 114 64
    </Envelope>
    Table 1. Time to make 1000 queries (secs)
    would under REST be encoded as:
    example, a query on a variable Text with value text00
    POST controlUrl/actionName HTTP/1.1 has a payload as XML document or as form encoded values,
    HOST: ... both wrapped in an HTTP packet. The sizes for this typi-
    CONTENT-LENGTH: ... cal query are given in Table 2. The sizes are significantly
    CONTENT-TYPE: application/x-www-form-urlencoded
    smaller for the form encoded encoded packets.
    argumentName=value SOAP REST
    Request payload 350 4
    The proposed encodings have the service control point
    packet 535 84
    as part of the address (as does the SOAP encoding). But the
    proposed encodings also have the query variable or control Response payload 365 11
    action as part of the address, unlike the SOAP encodings packet 526 171
    where this information is buried within the XML SOAP re-
    Table 2. Query request size (bytes)
    quest document. This proposed encoding fits better with
    the REST philosphy. It should be noted that this not only
    In addition to these factors, memory is also consumed
    allows quicker processing of valid queries, but also makes
    by running an XML parser or an x-www-form-urlencoded
    it easier for the server to detect errors such as invalid action
    parser, and the corresponding data structures built. We
    or invalid state variable without needing to parse an XML
    tested this by just parsing the SOAP payload of an action
    document.
    against the payload of the same action form encoded.

    6. Implementation SOAP/Xerces Soap/KXML REST


    classes+data 416,336 114,808 6,072
    CyberGarage has an implementation in Java for UPnP
    devices and control points [16]. This allows devices and Table 3. Size of parsers (bytes)
    control points to be written in Java and run as applications.
    This is available in source code form. CyberGarage is able
    to use two XML parsers, the Xerces parser from the Apache 7. Audio-visual proposal
    project and KXML, a lightweight parser better suited to
    enbedded systems. We modified CyberGarage to use the UPnP includes an extensive package for discovering me-
    simpler GET and POST commands of form encoded data as dia services and information [17]. This differs in nature
    described earlier. We then had three versions to test: using from existing UPnP standards in that it uses a far more ex-
    SOAP with both lightweight and heavyweight XML parsers tensive range of data-types. For example, to describe audio-
    and a REST-based version using no SOAP in method calls. visual data a ContentDirectory uses a subset of the MPEG-
    We ran a test of querying a service’s state variable one 21 Digital Item Declaration Language called DIDL-Lite.
    thousand times in a loop. In the first test the device and con- DIDL-Lite allows a complex hierarchy of resources to be
    trol point were run as separate processes on a Linux com- stored in a directory. A directory may contain other directo-
    puter using Sun’s JDK 1.4. In the second test the device was ries such as “My Music” and “My photos,” and in turn “My
    run on one computer and the control point on another, con- Music” might list music albums, while inside one of these
    nected directly by crossover cable. The first case is slower might be individual music tracks. The representation of any

    4
    part of the hierarchy is given as an XML document con- (a) remain as a separate service; (b) have all its media infor-
    forming to the DIDL-Lite DTD. However, this structured mation copied to an existing “central” server; or (c) under
    document is effectively invisible in the device and service this proposal could simply copy a top-level container ad-
    descriptions since it is simply represented as a string. dress to the central server. Requests in this last case would
    For example, the Browse action to search through a di- be referred to the device actually carrying the service. This
    rectory has an “out” parameter of A ARG TYPE Result would reduce traffic in amalgamating playlists, etc, from
    as a string, but this string is to be interpreted as a DIDL- multiple sources.
    Lite document. In its format as a string, it offers nothing
    new to the model proposed above. The string can simply be 8. A double standard
    returned as a parameter in a form encoded string.
    However, regarded as an XML document it is necessary The UPnP organisation has mandated SOAP for UPnP
    to look more closely at this structure. Each object in a con- v1.1. Discussions for UPnP v2.0 are now underway. It is
    tent directory is required to have a unique identifier “item”. possible for the REST proposals to coexist with the exist-
    Calls to actions such as Browse must give this “item” iden- ing SOAP. If a device receives a GET request then it must
    tifier of the object it is browsing (so that it can browse sub- be a REST request since SOAP does not allow GET. If it is
    directories and individual items). The returned XML docu- a POST request then the Content-Type can be used to
    ment contains a representation of objects in a directory, and distinguish between SOAP and REST. In this paper we have
    this representation contains the identifier of each object. For used the content type of x-www-form-urlencoded,
    example, a browse of item “0” (the root directory) might re- but to avoid any potential ambiguity another name could be
    turn a list of objects containing identifiers “1”, “2” and “30”. invented. Thus there is no difficulty in transitioning from
    Requests to these objects must include this identifier. one mechanism to the other.
    Effectively this identifier is the address of the object
    within the directory service. However, the current proposal 9. Conclusion
    hides this address deep within the SOAP call:

    POST controlUrl It has already been noted that the allowable data-types
    ... are not bound by the original specification documents.
    Browse(id, ...) REST can offer some pragmatic guidelines particularly in
    ... regard to addressability of objects for future work in this
    area.
    There is a significant advantage to using REST instead of
    The identifier is a “hidden” address in that knowledge of SOAP. Devices using SOAP need to be able to parse XML
    the address is not enough to get access to it: it is neccessary documents; devices using REST do not have this require-
    to use a SOAP method call. The identifier should be made ment. Although devices may be required to produce XML
    part of an address for the object, so that it can be accessed documents (as in media content) this can be done simply by
    directly. A possibility might be controlUrl/id. string operations that do not need an XML parser.
    Requests to the object could then be made directly to Thus there is a significant memory and processing re-
    its address, qualified by parameters giving the request de- quirement caused to devices by using SOAP that is not
    tails. For example, a browse request does not change state present using REST. UPnP systems using REST techniques
    so could be sent as a GET rather than POST: are demonstrably faster and lighter than those using SOAP.

    GET controlUrl/id?requestType=browse... References


    The current type of the identifier is string. This would al- [1] UPnP Forum, UPnP Home Page,
    low a URL to be given in place of just the identifier without http://www.upnp.org.
    changing the specification. But it would be better to change
    the specification to be a url instead of any string. [2] WWW Consortium, “SOAP 1.2 Protocol,”
    In addition to making the address visible, there is also the http://www.w3.org/TR/soap12.
    side-benefit that addresses are no longer restricted to just the
    [3] WWW Consortium, Web Services Home Page,
    device - an object could be anywhere on the network. Cur-
    http://www.w3.org/2002/ws/
    rently, the specification only allows a final resource such as
    a CD track to be a url. By allowing urls to be the value of an [4] P. Prescod, “A new direction for Web
    “item” would allow more flexible use of devices. For exam- Services,” XML Journal, http://www.sys-
    ple, if a mobile media service joins the network then it could con.com/xml/article.cfm?id=454.

    5
    [5] J. Newmarch, “A critique of web services” IADIS E-
    Commerce 2004, Lisbon, 2004.
    [6] R. Fielding, “Architectural Styles and the
    Design of Network-based Software Ar-
    chitectures”, http://www.ics.uci.edu/ field-
    ing/pubs/dissertation/top.htm.
    [7] IETF, “ONC Remote Procedure Call”
    http://www.ietf.org/html.charters/oncrpc-
    charter.html.
    [8] Open Software Foundation, Open Group DCE Portal,
    http://opengroup.org/dce/
    [9] Microsoft, COM+ Home Page,
    http://www.microsoft.com/com/tech/COMPlus.asp
    [10] Object Management Group, OMG Home Page,
    http://www.omg.org/.
    [11] Sun Microsystems, “Java Re-
    mote Method Invocation¡”
    http://java.sun.com/j2se/1.4.1/docs/guide/rmi/spec/rmiTOC.html.
    [12] UPnP, “UPnP Device Architecture”,
    http://www.upnp.org/resources/documents/
    [13] K. Arnold et al, “The Jini Specification”, Addison-
    Wesley, 1999.
    [14] Y.Y. Goland, et al, “Multicast and Unicast
    UDP HTTP Messages”, expired IETF draft,
    http://www.upnp.org/resources/specifications.asp.
    [15] MPEG, “ MPEG-21 Overview v.5”
    http://www.chiariglione.org/mpeg/standards/mpeg-
    21/mpeg-21.htm.
    [16] S. Konno, “Cyberlink for java”
    http://www.cybergarage.org/net/upnp/java/index.html.
    [17] UPnP, “MediaServer V 1.0 and MediaRenderer V 1.0”
    http://www.upnp.org/standardizeddcps/mediaserver.asp.

    You might also like