07/22/08 :: [SOA] Semantics (of the programming model) matter [permalink]
My post yesterday on Justin McCarter and Jim Ladd article on Physhun got me thinking about event semantics and the importance of both understanding and not abusing semantics.
"Event" semantics are probably the most abused semantic in the programming world. To start with, hardly anyone would see an event as the occurrence of a state. People even talk about "event occurrences".
This is what the Observer Pattern definition in Wikipedia states:
Primary objective of this pattern is to provide a way how to handle runtime one-to-many relationship between objects in object oriented languages. The event from the observable object's point of view is called notification and the event from the observers' point of view is called update.
you just want to cry out loud. An event (as the occurrence of a state) is notified to the observer. Why would the observer think this is an "update", the notification simply conveys the occurrence of a state that it is interested in.
If Justin and Jim had used the semantics of event and event notification they would have understood immediately the relationship between state machines. An event (as an occurrence of a state) in one state machine is notified to another. By thinking of that an event IS-A notification, in other words by dereferencing an event from a state and aligning its semantics with the ones of a mere message, they destroyed an otherwise obvious and key relationship of their programming model.
The other mistake that people do is to automatically associate publish/subscribe with events. Again an event is the occurrence of a state. The question becomes how do I convey the notification of the occurrence of a state to multiple parties potentially interested by this occurrence? Well, I need to broadcast this notification, but I can also design systems where event notifications are directly wired to an observer, the semantics of the event and the notification are separate and completely different from a programming model perspective.
Now, for sure, someone somewhere is going to need the semantics of "request/response" in some object lifecycle and for sure this someone will overlay these semantics on the notification mechanism that Jim and Justin expressed in their programming model and somehow will create "fake" events to express that this particular message is actually a request and this other one is actually a response and not the occurrence of a state.
The bottom line is that everyone looses when
a) semantics are abused
b) the programming model is incomplete which leads to abusing semantics
This is why I am so violent against the (other) REST and the people that propagate completely bogus rationales about the semantic completeness of REST. At the end of the day even Roy's REST is grossly incomplete when it comes to establishing the semantics of an enterprise information system (not the Web). The notion of "human tasks" is essential in such information system and the programming model needs to surface it directly (IMHO). This means that if you use Roy's REST as a programming model for your enterprise information system you will have to systematically re-implement human task semantics (tasks, task lists, delegation of tasks...) in the HATEOS model. This is not pretty to say the least. The Web does not have "tasks" and does not know anything about "tasks" but enterprise information system do.
The people that try to make you believe that there are somehow some uniform semantics that everyone can use and have a sense of completeness are F... of Sh... All these people care about shoveling bits from a data store to a client and back without any particular information or process semantics. They are the very reason for where IT is today and all they are recommending will lead to an even bigger mess. Semantics need to be carefully chosen (and never abused) to solve particular problems.