I recently listened to Udi Dahan’s excellent “Avoiding a failed SOA” presentation from QCON London (it is about an hour long, but it is worth your time). I agree with most of what Udi says except two points. One is that pub/sub is not the only way to go (and you should minimize duplex message). Events and choreography are definitely my preferred way to go since they make it easier to do the right thing – i.e. model the solution correctly, but I believe orchestration based solution can also work. Maybe I’ll expand this in another post – but the point of this one is on the other point I disagree with
Udi presents services (which I usually call business services) which hold within them autonomous components (I usually call these services). The solution offered is based on pub/sub (Inversion of communications pattern) so the contract for each component is actually the events/messages it sends. This is inverted to what you’d commonly do with a RPC-induced SOA e.g. usually with a WCF web service the contract includes all the messages the web-service provide. The example in the presentation is that of the Sales service which doesn’t own both “Customer status” events and pricing update events even though it processes both but does own Order accepted event which it sends away.
I don’t have a problem with the first part, i.e. with services don’t owning the events they handle – but I don’t think that it is always wisest to have the services own the events that they send out. I think a better approach is to move the events out to catalogs where each catalog is owned by the business process/entity. what happens with the services owns the messages they get/send is that the business process get fragmented – in this instance that would be the Order.
The order starts at sales but then get billed someplace else and fulfilled in some other place – and shipped elsewhere. Consider for example, the order business entity life-cycle that Jean Jacques Dubray published about a month ago. the transitions defined there don’t exactly match those Udi mentions since it is not the same example, but they roughly follow the same process. A catalog would hold all the events related to the entity.
Managing the events out side of the services brings the following benefits
- Increased visibility both to the business and dev teams- It is easier to explain, manage and even document event flows where the events are not scattered about
- Repeat usage – Several related services can use the same events. For instance a cancel order event can be used both in B2B and B2C scenarios event though the business flows are different. In fact coupled with context based routing (this is not a typo – I mean context and not content) you can use the same events within different flows where the context is set by the saga initiator and/or any participating service. Udi gives an example of a large customer that needs a different process from a regular customer, or a perishable goods vs. other goods (needed to be handled differently). If each involved service decorates the events with the context the bus can route it to different participants (or participants can disregard/filter them)
- Easier to make subscription explicit – not just parsing XML (or JSON etc.) – if the events are external services that raise the events and services that consume them can bind to the definition without adding too much coupling. There are still places where you want to just parse messages but you have the option not to
- Through a repository into the mix and you can also use this principle for better design and run-time governance – It is harder to do that when tthe events (and messages) are owned by individual services (whether RPCed, or Pub/Subed
For instance most the most important business service in xsights was “Identification” or matching service (take an image and find out what it is). Within it we had quite a few services that make that happen for instance we had several gateways services (get an image by email, from a mobile client or from MMS, from 3G video call). All the gateway services, once they managed to extract the image from the source raised the same event – a “Frame Arrived” event, which held the image and meta data describing the image. There were also several services that listened for the event some of them like the matching engine were part of the same business service and some, like the statistics collection, part of other business services (you can read a little more about it here)
To sum this up – there are always several ways to skin a cat so, what I am saying here is not an absolute truth or anything. I do however think there’s a lot of benefit in decoupling the events ownership from the services that use them and making them explicitly part of the business processes and entities. At mentioned above this helps both the flexibility of the solution and the long term manageability (esp. as the number of events and services grow)
* illustration by shho
Arnon,thank you for the reference, however, I am not sure I follow you when you say the “events” are not owned by the service. An event is “the occurrence of a state”. A message event communicates an occurrence. Actions are generally responsible for state transitions, hence, new occurrences. For me, most transitions from state to state (some are automatic or time based) are triggered by an action invoked as an operation. The service boundary (and its operation) are therefore easily derived from the state diagram. With that model in mind, I am not sure what you mean when you say something like “Catalog” will own the events. Will the catalog be the target of these actions (such as submit order, cancel order,…)? Where is the service boundary in your model?thanks,JJ-
Jean-Jackues,
I mean that it is defined and managed externally to the services that produce it or consume it.
For instance if the underlying technology is WS-* you need to define the event in the XML contract of each service that will consume the event (since you’d have to make the web-service call); if you use other technologies you’d still need to know it if you are to parse it. Still they consumers are not the owners. You also have to know the event where you raise it – what I am saying is that the events should be defined externally of both in a “central” place
In the orders example you’d have somewhere where you define the “occurances of state” as you say for an order and then use those as appropriate by services that raise these events and services that handle these events
I’ll try to clarify that in the post
Ok, I understand and I agree. Having a registry of events is a great idea.
[…] explicitly, by using a concept of Event Subscription which translates one or more low-level AR events to one enterprise-level event. There high-level events are shared by all systems of the organization and are preferable governed by some central authority. […]