XLattice
 

Business Messaging System

Requirements

  • Speed.
  • Reliability. Several nines of reliability would be essential. This might for example mean that 99.99% (four nines)of all messages would have to be successfully delivered or their non-delivery would have to be reported promptly.
    Another way of stating the same requirement is to say that the loss in one out of every ten thousand messages would be acceptable.
  • Confidentiality. This includes the capability of encrypting messages using a number of acceptable protocols and also some degree of protection against traffic analysis. In many business activities, the fact that a message has been transmitted or received is as important as the contents of the message itself; it must be possible to mask both.
  • Authentication. The system would have to be capable of generating and securely storing its own digital certificates and of interacting with commercial digital certificates and certification authorities.
  • Key Management.
  • Email Support, including Filtering. All of the requirements of the relevant IETF standards would have to be supported. In addition, we would need filtering in terms of source and destination, other header content, and message content.
  • Virus Scanning.
  • Archiving.
  • Logging.
  • Interface to Commercial Messaging Systems. For example, IBM's MQ Series.

Non-standard Elements, Client

popup A resizable popup window that can be used with keyboard and mouse.
contact list Persistent storage of such a list plus software allowing it to be viewed and edited through the popup window.
attachments Support for MIME attachments in the popup is likely to be fairly complex.
incoming messages Persistent storage of such messages plus software allowing them to be viewed and replied to through the popup window.
outgoing messages Persistent storage of pending outgoing messages plus software allowing the user to see what messages have not yet been successfully sent.
log Persistent storage of a log of sent and received messages plus software allowing the user to view this.
filters Persistent storage of a set of filters plus software allowing these to be viewed and edited through the popup window.
authentication Support for externally-generated digital certificates will be essential. It must be easy to install a such a digital certificate supplied from a local network admin or some other such authority within the corporate hierarchy.

Implementation Sketch, Client

Building a client for a business messaging system on top of XLattice would seem to be straightforward.

Non-standard Elements, Broker

log Any broker used for the Business Messaging System would have to keep comprehensive logs of any messages passed. There would be considerable tension between this requirement and the need for protection from traffic analysis.

Non-standard Elements, Filter

connections A firewall node (filter) would have only two (bidirectional) connections, possibly plus a secure HTTPS connection allowing remote management.
filters To operate an efficient business messaging system, it is likely that the firewall would have to support unusually complex filters which would reflect a hierarchical authentication structure. This would allow, for example, company-wide filter policies in conjunction with lower-level division and and still lower-level departmental policies.
message pool For speed, this would have to be in memory. However, it would be essential that any message entrusted to a filter be persistent.
log Any filter used in the Business Messaging System would have to keep comprehensive logs of any messages passed. There would be considerable tension between this requirement and the need for protection from traffic analysis.
remote management It would be very desirable for a filter node to be remotely manageable using a browser over a secure HTTPS connection.
views It must be possible for network admins to view the log and message pool and edit filters either through a popup or via an HTTPS remote management interface.