I have recently had the need to think about messages, events, and state. I may have finally caught up to where Nigel Green was three years ago!
These three ideas are often bundled together, but really they represent different things. And when we try to treat them homogeneously we run into difficulties.
Dealing first with a message. messages are units of transmission. They provide a mechanism for moving some bits from point A to point B. The arrival of a message is an interesting "event" in the technical domain. Useful for capturing statis, handling billing, etc. But it is not really the business trigger for business functionality.
The events amy well be bundled up inside a message. A message may well contain information about multiple events. In the airline reservation world, w might have events that create a new reservation skeleton, add passenger(s) to that reservation skeleton, add itinerary information to that reservation skeleton, etc. In other words events that indicate lifecycle happenings to the reservation. However, during the reservation business process, the various happenings may all end up being bundled into a single message. Or they might be separate. remember the message is about transmission not functionality.
Then there is state. By state we mean the values of all of the attributes associated with an object of interest. yeah, I know, a bit vague :-(. So the state of a reservation is the state after the various events have affected the reservation. That state might be notified after just the itinerary has been built, or it might be after the itinerary + passenger + pricing. The state is set at a relatively arbitrary point in time. That's a packaging issue.
In some cases, message size limitations will demand that multiple transmission units (messages) be required to transmit the complete state.
Bottom line EAI type patterns generally assume some kind of unification between message/state/event, but in reality they are separate concepts and should be handled differently.
These three ideas are often bundled together, but really they represent different things. And when we try to treat them homogeneously we run into difficulties.
Dealing first with a message. messages are units of transmission. They provide a mechanism for moving some bits from point A to point B. The arrival of a message is an interesting "event" in the technical domain. Useful for capturing statis, handling billing, etc. But it is not really the business trigger for business functionality.
The events amy well be bundled up inside a message. A message may well contain information about multiple events. In the airline reservation world, w might have events that create a new reservation skeleton, add passenger(s) to that reservation skeleton, add itinerary information to that reservation skeleton, etc. In other words events that indicate lifecycle happenings to the reservation. However, during the reservation business process, the various happenings may all end up being bundled into a single message. Or they might be separate. remember the message is about transmission not functionality.
Then there is state. By state we mean the values of all of the attributes associated with an object of interest. yeah, I know, a bit vague :-(. So the state of a reservation is the state after the various events have affected the reservation. That state might be notified after just the itinerary has been built, or it might be after the itinerary + passenger + pricing. The state is set at a relatively arbitrary point in time. That's a packaging issue.
In some cases, message size limitations will demand that multiple transmission units (messages) be required to transmit the complete state.
Bottom line EAI type patterns generally assume some kind of unification between message/state/event, but in reality they are separate concepts and should be handled differently.
Posts
0 comments:
Post a Comment