Your Garage botysf16 Amazon Fashion Learn more Discover it Songs of Summer Fire TV Stick Subscribe & Save Patriotic Picks Shop-by-Room Amazon Cash Back Offer AllOrNothingS1 AllOrNothingS1 AllOrNothingS1  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Introducing new colors All-New Kindle Oasis AutoRip in CDs & Vinyl Segway miniPro

Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

VINE VOICEon November 12, 2011
I have been a fan of the Martin Fowler Signature Series for a long time. This book fit into the series great and filled in a missing link in the series.

One of the things I liked seeing was that the author does not think web services are a silver bullet. Right off the bat he warns that web services should be reserved for situations which out-of-process and cross-machine calls "make sense".

The book is broken down into seven chapters, an appendix, and a nice glossary. The chapters include From Objects to Web Services, Web Service API Styles, Client-Service Interactions, Request and Response Management, Web Service Implementation Styles, Web Service Infrastructures, Web Service Evolution, and an appendix Reference to External Patterns.

I felt the book worked at the right level of abstraction digging into details when needed to shed a deeper light on the subject at hand.

Each chapter contains several related patterns. Each pattern answers a primary question. For example chapter one Web Service API Styles cover the following 3 patterns that answer the question that follows below.

RPC API - How can clients execute remote procedures over HTTP?

Message API - How can clients send commands, notifications, or other information to remote systems over HTTP while avoiding direct coupling to remote procedures?

Resource API - How can a client manipulate data managed by a remote system, avoid direct coupling to remote procedures, and minimize the need for domain-specific APIs?

The other patterns covered in the book include Request/Response, Request/Acknowledge, Media Type Negotiation, Linked Service, Service Controller, Data Transfer Object, Request Mapper, Response Mapper, Transaction Script, Datasource Adapter, Operation Script, Command Invoker, Workflow Connector, Service Connector, Service Descriptor, Asynchronous Response Handler, Service Interceptor, Idempotent Retry, SOA Infrastructures, Breaking Changes, Versioning, Single Message Argument, Dataset Amendment, Tolerant Reader, and Consumer-Driven Contract.

Like the other pattern catalogs the book contains an online catalog of the patterns in the book. Although the online catalog gives you an overview of each pattern, the book contains a lot more detail about each one. I like the online catalogs. I often visit them to spark my memory about the patterns that I have read about in the books.

I like that the book limited its scope to the fundamental patterns relevant to web service design. It does not try to be all encompassing, which I think made it better than if the author had tried to be. The book does not cover enterprise integration patterns, workflow or orchestration, security, event-driven architecture, or choreography. The book does include a nice reference to external patterns in the appendix that provides a summary and where to go for more information.

I think each pattern is explained really well and the examples used do a great job of showing a possible implementation. I liked the end of chapter 7 where the author provides a nice summary about how each pattern hinders or promotes evolution.

The book also includes a nice glossary that provides quick reference to additional information on topics mentioned in the book.

The author does an awesome job of providing examples in different technologies throughout the book. The author uses a nice mixture of .NET and Java technologies. Some of the technologies used are JAX-WS, JAX-RS, JAXB, JSON, XML, Xpath, XSLT, WSDL, DataContractSerializer, XmlSerializer, and WCF. To top it off the author's writing style makes the reading really easy.

All in all I think every architect and developer should have this book on their shelf.
0Comment|37 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 7, 2012
I found Service Design Patterns to be a refreshing and well-crafted book. I would expect nothing less from anything accepted into the Fowler series. The author is quite clear from the very beginning that this book is intended to get the reader familiar with the most common approaches for implementing services. At first inspection of this statement, I expected to read lots of problem statements, with pattern definitions, and code samples to follow that mapped directly to SOAP/WSDL and REST. I was pleasantly surprised.

In the pages of the very first chapter this book challenges your standard thought on Service Architecture. Over the years I have asked many colleagues why they think SOA is a superior architecture. Often I have received the response that it reduces complexity, provides loose coupling, and is the most reliable way to allow disparate systems to communicate. Naturally, the next question is, well how are those objectives met? That question tends to put a wrinkle on the face of some of the most seasoned software architects. This book presents those questions, and paints candid responses before you get to page 10.

