A little bit pie in the sky here, nice in theory but a killer in practice So as an example.
Imagine a message about a prisoner requesting a specific training class. The message would have to include All information about the prisoner, including why he is behind bars and past behaviour (after all you wouldn't let a pyromaniac into a cooking class), the place where he is banged up, the number of people there (might effect the number of course places available) and all of the information about the course being applied to. For the event to be relevant you'd also have to have all the information from the receiving side about the current number of open places and the reasons for a rejection as the event itself can't be viewed without a temporal perspective unless you include the response. The other problem with passing all data is that to understand the data you need to have the schemas and semantics of the information from that point in time, which is liable to be system specific. Now what I try and do is actively push using reference data in messages and then using the services to do the archival and logging. The reason for this is that it decreases the amount of information and schema changes and also ensures that the semantic information around the event can be stored. Storing the inflight messages is okay but the amount of scale required for truly temporally independent messages is too huge (IME) to be a place to attack. It can also lead to misunderstanding of what roll-back can be achieved (in one notable system I was involved in someone thought that by taking this approach they could roll-back to any point in time). So I'm really not a fan of the suggested approach. Steve 2008/11/24 Gervas Douglas <[EMAIL PROTECTED]>: > <<A fully self contained message is a pure and complete representation > of a specific event and can be published and archived as such. The > message can - instantly and in future - be interpreted as the > respective event without the need to rely on additional data stores > that would need to be in time-sync with the event during > message-processing. > > Some people disagree with me that it is good practice to strive for > fully contained messages in an Event-Driven Architecture. They > advocate passing references to data that is stored elsewhere as being > strong design. Let me explain why passing references is not suitable > as an architectural principle and should even be regarded as an > anti-pattern in EDA. > > First of all, I think everyone agrees with me that SOA and EDA strive > for loose coupling. Striving for loose coupling by definition means > minimizing dependencies. In SOA the services layer acts as an > abstraction layer of implementation technologies. In EDA loose > coupling is pulled further upwards to the functional level of > interacting business processes. > > Passing reference data in a message makes the message-consuming > systems dependent on the knowledge and availability of actual > persistent data that is stored "somewhere". This data must separately > be accessed for the sake of understanding the event that is > represented by the message. Even more: this data must represent the > state at the time the event took place, which is not (exactly) the > time the message is being processed. The longer the processing is > deferred the harder achieving this time-sync will be. E.g. think of > processing archives in behalf of business intelligence or compliancy > reports. How would you manage to keep available the referenced data in > a state (and structure) of the moment the event occurred? > Fully self contained messages relief the consuming systems from this > dependency; the event can be fully understood through the content of > the message. Consuming systems can process fully self contained > messages without being dependent on any additional data with regard to > the event. Newly implemented consumers don't need to be made aware of > the need for additional data access and so don't create new > requirements on connectivity to these data. > > In architectural approaches that strongly focus on loose coupling > (such as SOA and EDA) the principle of fully self contained messages > should be advocated as good practice. Advocating the passing of > reference data, which happens far to often, leads into the opposite > direction of the main goal of the architectural approach and so can be > stated as being an anti-pattern. > > However… Architectural principles must never be rigidly enforced. > Architectural principles are guidelines toward a goal, in this case > toward loose coupling, independency. Real-life situations may prevent > us from implementing architectural principles. For a certain use case > it may be too expensive or it may highly decrease performance and > efficiency. Or for a specific use case it may technically be > impossible to adhere to the principle. Architectural principles always > are subject to negotiation with regard to costs, performance, > efficiency and technical feasibility trade-offs. This also applies to > the principle of fully self contained messages. > > Passing reference data in a message may be the best solution in some > (or many) cases. But still it is an anti-pattern for the SOA and EDA > architectural approaches as it simply drives you away from the > architectural goal of minimizing dependencies.>> > > You can read this blog at: > > http://soa-eda.blogspot.com/ > > Gervas > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
