THE SOFTWARE SIMPLIST

Web Services Wisdom.

August 2006

Our question this week comes from Eli who asks:

"Hi Udi,

Thank you for you insightful comments on SOA.

We are re-designing an existing distributed system, but now we want to make it based on SOA and messaging. And we want to make it simple :)

I really like the autonomous service and its scalability, and the messaging approach. It helped me see exactly what I want / need from WCF.

But, if we need a failover mechanism for a service, in a mission critical environment, then the model seems to break. IMHO, we need another layer / mechanism to route a message between identical autonomous services.

Can you comment on the failover / mission critical issue?"

Well, Eli, happy to be of service.

My experience has taught me that knowing what you want is half the solution. In the scenario you describe (which is really quite common), you’d want clients of the service not to be aware of the failover, while allowing additional servers to take the load. You could configure various messaging products to give you just such a solution – each being somewhat different from the other.

Using MSMQ in a cluster could give you the first part – clients continuing to work with the same virtual server. On the flip side, for scale out, because MSMQ doesn’t support remote transactional reads yet (will in the LongHorn timeframe) you’d need some kind of dispatcher to spread the load among available servers. However, all this is just infrastructure implementation – it doesn’t make any difference to the architecture or design of the system. Of course, at deployment time you’d want to have everything configured for optimal performance.

I hope that answers your question.

--

If you happen to have any issues with the architecture or design of your service-oriented solution, don't hesitate to send me an email to Blog@UdiDahan.com.

Posted by Udi Dahan at 03:40 PM  Permalink |

If you've been following this blog you'll know that my views on SOA usually do not "exactly" line up with those of the major vendors. It appears that IBM is continuing this tradition with their recent redbook "Patterns: SOA Foundation Service Creation Scenario". Right from the very beginning you'll see the difference in views, for instance, even in the definition of a service "A repeatable business task. For example, check customer credit; open a new account."

It appears that the prevailing views on SOA found in the red book are based on wrapping existing applications (see 1.1.4 SOA approach for building a solution). The main issue I have with this approach is that you, in essence, define you're new, supposedly business driven architecture on a portfolio of systems developed (again, supposedly) according to a technical driven architecture. I really don't see how this approach helps.

Of course you'll want to reuse existing assets in any new solution, but the solution itself should be designed and validated according to today's criteria.

Some of what's described reminds me of the problems originally encountered when Use Cases came out, but these same problems live on 'till today. The common anti-pattern "Use Case as a function" is exactly what these kinds of services embody. "Check customer credit" is, for all intents and purposes, a function. If you were to describe the system requirements with use cases, you might have a "Debit/Credit" use case. In SOA, have just that kind of service seems like a good fit.

Don't necessarily look to fit an entire business process into a single service, but if you can split up that process into several cohesive and loosely-coupled phases, expect each phase to be handled entirely in a single service. Moreover, when examining multiple business processes, if you find phases repeating themselves, you'll be well on the your way to a high quality Service Oriented Architecture.

Posted by Udi Dahan at 05:17 PM  Permalink |

Get it here.

In this podcast, we describe the service oriented analysis process that leads to coherent services that are strongly business aligned. Verification techniques are also presented which can point to poor service decomposition. Finally, we drill down and show how services can be decomposed further into “Business Components” and “Autonomous Components”.

Resources:

1. Autonomous Services and Enterprise Entity Aggregation
2. Autonomous Services Podcast
3. Ask Udi a question on SOA
4. Subscribe to the Ask Udi podcast
5. Visit Udi's blog for more information.

Enjoy.

Posted by Udi Dahan at 04:53 PM  Permalink |

Not so long after the announcement of SCA (that's service component architecture) came SDO (service data objects). These 2 concepts were hailed as the pillars of IBM's SOA strategy (which apparently includes buying any company with an 'S' in their name). To tell you the truth, I'm not sure what's the point of SDO.

To me it seems like standardization is taking one step too far and ending up in the application realm. These SDOs are supposed to be what's passed between services. In my book, that's just a message. You want standardization? Make JMS XML based, whatever that'll give you.

Seriously, the payload of these messages is entirely application specific. Besides saying that the payload can be transformed to XML, is there anything left to be said?

On the consumer side of these specs, I have to say that there is increasing confusion. Many take these specs as a form of guidance when all they're really about is getting the tools from various vendors to interoperate better.

Maybe it's all just a marketing ploy, with each company trying to one up the others with the number of specs that their products support. I wouldn't be surprised.

Posted by Udi Dahan at 04:50 PM  Permalink |

Our question this week comes on the heels of last week's podcast REST vs. Web Services. Dean asks:

"Hi Udi,

What are the reasons you are seeing a more generic API, rather than one that is more strongly typed?"

Well, Dean, glad you liked it. To answer your question, I think we need to say a word or two about what a service exposes.

In the API you mentioned, there are 2 elements in plain view, and one that's hidden. Those that can be seen are the message contract and operation contract, to use the terms Microsoft has coined. The additional element that isn't visible is the endpoint where the service exposes this operation.

When I said that I see more generic APIs evolving, I meant that the only difference between one operation and another was the message types, which led to a single operation supporting top-level message types - all request message types "inheriting" from RequestMsg, and all response message types "inheriting" from ResponseMsg.

This would be looser typed than exposing a specific operation for each pair of message types, unless the message types were part of the contract. No one said that the WSDL file is the only element of the contract. You could just as easily pass an XSD file that contained all the message types along with a generic WSDL file.

As to the endpoint, you could have all the service's endpoints support the same generic WSDL file, but have a different XSD file for each one - of course you'd have to pass this information along to anyone who wanted to use those endpoints.

Finally, I would say that I'm not seeing much done in terms of asynchronous communications patterns with Web Services. It's probably because WSDL just doesn't support pub/sub, or the Return Address pattern. In my opinion, for Web Services to bring the greatest value to organizations, they need to, at the very least, support the rich messaging patterns we've come accustomed to in EAI.

Posted by Udi Dahan at 06:39 AM  Permalink |

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,

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.

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:

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.

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 |

As people are absorbing the guidance around autonomous services, specifically the asynchronous communication aspects, questions about interactions with client software come up. I've been getting a lot of these questions recently. Before I dive in to the nitty gritty of smart client SOA development, I wanted to lay some foundations first.

If we accept the view that services are coarse-grained, business focused units, and that a service may be made up of numerous executables, windows and web services, and run on multiple computers, data centers, and sites - is there any reason that a service should not present an interface to a person?

Let's put down the baggage of Client-Server that we've been carrying around so long.

Maintenance "screens" belong to the service, as do all the requisite maintenance activities. It doesn't matter if they're part of a smart client, or just a web page, it is simply a part of the autonomy principle.

If these UI programs are part of the service, there would be no requirement for them to communicate using the same paradigm as external services, would there? Synchronous communication is perfectly acceptable within a service.

Let's now consider what functionality is left in the "smart client" once we've re-packaged, and re-distributed its functionality among the services that it communicates with. We'll find one of two cases:

1. Nothing's left. The smart client was all about maintenance stuff for various services. Done! Isn't that great.

2. Some business functionality is left. That's probably a good candidate for another service, don't you think? And once again we'd find the client "collapse" into the service.

3. I know I said 2, but there is another one that isn't very common or well known. I'll delve into more detail next time, but consider the case where the user/smart-client combo is a service in and of itself.

Until next time.

Posted by Udi Dahan at 04:44 PM  Permalink |