|
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.
Solution
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.
Results
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.
Contact
For further details,
please contact Rajesh
Shenoy (rajesh.shenoy@hp.com) or Keith Moore (keith.moore@hp.com)
|
|
Access library and proprietary protocol for
integrating long-lived systems with .NET
|
Printable version
