GenEtic Message Oriented Middleware

Why are we looking at gemom.eu? I don't really know.. anyway, working through http://www.gemom.eu/public/modules/wfdownloads/viewcat.php?cid=98 and guess what.. so much of it sounds familiar, although the wording is different. For instance a topic is what we call a channel.

MC.2: The system MUST support persistence of messages without binding to specific database implementations

In the side notes they actually mention SQL.. oh dear. Of course PSYC is very happy to be operated without any legacy database technology anywhere close to it.

MC.9: The system SHOULD be able to persist meta-information about last update on all topics.

In PSYC terms this means that a notice making some changes in the distributed state of a context shalt be stored in history as such, so that not just the current version of the state can be recovered but also a list of changes and any intermediate view of the state. In other words, PSYC provides for this, although there is no functional implementation of distributed state as yet.

MC.10: The system MUST support a “Total Ordering” message-dispatch policy on topic-type destinations

By implementing packet ids you are given order beyond just trusting the linearity of a TCP connection which is to be reflected in your history and state.

MC.15: The system SHOULD attach the following meta-data (signatures) to any topic: Structural, Ownerships, Approvals, Publishers, Access rights, Transient (e.g. states during persistence, replication, recovery etc)

Various application specific stuff. Just do it. Just put it in.

MC.16: The system SHOULD specify signatures at topic, cluster or broker level

Not sure, but to me it sounds like this application needs PSYC's channel inheritance and state per channel model.

MC.20: The system SHOULD be able to assign different priorities to topics, topic clusters or single messages.

We haven't needed priority logic as yet.

MC.21: The system SHOULD support an “out-of-band” priority where messages are sent first, regardless of the order in which they arrived at the server.

PSYC is event oriented. If a request could not be answered immediately, the next request will be answered while the other is being processed. Thus any request that can be dealt with immediately will have an “out-of-band” status over asynchronous requests. Only if your application has lots of asynchronous requests a prioritization may be useful. Just add it in then.

MC.27: The system SHOULD be capable to apply transformations to the data (e.g., XSL transformations) before messages are delivered to clients.

Uh.. this one is nasty. It is putting application logic into the message, somehow.

SD.5: The system SHOULD be able to spawn new hot-standby component instances for extended resilience or self-healing
SD.6: A system configuration also defines the system topology (the set of active components together with their interaction patterns). At runtime, the system SHOULD be capable to adapt its topology according to information gathered from its operating environment.

The protocol enables it, but it's not implemented.

Case studies described in the document:

  1. Financial market data delivery
  2. Collaborative business portal
  3. Distributed, linked exchanges
  4. Dynamic road management systems
  5. Banking Hub case Study
[edit]

See also