As you advance through the chapters, the author did a great job at codifying various approaches to web service design in a way that's not specific to any particular technology or specification. The pattern descriptions are easy to read, help the reader understand how to choose between them and the contexts in which to use them. The book provides an easy to reference handbook that classifies the patterns into categories that really make sense, and I think it gives practitioners a very useful vocabulary. Although the title says it's about creating services for SOAP/WSDL and REST, it's not a book about either. I am glad the author took this approach as there is plenty of material on both of these subjects. It might have been helpful for the author to address this up front.

Long story short, this book does a nice job of bridging the gap between Patterns of Enterprise Application and Enterprise Application Architecture. A nice reference book.
0Comment|19 people found this helpful. Was this review helpful to you?YesNoReport abuse
on December 27, 2011
SUMMARY: This book might have presented some interesting topics and patterns for discussion and debate, but it is far from an authoritative patterns book. It lacks "The Narratives" in PoEAA, while the patterns in it lack the usefulness of those found in EIP.

When I saw this book on the Amazon, I purchased the printed book straight away without having had a quick read of the book, say from a pdf you can download on the Internet, since I really enjoyed reading the other two pattern books in the Martin Fowler series, i.e., Patterns of Enterprise Application Architecture (PoEAA) and Enterprise Integration Patterns (EIP).

It turns out to be a disappointment with this book.

Why? First, with the other two patterns books, in some cases I learned/relearned some core concepts of Enterprise Application or Enterprise Integration, while in other cases I learned some best way to describe what I had already learned from experience. Unfortunately, That has not been the case with this book about SOAP based Web service or REST Web service, except "situations in which out-of-process and cross-machine calls 'make sense'" (page 8).

Second, the patterns in the book generally try to prescribe what industry has been actually doing (often using a different vocabulary). The problem starts when you try to have a more clear understanding of the patterns by reading the examples for the patterns and by trying to make a connection between the patterns and actual SOAP or REST implementation technologies.

Take chapter 2 Web Service API patterns as an example. After reading the three patterns (RPC API, Message API and Resource API), you would think the SOAP document/literal wrapped style or SOAP RPC style are typical implementation of the RPC API pattern, SOAP document/literal bare (unwrapped) or POX as typical implementation of the Message API pattern.

No, not according to the explanation the author gives for the examples.

This is how the author explains the difference between RPC API and Message API (page 31), "Notice that each operation receive a single message argument. This is one very subtle characteristic that differentiates RPC APIs from Message APIs. While the former ..., Message APIs that leverage WSDL are specifically designed to receive a single message argument". But when you turn to page 234, there is actually a Single Message Argument patten for RPC API. What does the author really try to say? Convert RPC APIs to Message APIs by using the Single Message Argument pattern? :-)

Another peculiar in the book is to associate "Service Interface Classes" exclusively with generated service interface code in the contract-first approach (page 179) and describe the code-first approach as "In the Code-First practice, developers create annotated Service Controllers in languages like Java and C#" (page 180). While in reality, for RPC API and Message API, the widely used and more sound practice with code-first is to create annotated "Service Interface Classes" in Java or C# first and then write Service Controller that implements the interface.

There are definitely some good sections/patterns in the book. The sections/patterns I found beneficial are: Resource API (page 38), Request - Acknowledgement (page 59) and Asynchronous Response Handler (page 184).

Overall, this book might have presented some interesting topics and patterns for discussion and debate, but it is far from an authoritative patterns book. It lacks "The Narratives" in PoEAA, while the patterns in it lack the usefulness of those found in EIP.
55 comments|41 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 4, 2012
This book discusses many of already commonly used patterns in the industry concerning web services. Each pattern has code examples, and the nicest part is the very reasonable "Considerations" part, which has a list of items to consider before using any of the patterns.

However, if you have been working with web services for some years and have kept up with the changes and trends, you will not necessarily learn much from this book. It's not a long book, so it may be worth your time reading it to fill any gaps in your understanding of web services. For anyone new to web services, though, this is a must read to understand the common patterns before moving on with any trendy way of doing things.

