Candidate Replacements for Telerian Smart Sockets in TriNet codes:

Oracle Advance Queuing

Stephane provides this about Oracle Advanced Queuing, with my comments 
added:  

The Oracle9i Advanced Queuing offers similar features to the smart sockets.
Messages are stored in tables and the message structure is defined by the
fields of the underlying table. For example, to implement a message type
similar to the one currently used in the [TriNet] real time system, we could
define a table with two fields (string subject, string content).  The AQ
administrator has to create the message table and the queue. [Note that the
table does not define the message subjects or the content format, so any
subject can be published by a client.]

Subscribers need to be added by the AQ administrator. A subscriber is
registered by a name and optionally some message [content] filters (similar to
the SQL WHERE clause). This can be done without interrupting the other
clients.

Any publisher can send a message to the queue, either by broadcasting it to
all the subscribers, or by sending it only to specific subscribers (that might
not have subscribed yet at the time the message is published).  The publisher
can also specify a timeout for each message.  

Messages can either be browsed (message stay in the queue) or dequeued
(message removed from the queue). API's allow the applications to listen on
multiple queues, define a callback function or dequeue messages directly. When
dequeuing a message, a timeout value can be defined (0, >0 or wait
forever). Another benefit of the Oracle AQ is that messages can be transfered
between different queues on different machines automatically.  If an
application dies and comes back online, it will be able to retrieve messages
from where it left. 

A disadvantage of Oracle Advanced Queuing is that subscribers need to be
connected to the database constantly while they are interested in receiving
messages. Also, messages published while the database is down will be
lost. [TSS clients can attempt to start the TSS server if they find that the
server is not running.]


From this description, it seems that Oracle Advanced Queuing provides most of
the features and flexibility that we would need for a TSS
replacement. Additional disadvantages: cost (no additional cost if we already
have Oracle); single point of failure; ties us to one vendor.


IRIS Free Orb

The IRIS free version of ORB (object ring buffer) provides a few of the
features needed for a TSS replacement. The orb server provides a memory-mapped
file buffer for publishers to deliver messages and clients to request
messages. Each message has a "type" assigned by the publisher. Clients request
to read messages through a matching pattern (regular expression). It should be
possible for the client to receive a "bookmark" with each message. The
bookmark would uniquely identify the place in the orb server from which the
message came. After a client shuts down and restarts, could use that bookmark
(saved to disk) to resume reading from the same place in the orb, or learn
that that place has been overwritten by newer data.

In order to make the ORB look more like TSS, we would have to write some code
for the clients, primarily the subscribers. This allows us plenty of
flexibility, but at the cost of development and testing time.

I've discussed my ideas for using the free ORB for TSS with Paul Friberg. It
seems that CalTech has asked Paul to look for TSS replacements. We certainly
should get on board with CalTech on this; it would be a shame to duplicate
efforts on this.


CORBA ORB

Paul is looking at a third candidate for a TSS replacement. This would involve
some sort of CORBA ORB. (Here ORB is object request broker; CORBA is Common
Object Request Broker Architecture.) I don't have a lot of details on this
yet. CORBA is potentially a large system; it could provide all the
functionality we need. But it could also be overkill. We need to see where
Paul and CalTech want to take this. There are free versions of ORB available.