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 M E S T 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]

Agile modeling with UML 2 templates for Visio

Friday 17 November, 2006 (Agile | Architecture | Reviews)

I have been working on putting together the documentation for a project these last few days and I use Visio for all my diagrams. I don’t always create UML diagrams for my projects because they just take too much work. UML in Visio is difficult to use as pure documentation since you also need to create the underlying structures for it to work properly and there is some pretty extensive validation built in, although obviously nothing like Rational’s software. I was working on a sequence diagram when I realized that some of the UML features that I wanted to use where not implemented in Visio. I have never really thought about it but it turns out that Visio only supports UML 1.2. There have been several minor revisions of the UML specification since 1.2 was released in 2002 and the latest version of UML is 2.0 (I believe that 2.1 is on its way).

Searching the Internet I quickly found UML 2 template support for Visio at Software Stencils. These are simply new shapes for Visio with some smart behavior. Unfortunately you don’t get any help with your UML syntax using these templates, so you either have to know your UML or accept that your diagrams don’t conform to the UML specification. They are not useful for forward or reverse engineering nor are the artifacts integrated with each other so a change in one place will not propagate to other instances of the same artifact in other places. Maintaining you diagrams is potentially more work with the new templates than using the built in UML support that Visio offers. On the other hand maintaining UML documents that are not integrated with your code is just a lot of work no matter how you do it. But who really uses UML in a completely integrated modeling tool? You can only realistically expect the static structure / class diagrams of UML to be integrated with your code, getting automatic generation of activity or sequence diagrams at the right level of granularity seems to me to be too much to expect. And if you use Visual Studio 2005 you will probably use the built in Class Diagram support instead, which is a visual representation of your code and allows refactoring and reworking of your code through the diagrams. Channel9 has more info on the Class Diagram / UML debate.

In the end this really begs the question of what we want to use UML for. I am in the Agile Modeling camp we should be using UML and other modeling tools as abstract representations of our system to enable communication of the concepts and structures that exist or could exist in our software. A whiteboard or a napkin should be all that is necessary to start modeling your software together with others. Just taking a snapshot of your whiteboard after you have finished drawing is enough for team documentation. Sometimes you want a more formal look for including your models in official documents or for presentations and that is where Visio or any other modeling software comes in handy; simply a way of getting your diagrams into an electronically editable format. My colleague Peter Tallungs is a firm believer of Word’s built in diagramming support as the best way to document your models since this does not require any additional software from your readers (article published in Computer Sweden in Swedish). I guess I agree with him in principal but in practice I find that the lack of built in support for software diagramming in Word just makes it too difficult to work with your models. For all of us who want a balance between formal modeling, agility and ease of use the Software Stencils templates offer a perfect solution for Visio.