This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
The basic message passing is conceptually simple:
- A message has a single subject composed of elements separated by periods. A message is sent to a single Rendezvous Daemon (though it may end up being broadcast onto Daemons).
- A listener announces its subjects of interest to a Daemon (with a basic wildcard facility) and messages with matching subjects are delivered to it if the two daemons are 'connected' to each other (or indeed the same daemon).
Considerable "Enterprise" functionality is layered onto this if desired with Fault Tolerance/Reliable or Certified options possible, all implemented through the underlying basic messages.
The messages themselves can be viewed as typed name-value fields and/or number-value fields (the two identification mechanisms within a message can mix and match with certain restrictions). A message can itself contain sub-messages which themselves may contain sub-messages, and so on.
The quality of the respective API implementations varies considerably. The C++ library is simply a wrapper providing an OO view over the C implementation. Likewise the Java and .NET implementations wrap the C++ implementation. This has led to memory management issues with the .NET implementation (though not with the COM Interop version which is considerably more cumbersome).