The Xmarc messaging system is designed to provide
an intelligent messaging
service between co-operative clients, and
a means for a web service to send
messages to passive clients.
The messages can be "self-describing" which means they can contain within them instructions for how they are to be interpreted by the recipient and how data within them is to be visualized. Alternatively they can be data-only messages for a client-resident application to process.
Currently, the client software for sending and receiving messages is the Xmarc Fire tool (version 6.1 or later), which may run stand-alone or within a web-browser.
The base system requires the following software components:
1. Xmarc Fire (6.1 or later) resident client-side.
2. The generic client-side messaging Fire application
(redline.mxa).
3. The generic server-side message marshalling and administration
service (XRedLine).
4. Xmarc service manager and broker, installed on a
suitable web-server.
5. A server-side relational database with blob facilities
(e.g. Oracle).
For simple messaging, the above components are all you need. For more complex systems, where clients are required to interact in an application-specific way, there is a client-side Fire API to enable applications to be built on top of redline.mxa. Co-operating clients would then have such a client-side application installed as an addition.
Alternatively, where clients are "passive", i.e. they only receive messages, there is a Java API available to extend and enhance the XRedLine server-side software to enable messages to be sent unsolicited to clients who have "registered" with a service. Typically such a service would be driven by external events, not by another messaging client.
Examples of both systems are discussed later.
A message is packet of "intelligent" data sent between clients. This data comprises header information followed by one or more binary sections (blobs). Typically each blob originated as a file before being parcelled up by the sender.
A message can fall into one 1 of 3 categories:
Associative Message
This is the simplest form of message, whereby the recipient treats it as a series of one or more files and takes appropriate action according to the file extension of each, e.g. an image file would be displayed in an image display window, an html file would be displayed in a browser window etc. The actions to take are built-in to the redline.mxa application. Each blob contains the relevant file-extension information for this to work.
Macro Message
This message gives the sender the ability to tell the recipient how to process the message. The first blob in the message is a Fire macro which, when executed by the recipient (this execution being done automatically), processes the other blobs in the message. Since this first blob is a Fire macro, the full power of the Fire macro-language is available to process the data however the sender wishes.
Application Message
This message is similar to a Macro Message, but details of how to process the message are contained in the message header in the form of a function name, which must be resident on the recipient's machine. This method removes the necessity of pass Fire macros within the message, but requires that application code has already been installed.
The service monitors user logins and logouts, administers sessions and user groups, and marshals data between co-operating clients. It is driven via HTTP get/post packets via a web server.
It is permanently connected to a data base to record message activity and also maintains connections to logged-in users.
Each participating user (client) has a connection to the back-end service. This enables the service to make unsolicited calls to a participant, without the need for the client to keep polling.
For intranet/dialup use the connection is via a socket initiated by the client, in the form host:port and the service connects to this socket whenever the service needs to communicate with the user, dropping the connection when communication is no longer required.
For internet use, where the client sits behind a firewall preventing access from the outside, the client connects (logs in) via a permanent switchboard-type socket on the service host.
In both connection cases, once a connection is established between service and client there is no difference in behavior.
Each client is identified by a unique user name and password. A user may only have one logged-in to a service at a time.
A group is a set of users who can together participate in a session, or who share an ability to receive particular messages. The service itself will determine this capability. Each user has privileges within a group, giving them rights to perform particular functions. A user can be a member of many groups with different privileges in each group if required.
A session is an activity whereby users within a particular group can send messages to all or any other users participating in the session.
User privileges maintained in the database are as follows:
Privilege Description control the user can initiate or terminate a session participate the user can participate in a session receive the user can receive but cannot send messages admin the user can administer the database
A session is initiated by any user who has control rights, and thereafter is known by a combination of group/name, e.g. a session named mysess within the devel group is known internally as devel/mysess.
The administration of users and groups is currently not performed by XRedLine but is done by standard database admin (e.g. sqlplus etc.). Such a capability could be added later.
Sessions are currently held in memory for the duration of XRedLine. XRedLine keeps track of which users have joined and marshals the messages between users. Sessions can be recordable, in which case all activity, aka events, (e.g. users joining, leaving, messages sent) is recorded in data base tables, the messages using a blob column type.
Messaging can be used in a variety of ways. Consider the following fictional situations:
Simple Data Sharing
Users can pass images, web pages, sound files in a conference-type situation. This would use simple Associative Messaging.
Information Dissemination
Users could register for information to a data service, e.g. traffic accident reporting, vehicle geo-positioning. At appropriate times, a service might pass a self-describing message containing data and how to visualize it via a Fire macro. This would use simple Macro Messaging.
Application Interaction
Users might be running a live application where one user could highlight graphics and have those graphics highlighted for other users in the same session. All users in the session would be executing the same application. This would use Application Messaging.
This enables users to log in to the system and via a Fire API provides a base set of messaging functionality, executed by blob/file association, e.g. an image file is displayed in a new image window, a text file is displayed in an alpha window, an entity file is displayed in a graphic window, etc.
Standard functions provided by the API include:
Ability of a user to log in/log out. Ability of a user to open/close/resume a session. Ability of a user to join/leave a session. Ability of a user to invite other users to join a session. Query for a list of users (who are logged in/out to a session etc.). Query for a list of active sessions. Send a message to named or all users in the same session.
Overridable event handlers, invoked asynchronously when events are received from a back-end messaging service, permit application-specific action to be taken:
What to do when another user logs in/out. What to do when another user has joined/left a session. What to do when an invitation to join a session is received from another user. What to do when another user has declined to join a session subsequent to your invitation. What to do when there is a message pending from another user.
There are default implementations of these overridable functions, which typically throw up messages.
Fire macros should be written which can override the base functionality of event and message-handling (outlined above).
Typically within an application, a sender of a message would format a message as a series of blobs and pass these to the generic send message function. The sender would also pass a macro which would be executed by the receiver of a message. This macro, when executed by the receiver(s), would interpret the message and take application-specific action.
e.g.
exec myproc(~redline.packet_t)
where ~redline.packet_t is a fire class with message details, e.g. sender, description, blobs etc. This is a standard class for all messages in all applications.
The macro (myproc.cmd) can be sent as part of the message, or, to reduce network traffic, can be indicated merely by name on the assumption that the receiver already has it on their system.
There is a test harness available with 2 dialogs.
This enables a user to log on to XRedLine without yet joining a session. Once logged in, all other appropriate users would be informed of the availability of the user.
It is envisaged that a similar log-in dialog would be a standard preamble for all applications.
The session/message dialog would typically differ for each application. In this one, files can be dropped into the list box, or typed into the text box below it and sent to a user.
