Open-Source Tools for Distributed Device Control within a Service- Oriented Architecture

Abstract

Within the past few years a new paradigm for software organization and intercommunication has emerged—SOA, or Service-Oriented Architecture. This article explores the relevance of this approach to automation and control of laboratory devices and examines some of the excellent open-source software tools, libraries, and frameworks available to implement software according to SOA principles. Not only can the open-source packages described here serve as the basis for practical laboratory automation systems, they also can serve an educational role to illustrate the principles and advantages of an SOA approach. Open-source software represents a significant opportunity for leveraging the skills and budgets of small automation development groups to produce very sophisticated and reliable software systems that would otherwise be out of reach for such small teams. An added benefit is that because of the standardized protocols involved, opportunities for interoperation with other systems that are following a similar approach becomes a realistic possibility. Although intellectual property and licensing issues may represent a barrier to the open-source approach for commercial developers seeking to market their solutions, it may be the ideal approach for many in-house projects and for standardized elements within commercial packages.

Introduction

The development of the so-called Service-oriented approach to distributed software design (Fig. 1) represents an evolution of concepts that originated to support intercommunication between software elements over the Web. Standardized protocols to support Web Services have emerged and rapidly matured over the past few years; the protocols and architectures developed in this arena have general utility beyond the domain for which they were originally developed (primarily business transactions conducted over the Web). Many variants and combinations of service based and peer-to-peer protocols have been developed, some optimized for widely distributed and heterogeneous systems (e.g., standardized Web Services based on SOAP [Simple Object Access Protocol] ¹ -WSDL [Web Services Definition Language] ² -UDDI [Universal Description, Discovery, and Integration] ³ ) and others that are optimized for local networks of interoperating devices and services (e.g., Jini, ⁴ Rendezvous ⁵ /Zero-Conf, ⁶ and so on). Fortunately, the surge in popularity of open-source implementations of such software has coincided with the establishment of service-based standards and methodologies; this represents a great opportunity for lab automation developers to take advantage of this tremendous body of work to efficiently serve many common automation needs with relatively little development effort.

Figure 1.

SOA architecture. Service Providers publish their identity and description of services with the Registry Service; when a Service Client needs a particular service, it can query the Lookup Service, which returns all information needed by the Client to contact the required Service Provider directly and begin making service requests.

This review is not intended to be a comprehensive survey of Service-oriented standards, protocols, and implementations. Instead, the intent is simply to highlight and contrast a few of the key Service-oriented open-source projects that have great potential for use in an automated laboratory environment. Understanding the rationales and target domains of the projects presented here represents a good foundation for selection of the protocols and approaches that are best suited for a particular need in the automated laboratory environment.

This author has successfully followed the Service-oriented approach suggested here to rapidly implement a flexible lab automation system. ⁷ Since that article was published, the Service-oriented approach to distributed systems has matured considerably, and developers now have a wider palette of open-source projects from which to choose. The project described in the aforementioned paper (LabRAT ⁷ ) proved the viability of the concept, both in terms of rapidity of development and stability and reliability of the concept. Several other groups have also implemented laboratory systems following the same general design approach (e.g., Retisoft, ^8,9 Userspace ¹⁰ ).

Before examining specific packages, definition of the key services and functionality necessary to implement a Service-Oriented Architecture (SOA) to facilitate interoperation of devices and software applications in the lab is in order. The chief advantage of a Service-oriented approach to software development is that it facilitates development of loosely coupled software modules operating in a distributed manner, that is, modules that can intercommunicate and cooperate but that impose minimal requirements on one another in terms of specific development languages and interpreters, implicit knowledge of application programming interfaces (APIs) and internal data structures, shared object libraries, and so on. To accomplish this, several sets of functionality must be implemented within any Service-oriented system:

• Protocol implementation to allow distributed intercommunication. This requires a defined communication protocol that allows components to reliably talk to one another (the envelope) and a specification for the message payload, most often one that is based on XML (Extensible Markup Language). ¹¹

• Service interface description and introspection. This defines a published contract or specification that provides information on what the service does and how to access the service.

