SOA Business Events

Introduction

I read a nice article here on the SOA Magazine site about "SOA: Dealing with events". This blog item discusses some of the points made and the practical consequences it has (in my opinion).

What is an event?

The first fundamental question you have to ask yourself is "what a business event" actually is.
The writer talks about "a significant or meaningful change in state", "a higher level semantic form" and "meaningfull" for the business. Technical local events are not considered business events.
I think this is the same discussion you always have about what a "Service" is. So this always remains a point of discussion.
A technical event can also be very usefull when for example systems are going down. This shall have impact on other parts of the business and maybe should trigger the business.

Key Concepts

Autonomous messages

The clue of the statement the writer makes here is: "each message contains just enough information to represent a unit of work.
This is about the fine or coarse grained events. Just like the design decisions about the finegrainedness of the service operations, this also holds for the business events.
So maybe you should also consider several events that represent the same event only that the information differs, for example EmployeeAdded with just employee number or EmployeeAdded with more information.

Pub/Sub for Lossely coupling

The writer states here: "The only requirement is a well-defined message semantic format, which can be implemented as plain old XML-based (POX) payload. "
I think (as pointed out earlier) this can be a challenge of its own.

Another statement: "Furthermore, due to the overall reduced dependencies, changes to each connected system can be deployed more independently (and thus more frequently) with minimal impact to other systems. "
This also holds for request-response systems when you adhere to the service interface. Also there each system (service) can be deployed independently as long as it adheres to the interface.

The example given is about the Web application generating an event that the registration of a new Employee is finished. I would say that the business event is the Employee has been registered within the HRM system.
There may be aother ways to register a new employee, should each client generate such an event?

Aspects of implementation

I like the statement of the writer that request/response and event driven architecture style are complementary, i totally agree on that, and would otherwise make the statement myself.

Event Normalization and Taxonomy
Just like a CDM of ojects used within Services a CDM has to be made for Events as well. This also holds for the granularity of the events and the governance of the Events.

Process Design and Modeling
I like the rule of thumb: "As a rule of thumb, the Synchronous Request-Driven pattern is appropriate when the event source (or client) depends on the receiver (or server) to perform and complete a function as a component of its own process execution and is typically focused on reusing business logic. On the other hand, the Asynchronous Event-Driven pattern is appropriate when connected systems are largely autonomous, not having any physical or logical dependencies; typically focused on data integration. "

Security
The weriter states: "event-based security can be simpler as connected systems can leverage a point-to-point, trust-based security model and context, compared to the end-to-end security contexts used in multistep request-driven distributed transactions. "
But you also need end-to-end security for Events. Furthermore when the security requirements are different between parts of the enterprise this can also be more complex.

Conclusion

A good article that shows which elements and challenges you will face when (also) implementing event based SOA.