This post is about service semantics and how to be “liberal in what you accept” in your service-oriented architecture implementation. Let me start by defining that in this post the term "service" is used for a specific business capability that can be composed and reused in different business processes. I.e. the idiom “service” used here is representing a building block business capability. This is not to say that a service equals a single business process step, it just makes it easier to talk about the topic of this post (which is not BPM): semantic covenants.
A service has a defined contract, but also some implied semantic. The semantic is hard to express through the contract, and the business compositions that utilizes (consumes) the operation can only assume that the service is a covenant, i.e. that the service will do B when provided with input A. Having semantic coupling is just another type of coupling that prevents services to be truly loosely-coupled and that will cause a breaking ripple effect through all consumers of the service when the inevitable thing happens: change.
There is some thinking in the SOA community that to avoid this ripple effect caused by a service contract or semantic change, it is up to the service to do the right thing independent of the information provided by the sender of the message. That is, that the service should behave as if the consumer is always right, and adapt its semantic to suit the sender.
A service can do no such thing, as it is an actual representation of a specific business capability. The capability does what it does, i.e. a credit check is just that – a credit check. It must be up to the business composition of the services to interpret the real-life events that have occurred and their context, and then invoke the right set of operations. Note that the service should still be liberal in what it accepts (message duck-typing), as it is the business event that is important, not the format of the event message.
It is easier to recognize that the service is always right when you think of messages as representing business events and apply EDA thinking such as publish/subscribe instead of a habitual SOA command and control pattern. A service will then subscribe to business events that must trigger the business capability, but the service need not know who the publisher is. Neither need the publisher know who is listening for the business process state changed events (event topics). Thinking in service “consumers” is very connected to having a request/reply, command and control style SOA.
To simplify the “service is always right” notion, let us call the publisher a “consumer”. The consumer can send any message (business process event, context and state; mail-order analogy) it likes, as it is the publisher. However, as the consumer does not know who the subscribers are, it cannot know or depend on the services having specific semantic. The service cannot depend on who the publisher is, it just accepts that a business event happened that it must process. A business event message never specifies any handling operations, the logic to decide how to handle the event is part of the mechanism that routes messages to services. This ensures that the autonomous and loose coupling tenets of SOA are fulfilled.
When you apply EDA style thinking to service orientation, you’ll see that the service is always right. There cannot be any traditional “the consumer is always right” in relation to service semantic, as the services have no request/reply consumers.
Alas, still the consumer can still be right; it is just the responsibility of the process composition mechanism to accept what ever messages (events) the consumer (publisher) throws at it and invoke the applicable service operations. It is the business process composition mechanism that has to be the semantic covenant.
PS! Note that I have deliberately used the term "composition" here and not even mentioned using an ESB or BPM to implement this. The semantic covenant composition mechanism can simply be implemented as a mashup (composite application) instead of a composite service or an orchestration/saga.
4 comments:
Does your semantic covenant concept apply at all layers of the service model, or just at the 'business activity' layer? (Assuming Shy Cohen's taxonomy).
I ask because it appears that you are viewing the world as having two types of SOA objects: composers and services. The composer being an orchestration or a workflow, while a service is a step in a business process.
I'd suggest that there are many levels, and they have different covenants and interrelationship constraints. Things that you can do at one layer do not make sense in another layer.
I like your concept and I agree that the publisher of the event is right, as long as the event is a recognized and shared business event. In other words, as long as we all agree on the semantics of the event, and the publisher of the event is constrained by that agreement, then the subscribers will not need to be coupled to the particular publisher.
The atomic business function delivers a specific business capability; and thus it cannot be a semantics covenant, it just need to be liberal in what it accepts (different message formats). By semantic covenant ("if you send me X, I will do Y") I mean what Jack van Hoof calls a condition in his post How to implement a loosely coupled process flow (EDA).
As I see it there are two ways of implementing the covenant logic, either in a capability service that aggregates the "building block" capability services (see Arvindra Sehmi and Beat Schwegler's capability models - level 3 and below) or in an orchestration layer. The former is kind of hardcoded command-and-control-style SOA, while the latter is more event-driven publish-subscribe style SOA (EDA). Both ways are allowed, it depends on how agile the composition needs to be and/versus the cost of changing it.
Thus, I think that this concept applies to both the process and activity layer of Shy Cohen's taxonomy, while the entity services should be considered atomic.
Why do you say, "but the service cannot know who the publisher is"? Couldn't Source_System be an attribute of the message and cause a differentiation in the treatment of the message? FWIW, I agree that it won't directly know any consumer.
Yes, "should not need to know" is the point, as the service implementation details being based on who the message publisher is would create strong coupling between consumer and provider.
Post a Comment