| The
Distributed Message Hub (DMH ) is a high-level software
facility providing inter-process communication for
applications executing within a TCP/IP network. The DMH
provides functionality that is similar to the familiar
message and message queue API families, as provided by
products such as CELLworks, DECmessageQ, MQseries, MSMQ,
and QNX. The DMH
provides transparent support for message distribution
across multiple workstations. Unlike some competing
products, there is no distinction between executing on a
single workstation versus multiple workstations.
Therefore, there are no additional complexities to the
startup, and there is no explicit configuring or
linking of participating workstations.
The DMH is provided as a
server component that manages message queues, as client
code for message communication that is available for a
wide variety of platforms, and as a gateway component that
interconnects independent communication groups. An
application process such as the Hume
Datahub can execute the DMH server component on behalf of all the communicating
client processes in a group. DMH client software is
available for .NET, Visual Basic applications or other
Active-X platforms, for Java applications or
applets, and for POSIX C/C++ applications.
Client processes on one
or more hosts can be started, terminated normally,
terminated abnormally, and restarted without affecting
or disrupting the DMH server component or other client
processes. Workstations that are executing client
programs on the TCP/IP network may be taken offline, or
rebooted, and then brought back online. When the
workstation is back online, restarted client programs
may attach to the existing DMH server, and resume
application functions.
Native TCP/IP and
operating system facilities are utilized for name
resolution, permissions, performance tuning, and other
low-level services. Unlike competing products there is
no need for device drivers, additional networking
daemons, configuration files, diagnostic utilities, or
similar artifacts of duplicated system functions.
The DMH is a high-level
facility. The application developer deals with text
messages and named message queues, not with data
marshalling, protocol conversions, retries, and
timeouts. Typically the messages are SQL or Tcl commands
that are executed by the SDK software, so there is no
need to specify message formats or to develop message
parsing code. The DMH is well suited for the development of CIM applications where the efficient utilization of the
development staff is a priority.
The DMH is efficient.
Multiple high speed testers can send hundreds or even
thousands of messages per second to a
Datahub
where the data can be manipulated in real-time and
organized in SQL relational database tables. Using the
subscription features of the Datahub, the
acquired data can be fed into a persistent database such
as Oracle, and fed to multiple user interfaces across
the TCP/IP network.
The use of asynchronous
messaging as provided by the DMH is preferred to RPC-based
solutions in the CIM arena for several reasons. First,
the use of message queues permits fast rate processes
such as test floor data acquisition to be connected to
slow rate processes such as the interface to a
persistent database. The queuing management provided by
the DMH smoothes over the peak loads of the production
cycle. In this example, the data acquisition interface
and the database interface are written as simple,
single-threaded clients of the DMH message server. The
complexity of managing the rate mismatch is borne by the
message system, and not by the application developer.
Another advantage of DMH
messaging is that it provides a dynamic connection
interface. In a distributed factory system that is
running around the clock, it is vital to be able to
bring component processes off-line or on-line in perfect
synchronization. Common examples of dynamically
connected processes are user interface sessions and
equipment interfaces. Being able to dynamically connect
or disconnect from the distributed application is a key
requirement.
The message queue
interface of an application also provides a testing
interface for development work, debugging, and
verification. Here the use of plain text messages such
as SQL statements or Tcl statements instead of binary
messages is a strength; test messages and test suites
can be created without the use of a compiler. |
