|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
J2EE patterns
J2EE patterns
J2EE patterns
|
Messages: 0
Messages: 0
Messages: 0
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The architectural principle of fully self contained messages
Taken from: Thoughts on SOA and EDA
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.
|
|
|
| EJB Design Patterns PDFEJB Design Patterns PDFEJB Design Patterns PDF |
|
|
EJB Design Patterns is now available for free download in PDF format. The book contains a catalog of twenty advanced EJB patterns and provides strategies for mapping application requirements to patterns-driven design, J2EE development best practices, and more. EJB Design Patterns was the #2 book at Java One 2002, and held the #1 Java book position on Amazon.com for weeks since the book was released in March. Download your PDF here.
|
| Useful patterns around the webUseful patterns around the webUseful patterns around the web |
|
|
This
essential pattern describes how to model your entity beans.
How to make an entity bean a facade to a set of dependent objects.
Every guru should use unit testing.
|
| Other Patterns sitesOther Patterns sitesOther Patterns sites |
|
|
|
The original reference
site for patterns. Frequented by the gang of 4 and their mentors (Kent Beck, Ward Cunningham).
A catalogue of J2EE design patterns from Suns Consulting Division.
A catalogue of
high level business, architectural and topological patterns for large scale systems.
Design Patterns from the J2EE Blueprints, Suns authoritative guide to J2EE development.
|
|
