Web Services
  Home arrow Web Services arrow Page 2 - An Embeddable Standards Compliant Web Service Server
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
Google.com  
WEB SERVICES

An Embeddable Standards Compliant Web Service Server
By: Terry Ess
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 7
    2004-07-27


    Table of Contents:
  • An Embeddable Standards Compliant Web Service Server
  • Design
  • Results
  • Appendix

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    An Embeddable Standards Compliant Web Service Server - Design
    ( Page 2 of 4 )

    The external world knows the service from a formal definition, the WSDL document.  This can be a fairly lengthy document so luckily this is produced as part of the design process (in fact it makes a really good starting point for the design) and not by the service itself.  The WSDL for the reference implementation is included as an appendix.  In the case of the reference implementation, we provide the ability to retrieve a copy of this definition from the device using any web browser.
     
    The overall sequence of the application is straightforward:

    1. Open a TCP server socket.

    2. Wait for a client connection.

    3. For each client connection start a new thread to handle the client’s requests (NOTE: The thread per client model is fine for cases where a relatively small number of simultaneous connections is maintained.  In the commercial Web server arena where the number of connections is in the thousands this does not work well.  Then you have to do things like thread pooling).

    4. The client handling thread waits for a complete HTTP request and based on the request provides the appropriate response.

    5. When the client closes the socket or the socket hits a inactivity timeout, the client handling thread closes its side and terminates.

    The workhorse in the code is the client handling.  It can be described very succinctly as a state machine:

    An embeddable standards compliant web service server

    For each request it tries to find a handler for the specific request.  A typical GetShort request follows:

    POST /DeviceIO HTTP/1.1
    User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.573)
    Content-Type: text/xml; charset=utf-8
    SOAPAction: "DeviceIO#GetShort"
    Content-Length: 313

    <?xml version="1.0" encoding="utf-8"?>
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body>
    <GetShort xmlns="http://device/def/">
    <id xmlns="">1</id>
    </GetShort>
    </soap:Body>
    </soap:Envelope>

    Finding a handler makes use of a lookup table that contains a list of accepted requests (the first line in the request) and a pointer to the function that will handle this request.  In the reference implementation this looks like:

    struct request_handler
     {
     char *name;
     void (*function)(class client_handler *,char *);
     };

    struct request_handler client_handler::request_handlers[] =
     {
     {"GET ",GetHandler},
     {"POST /DeviceIO",SoapHandler},
     {"",NULL}
     };

    The subsequent handling of  soap requests by “SoapHandler” is done in a similar manner using the SOAPAction line.  In the reference implementation the look up table looks like:

    struct soap_handler
     {
    char *name;
    void (*function)(class client_handler *);
    unsigned char required_auth;
     };

    struct soap_handler client_handler::soap_handlers[] =
     {
     {"SOAPAction: "DeviceIO#Connect"",MakeConnect,AUTHORIZED_NONE},
     {"SOAPAction: "DeviceIO#GetShort"",GetShort,AUTHORIZED_GET},
     {"SOAPAction: "DeviceIO#SetShort"",SetShort,AUTHORIZED_SET},
     {"SOAPAction: "DeviceIO#Start"",StartAction,AUTHORIZED_ACTION},
     {"SOAPAction: "DeviceIO#Stop"",StopAction,AUTHORIZED_ACTION},
     {"",NULL}
     };

    How we handle the parsing of XML documents is the most critical item in terms of meeting a small footprint requirement. The typical XML parser, whether of the DOM or SAX variety, is large. Since we have control of the XML layout, we can take advantage of this information to make a minimal, sequential parser. Using a list of tags and associated handlers, the parser does nothing more than find each tag, parse the “value” as a string, and invoke the associated function which knows how to convert, store etc. the item.  In the reference implementation the sequence list for a SetShort XML document is:

    struct xml_element_handler
     {
     struct *tag;
     void (*function)(class client_handler *,char *);
     };

    struct xml_element_handler client_handler::set_short[] =
     {
      {"<id",SetShortId},
      {"<value",SetShortValue},
      {"",NULL}
     };

    Once the parsing is completed, the saved values are checked and the appropriate response composed and sent as the response to the original HTTP request.  The response for a successful GetShort follows:

    HTTP/1.1 200 OK
    MIME-version: 1.0
    Content-type: text/xml
    Connection: keep-alive
    Content-length: 276

    <?xml version="1.0" ?>
    <soap:Envelope xmlns:soap="
    http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body>
    <GetShortResp xmlns="
    http://device/def/">
    <id xmlns="">1</id>
    <value xmlns="">1</value>
    </GetShortResp>
    </soap:Body>
    </soap:Envelope>



     
     
    >>> More Web Services Articles          >>> More By Terry Ess
     

       

    WEB SERVICES ARTICLES

    - Dynamic Data Analysis on the Web-a Design Ap...
    - Use collection types with SOAP and JAX-RPC
    - Blogging Away To Glory (A bBlog Primer)
    - Introduction to Service Oriented Architectur...
    - Connecting Smart Devices on the Internet
    - An Embeddable Standards Compliant Web Servic...


    Email Marketing Software
    iContact Email Marketing Software Simplifies Online Communication.
    Internet Marketing Company
    Provider of internet marketing services to boost your site rankings.
    seo firm
    SEO firm with excellent organic results for clients in all verticals
    Survey software
    Survey Software that helps you create elegant web based surverys.



    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 4 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek