Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP

HP.com home

Bridging Embedded Systems to .NET


HP Labs

» Research
» News and events
» Technical reports
» About HP Labs
» Careers @ HP Labs
» People
» Worldwide sites
» Downloads
Content starts here

Problem Statement

Embedded imaging and printing devices such as printers, cameras, projectors and scanners tend to be long lived. A problem for any developer of such devices is how to connect these devices to the rapidly evolving desktop and handheld environments (e.g. Windows XP and Windows CE). The problem is not which protocol to put in the device, but rather whether that choice is appropriate even a few years from now. With the advent of web services standards, it is tempting to think that heterogeneous systems can interoperate using common communication protocols. The reality is that the lifetime of long-lived devices far exceed the effective lifetime of the clients and the particular interoperability protocols that were in vogue when the devices were deployed. Many hope that consortia such as WS-I  will address interoperability issues between J2EE,  and .NET; however, these consortia are still addressing simple SOAP message exchange. Even if an agreement is reached on a set of protocols, there will continue to be a reason (such as vendor differentiation) to evolve the protocols (e.g., WS-Security, WS-Routing etc.) and the protocols will evolve faster than these deployed devices. Printers, for example, often outlive the desktop platform to which they are attached, and hence there is a fundamental issue in getting stability while the platform, protocols, and infrastructure evolve.


At ISL, we have designed and implemented a novel approach for sustaining long-lived system integration by using application-level interoperability. This follows from our historical experience is that the only point of stability on a client is the language specific function call mechanism (the programming language and the APIs for the platform). Rather than trying to dictate a common wire protocol, or even to try for .NET/J2EE interoperability with multiple vendors' products, tracking interoperability at the application layer is attempted. Unlike protocol interoperability where the .NET/J2EE application communicates directly with a wire protocol, for application layer interoperability an access library is used. For the case of .NET interoperability, the long-lived system exports an access library that is hosted on the .NET platform. This device access library exposes interfaces presented by the device, and interacts with the device using a controlled protocol. This could be a version of a standard protocol such as SOAP or IIOP, which has been frozen until the device vendor decides to upgrade the protocols.

The .NET/J2EE applications are developed using the access libraries, without being aware of the controlled protocol. Since the access library is in the control of the device vendor, the protocols can be kept stable even as the platforms evolve. Since the function call mechanism on the .NET/J2EE platform is far more stable than the wire protocols, the access library need not be changed frequently. In contrast, if there is no access library, the long-lived system shown in figure has to be directly connected to the .NET application. This requires the long-lived system to implement the protocols that are currently supported by the .NET infrastructure and the device vendor must keep pace with the new protocols as the .NET infrastructure evolves.


Achieving application-level interoperability requires installing an access library onto each client that needs access to the device or consolidating on a server (three-tier architecture). However, from our experience with device drivers, this installation is far less expensive than tracking wire protocols. As the platform evolves, in the worst case, the access library has to be recompiled for the new platform. However, we have found that the platform vendors typically provide migration tools for moving applications to the new platform and these tools could be leveraged for the device access library. The important fact is that the device can remain unchanged as the platform evolves since the protocol is stable. To simplify code-generation and tracking of the device exposure, we use IDL to specify the interfaces that are exposed from the device.

We have developed compilers to convert from IDL to application libraries, for C# and Java. We have also developed runtimes (libraries) to convert from the language function cal into the stable protocol used in the device.

For more technical details, please refer to the following paper

R.Shenoy and K.Moore, "Sustaining long-lived system integration with .NET", submitted to Middleware 2004.


For further details, please contact Rajesh Shenoy (rajesh.shenoy@hp.com) or Keith Moore (keith.moore@hp.com)

Printing and Imaging Research Center
  » PIRC web site
» Imaging Systems Laboratory
  » Projects

Access library and proprietary protocol for integrating long-lived systems with .NET
Access library and proprietary protocol for integrating long-lived systems with .NET


Printable version
Privacy statement Using this site means you accept its terms Feedback to HP Labs
© 2009 Hewlett-Packard Development Company, L.P.