When implementing the business logic within each of our services, it is important to get the communication infrastructure abstraction correct such that we don't have a leaking of communication concerns into our business logic.
We need to define which concerns relate to the transport of a message from its source to its destination, and which relate to the business logic of the service.
One concern which should be handled by our communication infrastructure that we often find embedded in our business logic is addressing. It is not uncommon to see implementations where the service consumer creates a proxy as a means of communicating with the service:
MyEndpointProxy proxy = new MyEndpointProxy();
DoSomethingRequest request = new DoSomethingRequest();
proxy.DoSomething( request );
Although the endpoint address in the above example is not specified in the code (let us assume it is specified in an external configuration file), we have still bound ourselves to the assumption that MyEndpoint is the logical endpoint that should receive the DoSomethingRequest message.
Although this fact is exposed in the contract of the service producer, the problem is that the service consumer must choose the logical endpoint to receive the message. As such, the structure of the service producer is now influencing the implementation of the consumer. If we were to update the structure of the producer, we would have to update its consumers. This is coupling we would like to avoid.
The solution here is to push this addressing decision down to the communication infrastructure. The business logic of the application provides only the message and mode of communication (send vs. publish). The infrastructure then, based on the content of the message determines which endpoint(s) should receive the message.
Content based routing is generally performed based on a rules engine. XPath is a common strategy employed to determine the destination of a message based on its content.
Now if we update the structure of our service producer, all we need to do is update the routing rules and everything continues to work. We do not need to update the implementations of any service consumers.
Saturday, March 29, 2008
Content Based Routing
Labels:
content based routing,
SOA
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment