August 05, 2006
Re: Muddled definitions of services
After my recent back-and-forth with Bill on what the definition of a service is, the number of questions I'm getting has increased nicely. Keep 'em coming.
Bill follows up with some more specific questions on how one would go about implementing pub/sub, use WSDL, and how smart clients fit.
Hi Udi,
I want to thank you for taking the time to respond to my lengthy email in detail. Your responses have certainly helped better position these SOA concepts and terms in my mind.I have a few follow-up questions if you are able to take the time out of your busy schedule.
In the context of your response, would each “message handler” have its own WSDL definition? Or should a service be entirely defined by a single WSDL document? If it is the latter, then in the Microsoft world, would that not imply that the entire service functionality must be accessible via a single ASMX or SVC file?
Truthfully, I would stay away from ASMX, since it does it's own binding and dispatch. Rather, I'd use a generic soap listener (if I wanted SOAP) as an HTTP handler in IIS.
This question is more interesting when you ask what the WSDL file is used for. In essence, WSDL "binds" together several independent concepts. When using messages/messaging, there are no real operations, just messages flowing between endpoints. You could easily communicate this information without WSDL - XSD for the messages, and something else for the endpoints.
Why do I say "something else"? Since sometimes you'll want to have a message (say a response) returned to a different endpoint than the one you received the request on. This is known as the "Return Address" pattern. WSDL's binding of messages/operations to endpoints doesn't enable this capability.
If you think more in terms of queues than endpoints, a lot of the confusion goes away. Instead of invoking an operation on a web service, just drop a message in a queue. A service could have a number of queues that it can receive messages from.
I’ve sometimes seen an approach where a single message handler with a very generic interface route messages to more specific message handlers within the service implementation. This approach facilitates having the entire service’s functionality accessible through a single ASMX file and described using a single WSDL document – but seems to be a rather clunky approach. Would you consider this approach to be good practice?
Not especially - but better than the common practice.
I recently enjoyed your “Autonomous Services and Aggregating Entities” article in The Architecture Journal recently. I found your use of pub/sub message exchanges to publish data between services that share entities very enlightening. What is the easiest/best way to implement such a pub/sub exchange pattern on the Microsoft platform at this stage?
Well, easiest depends on what you already know, and best depends on a concrete set of criteria valid only for very specific circumstances. Let me just say this:
Current Microsoft technologies do not, out of the box, support queued pub/sub. You could implement pub/sub on top of current queuing technologies like MSMQ and Service Broker - I have. On the other hand, there are other vendors besides Microsoft that have worthwhile products. I'd keep an open mind.
The one thing I will say about this is that the common "subscribe" APIs out there aren't that nice. I proposed a diffent style that's more in line with the Message Handler pattern above on my personal blog called "Can Indigo be my bus?". I suggest you take a look.
One of the concepts that seems to be strongly encouraged is the use of one-way or pub/sub asynchronous message exchanges between services. Two-way CRUDdy RPC-style exchanges are discouraged. I strongly agree with this assessment in the context of one service communicating with another, but wonder how it applies when designing the interactions between a smart client application and one or more services that power it.
Many of the operations performed by a smart client application are CRUDdy in nature – specifically when dealing with “maintenance screens”, the sole purpose of which is to add/remove/edit/delete certain data housed in a service. There appear to be many cases where a request/reply message pattern is appropriate – such as performing a lookup or a search. In these cases, would you consider it acceptable practice to utilise a request/reply exchange pattern? Or would you leverage an asynchronous pattern in all cases?
I have a separate post up on smart clients and SOA here, take a look. But even between services there are times where you need interaction - meaning request/response. But there's no reason you can't do this asynchronously. This is known as the correlated request/response message exchange pattern, or duplex for short.
And finally, I was wondering if you might be able to recommend any books or other reading materials which you would consider provide a good practical discussion on the design and implementation of services in an SOA (I am about to purchase “Enterprise Integration Patterns” by Gregor Hohpe and Bobby Woolf).
EIP is an excellent book. I highly recommend it.
I thank you again for taking the time to help me out on these issues.
Best Regards,
Bill
--
Well, Bill, thanks again for your excellent questions. I hope that things are a bit clearer now.
If you too have a question regarding SOA or Web Services, don't hesitate to fire off an email to Blog@UdiDahan.com, and you can always check out my site for more in depth information: www.UdiDahan.com.
Posted by Udi Dahan at 12:31 AM Permalink
|
