Archive for the ‘enterprise integration’ Category

Event Sourcing

July 3, 2009

I read a very interesting article yesterday. We are busy with a POC on this and will probably be implementing this on one of our big projects coming up.

Marting fowler describes a new pattern called event sourcing (http://www.martinfowler.com/eaaDev/EventSourcing.html) which is based on the Domain Event pattern. This pattern challenges your thinking around traditional business application development.


The idea is that you have a domain model that is based on state. This state comes in from one or more input sources. These input sources generate events that come into your system. These events get routed to your EventLog.
The EventLog has three purposes:
  • It persists all events it receives (in order) to some repository (in memory, database, etc).
  • It generates events based on the incoming events and forward the events to the EventProcessor.
  • On startup, it will get all available events persisted from the repository and reconstitute the state of the domain.
The EventProcessor propagates the events throughout your domain model.Once the domain receives the events, additional events can be triggered based on domain change. These events get routed to one or more output sources.
What this gives us is that the domain model is completed driven around events. This is especially usefull when working in a publish/subscribe model where your system is receiving broadcast messages (like order price change) from a broadcaster. Only the relevant data is pushed to your system. Because we have a complete log (in order) of events in a repository we can provide rollback or playback functionality. If the system dies for some reason, on startup the domain will reload itself from the repository and be in the correct state because the order of events were persisted.
A very interesting model to adapt when working in a messaging system.

Enterprise Integration Patterns: Overview

July 3, 2009
I would like to cover an overview of the general concepts in Enterprise Integration Patterns in messaging systems. I will cover each topic in more detail in further posts, but lets start at the basics.
Figure 1: Message Router routes messages from input channel to one or more output channels
Firstly, where would you use these Integration Patterns? Well anytime you want to move information from one system to another you can use these patterns. These patterns are extremely useful if you have to access data that is contained in a legacy system or if one system is “sealed” and you cannot easily access it’s data (through API, database, etc).

The first challenge and the major selling point of Enterprise Integration is that you want the 2 or more systems to be as loosely coupled as possible i.e you don’t want one system having a direct reference to the other system. Why do you ask? Any change in business rules or the addition of additional recipients will result in code changes at numerous places. This makes it very inflexible.

There are two main flavors of messaging:
  • Request/Reply: An example is you needing customer information that resides in different CRM system. A request message will be sent to the CRM requesting information. The CRM system will send a reply containing the information.
  • One way: An example is that you have an event that occurred in your system that you want to broadcast to other systems. These systems do not have to acknowledge or reply to your broadcast.

Messaging consists out of a couple of main concepts:

  • Channels: Messaging systems transmit data through a Message Channel – a virtual pipe that connects a sender and a receiver.
  • Messages: Message is an atomic packet of data that can be transmitted on a channel.
  • Pipes and Filters: Break up various operations between sender and receiver by chainging operations using pipes and filters.
  • Routing: Router receives a message on input channel and determines how to navigate the channel topology and directs the message to the final receiver.
  • Transformation: When applications do not agree on the format for piece of data, use a transformer to map one message type to another.
  • Endpoints: An endpoint bridges the gap between how the application works and how the messaging system works

Thus to illustrate we can use the request reply example. An ordering system needs information stored in CRM system when placing orders. The ordering system would create a request message (CustomerId=1 request) and place this message on a channel (MSMQ as an example). The router will receive this message of the queue, determine the type of message and route it to the CRM system endpoint. The endpoint will receive the message and use a Channel Adapter (discussed in future post) to act as anti corruption layer and transform the message into an object the CRM system understands. The CRM system will process the message, retrieve the valid customer information and send that information via a response message to the Reply Address specified in the original request message. The route will pick up the reponse message, perform any needed operations on it and send it off to the ordering system endpoint.

In further posts I will go into detail on each of these topics by illustrating why they are important and when and where you will use them. I will also show a couple of different flavors on each of them.


Enterprise Integration Patterns

June 30, 2009

Recently I have started working with Enterprise Integration at work. Although I have worked in the past with this, I have discovered a book by Martin Fowler called Enterprise Integration Patterns which covers Integration Patterns. This book has altered my view on integration and in software development in general.

This book can be found on his website at
http://www.martinfowler.com/books.html#eip

Anyone working in this field should read this book if they have not done so already. These types of books should be made as course material in any university or tertiary institute as this explains design problems and is technology agnostic.

In upcoming posts I will discuss some concepts and implementations which I find really interesting and has already helped me out of some serious issues.