Connecting Smart Devices on the Internet - Comparison of Options (Page 3 of 5 )
If we wanted to examine every possible solution combination that would become a very large task. Luckily we can take a serious look at only a sub-set of the possible solutions and get a pretty good idea of what is practically available. Specifically the options summarized in the following table were examined in detail, including the design, implementation, and test of reference code sets:
| Description | Application | Top Level Transport | Data Format | Operation |
| Proprietary content updater | Content updating | Proprietary | Proprietary | Synchronous |
| Email client | Periodic pre-defined reporting | SMTP, POP3 | XML
XML Scheme | Asynchronous |
| Web service client | Content updating | HTTP 1.1 | XML
XML Sceme | Synchronous |
| Web service server (light) | Information retrieval | HTTP 1.0 | XML | Synchronous |
| Web service server (WS-I Basic Profile) | General Purpose for control, configure and reporting | HTTP 1.1 | XML
XML Scheme
SOAP
WSDL | Synchronous |
The proprietary content updater is described in detail in http://www.the-solution-llc.com/strategy.zip. The specific reference implementation provides a good example of offloading access to an Internet capable device (in this case an off-the-shelf Windows CE device). Since the application-level protocol is simple and binary, data exchange is the most efficient by far. The reference implementation on the CE device is fairly small, requiring less than 900 lines of C. If the device itself had the capability to connect with the Internet, the implementation on the device would be the same size, etc. Since the application-level protocol is proprietary, the server-side component had to be implemented at the socket interface level. A minimal server required another 900 lines of C++. This does not include the support applications that would be needed to keep track of changes, etc.
The email client provides the means for a "center" to specify the pre-defined report which a device will mail periodically. Both the requests and the reports are sent in the body of the email in XML format. Both also include security measures to circumvent attacks. The device reference implementation using a socket interface required less than 600 lines of C++ while the implementation using offloading to an Internet chip, ConnectOne’s iChip, required less than 800 lines (Note: The overall size of the iChip implementation would be substantially smaller since the software TCP/IP stack etc. is not needed). The performance of both implementations was roughly the same. Two desktop-level (not enterprise) applications for a center were also implemented. These provided the means to easily compose and send report requests and to retrieve, parse and store device reports in a database. Both were implemented in Visual Basic as email client programs (the email server was provided by the ISP). Together they required less than 1000 lines of VB.
The web service client is described in detail in http://www.the-solution-llc.com/updateservice.pdf. It provides the means for a device to intelligently update its content (including software). The updating procedure is significantly more sophisticated than that used in the proprietary content updater though it achieves the same basic objective. The procedure uses the exchange of defined (using XML Scheme) XML documents and then a series of HTTP gets to update the device. The reference implementation includes some security measures but is not completely adequate in this area. The device reference implementation using a socket interface and a minimal sequential XML parser (Note: the actual implementation used the Xerces open source XML parser which is large) should require less than 800 lines of C. Two server-side reference implementations were undertaken, one using J2EE and one .NET. Each took less than the 500 lines of code (Java and C# respectively) to implement the update web service.
The light web service server is described in detail in http://www.the-solution-llc.com/webservice.zip. It provides the means for client programs (including web pages, spreadsheets etc.) to easily retrieve information from a device using HTTP gets with “freehand” XML documents as the response. The device side server reference implementation took less than 500 lines of C++. The client side scripts (VB script and VBA) required less than 100 lines.
The basic profile compliant web service server is described in detail in http://www.the-solution-llc.com/embeddableserver.pdf . It provides a general purpose “command and control” interface through a WSDL defined interface. The device side server reference implementation using a socket interface tool less than 1000 lines of C++. The Internet chip version, ConnectOne’s iChip, required less than 1400 lines (Note: The overall size of the iChip implementation would be substantially smaller since the software TCP/IP stack etc. is not needed). Unlike the email case, the performance of the Internet chip version was substantially less than that of the socket interface version. In general the Internet chip should be restricted to five or less simultaneous connections. Where this option really shines is on the client side. Two client applications were built to test the server, one using C# and .NET the other Java and Sun’s Java Web Services Developer Pack 1.3. In both cases ,access to the web service was automatically generated from the WSDL and the client program simply called stubs.
None of the solutions examined used a De factor or industry standard data format. Why? Because with the possible exception of government EDI standards, they are all expected to disappear under the integration power of web services. This is not to suggest that the use of XML standards comes without a price. For example, the amount of data (in bytes) exchanged to “read” a device’s short parameter would be approximately (10) bytes with the proprietary binary encoding option, (130) bytes in “freeform” XML and (900) bytes with a basic profile compliant web service. The only reason this inefficiency is tolerated (or even ignored) is because bandwidth and processing capabilities have grown so large and web service support so widespread.
Until the advent of the Internet chip, the use of the offloading option was too expensive for most applications (though it did provide a good development path to get from legacy to next generation devices). With the Internet chip, that is no longer true. If your device has an available serial interface and the connectivity-enabled applications have value (e.g. performance optimization), then you can probably fit and afford one.
Next: Recommendations >>
More Web Services Articles
More By Terry Ess
/ 1 
