Home arrow Web Services arrow Page 2 - Accessing Devices Using a Web Service
WEB SERVICES

Accessing Devices Using a Web Service


Web ServicesThe old days when embedded devices and factory floor machines had only minimal interaction with humans, the on/off button and little else, are gone. Today the ability to access the device from anywhere is expected. This is a significant challenge when we are sweating over every dollar required in hardware. With a little bit of knowledge and a relatively small piece of software, we can provide a Web service for this type of interaction.

Author Info:
By: Terry Ess
Rating: 4 stars4 stars4 stars4 stars4 stars / 19
January 14, 2004
TABLE OF CONTENTS:
  1. · Accessing Devices Using a Web Service
  2. · HTTP Requests and Responses
  3. · XML
  4. · Web Service Implementation
  5. · Conclusion

print this article
SEARCH DEVARTICLES

Accessing Devices Using a Web Service - HTTP Requests and Responses
(Page 2 of 5 )

HTTP Requests

An HTTP based client application, e.g. a Web browser, establishes a TCP/IP socket connection with an HTTP server and then carries on a request – response conversation.  A typical HTTP request looks like:

GET /listener.htm HTTP/1.1<cr><lf>
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms<cr><lf>
Accept-Language: en-us<cr><lf>
Accept-Encoding: gzip, deflate<cr><lf>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0; .NET CLR 1.0.2914)<cr><lf>
Host: the4<cr><lf>
Connection: Keep-Alive<cr><lf>
<cr><lf>

The key things to note are:

  1. An HTTP request is just a series of text lines (i.e. displayable text terminated with a carriage return and line feed). An empty line terminates the request.

  2. It provides a wealth of information, most of which we can ignore.

  3. What is important for us is the first line. This includes three key pieces of information. The action requested, the item associated with this request and the version of HTTP used.

The current version of HTTP, 1.1, supports a number of different actions, POST, PUT, COPY etc. but the only one we need for providing information is GET.  A side effect of only supporting GET is that the actions that are prone to be used by hackers to break in will not be supported.

HTTP Responses

An HTTP response has one or two parts.  The response header provides the status information necessary for the client to make use of the response.  If the response includes the movement of data to the client then the second part is the data stream.  We will use three types of responses, a generic error response and two different data response.  The error response is a one part (i.e. header only) response and it is:

HTTP/1.1 400 Bad Request<cr><lf>
Content-length: 0<cr><lf>
<cr><lf>

The key things to note in the error response header are:

  1. A response header is just a series of text lines.  An empty line terminates the header.

  2. The first line in the header provides two basic pieces of information, the HTTP version used (which should match that in the request) and the status of the request.

  3. The last line tells the client how big the data stream section will be.  Our error response will include no data section.

There are dozens of possible status responses, each composed of a number and a matching text string.  For out simple service we only need two, 400 Bad Request and 200 OK.  The OK response header is used in the two different data responses we will support.  The first of these is our XML response header.  This is:

HTTP/1.1 200 OK<cr><lf>
MIME-version: 1.0<cr><lf>
Content-type: text/xml<cr><lf>
Connection: keep-alive<cr><lf>
Content-length: 100<cr><lf>
<cr><lf>

This header includes a little more information then the error response header.  The key things to note are:

  1. The overall composition of a response header has not changed.

  2. We have included two additional lines which define the nature of the data stream we will be providing:

    (a) A line that defines the MIME (Multipurpose Internet Mail Extensions) standard version that is being used.

    (b) A line that defines the content type using the indicated MIME standard, in this case XML.

  3. We add the “keep-alive” line so the client will hopefully not drop the socket immediately after each request – response cycle.

  4. The last line must contain the actual byte count in the following data stream.

The second data response will allow us to return an HTML page.  This is:

HTTP/1.1 200 OK<cr><lf>
MIME-version: 1.0<cr><lf>
Content-type: text/html<cr><lf>
Connection: keep-alive<cr><lf>
Content-length: 100<cr><lf>
<cr><lf>

The only thing new here is the content type.  In general we do not need to support an HTML response.  One of the key advantages to providing an XML response is that we are only providing data; we are not specifying how the data should be presented to the user.  This keeps what we have to produce relatively small and easy.  Picking up this data and placing it into a display application is not difficult but it does require some knowledge on the part of the users.  Most of this can be provided in a couple of simple tables but it is always good to provide a simple example.  Along those lines a single HTML page that includes VB or Java script can provide a living example of how to access and use the data provided.  Then it is up to the user organization to build what ever interfaces it needs.

The second part of the data responses is nothing more then the data stream that makes up the response, i.e. we are sending the XML document or HTML page.  The only requirement is that the content type and byte count of this data stream be the same as the information provided in the response header.

Next: XML >>

blog comments powered by Disqus
WEB SERVICES ARTICLES

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials