One of the best books which answers the question , Why Web Services?? Unique perspective on middlewares in general.

Do not expect any code examples or details of any particular middleware.
Rating: 5 / 5

Advice: if you are looking for a hands-on how-to book about XML this is not the book to pick up. Otherwise, if you are looking for a good fundamentals book that will help you paint a big picture of Web Services this book is great!
Rating: 5 / 5

This book is must have which draws detailed conceptual and architectural views on Distributed Systems, EAI and Web Services.

Rating: 5 / 5

I gave it 4 stars mainly because it kept me interested throughout AND Chapter 6 was well worth the wait. Also, the author was direct and decisive in what he was saying. I never felt while reading that he was talking over my head or down to me from some higher plateau.

Some criticisms which kept it from a perfect 5 include:

(a) Too many repeated themes. I felt at times that I was reading the same sentence and paragraph over and over. Not a major thing, but I think I read that XML is a “standard” for organizations to exchange business data more than twice!

(b) The author throws around many acronyms, some of which without expanding. At one point, he used “PO” to refer to “Purchase Order” and I really had to stop reading and thing about what on earth a PO was (duh!). There are several examples of this throughout the text making it a bit difficult to read.

(c) Related to (b), I would have liked to read more background on some of the technologies discussed. Examples include the Java technologies that the author refers to throughout. I’m not a Java developer, so I felt a little behind in some of the discussion.

(d) I think the author spent too much time on his low-level XML discussion. I realize that XML is integral to SOA but for a book designed for “architects” and “senior developers”, as the back cover suggests, it seemed too deep for “architects” to care about and too shallow for “senior developers”. It might have been better to present an XML primer and leave it at that.

(e) By reading this book, I DO NOT feel ready to build an SOA, nor do I feel qualified to jump into a team implementing SOA.

Chapter 1 was a sufficient setup for the chapters to come. It would have been good to build a better case for SOA, though. If I was on the fence about SOA, I don’t think this book would have convinced me that my organization needed to go down this path. This chapter does however provide a lot good background and helps draw the line between different integration strategies.

Chapter 2 introduces the ESB — which for me is the most interesting aspect of the SOA approach. There is also a good discussion about processes and orchestration, which was enlightening (coming from me, who has no real world SOA experience).

Chapter 3 was the lowlight. I found myself skipping ahead when the author started discussion XML schemas, namespaces, declarations, and the like. I know this stuff already and was wondering how an “architect” or “senior developer” (I’ve been called both) would treat this chapter. I concluded that they would do essentially what I did: skim it. It is too light to be a reference and too heavy to be of any practical value.

Chapter 4 was better than the previous chapter. I like history (IT Evolution, and WS Specifications) and discussions on Patterns (the author discusses integration patters, business patterns, composites, application patterns, and runtime patters). He does however loose me a bit on writing WSDL and the simple web service example. I’ve written several web services and understand the concepts so I found myself skipping ahead a bit.

Jaded by some of what I read in Chapters 3 and 4, Chapter 5 got me back in the mood. BPEL. Finally. The book had been talking about BPEL (Business Process Execution Language) on-and-off and now this chapter gave me a heavy dose. Good job.

Chapter 6 was my favorite chapter by far. ESB is an area of interest for me, and to have it explained and examined in the context of SOA was eye opening. In fact, it’s one of the reasons I wanted to read this book in the first place.

All-in-all, I learned a lot from this material. I took a few notes, which will lead to further research on my part. This book presents a good overview of some of the complexities and key points in building an SOA infrastructure/environment. Get it if that is what you’re looking for!

Rating: 4 / 5

Because of their experience with Packt Publishing and their real world experience for SOA, Packt has chosen them to write this book about SOA Integration.

Clearly this book requires deep familiarization of the components discussed in SOA. XML and Web Services are extensively discussed so that developers will understand why the mark-up language (XML) and approach (Web Services) is perfect for integration which eventually leads to SOA. For those who are beginning in SOA, this book provides explanation in great detail in the basic concepts of SOA – from the challenges until specific terms that will greatly influence in building an application using the architecture.

What is even interesting is that it provides an insight to an alternate to JavaEE and the .Net framework. If you have a vague idea of what COBRA is, then this book will enlighten you further why this application web language could help you in building an application.

Some parts of the book are great for beginners while other parts of book are intended for advanced users. If you are looking for specific instructions on how to integrate XML to SOA, then this book will help you. For beginners or for those who just wants an in depth information of SOA, then this book will also be of great assistance.

Ultimately, this is a great addition to your library as it provides the basics while introducing you to the advanced concepts and principles behind SOA.
Rating: 5 / 5

There are a set of standards that make all this possible, and the text explains these. The lowest level is simply to use XML for data interchange. This gets around the alternative of binary data interchange, and all the compatibility problems therein. The latter was the realm of CORBA. But that proved brittle in many practical deployments.

Another standard is the Web Services Description Language (WSDL). This and BPEL let you construct interoperable “parts”, that can usefully interact with other programs on the net.

There is lots of practical advice. Like the fact that parsing large XML documents can be slow. So you should not use XML to communicate between tightly coupled components. Plus, the book offers numerous patterns that can simplify your design efforts. These patterns have proved successful in existing applications, and you should take advantage of them whenever possible.
Rating: 4 / 5

Chapters:

1.) Integration Architecture, Principals, and Patterns – covers a wide variety of concepts including types of integration including data, application, process and presentation. It also speaks to layers of integration such as communications, brokering, routing, transformation and others. The authors touch on various technologies in the integration arena, for example, database access, message oriented middleware, remote procedure calls, transaction monitors and more. The chapter finishes up with a quick overview of the integration process, various practices activities and patterns.

2.) Service and Process-Oriented Architectures for Integration – talks a great deal about the concepts and standards that make up Service and Process Oriented Architecture. It is not an in-depth tutorial on either subject but is a good reference for the standards associated with them and why they are well suited for integration.

3.) Best Practices for Using XML for Integration – is closer to a tutorial on XML than a description of the architectural rationale and implications of it with respect to SOA. Since part of the target audience is developers the level of detail in this chapter is not un-warranted. This chapter includes a comparison of JAXP API’s and shows a number of XML schema and XSL stylesheet examples. It also speaks in reasonable detail to validation, security, encryption and performance considerations with respect to XML.

4.) SOA and Web Services Approach for Integration – steps more deeply into the area of web services and again much of it is directed to developers as opposed to architects. It contains a good overview of various patterns and contains some guidelines on their usage. The chapter contains a light review of web services for B2B and EAI and then a more detailed description and examples of interoperable web services, WSDL and WS-I.

5.) BPEL and the Process-Oriented Approach for Integration – speaks in more detail about BPEL and what the authors refer to as “the process-oriented approach to SOA-based integration.”. This chapter addresses the usual suspects of choreography, orchestration and complexity in a clear fashion. It then goes into more depth on writing BPEL processes and works through a fairly complete example.

6.) Service and Process-Oriented Approach to Integration Using Web Services – gets to the heart of the notion of using SOA for integration by delving into the Enterprise Service Bus (ESB). This chapter covers the ESB at the appropriate level of abstraction for an architect and touches on key areas such as mediation, transformations, communications, transactions and security.

Conclusion:

I enjoyed the book and felt it delivered on the topic of SOA Approach to Integration. Trying to target both architects and developers is a difficult task but readers from either area will find something useful in this book. It is not the definitive work on SOA and Integration but it does a good job of tying together a broad range of material and will be a welcome addition to anyone’s technical library.
Rating: 4 / 5

The choice of PHP as an implementation language: This is a refreshing reminder that SOA is about hiding service implementation details from service consumers. The implementation language doesn’t always have to be Java or C#. What matters is what the service consumer sees (i.e., SOAP). There is however, a downside with PHP, which I’ll cover in a moment.

The use of Open Source technologies: I believe that Open Source is the way of the future, and the use of Apache/PHP, Tomcat and ActiveBPEL to illustrate SOA concepts feels just right. Besides, readers can readily try out the examples in the book without having to buy expensive commercial software.

Copious examples: This is not a theoretical book, and there is plenty here for the reader to try out for themselves. Every concept that the author deals with is represented in code. [I can't comment on how complete or correct the examples are and whether they work, because I haven't tried them out yet.]

Lots of diagrams: Pictures are really worth thousands of words, and there are diagrams sprinkled liberally throughout the book to illustrate almost every concept discussed. I thought they were quite decent.

Emphasis on data: One of my pet peeves with many people’s approach to SOA is their relative neglect of the Data Interchange view of service interactions. SOAP-based web services is about exchanging XML documents that represent some structured data relating to the operation being performed. There is a lot of design that needs to go into these XML documents. Thankfully, the author spends a fair amount of time showing how to design the data payload of messages with XML schema and converting data into XML format (but a nit about that bit later!) I also liked the treatment of the data within the contract (importing the schema file into the WSDL file instead of defining the schema in place).

Introduction to WS-Security and to Qualities of Service (QoS): The book has a section on implementing secure messaging using WS-Security, and also makes the point that virtually all the WS-* specifications use SOAP headers to implement functionality. There’s not too much here, but enough to get the developer to understand the WS-* approach.

View of a process as a service in its turn: One of the value propositions of SOA is its ability to exhibit a “flat” landscape of services, regardless of how they were implemented. From a service consumer’s point of view, it doesn’t matter if a service was purpose-built in a programming language (e.g., PHP) or stitched together out of other services (using BPEL). Services of both types should look the same. The book shows how composite services can also be exposed as services in their turn, with the appropriate WSDL sections highlighted.

