Events in XML – Two Options
Option 1 |
Option 2 |
|
|
|
|
If we get practical for a short while, before going on and talking about event semantics and event models.
If we agree that XML is one good way to represent events in most common cases, we have basically two ways of doing it. Above you can see two different approaches.
Option 1 uses a common XML element as the root and says that this is an "Event". The type, id and other properties can be defined in the header element of the event. The body would then contain a payload suitable for this particular type of event.
Option 2 uses the root element to name the type of the event. The properties of the event are given in the root element and the Body element contains the payload just as in option 1.
It might be a matter of taste which ones to prefer, my taste is for option 2. It’s just more XMLish…
There are a number of features of it I like:
- The event type is apparent directly from the root element. Many times processing is based on event type and it can be critical to find it easily
- Having the root element define the event type lets us easily use a schema to verify it. The schema, if done properly, can contain two parts. One base which defines the overall structure of the event. That is the <Header> and the <Body> tags. The base also contains the definition of the header and which attributes to expect in the root element.
- The extension to the base schema, specific for the event type, defines what can go into the Body.
So each event would have a well defined properties and header part, but still having a totally flexible body.
At the same time everything can be validated against schemas.
It might not come as a suprise that we use option 2 in the ruleCore event model.
Option 1 is not completely wrong either, but iit does not feel as XML Schema friendly to me and it requires some more parsing to get the event type.
This is the to main ways I see using XML, do you have ideas for other ways of doing it?
That’s if you prefer XML. I can see that there are a place for more compact binary formats too. So the event model and the definition of semantics should be neutral to the format used to encode events. But for practical purposes XML might be a good candidate in most cases.
One advantage of option 1 will be compatibility with formats like JMS MapMessage and Google’s Protocol Buffers, etc.
Compatibility with existing systems is of course a important topic to look at. Do you have examples of how these two formats look like?
Marco,
its got to be Option 2 every time. In fact I would go further than this. Where there is always a 1-1 mapping between an element and a child, the child should be defined as an attribute, not a sub-element. Your id attribute is the perfect example of this. Potentially, your Err element should also be an attribute (assuming always exactly one Err per Exception)
Regards
Stan
I guess the faster the parsing into an event-object, the better–it is about objects at the end, I guess. When tossing object in between systems I actually prefer JSON (30% lighter), but XML is a bit more human-readable, so better for examples.
One may prefer the first example in cases where an event-message may travel through several systems and find itself in a queue with other message-types; like traveling through a mesh-network.
Why not use an RDF approach?
XML might not be the optimal format, but still it’s something all tools can handle and there’s nice things like XSD and XSLT to come with it. For optimal transfer it just not, well optimal…
One benefit of having the type in the root element is that you can easily fint the type, as it is in the same place everytime, No need to understand the structure in order to find the type.
It’s very common that you need to get the type so that you can look up the definition of the event. Many types of processing requires that you consult the definition of an inbound event so its nice ta have a easy way to access it.
Sam, RDF sounds interesting… But how?
Option 1 has the advantage that it allows consumers who do not understand the “Exception” event type to learn a little about what happened without diving any deeper. Consumers can peek at the messages without needing to know what an Exception event is. With option 1 you don’t need to standarise all your Event types. You just need to agree on the header section and agree on how the body should be extended.
Des, that’s true. But then we end up in another discussion. Should a consumer be able to subscribe/listen to events it does not know anything about? Can a consumer do anything usable with an event is does not know anything about? In my vision there’s a repository of event type which can be searched for events with required semantics and types (Is it here where RDF comes in perhaps?) and the consumer can subscribe to events only when it has the definition of the event.
But I think there might be cases where “give me all events” might be usable. But it seems to be more practical to require that event definitions can be distributed to all actors in a event processing system.
For example, if I create a rule which I want to trigger when there are more than 100 “error” events last hour, I might want to see all events which are semantically notifying me of any kind of error. So I would need to figure out which event types those are using some kind of lookup mechanism. Even if I don’t care about the actual type of the event, I still know the type as I looked it up as an “error” event.