Is EDA the way to go?

Tuesday 01 July, 2008 (Architecture | EDA | SOA)

I have been reading a lot about Event Driven Architecture (EDA) in relation to SOA recently and while the ideas are very interesting and the benefits are alluring it adds an additional complexity and uncertainty to the overall behaviour. Two good articles on EDA are http://martinfowler.com/eaaDev/EventCollaboration.html and http://eaipatterns.com/docs/EDA.pdf

From my view the main problem is that when implementing a business process that spans several services (for example entity services) we do not generally want the entity services to react to events and then store or retrieve data based on the events because this means that the services need to have some kind of knowledge of the expected behaviour relating to the process - generally seen as a bad thing in SOA, as the northbound - southbound dependencies get reversed. We also want to have some stability from a callers perspective that the overall flow will be moved forward, traditionally done by issuing a command. If events get turned into commands then I believe we will have problems coordinating the different actors (presuming that the command event was only meant to be acted on once). Jack Hof has an interesting take on the relationship between SOA and EDA especially his extended pdf version has some interesting ideas about how to realise SOA and EDA together which contains a potential solution to the problem, basically by just combining EDA and SOA and knowing when to implement which principles.

A related problem is what should our messages contain - are command messages even required? Two slightly different takes on the problem are presented here and here. Thinking about events and messages has lead me to attempt to create (a very crude) classification system for events that are related to a solution that I am developing for a client.

• State-change events: no messages are published as long as the underlying values are not updated, the message is related to a specific instance of an entity or service. There is no expected behaviour for the recipient.
• Scheduled events: messages are published at a certain frequency whether the values are updated or not, all available data should be published simultaneously within a single message or as multiple messages. There is no expected behaviour for the recipient.
• Request or reservation events: these messages are requests for behaviour. A receiver may safely ignore the message, send a negative response if it cannot fulfil the request or a positive response if it can fulfil the request. The event needs to have a predefined response message which the event source can understand and the response needs to be able to be routed back to the source without the listener needing to have prior knowledge of all sources. This is basically an event which initiates a dialogue between two parties based on the reservation pattern. It is the requestors responsibility to coordinate the possible responses and outcomes. There is an expected behaviour for recipients who return a positive response but no prescribed behaviour for those who ignore the event or actively return a negative response.
• Command events: This must be an anti-pattern since a command denotes that the sender expects the recipient to perform some specific task and thus exhibit an expected behaviour, which is impossible in a loosely coupled, event-driven, service oriented world since the sender does not know who is listening.

The first two event types are just statements, the third (reservation) is really just a variation of a state-change event with additional semantics attached to it. Using EDA the expected behaviour that is needed for a specific business process must be realised with the help of some kind of process controller (notification server in Jack Hof's world) which follows the traditional Command and Control (call stack) approach for coordination but uses events to track what stage the overall process or task is at.

Comments [0]

Jim Webber: "Business people are spaghettiheads!"

Thursday 29 May, 2008 (Architecture | Interviews | SOA)

This is a guest post by Herbjörn Wilhelmsen @ Objectware

After working for years with business people and SOA Jim Webber has come around to thinking that fighting against real world complexity is neither successful nor valuable.

Dr Jim "World Wide" Webber - an author as well as global architecture lead for Thoughtworks - gave an interview last month after finishing his "Guerilla SOA" presentation at the Developer Summit 2008 conference in Stockholm.

Watch the interview to see Jim Webber

• Say that business people are spaghettiheads, tell us why business people scare him and that business people should be the architects of our projects!
• Come down hard on message oriented middleware (ESB’s) and WSDL
• Give his definition of a what a service should be
• Talk about why MEST and SSDL makes for better SOA
• Describe how MEST and SSDL helps you handle versioning problems in an SOA
• Talk about his next big thing: Middleware! (despite his grudge for ESB’s)

Jim does a great job - he explains things that seem contradictory in a very smooth and straightforward way and in the end you just can't help yourself: You have to like him!

Thanks for the interview Jim!

I also want to thank my colleague Joshua Anthony (the owner of this blog) for standing behind the camera and doing a lot of post production work!

Update:
During the interview Jim talked about the SOYA project and a case study. Here are some links:

• SOYA @ sourceforge
• A description of the LIXI case study can be found inside Patric Fornasier’s master thesis

Comments [1]

Norwegian SOA weekend

Monday 21 April, 2008 (Architecture | SOA)

I spent last weekend with a bunch of my Norwegian colleagues at Objectware listening to their experiences implementing SOA and looking over the material that they have produced. It's great to hear some really pragmatic and developer-oriented ideas about how we can implement SOA. In contrast to many of the theories and ideas that I have been reading up on in my current project, Objectware's patterns and theories support the developers as well as the architect/analyst. A lot of the theories on SOA are at such a high level that they really aren't much help when you're looking at actually implementing something.

For me the main points of interest were:

• A new categorisation of services: Human to Application, Application to Application, Aggregated Core Services and Core Services.
• Enterprise Domain Repository Pattern (EDR): basically a hybrid entity service and Master Data Management (MDM) which makes it easier to create services with multiple backends.
• Evolving Service Endpoint Pattern (ESE): A service endpoint WS-*, REST or whatever you want that supports different dialects over time without using client-breaking versioning if previous client calls can still be supported by the business.

I will be looking into the patterns more closely over the next few weeks and may try my hand at implementing some of these ideas with BizTalk.

Comments [2]

ARC201 – Patterns and Anti-Patterns for Service-Oriented Architecture (SOA)

Wednesday 08 November, 2006 (.Net | TechEd 2006 | SOA)

I can only say wow! Ron Jacobs is a brilliant speaker, entertaining and very informed, an expert to say the least. A couple of his insights into SOA and what he things works and doesn’t work for SOA were real eye openers for me. Not because I didn’t understand the principles behind SOA or the problems with implementing SOA but because I do understand SOA and I realise it isn’t just about choosing the right technology and then claiming that we are service-oriented!

I will try and compress some of what he said in a short list, mainly to remind myself of this from time to time:

• Don’t loosely couple everywhere: tightly coupled components and services have a place in our architecture too they just aren’t service-oriented in the SOA sense.
• Rely on explicit behavior over implicit behavior: a service will do what the contract says it will. Just because it happens do something more right now (like ordering the returned data) doesn’t mean you should create a dependency on this implicit behavior.
• Business Processes are a good starting point for identifying your services: is this performed as multiple business processes then it is probably multiple services.
• Everything changes when we cross an external boundary: just like everything changes when we cross an international border in real life. Languages change, laws change, the weather, everything. But we should strive to make crossing the external boundaries as friction-free as possible.
• Think about services like paper-based business processes: what does the paper form like look? That’s our message. Who do we send it to? That’s our service. What do we expect them to do with it? That’s our contract and policy.

Start with the business process:

1. Decide on a process
2. Decompose the process
3. Create the contract
   a. Define the messages – messages define what we can do
   b. Define the operations – operations move the process from one state to another

If anyone who reads this has the opportunity to see Ron speak on this topic then don’t miss it. Here at Tech-Ed he will be holding the same session again on Friday.

Technorati tags: TechEd-Developers

Comments [0]