Home arrow Web Services arrow 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
(Page 1 of 5 )


Introduction

The 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.

There are at least four questions we need to address to examine the issue of remote access:

  1. Who needs access? The manufacturer of the machine, the user of the machine or both, other?

  2. What will they do? Gather status/historical information, perform maintenance, updating or troubleshooting.

  3. How will access be provided? Proprietary protocols, open protocols or a mixed set.

  4. When will access be allowed? User controlled physical access, open access with appropriate security measures or something else.

In general the answers to these questions are:

  1. Both manufacturer and the user will need access.

  2. The user will access the machine primarily to gather status/historical information (i.e. listeners).

  3. The manufacture will use their access for all the stated reasons (i.e. controllers).

  4. We will use the most ubiquitous and cost effective transport possible, TCP/IP on top of Ethernet (probably of the 10BaseT variety).

I strongly favor a two-channel architecture.  This is:

  1. Use a TCP/IP socket interface with an unknown TCP port and a proprietary application message protocol to provide control. This is both the most secure and the best performance solution possible. In addition it is a small footprint/low overhead approach that can be supported even on a slim platform.

  2. Use open technology (HTTP and XML) to address data gathering/surveillance requirements. This is a “read only” channel thereby eliminating most security and performance issues. (In the parlance of the time this is a bare bones web service.)

A typical factory floor machine controller might look like:

The second channel is what will be explored in more depth in this paper. The normal means of achieving this capability is by using a full function Web Server with extensions to provide an interactive exchange between the client and the server, e.g. Microsoft’s IIS with ASP, or Macromedia’s ColdFusion with JSP etc. This is a complicated solution that can prove to be costly and difficult to administer and secure.  For an embedded application it is like driving a finishing nail with a ten-pound sledgehammer.  Luckily there is a straightforward solution that does not require the sledgehammer.  Even a rather cursory knowledge of HTTP and XML enables a software engineer to develop a secure application specific solution with the smallest possible resource demands.  The basic facts are:

  1. The transport for HTTP is a TCP/IP socket that uses TCP port 80 on the server.

  2. HTTP is a simple text based protocol, most of which we can ignore.

  3. XML is a text based mark-up language that is easy to understand and create. It does not have to be any more complicated then we want it to be.

We need a TCP/IP stack, a socket interface to the stack and a relatively small piece of software, the Web Service Interface, and we are there.  We will travel down the road of developing this interface one step at a time:

  1. Understanding HTTP requests.
  2. Understanding HTTP responses.
  3. Understanding an XML document.
  4. Defining requests and responses.
  5. Implementing a simple Web service.


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