• Service publishing and service discovery. Publishing is the process by which a service provider makes its service description available to potential clients. Discovery is the process by which the client becomes aware of an available service.

• Service registry and lookup. This is the mechanism by which service nodes notify a central server of their presence and by which client nodes request a reference to a needed service node.

Some Service architectures rely upon a centralized set of base services such as those listed above that are defined at a particular network location; others (e.g., JXTA ¹² ) operate in a pure peer-to-peer mode, whereby registry and other traditionally centralized services are provided in an ad hoc manner by peer nodes.

It is worth noting that current implementations of the messaging protocols discussed below all rely upon a single, pervasive network infrastructure, that is, TCP-IP (Transmission Control Protocol-Internet Protocol). None of these service-based messaging protocols are, however tied in principle to TCP-IP-based networks; alternative network protocols may be used without violating the core messaging protocol specifications. As the transition from the current version of TCP-IP (IPv4) to the next-generation version (IPv6) occurs, additional address space, efficiency, and security become available for the messaging systems described here. This is because IPv6 uses larger address values (128 bits instead of 32 bits in IPv4) and can therefore directly support many more devices on the network. Additionally, IPv6 includes integrated features like authentication and multicasting that had been secondarily added to IPv4; these features are of central importance to the integrity and security of the messaging protocols discussed here.

JINI, JXTA, and All Things “J”

Within the open-source community, Java is king. Many excellent Java-based Service-oriented open-source packages are available, some of which are quite mature, stable, reliable and battle proven. Perhaps foremost among these is Jini, ⁴ which was first released by Sun Microsystems in January of 1999 to enormous fanfare and acclamation. Jini is well into its second-generation release and, in its current form, is quite stable and complete. Sun defines Jini as follows.

“Jini is a network architecture for the construction of distributed systems where scale, rate of change and complexity of interactions within and between networks are extremely important and cannot be satisfactorily addressed by existing technologies. Jini technology provides a flexible infrastructure for delivering services in a network and for creating spontaneous interactions between clients that use these services regardless of their hardware or software implementations.”

