JMS Java Messaging Services provide Point-to-Point and Group Messaging services. We are using the SwiftMQ implementation, which uses JNDI and RMI for message delivery and router discovery.
JMS Router An application that manages out the routing, caching, and delivery of Messages. To send and receive messages via JMS, a client program must establish a Session with a Router.
JMS Topic JMS Topics are synonymous with News Groups. And use a similar naming convention. I.E. TKSite.1.Announcements, TKSite.1.Data, TKSite.Management… A JMS Client can Publish a message to a JMS Topic, and all JMS Clients who have previously Subscribed to that JMS Topic will receive a copy of the message.
FSDB Fail-Safe-Data-Bin. An FSDB is an abstraction layer for Databases to allow the storage of arbitrary data in a Database Table accessed through JDBC with a minimal amount of coding.
FSDB Server An application that provides one or more FSDBs for client use. The current implementation supports access to the FSDBs via RMI, and allows for Transactions to be performed against an FSDB via a JMS Topic. FSDB Servers currently require a local JMS Router to be Transaction Fail Safe.
FSDB Replication The current FSDB Server implementation requires the use of JMS Group Messaging for Replication. Any time a change occurs to a local FSDB, the FSDB server broadcasts a Transaction message to a JMS Topic. All other FSDB Server who are Subscribed to that JMS Topic will then receive the Transaction and perform it against their local FSDBs – thus replicating the original FSDB.
Collective A collective is a group of FSDB Servers who all Subscribe to (and Publish to) the same JMS Topic. Thus forming a group of FSDB Servers who all have exact copies of the same data.
RMI Remote Method Invocation allows a Java Application to access a remote Object, invoking methods on the remote object as if it were in the Application’s local Java Virtual Machine.
Conduit A conduit is an
application that acts like an FSDB Server, in that it connects to a Collective
via JMS, and receives and transmits Transactions for FSDBs.
The primary differences are 1) the Transactions that a Conduit receives from
the Collective are either Discarded or Transmitted to another Data Source –
such as the DEC, Needles, or a Calculation program. 2) The Transactions that a Conduit transmits onto the Collective
are a means of importing new data from outside of the Collective into the
collective, i.e. an import.
Conduits can allow two or more Collectives to be joined with intelligent data
filtering between them. It also allows
importing, and exporting data to/from a Collective.
TKStation A Time Keeper
Station is an application that allows users (students) to Clock into and out of
Labs, Class, and other Activities. The
TimeKeeper System utilizes Collectives to distribute, synchronize, and collect
Time Keeper Data.
TKStations are placed in Labs, Classes, and other activity areas, and have one
or more Input Receivers to facilitate the gathering of data. They provide an easy to use Graphical
Interface to inform users if they have been clocked in, what they have been
clocked into, if they have been clocked out, and at what time they clocked
in/out.
Heavyweight TKStation Heavyweight TKStations, implements a local JMS Router, and FSDB Server in addition to the Standard TKStation GUI. Thus creating a Fail Safe, or Possibly Stand-Alone TimeKeeper Station that has guarantied access to a FSDB for Data Storage.
Lightweight TKStation Lightweight TKStations only provide the TKStation GUI, and have to rely on a separate FSDB Server for Data Storage. This provides the capabilities of running on a less expensive older machine, creating less Network Traffic, providing instantaneous synchronization of data between two or more TKStations (because they share the same FSDB) at the cost of Availability. A Lightweight TKStation cannot be used in a Stand-Alone Configuration, nor can it operate without a network connection.
TKStation Node TKStation Nodes provide a remote User Interface, and act as an Input Reciever for a TKStation. For example the jRDC provides a remote text display, and allows the remote attachment of an input receiver. TKStation Nodes act as Dumb terminals, merely relaying data from the remote Input Receiver to the TKStation, and Displaying data dictated by the TKStation.
TKStation Input Receiver Input Recievers are devices that are capable of determining a User’s identity, and any coralary information needed to perform a Clock in/out. i.e. A Barcode Scanner, Magnetic Card Reader, Keyboard