WS-BPEL treatment at the right level of detail: I thought the level of discussion and the examples of WS-BPEL were just right for a beginner. There is enough detail to be meaningful, but not so much as to overwhelm.

What I don’t understand or don’t like in the book:

The title: SOA and WS-BPEL are like fruit and oranges, not even apples and oranges. The first is an architectural approach; the second is a language used to implement processes. Considering that the book deals with building standalone web services in the first part, then composing them into processes in the second, perhaps it should have been called “SOAP and WS-BPEL” or “SOA: SOAP and WS-BPEL”.

The unquestioning acceptance of the RPC view of Web Services: I have religious feelings about RPC. It is the devil’s spawn. Many of the REST camp’s arguments about SOAP are actually directed against SOAP-RPC. The modern view of SOAP-based Web Services is based on messaging. Messaging, not RPC.

What’s the difference, and why is this important? RPC is architecturally dishonest. It is impossible to make a remote object behave like a local one, and I don’t mean the effect of network latency. A reference to a local object that is passed to an application carries with it the promise that any change made by the application using the reference will change the object. But with RPC, what is passed to the application is not a reference to the object, but a reference to a copy of the object. This is not an insignificant difference. When the application makes a modification using the reference, the local copy is changed, not the remote object. But the application thinks the actual object has been changed. That’s what is so dishonest about it.

Messaging turns this essentially hopeless exercise around. It makes local objects look remote, by always passing copies around, even if the actual object is accessible by a reference. The application is under no illusion. It knows that in order to make a change to the real object, it is not enough to make a change to the copy. Either the copy must be passed back to be synchronised in some sense with the original, or an independent operation to pass a Data Transfer Object is required. This is architecturally honest and clean. What it may lose in efficiency in some corner cases (local access), it more than regains in terms of robustness, flexibility and scalability.

That’s what SOAP messaging brings to the table. SOAP-RPC is evil and should have nothing to do with a book on modern Web Services. It’s a pity the author actually mentioned RPC by name when introducing SOAP messaging, because the actual examples do not assume RPC.

In this context, the use of PHP has a downside, as I indicated earlier. PHP is heavily tied to HTTP and by extension, to synchronous request/response semantics. SOAP-based Web Services technology does not inherently have this constraint and can work with asynchronous transports as well. The book could have illustrated this effectively using a message queue example. There are tools such as PHPMQ and Mantaray that make this possible.

Automatic data transformation to and from XML: This is another of my pet peeves. The service contract (of which the XML document forms a part) is a First Class Entity. So are the classes that make up the internal Domain Model. How can one ever be generated from the other using a tool? Code generation is an example of tight coupling, and if two First Class Entities are tightly coupled, then at least one of them is not a First Class Entity. QED. I’m not sure if there is an equivalent to TopLink or JiBX in the PHP world, but such a mapping tool is what is required to transform data between the PHP and XML worlds. To be fair, this book is not alone in propagating the code generation approach. Virtually the entire Java Web Services industry is consumed by JAXB disease.

Data-centric Web Services – Actually, I didn’t understand the point of this as a separate topic. It’s a special case of service implementation. In fact, I have a totally different view of Data-Centric Web Services. I call them REST.

No high-level view of process as an aspect of the business: For a book that purports to be on SOA, the treatment of composite services and processes is surprisingly low-level and technology-oriented. There should have been an introduction that focused on business processes and their decomposition into services. In fact, SOA best practice is all about business process modelling and re-engineering. That’s how architects and business analysts determine the services that are required and their granularity. Proceeding bottom-up from services and composing them into processes, as the book seems to suggest is the way to do SOA, is ingenuous.

Anaemic index: The index of the book doesn’t list many of the things discussed inside. I tried going back a couple of times to look up something I had seen earlier, but the index was of no help.

Other comments:

ActiveBPEL Designer is not an Open Source product, merely free. This isn’t the fault of the author. It’s just something I’m personally sad about. I haven’t yet found a truly Open Source BPEL designer that is powerful and friendly, and generates full-featured BPEL.

Overall comments:

Actually, notwithstanding the negative comments I made (I’m a nitpicker, as my wife will attest), this is a pretty decent book on Web Services (SOAP and WS-BPEL). It’s got enough low-level detail to help developers get their hands dirty and understand the technology by actually building services and processes. The choice of PHP could turn out to be a masterstroke by reaching beyond Java or C# developers and appealing to the vastly more populous LAMP community. Time will tell. I thought the book was a bit light on architectural insight, but maybe it’s for the best. For a developer audience, such discussion might just cause eyes to glaze over.
Rating: 4 / 5