Jini (Fig. 2) provides services to enable plug-and-play device integration within a local network. It facilitates automatic discovery of services within a Jini network by means of a well-defined protocol to describe service interfaces along with a registry and lookup service. Many additional services are provided, including JavaSpaces, ¹³ a distributed, shared memory service that is available to peer Jini services. A JavaSpace is a persistent, shared set of memory that facilitates distributed and parallel task execution. Extensions to Jini exist to provide full-featured gridcomputing environments (e.g., the JGrid ¹⁴ open-source project from the University of Veszprem in Hungary). Jini and secondary open-source projects such as JGrid provide a nearly ideal basis for laboratory automation and scientific computation systems. A few key restrictions of the Jini platform are that it is a Java-based system (Jini's Interprocess Communication mechanism, or IPC, is based upon the Java-specific Remote Method Invocation, or RMI, protocol), it works exclusively within the context of a local network, and development is controlled by a single entity (Sun Microsystems). In additional, Jini relies upon a distributed object model wherein services are defined in the form of Java objects and thus involves a tighter degree of coupling and stricter coding restrictions (e.g., all applications must be able to execute Java code) than do generalized Web services, wherein services are defined in the form of XML-encoded schemas (e.g., WSDL) to avoid such tight coupling. Considering the tradeoffs of various implementations and approaches to SOAs, however, it is the opinion of this author that Jini in its current form is the most optimal platform that is currently available for building a distributed device control solution for lab automation.

Figure 2.

Jini architecture. Jini includes a Lookup Service that allows Jini Service Providers to register themselves within the system and protocols that allow Service Clients to locate or discover available Lookup Services using a multicast message over the local network. Registration optionally includes proxy java code that can be used by the Service Client to use an interface within the Service Provider and invoke methods on the interface.

Many extensions and secondary projects exist within the Jini domain to enable Jini networks to interoperate with other Service-oriented protocols, such as SOAP-based services and .NET-based services. In addition, alternate IPC mechanisms (other than RMI) have been developed; it is worth noting that the Sun Jini protocol specification does not mandate the use of RMI (this is a feature of Sun's reference implementation, not of the specification). In addition, the current version of Jini supports security features that are important for regulatory compliance in many lab settings, and in general, it provides an ideal infrastructure to support lab automation. Such critical features as secure authentication, data integrity, and confidential exchanges are built into the current Jini implementation (for more details, see references ^15,16 ).

Jini has been used successfully in conjunction with USB (Universal Serial Bus)- and CAN (Controller Area Net-work)-based systems. The CAN protocol in particular is often used as the basis for real-time embedded networks and was internationally standardized in 1993 as ISO 11898–1, ¹⁷ which defines only the data link layer of the ISO-OSI seven-layer Reference Model. ¹⁸ Many different non—Service-oriented CAN application layers are in use (e.g., DeviceNet ¹⁹ and CANKingdom ²⁰ ); Jini can provide a Service-oriented interface for such networks. ²¹

JXTA ¹² (Fig. 3) is another Java-based project supporting a Service Oriented network model that is well suited for many lab automation applications. There is some confusion among developers about how JXTA compares with Jini in terms of feature set and applicability to various problem domains, because the two projects have significant overlap in functionality. One key difference is that JXTA can operate on a strict peer-to-peer basis and therefore does not require a specific service node to provide registry services and so on. JXTA is versatile enough to accommodate a brokered mode of operation as well, whereby “Super Peer” nodes can take over the role of the Registry and Lookup servers. In addition, JXTA is designed to facilitate interconnection of widely dispersed service nodes across the Internet, as opposed to Jini's focus on local network connections. Jini therefore offers advantages in terms of latency and predictability, whereas JXTA provides looser coupling of services and a more dynamic model of operation. The JXTA project adheres to a more open licensing model than does the Jini project because it is the result of an open community development effort, as opposed to Jini's origins, which are from within Sun Microsystems.

Figure 3.

JXTA architecture. JXTA includes the concept of Super Peer, whereby a peer service node can assume the role of facilitator, enabling a strict peer-to-peer architecture. These Super Peer nodes can relay requests and responses to facilitate communication between pairs of peers that are unaware of each other's identity. Alternatively, peers can make calls directly on one another if identities are known.

The Web Services Holy Trinity: SOAP, WSDL, UDDI

SOAP ¹ evolved from the XML-RPC ²² (Remote Procedure Calls) protocol as an RPC mechanism operating over HTTP (HyperText Transfer Protocol) to exchange XML-encoded objects and messages. Some authors claim that SOAP now stands for “Service Oriented Architecture (or Application) Protocol” and others say that SOAP no longer stands for anything in particular. In any case, SOAP has become the predominant messaging protocol for exchange of XML-based data packets. SOAP has evolved to include ancillary functionality, such as “SOAP with Attachments” ²³ and “WS-ReliableMessaging”. ²⁴ SOAP can be used in either a synchronous, request—response RPC style of messaging that is similar to XML-RPC or in an asynchronous, process-driven, document-centric style of messaging.

WSDL ² provides a means of describing a Web service by means of an XML document that can be provided to a client of the service. This includes information on how to refer to the services, how to construct messages and what to expect in response (data type information, and so on), as well as information on protocols (e.g., SOAP and HTTP) and physical addresses to use with the service. Ordinarily, the WSDL document defining the service description is published to the Lookup Server, which in turn makes it available to potential clients (see Fig. 1).

UDDI ³ provides a means for clients of a service to “discover” the service—it essentially defines a service directory and registry for Service-oriented systems. A UDDI server provides information to potential clients on what services are available and how to subscribe to these services. UDDI also specifies how service nodes list and publish their services in the directory.

Together, SOAP, WSDL, and UDDI comprise a consistent set of standards upon which to build Web services. Several open-source and commercial development tools and libraries include support for largely automated construction of servers that implement these standards to Service-enable applications. Microsoft's Visual Studio for the .NET framework ²⁵ provides a high degree of such functionality and can, for example, transparently build a WSDL service definition based on code that the user has written. Likewise, Sun's JWSDP ²⁶ (Java Web Services Developer Pack) development tools support highly automated construction of components based on these standards. In the open-source world, several fine packages are available, such as the Apache Software Foundation's Axis ²⁷ project, which supports both Java- and C++-based projects.

As noted earlier, the generalized, loosely coupled model that is represented by the SOAP—WSDL—UDDI trinity excels at providing a basis for widely distributed services hosted on diverse platforms and coded in a wide array of development systems. In contrast to a Jini-based solution as described in this article's section Jini, JXTA, and All Things “J”, this more generalized solution must be supplemented with a great deal of additional code to match the built-in set of functionality that is included within the core of Jini. For example, Jini includes the concept of a service lease and full functionality to support it; such functionality is essential to support reliable asynchronous messaging but is missing in the core Web Services standards that were just described. To provide such needed functionality within a distributed command and control lab automation environment, the developer must layer in a whole series of additional components implementing secondary Web Service standards, such as WS-Coordination ²⁸ (defines a coordination service that maintains contexts for persistent connections), WS-Transaction ²⁹ (defines asynchronous interactions such as commit/rollback and message acknowledgement requirements), and WS-ReliableMessaging ²⁴ (specifies how to maintain reliable messaging in the presence of software component, system, or network failures). Security is another area of functionality that is supported within the core Jini system but that requires additional layered support within the more general model (WS-Security, ³⁰ WS-Policy ³¹ ). Finally, XML-encoded SOAP messages, in contrast to binary-encoded Jini objects, require additional overhead for encoding and parsing, and they are inherently bulkier messages, requiring more transmission time. These disadvantages may be inconsequential, however, depending upon the network characteristics and the performance requirements of the system.

Messaging Protocols, Queues, and Frameworks

Various protocols have been developed to allow software elements to exchange messages, both synchronously and asynchronously. Traditionally, messaging mechanisms have been built according to a queued architecture, that is, one in which incoming messages are held in a sort of electronic post office until the receiver is ready to retrieve and respond to them. Although this style of message exchange is suitable (and even optimal) for many non-real-time applications, device command and control for laboratory instruments generally requires a more immediate mode of messaging. Microsoft's MSMQ, ³² Sun's JMS, ³³ and IBM's MQSeries ³⁴ technologies are examples of this style of messaging.

A new messaging paradigm that is rapidly gaining in popularity is variously called a Messaging Service Bus or Enterprise Service Bus (ESB). A key concept of this idea is that messages (usually XML encoded) carry with them routing instructions that do not rely on a centralized server or rules engine to define how they are transported from one place to another. The bus infrastructure provides support for routing of these messages, along with service discovery, security, logging, and so on. In some implementations, such services are built into the core layer of the bus; in other implementations, some or all such services are provided as plug-in framework modules.

One very interesting open-source project that bills itself as an “Enterprise Service Bus messaging framework” is called Mule ³⁵ (Fig. 4) and can serve to integrate many disparate messaging technologies, such as JMS (Java Messaging Service), HTTP, e-mail, and XML-RPC. Mule is Java based and can interoperate with components running within the same Java virtual machine or with widely dispersed components communicating over the Internet (and everything in between). Mule is designed around a very clean architecture based on the idea that incoming messages trigger events within the Mule server and can operate in any of the three primary messaging modes: asynchronous, synchronous, and request-response.

Figure 4.

Mule architecture. Mule is built around a pipelined, event driven architecture. Flexible connection and transformation modules allow many different messaging protocols to plug in to the service bus.

A lighter weight alternative to Mule is the “FreeSB” ³⁶ project (FreeServiceBus; Fig. 5), developed by Spherion. It defines a standard ESB client implementation (by using the Apache Axis code base) that allows a variety of specialized services to easily “plug in” to the service bus. The bus itself is designed around SOAP messaging and comes prepackaged with plug-ins to provide logging, authentication, and supervisory or management services (which implement registry and coordination functions for clients).

Figure 5.

FreeSB architecture. FreeSB employs SOAP for message transport and includes basic services such as Supervision, Authentication, and Event Logging. Additional services written according to the FreeSB specification plug in to the service bus to allow integration and coordination of a wide variety of services.

Lab Automation Protocol Standards

So far we have discussed infrastructure level software elements with which to implement a service oriented communication system suitable for distributed control and coordination of laboratory devices. Once such core infrastructure is in place, higher level protocols must be devised and implemented to serve such functions as defining command, control, and coordination mechanisms for the devices, defining device capabilities and identities, and devising a means of tracking and representing sample information and data. Luckily, all three of these functional domains are covered by existing open standards, obviating the need to design such protocols from scratch. Even if these protocols are not adopted in their entirety, they can serve as excellent guidelines for adopting one's own set of standards covering these areas of functionality.

LECIS

LECIS (Laboratory Equipment Control Interface Stan-dard) ³⁷ was released by the American Society for Testing and Materials (ASTM) in 1998. LECIS seeks to standardize several aspects of automated device control, including a very comprehensive device state model and associated command-response definitions to effect device state changes. Although certain aspects of the released standard are somewhat dated (e.g., the adoption of CORBA ³⁸ as a distributed communication mechanism), much effort can be saved by adopting the core concepts that are specified in the standard. In addition, LECIS itself is evolving in a Service-oriented direction (see http://lecis.org).

Within the LECIS standard is a very good substandard defining device definition description in the form of DCDs (Device Capability Datasets). The LECIS DCD standards can serve as a model for definition of data structures that specify device properties (functionality, identity, and so on).

AnIML

A recent effort sponsored by the ASTM, AnIML ^39,40 represents a standardized approach to structuring and tracking sample data throughout a laboratory process. It is divided into two parts: the Core, which provides a generic means of representing data, and Technique Definitions, which formally prescribe how the Core is to be parameterized for particular experiment types. Such issues as security and logging have been addressed in the standard; 21CFR11 ⁴¹ compliance was a key consideration of the designers. The standard is expected to be ratified by the ASTM in the fall of 2004.

A Note on Licensing Issues

There is generally a great deal of misunderstanding and misinterpretation of open-source software license requirements. Although many different open-source licenses exist, and some are much more restrictive than others, the most common licenses, including the GPL ⁴² (Gnu Public License), the LGPL ⁴³ (Lesser Gnu Public License, generally applied to components or libraries), and the Apache License, ⁴⁴ all allow for use of unmodified compiled components, even in commercial packages, without requiring open sourcing of the host software. Most often, this is the manner in which these packages will be used within the context of this discussion. For in-house projects and for purely server-based projects that do not follow the traditional distribution model, virtually no restrictions on use of software governed by such licenses apply. Some popular licenses are extremely liberal and allow for use of modified code within commercial products without the traditional requirement to release the parent project under the same license (e.g., the Original Free BSD License, ⁴⁵ which Apple uses to great advantage as the basis for its highly profitable OS X operating system).

On the flip side of the open-source licensing issue, many companies are now profitably offering software products under a dual-licensing program: a commercial license for those desiring support and updates and an open-source license to encourage widespread adoption and increase user base. Several very successful companies are following this strategy, including MySQL (mysql.com), SleepyCat Software (sleepycat.com), and Trolltech (trolltech.com). This model can be especially effective when the software manufacturer or author wishes to encourage use of a particular protocol or format to establish a new paradigm or standard.

Conclusion

The availability of widely accepted standards and open-source software developed within the last few years to support a Service-oriented approach to software component interoperation has created a great opportunity for laboratory automation architects and developers. The utility, adaptability, and scalability of this approach represent a natural fit with the needs of the lab automation and control environment. By leveraging such standards and software, the automation architect and developer can dramatically shorten the development cycle of distributed control systems in the lab while simultaneously ensuring a high level of maintainability and extensibility for the project. By further taking advantage of the high-level laboratory standards that are available from the ASTM, a great deal of additional effort can be saved, while again assuring good interoperability of components.