Also, this book is an attempt to formalize many of the patterns that the industry already follows - at least I've seen many companies following them in a way or another. It is good that we all have the same terminology, but on the other hand, it doesn't really get into a lot of details of each pattern, so the the reader needs to research further if s/he wants to deepen his/her knowledge. For each of these patterns - just like in a recipes book - the author gives an example (either in Java or C#) and he was able to keep them short enough but focused on the patterns he wants to show.

From my own experience, these are some patterns or areas I'd include in the book to make it more complete:
- Client-service interaction: long polling. Other than a regular Request/Response, nowadays you see services with long polling, which can be a quite important pattern to use depending on your use case. This pattern has been out for so many years that I surprised not to see it in this book.
- Service Interceptors: this is a really important and probably can be a book of its own, but I'd love to see more patterns on how certain things like exception handling and validation could be done and pros/cons of each approach. Oftentimes these are areas that many service developers get wrong and having patterns here would help steer them into the right direction (rather than realizing later the mistake). The author touches briefly on them from a high level, but there are different ways of the doing the same thing, and it deserved a little more attention in my opinion.
- Operation concerns: typically if one has a service, it tends to be a system that is supposed to be highly available, so service developers want to minimize downtime. For that, you must have a "devops" mindset to know where to put the right logging, where to log metrics for performance, in what places to log errors, how to handle log files. There are so many pieces of advice around operations - but unfortunately I did not find a book on them yet, so developers still need to learn from practice.

Last but not least, note that this book doesn't talk service architecture. It doesn't get into details of how to architect the service, including scalability, reliability, etc. You would need to find other option for that.
0Comment|9 people found this helpful. Was this review helpful to you?YesNoReport abuse
on November 22, 2012
I've enjoyed several of the books in the Martin Fowler series - and was predisposed to have a very positive impression of this book, before I even opened the cover. However, one point is worth noting:

There is value here - however, the short-shrift / sparsity of discussion given to RESTful web services - even though it is quite visible in the subtitle of the book's name - left me, as a consumer, feeling a bit cheated. Perhaps a much better value for money spent, could be Thomas Erl's 'SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST' - at 624 pages, versus the 352 in this book (although 268 would be a fairer number (excluding the Appendix, Glossary, Bibliography, and Index) . A quick review of the table of contents for Erl's book should give you a fairly good feeling for the deeper level of RESTful patterns discussed therein.

To truly explore the topic of design patterns - certainly one needs to at least give equal measure to the discussion of anti-patterns. Particularly with regard to the way that RESTful services are often incorrectly designed.

Another almost trivial and minor aspect of the book that grated on my reading pleasure: the introduction of some different names for a few patterns that were already fairly well known and established within the SOA literature prior to the publication of this book.

Perhaps a more generous criticism could be that the author attempts to tackle a fairly large task - and the constraints of covering so many topics in a book of this length, must necessarily result in a lighter touch. As the subtitle itself calls out ("Fundamental Design Solutions....") and the author himself points out in the Preface on page xxi - "The content of this catalog has therefore been constrained to only include the most fundamental solutions relevant to web service design".

...Which leads me to agree with a sentiment expressed by another reviewer [George Jiang] - "it is far from an authoritative patterns book".

A few possible suggestions for things that could enhance the value of the book for other readers:
- A github code repository to provide worked examples of the book's patterns
- A discussion of possible performance trade-off considerations when considering different patterns
- [even better] a set of unit test of the worked examples to compare and contrast performance considerations
11 comment|5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 8, 2012
I was searching for this book even before it existed. I have designed and implemented many web services, and have lead several teams in the designing and implementing them. For this, I've consulted a lot of design pattern and SOA literature, both technology-specific and technology-agnostic, and have learned a lot of lessons the hard way. I always felt that there needed to be a book specifically targeting the design of web services. So, I was very happy when I found out about this book before it came out. And, after looking at the web site and a rough cut, I knew that the book I had been looking for had finally been written.

Because services have become so prevalent in software development, there is a great deal of tooling support for them. Both the creation and consumption of web services can often be performed with a couple mouse-clicks. While this is great for supporting Rapid Application Development, it has lead to a lot of under-designed services. This under-designing doesn't hurt at the beginning of the project, when it's easier to fix. It hurts towards the end, or after delivery. You will be shown how to prevent this.

This book belongs beside the likes of Patterns of Enterprise Application Architecture and Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions on every software developer's bookshelf. It follows all of the conventions that a patterns book should follow, and is excellently organized and written. There is no fluff in this book either. Virtually every page has value, and everything explained at the right level of detail.

You will become better at designing and implementing services at a time when such a skill-set is in VERY heavy demand by reading and internalizing the information in this book (as well as using it as a reference). Because SOA and Design Patterns are buzzwords, there are a lot of non-substantive books in these areas. This is NOT one of them.

From this point forward, I will be making sure that this book is available to the software teams I work with. This book needed to be written, and it is evident that the right people ended up writing it.
0Comment|6 people found this helpful. Was this review helpful to you?YesNoReport abuse
on June 5, 2015
One of the most influential architecture books of the early 00s was Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf. That book not only provided far and away the best set of patterns and supporting explanations for designers of message-based integration, but it also introduced the concept of a visual pattern language allowing an architecture (or other patterns) to be described as assemblies of existing patterns. While this concept had been in existence for some time, I’m not aware of any other patterns book which realises it so well or consistently. The EIP book became very much my Bible for integration design, but technology has moved on an service-based integration is now the dominant paradigm, and in need of a similar reference work.

The Service Design Patterns is in the same series as the EIP book (and the closely related Patterns of Enterprise Application Architecture), and overtly takes the earlier books as a baseline to build an additional set of patterns more directly related to Service-oriented integration. Where the earlier books’ content is relevant, it is just referred to. This helps to build a strong library of patterns, but also actively reinforces the important message that designers of newer integration architectures will do well to heed the lessons of previous generations.

The pattern structure is very similar to the one used in the EIP book, which is helpful. The "Headline" context description is occasionally a bit cryptic, but is usually followed by a very comprehensive section which describes the problem in sufficient detail, with an explanation of why and when alternative approaches may or may not work, and the role of other patterns in the solution. The text can be a little repetitive, especially as the authors try to deliver the specifics of each pattern explicitly for each of three key web service styles, but it’s well written and easily readable.

This is not a very graphical book. Each pattern usually has one or two explanatory diagrams, but they vary in style and usefulness. I was rather sad that the book didn’t try to extend the original EIP concept and try to show the more complex patterns as assemblies of icons representing the simpler ones. I think there may be value in exploring this in later work.

One complaint is the difficulty of navigating within the Kindle edition, or in future using it as a reference work. Internal references to patterns are identified by their page number in the physical book, which is of precisely zero use in the Kindle context. In addition the contents structure which is directly accessible via the Kindle menu only goes to chapter level, not to individual patterns. If you can remember which chapter a pattern is in you can get there via the contents section of index, but this is much more difficult than it should be. In other pattern books any internal references in the Kindle edition are hyperlinked, and I don’t understand why this has not been done here.

To add a further annoyance, the only summary listings of the patterns are presented as multiple small bitmapped graphics, so not easily searchable or extractable for external reference. An early hyperlinked text listing with a summary would be much more useful. Please could the publishers have a look at the Kindle versions of recent pattern books from Microsoft Press to see how this should be done?

A final moan is that the book is quite expensive! I want to get all three books in the series in Kindle format (as well as having the hardcover versions of the two earlier books, purchased before ebooks were a practical reality), and it will cost over £70. This may put less pecunious readers off, especially as there’s so much front matter that the Kindle sample ends before you get to the first real pattern. That would be a shame, as the industry needs less experienced designers to read and absorb these messages.

These practical niggles aside, this is a very good book, and I can recommend it.
0Comment|Was this review helpful to you?YesNoReport abuse
on October 7, 2013
This book desribed the principles of the SOAP/WSDL and RESTful web services. It is straight forward, you do not have to read too much text that is unnecessary to learn the WS priciples. It does have some sample code to illustrate the principles. My suggestion is that the book would be better if it has some discussions on the WS technical problems that happened in the real-world business. I recormand the book to the WS developers and architects.
0Comment|Was this review helpful to you?YesNoReport abuse
on January 8, 2012
I recently wrapped up a roughly 18 month project that was heavily service-based. I wish I had this book before I started that project because it definitely would have saved me a lot of time and experimentation. Similar to Patterns of Enterprise Application Architecture (PoEAA) Patterns of Enterprise Application Architecture, the real value comes from seeing all the different aproaches in one place and also seeing what the experts think are The Big Problems. When you're building something and come across a sticky problem, pop open the book and see what the big issues are and what the options are for solving it. Huge time saver.

I'm sure that I'll design my services differently on my next project because of this book.

Great job.
0Comment|4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 30, 2012
As with many pattern books, my first reaction was "I know all this". But as usual, this isn't true to the degree one likes to believe, as there is always additional perspective to be found, and even more importantly, it's the whole point of pattern collections to describe stuff that is well-known and part of industry folklore. I enjoyed this book and will recommend it, specifically because it's a good resource (pun intended) for those who want to apply REST to their service design.
0Comment|4 people found this helpful. Was this review helpful to you?YesNoReport abuse