1. Rob, what you’ve been up to lately, what you’ve been doing, what you’re working on these days?
Eric: Hello, this is Eric Newcomer at QCon New York 2012, I’m here with Rob Daigneau to talk about web API’s, to talk about service orientation, service oriented patterns, Rob’s got a new book out, he is speaking here at QCon, I can definitely recommend this book, by the way, having read it, so it’s really good for information about service design patterns, but first let’s start with a little bit about you, Rob, what you’ve been up to lately, what you’ve been doing, what you’re working on these days?
Rob: I’ve been in the industry for probably for 20-something years, I’ve seen a lot over the years, most recently I went back to independent consulting, and I help clients design SaaS type of applications and products that can be used for internal consumption, or in B2B and B2C scenarios. I also help teams become more effective and more productive in what they do.
Eric: So that involves a lot of work on the web and with service patterns I suppose.
Rob: Absolutely.
2. Rob's book "Service Design Patterns"
Eric: So the book would’ve come from that some of this experience that you’ve had.
Rob: Oh, yes. So, all patterns types of books essentially come from observing the world and what people have done out there and the solutions they’ve used to solve recurring problems. Everything that you see in the book is essentially something I’ve seen out there in the wild and encapsulated into the catalog.
Eric: What got you going on writing a book, what was the motivation there, the origin of that whole project?
Rob: The truth is that a request came to me out of the blue from Addison Wesley, they’ve seen some of my writing in the past and they thought I might be a good writer for them so then they said “why don’t you come up with an idea” and I was intrigued by the problems we’ve been having in distributed systems engineering and integration throughout the years and the whole web service genre of designing solutions was really appealing to me and I saw it taking off in a different direction so I thought maybe there is something there and there is a catalog of patterns that we might be able to put together, develop a vocabulary for.
Eric: That whole area seems kind of ripe, now that it’s maturing a bit, for somebody to define some of the common patterns or get them down on paper?
Rob: I would agree and that’s the thing, when it comes to a pattern sort of book, we are not inventing something new, we are just out there, cataloguing, observing, codifying things that people have already done, giving them a name and helping people essentially understand the decision points. So it’s not a book on how to create a web service, how to use a particular API, whether it's, I don’t know, JAX-WS or JAX-RS or WCF for that matter, it’s more about the decision points and the things you’ve got to consider when designing your web services.
Eric: So it’s really a design type of book like most patterns books are of course. Can you give us a couple of examples of some, maybe what you might consider the more interesting patterns or one of the more challenging patterns to think about?
Rob: One of the more challenging patterns? If I may take it a slightly off in a little direction, I’d start with probably the most fundamental decision points for any web service designer which is trying to figure out what sort of API you should create. So it came to me, after looking at what a lot of people have been doing over the years that it really kind of boils down to three API styles. We have the RPC API, we have more of a message API, some people call it a document based APIs, then we have what is probably newer and taking on a lot of popularity out there, is the resource API, which often times exhibits the characteristics of REST.
Eric: I know after just having worked in a large IT environment recently that there is often a long debate, is messaging the right thing to use, is RPC the right thing to use, what about this REST stuff, does it make sense, is it too weird and new and different? So tell me a little bit about how your thinking sort of went along the lines of, if you were talking with someone or writing the book about, how to think about these things, how to think it through, make the right choice for a given application or given environment?
Rob: I think a lot of it depends, of course every design decision depends upon your particular context, what is the problem you are trying to solve, what is the context of your environment, who you’re interacting with in the case of web services, of course, what the clients are and what your constraints are. So when it comes to something like an RPC style, I think that is probably the most natural for a lot of developers out there today. People think in terms of procedures and the tooling thus far has made it incredibly easy for people to create web services that simply expose these remote procedures. But with that comes a lot of downsides, you have a lot of coupling out to the clients.
So some people have taken that another direction, they try to loosen up the coupling, by not tying the message definitions in so tightly to this remote procedure that might be processing the request, so to that end we use something like a message API. But that means you are going to have to code a fair amount more, they are more complex to create. So there is that tradeoff, productivity, ease of development versus loose coupling. And then we have the resources API, which is a very different way of thinking about services, compared to the first two styles, where we put some logical entity front and center in your domain and then we think about the actions that we perform against that service. So that’s where we get into URIs and leveraging, HTTP and uniform interface to essentially achieve the same ends. But we really have to kind of invert our thinking from this verb-noun sort of approach, get customer, we have to think about customers and entities first and then the actions.
Eric: Right. I remember years ago starting to work with a RPC and it was really a programing model, it was “how do I get my subroutine to be remote when I’m still going to program it the same way in my program and my code, it’s going to react the same way as if I were calling a local routine and then it would be remote”, but as we know over time these remote characteristics have become sort of less transparent than the designers may have imagined it would be initially, and then you would get the messaging which was on the other hand very explicitly, packing the data into message and putting that message on the wire getting it off, there were all these trade-offs and debates among the two, but now as you said there is another way to do it that’s coming up, and I would say that is representing the future but I think there is really a lot of IT environments that are still way in the past with RPC and messaging, sort of pre-web/post-web demarcation line you might say, if you have the good fortune to have developed your IT systems after the web, you’re probably naturally using REST, if not you’re using some of these other things . What’s the guidance, what do you tell people about this whole picture and how do you get from one to the other?
Rob: Again there are trade-offs in each approach. The RPC approach has more tooling out there but at the cost of higher coupling, which means the pace of change is probably going to slow down. And it doesn’t scale so well to larger environments like internet scale. A lot of companies insist when they do B2B types of integration that that is still the only way to go. That or message APIs. But if you want to loosen up the coupling to your procedures, I think the only way to go is resource APIs. I’m a big fan of that approach. Again, it’s a paradigm shift; you have to think about the way you are going to provide the same capabilities a little bit differently. The tooling isn’t there as much as it is for the older styles, and in fact some things are completely missing and on purpose.
With resource APIs we typically don’t see service descriptors. And an example of that being WSDL, where we have one document that defines all the operations a particular URI might take in and the message structure and such like that. With the resource API we kind of do away with that, because in most cases it’s not even necessary. What we might call the service contract is already defined to large extent through RFC 2616, the HTTP spec, the status codes that are listed there as well. The stuff that you have to manage is the definition of the message, the representations that is, and the URI patterns that you use to address the different resources in your domain.
4. More Service Design Patterns
Eric: Let’s get back a little bit just more to the topic of thinking and conceptual approaches because I think you are right, when you approach a new technology or a new pattern or a new way of doing something, the first thing you have to do is get your head around it and understand what it is, and how it applies and why to do it. What are some of the main categories of patterns that you’ve got in the book there?
Rob: Sure, well, I have to open this up because I haven’t got it completely memorized, I wish I did, but a lot of times you will see pattern authors do, they’ll organize the patterns in such a way that they can be easily referenced. And the patterns that go into individual categories have a particular theme. There were classes of problems they were trying to solve so we’ve been speaking about the most fundamental one which is the web service API styles.
That I think is probably one of the most critical decision points because once you choose a particular style you’re kind of married to it. It’s very difficult to move off that one style on to another. The next category has to do with client service interactions. So here we are talking about how a client and service talk to each other. Of course the most fundamental we are all familiar with, request- response. But we can start doing asynchronous sort of communications with our services as well.
Eric: We see a lot of that now with AJAX, JavaScript, Web Sockets.
Rob: Sure, some people would say that web sockets are not RESTful, but I’ll save that for another, and it “ain’t the web”, as Jim Webber would say. So the next category anyway, client service interactions we have what I refer to as request/acknowledge, where a service can actually take in a request and provide some of the acknowledgement back to the client saying “I’ve got your request, I’m going to take care of it, I may or may not get back to you”, but that’s a way of achieving asynchrony. Beyond that, within that same category, we have things like media type negotiation, which is a type of content negotiation, and also a concept called linked services, where rather than having the client have to keep track of all the different URIs and web addresses it needs to call, and know how and when to call each of them, the service itself in its responses provides information that helps the client choose.
Eric: This is the famous “hypermedia is the engine of state” paradigm that needs to be considered and often in REST sometimes the most difficult part in terms of people explaining and understanding something new here.
Rob: Yes, and according to Fielding’s definition, you’re not doing REST if you’re not doing things with hypermedia and links.
Eric: Absolutely, we don’t need to get religious but I think it’s good to make a point that it’s a very important aspect.
Rob: It is. What I found interesting is you can still do that concept with the other API styles it just doesn’t come as naturally to people.
Eric: Right, not baked in from the beginning and so on.
Rob: So let’s see, other categories we have here. There are ways to manage the request and response, so once you’ve crossed that threshold into the service itself, there are ways to deal with the routing of the request through the service controller, ways of essentially decoupling your domain model from your request and response messages, that’s the classic data transfer object, and ways of handling different variants request and responses and that you do with request and response mappers. Three more categories I have here: different ways to implement the web services, the most natural way I think a lot of people are going to take, especially when they are just cranking out the code, got to meet a deadline, is the user transaction script. Now these essentially a repeat on what you’ve seen in Fowler’s book on Patterns of Enterprise Application Architecture.
I had a different name for it and he was like “no, that’s transaction script”, so I went “ok, Martin, I’ll change that”. So we can put all the code right there, of course, if we do, we stand the chance of having a lot of duplicate code. Another approach is to use what I refer to as being a data source adaptor, there is a fair number of tools out there which allow you to essentially take a database, generate out from that a domain model, and then with a few clicks of a button essentially serve that up through a service, which is really interesting and cool, very productive, but I think the downsides to that approach are apparent. Very tight coupling for the client, so whenever you want to change your database or your domain model, it will ripple straight out to all your clients and if they want you to change something, likewise back in the other direction.
Other things we might consider here, operation script provides a way to essentially put a façade over our domain model where the service itself is typically delegating the work into the domain model, receives and requests, unwraps them and maps them into operations of your domain model. Command invoker, if we want to have the opportunity to further reuse logic from a given service, and this may be for cases when I have let’s say multiple APIs styles for given logical operations, I may have clients that prefer an RPC style, others that prefer resource APIs style, I don’t want to duplicate that code, I can wrap it up in a command and then execute it, and even have that operation deferred to some other time, I can enqueue that command and finally we have what I refer to as being a work flow connector.
So sometimes these services tie directly into work flow engines or orchestration engines to do things that are more complex across a number of services, your idea of service composition.
Eric: Sometimes you just need to design specifically for that or to make the right trade-offs.
Rob: Yes.
Eric: Services seem to be everywhere today, we’ve seen quotes from Amazon’s founder even, Jeff Bezos, saying that everything had to be service oriented in Amazon, I just came out of an environment where SOA services were very important, we hear a lot about components, modules, the way to design and architect systems. I think services is probably a good general word to use for what’s going on in the industry in terms of trying to break the problem up into manageable pieces that can be composed into larger pieces of functionality to applications. And in the different ways that you talk about, I think it’s very important to consider those different ways when designing and building those systems. But something I do have to ask you in that context is about SOA, you used the word services but you haven’t said service oriented architecture yet, I certainly know what I would mean by it, maybe you will say the same thing, but can you tell us a little bit about the relationship of the services design patterns to the SOA, generally, what your view of the relationship is there to that SOA?
Rob: It’s kind of an interesting history with respect to the book and my take on SOA here. It originally started as an attempt to codify design patterns for SOA and the more research I did, and the more I spoke to people, frankly, the more I came to not understand what SOA is, there are so many definitions, if you talk to three different people you get three different definitions, I thought your definition in your book was wonderful, by the way.
Eric: Thank you, I wasn’t fishing for that but I’ll take it.
Rob: I’ll give it to you. So for example in your book, not that I need to remind you, it became very clear that SOA can be thought of as more of a methodology that covers the design, the creation and the management and governance of these entities we call services, from the beginning of their life span through whenever we decide to retire them.
Eric: Right, that’s the way I look at it, and again I really wanted to get your view on this question.
Rob: Well I thought that made a lot of sense to me but then I heard some other definitions too. And I liked that definition. There’s the one from OASIS, which I won’t bother repeating for people but it’s a bit abstract.
Eric: I think they got it wrong.
Rob: Yes, and then in the Microsoft world a while back, I think this is largely been there is this thing about four tenets, which again I won’t bore the people who are listening, but it really didn’t help us to understand what SOA was. Some time back Martin Fowler wrote a blog on service oriented ambiguity, and that really rang home to me, because in my initially research and the writing of the patterns, I just came to say “this really is kind of still vague to me but there is something that still kind of makes sense” and that is the utility of services and especially with respect to web services that is those that use HTTP, either simply as transport or the full application protocol, as is the style for resource APIs, there is something really good there.
And we now have it easier than ever before to share business logic and data to integrate our applications, and again, we’ve solved real world problems, I decided to go with that and my final decision was “now I’m going to side step the whole SOA thing”. So the patterns in the book can be used for you to make real systems, to do integration and maybe it’s going to help you create a SOA, whatever that means to you, but I decided not to try to redefine it, try to clarify it, I kind of went in a different direction.
Eric: Well, speaking of different directions, Rob, what’s next for you, what’s on the horizon, you’ve mentioned I wrote a book, I know personally how much effort it is and it’s a relief to have it out, you said it’s been eight months now so you’ve had time to think about what’s next, what you want to get involved in next, what’s the future?
Rob: Well, obviously I think there are more areas to study in the domain of web services, we can drill down into how we scale these out, how we can insure they perform well over time, fault tolerance and availability patterns, I thought that was just too much to put into one book. But I think what is really intriguing to me it’s that we are now entering a phase where web services are just kind of the norm and they are being used everywhere.
Eric: You mean in the generic sense of web APIs, I guess.
Rob: Yes, so there is this intersection between the cloud, services and mobile that’s really intriguing to me, to see what’s going on there and how those different concepts are playing with each other.
Eric: One of the things, one of the reasons we were pursuing and I was pursuing in particular the SOA design approach at Credit Suisse were I was working, was because I felt very important the modularity aspect of it, very important to prepare for cloud computing. I think the biggest challenge, and this seems to be well understood in the financial services industry, is how to get the application from where they were, how they are currently designed is this bespoke model, into modules that are suitable for cloud deployments into virtual machines. The virtual machine abstracted the environment of the cloud and we probably don’t need to debate the cloud too much, I probably didn’t get that right, but the question is how do we get the applications ready for those cloud based deployments?
Rob: That’s a pretty big area of study I think. Obviously I think don’t bite off more than you can chew, start small, think about some logical area that is called a low hanging fruit, that’s something easy to pick off, small and that you can take for a test drive. So assuming you can identify the use cases, I don’t know how you’re interacting with these, you’re talking about components?
Eric: We were trying to look at functional components to match functions that the business would perform for trading functions or risk analytics, reference data operations, these kind of things, we were trying to map functions to services and create components on general bases.
Rob: Again, you have to think of how you look at the world, is it more your RPC style, your message style or your resource style. If you do feel comfortable with the resource style, I would certainly recommend that, especially if you’re going to deal with mobile apps, I mean the whole RPC way doesn’t work so well with mobile.
Eric: Right, I agree, I was telling them the same.
Rob: And with resource APIs, they really are just a natural for the cloud. So, your typical analysis, start with your logical functions, what are your use cases, and again they are going to typically take the form of verb - noun, get customer - update customer, and then turn that around, think about what the logical entities are, that you want to match, those become your resources, then think about the actions you want to perform in them, and then you can map the HTTP methods to them. Then you think about the URI patterns that you might want to be using with them. And again, keep it small, and you can do a test drive, move those logical functions out to a cloud perhaps, and possibly even use those same components on the other side of the service.
So essentially your resource API is still delegating to those existing components, so it’s less disruptive. Of course, you’re still going to have to worry about what the dependencies are between those underlined components and some persistent data storage or other resources you are going to have to get at and whether or not that information is even accessible from where you are trying to move it off to.
Eric: So it’s always good to pick a meaningful starting point, I like that, it’s really good advice. I think you’ve got about the end, so I want to say thank you very much to Rob Daigneau for talking with us today here at QCon New York 2012 and look forward to the rest of the conference. Thank you.
Rob: Me too. Thanks a lot, Eric.