Home             Products            Support   




Our Customers



Consulting and Implementation
Services

Supporting
SECS-I      HSMS
 SECS-II    300mm

   GEM    PVECI

Platforms!

     

 

About the Hume Distributed Message Hub

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.

Back to Datahub SDK page

 


  About Us                   Contact Us                 News and Views             Integrators                Documentation                Support 

Serving the semiconductor manufacturing industry since 1992                          Copyright Hume Integration Software 2009