A formal definition for Message-Oriented Middleware can be provided as "a client/server infrastructure that increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces- Application Programming Interfaces (APIs) that extend across diverse platforms and networks are typically provided by the MOM" [Reference 1].
So, MOMs are a middleware layer that allow applications to send messages to each other. Applications have an 'Outbox' and 'Inbox' on the MOM system, and they check the Inbox for incoming messages, while putting the messages to be sent in the 'Outbox'. An easy analogy for MOMs is actually email exchange between several persons. Each person assign others tasks and send the results of these tasks by email. MOMs perform the same functionality except that the persons are replaced by applications.

Solstice is a MOM application that uses regular emails to send messages from one point of the application network to the other. This allows easy implementation since Solstice can directly take advantage of existing network architectures to convey information between one node to another. As a MOM system, Solstice not only transports information to another, it also stores messages requests in outgoing and incoming queues, which are the only way the application can access the messages. Solstice also provides guaranteed processing, meaning that one a request is given to Solstice for delivery to another application node, the delivery will happen (obviously the succes/failure of the task in the remote application itself is independent of the MOM).
The format of the message to pass between applications is not defined by Solstice, since Solstice only relays these messages without interpretation. Applications must define a common format that each of them can understand (There exist many such formats, SOAP for example).
One Solstice server can handle several applications. The only restriction is that the Solstice server is locally accessible from the application since the interface between those is using RMI/CORBA. In case on wide area networks (which would me the main use of Solstice), a Solstice server needs to exist for each LAN. Each of those servers would then pass the messages to each other using regular email.

Obviously, it is possible to have the different applications communicate directly with each other. In case these applications are separated by firewalls or through the internet, this causes many extra overhead and risks in fail-over and security. With Solstice, the only requirement for an application to communicate to a remote network is that both are linked by SMTP/email. This directly applies to the Internet, and while security may be an issue, Solstice provides the necessary features to encrypt all information.
When the applications can connect to each other directly, Solstice still shows several advantages over direct application-to-application communication:
- It is asynchronous
- It guarantees delivery and provide fail-over mechanisms
- It allows heterogeneous applications to communicate with each other (the only requirement is to define a common task format, which would be the responsibility of the application developers)
- It prevents the applications to communicate directly with each other, which may be required for security reasons. One application just asks Solstice to send a message, and the other application checks with the other Solstice system if there is any incoming message and processes them.
Furthermore, if Solstice already exists, the application developers will not need to write the messaging layer of their application. All that they would do is implement the Solstice interface to allow their application to communicate to Solstice.
But the real advantage of Solstice is when it is used between several applications running on remote sites. All that is required in this case is an email connection between those. Solstice will take advantage of this infrastrucure to act as a robust communication layer. In the case of the Internet, it is a substancial benefit in security since you do not need the hosts to be visible from the outside world, they will just send emails to each other. Obviously, Solstice provides encryption to protect those sensitive messages.

Database replication
Let us imagine that site A runs a database server. Site B, which is a remote site sometimes needs some data from site A. Connecting directly to site A may cause performance issues, and could be an issue while site A is down. A good solution to this kind of problem is to replicate the database from host A to host B. If the database does not have a very high update activity, Solstice would provide a way to keep the data on site B in sync with the original data (with a reasonable lag), while ensuring complete data integrity and security.
Distributed computing
If one system of super computers process extensive calculations and they need each other's results, Solstice could be used to pass the information between them. To some extent, this could be used in projects similar to SETI@home.
Enterprise system federated workflow
Imagine several enterprise systems running workflows. Solstice would be a good candidate to provide a bridge between those systems, in order to run federated tasks. For example when a user on site A completes their activity, this fires a new workflow or advances a running one on site B. Solstice has been designed keeping in mind all security and fail-over mechanism required by entreprise systems.

1 - Rao, B.R. "Making the Most of Middleware." Data Communications International 24, 12 (September 1995): 89-96.