Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

A look at ''Service Design Patterns'': Q&A with Rob Daigneau

SearchSOA.com’s Jack Vaughan spoke with Rob Daigneau, whose new book Service Design Patterns offers solutions to common service design challenges.

Rob DaigneauRob Daigneau,
Slalom Consulting

As mobile, cloud and SaaS platforms continue to spread, enterprise architects and developers increasingly turn to Web services to meet diverse information needs. But when it comes to designing those Web services, things have changed. Development team leaders face difficult decisions as they ponder use of REST and SOAP in special cases.

Recently, SearchSOA.com spoke with Rob Daigneau, whose new book Service Design Patterns offers solutions to the most common service design challenges -- from how to create service APIs to addressing problematic latency. 

Rob has served in such prominent positions as director of architecture for Monster.com and manager of applications development at Fidelity Investments. He currently holds the post of application development practice lead for Boston-based Slalom Consulting. Both audio and an edited transcript of the Q&A follow.

Listen to the Q&A now:  Rob Daigneau talks about Web service design problems and solutions

It seems that one of the goals of this book is to provide a reference that codifies Web services designs and concepts. How did you go about that, and how did it pan out in the book?

That's exactly what it is: a codification and a reference. It's not meant to be read cover to cover, it's meant to be a book that, when you encounter a particular issue or problem you're trying to solve in your project, you can go look and see the different options that people have taken in the past to solve some recurring problems out there. It's a classic patterns book essentially presenting a number of recurring problems; the context in which these problems occur; the reasons why those particular problems are very difficult to solve; the things we've done in the past that may not have worked out so well; and then solutions that people find to essentially answer those issues. Of course every solution that we select has its good and bad, so we try to spell out the consequences here.

As far as how I went about getting there, first was the identification of what the focus of the book should be about. I started with looking at things from the larger SOA perspective, but over time I decided that was an area I would leave to others. Instead I thought I should just focus on how developers implement Web services that might be use within SOA. It involved tons of research, reading lots of specifications, talking to a lot of people out there, and also experience with my own teams that I've managed. It was essentially seeing how people solved these problems, noting them down, sorting them out and organizing them into what you see in the book. One of the things I wanted to do was show that there are a lot of common approaches between the folks that still use or ascribe to SOAP/WSDL and the folks that implement RESTful services. I try to show a common thread that goes between all of them.

Can you give a view on some of the Web service API styles that are discussed in the book, and show that one size does not fit all?

Absolutely. So the book starts by identifying three API styles that we may choose from. These are very much driven by the context in which the services are used. So the first I call RPC APIs, and RPC is short for Remote Procedure Call. The second is called a message API—some people refer to this being the document API. And the final is the resource API. A resource API is quite often used by those who follow the REST school of thought, although not all resource APIs are RESTful.

So the first approach—an RPC API—is probably the one that most developers out there are familiar with. It answers the question, “How do clients execute remote procedures over a CDP?” And in this approach essentially we create a service with an external interface that’s derivative of some procedure out there which is hosted on a server. So we can find messages and identify within them the remote procedure to execute. And they also have a few sets of elements in that message that essentially map directly back into the parameters of the remote procedure. So as you might guess, this can create a rather strong coupling between the client and the service.

That all being said, most of the tools out there support this style quite well. We’ve gotten over a lot of the hurdles for cross-platform interoperability that you would often see, for example, between .net and Java servers out there. So it really speaks to a style that is promoting faster development. It’s very productive, but the downside is a strong coupling.

Then the next style, message API, really tries to break that coupling apart a little bit more. So here we may be sending commands, notification or other sorts of information over the network to a service while avoiding the direct coupling to these remote procedures. In this case, rather than creating some service with an interface that is derived from the remote procedure we say, “Well let’s just create an interface that stands alone. And the messages should carry all the information as required about a particular topic, a task to execute, events, things of that nature. And when this message is received at a particular URI, the service will interrogate the content of the message to essentially route it to the correct handler.

So there really is a level of indirection between the service and the actual procedure that’s executed. Now, that really promotes independent evolution between the client and the server—quite a bit more than your RPC API style. But, as you can probably guess, it requires a lot more skill. You have to really kind of understand some things at a lower level. You may you SOAP and WSDL, you may not use SOAP or WSDL—which is probably the most flexible approach. So the time to development might be a little bit longer than your RPC style but, again, it promotes evolution quite well.

And then the final style we have is resource API, and here what we’re trying to do is much of the same sort of thing—we want to call some logic on a remote system but really avoid direct coupling to remote procedures and minimize these domain-specific APIs. What I’m referring to there is creating messages that identify procedures to call, that really kind of name the request message and response message. What I mean by that is, for example, in the RPC style I may have to create a message for each request and response for a particular activity…

So as you can imagine in a domain of any significant size we could just have a real plethora of messages out there that we have to maintain. And the larger number of messages we have out there, the more coupling there is. So the resource API says, “Let’s think about things a little differently. Let’s assign all procedures, domain data, files, even transactions, a unique URI. Then we can leverage the existing HTTP protocol to define the standard service behaviors…"

Now we can exchange information by taking advantage of this application protocol stack and then, where possible, use standardized immediate types and the status codes of HTTP to communicate. So it’s a very flexible approach, but it’s one that kind of looks at the world differently and doesn't usually utilize this unified service descriptor—for example, WSDL—to say, "Here's all my service operations, and all the messages going in and out of some problem domain." Quite often these contracts are defined outside of the service itself. It's a very different way of looking at the world.

Follow us on Twitter at @SearchSOA.

This was last published in February 2012

Dig Deeper on Microservices pattern, platforms and frameworks



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.