News: SOA Cookbook
I am getting addicted to the SOA books of Packt Publishing. Now it is the SOA Cookbook that I've been reading with delight. Why with delight? Because, again, the focus is on practical use. The concepts and technologies in the book are challenged against existing products in the market, including tools of BEA, Oracle, TIBCO, and IBM. This is of very great value to practitioners. The author roughly knocks down some simplifying myths around SOA. He teaches techniques in the modeling of orchestration processes. These processes belong to the process integration layer of the universal model stack provided by the leading vendors: BPM, Process Integration and ESB. The book starts with the A (architecture) of SOA which has been approached from Kruchten's famous 4+1 model. The author combines aspects of this approach with the well known ARIS method based on the Event-driven Process Chain, EPC which is an evolvement toward EDA. The book tells you how to separate SOA from BPM (including design tips) and how BPEL fits in this context. Orchestration versus choreography comes the the scene as well. The author explains how choreography is fundamentally decentralized and acts as a set of traffic rules to govern how participants interact, whereas orchestration builds a flow of control around these interactions. Real-live examples using BPMN support the understanding. Long and short running processes come to the scene and the change problem of dynamic processes is addressed. You can read why the author calls versioning "Poor Man's Change" and why he thinks versioning is only a beneficial approach to vendors, but hurts adopters. "Design processes that are adaptable to begin with", he says. The book ends with a chapter on measuring the complexity of SOA where Thomas McCabe's cyclomatic complexity measure (1976) is applied to BPEL and TIBCO's BusinessWorks. Conclusion: the book is of great value to SOA practitioners in the semi-technical domain. That is, it doesn't deal with the organizational aspects of SOA neither does it deal with the hard-core deployment of services. The book implicitly assumes that your IT-organization is mature with regard the building and deploying software and with regard to procedures to control these development processes. This book adds value in teaching you the state of the art techniques of process integration on top of your current development processes.
You can read why the author calls versioning "Poor Man's Change" and why he thinks versioning is only a beneficial approach to vendors, but hurts adopters. "Design processes that are adaptable to begin with", he says.This comment does not bode well for the book in my mind. The author's bio says that he's got plenty of consultant (maybe that's the problem) experience but I don't see how anyone can believe this if they've had to support a service that was used by more than one client. One of the core principles of SOA is that the contract is the most important part of a service. It's the hardest thing to change. The reason, as I've experienced, is that you will not have the power to force your clients to upgrade and even if you do, consider the logistics of having a dozen or more clients flip over to a new service at the same moment. It's hard enough to coordinate this kind of thing with one client. No amount of flexibility in your approach will fix this. It's the users of your service that limit your ability to change it, not your approach to building services. Try to tell your CEO that your company's going to lose millions of dollars of business because you don't want to have multiple versions of a service running. You'll be extracting a boot from your ass. If you are reporting what the book is saying, he's wrong on this, unless he's discovered a new brand of pixie dust that I don't know about it. Versioning of services is something being demanded of vendors by people who have battle scars. Understanding this means two things. 1. Take your time and create the contract first. This cannot be emphasized enough. 2. Be ready to version at the drop of a hat. You will not get all the services right all the time. the best you can hope for is to minimize the number of versions.
There is another book by the same name "SOA Cookbook" by Eben Hewitt which is oriented towards developers. It will be published by O'Reilly and is available in Rough Cuts form at safaribooksonline.com. The few chapters that I've had a chance to read look good.
There is another book by the same name "SOA Cookbook" by Eben Hewitt which is oriented towards developers. It will be published by O'Reilly and is available in Rough Cuts form at safaribooksonline.com.We've decided to rename my book to "Java SOA Cookbook", in order to distinguish it from this one, and to highlight the fact that it is focused on Java developers. It is actually very different than the Packt book, covering BPEL in depth, as well as JAX-WS 2.1, the new JAX-RS specification for RESTful services, and more. Here's a link to the product page on O'Reilly: http://oreilly.com/catalog/9780596155315/index.html The book will be in stores in March.
The few chapters that I've had a chance to read look good.