Service Oriented Architecture For Dummies (For Dummies (Computer/Tech))

• #18 in Best Architecture Books

16 Reviews

Sort by: Most Helpful ▲ Date Rating

The authors of "Service Oriented Architecture for Dummies" are partners of Hurwitz & Associates, an information technology consulting firm. They provide a high-level overview of service oriented architecture (SOA). SOA breaks with traditional practices of software development, which frequently led to the creation of many redundant "siloed" data stores and applications across the enterprise, by promoting the development of reusable services that can be strung together in different ways to achieve multiple ends.

A key thesis of "Service Oriented Architecture for Dummies" is that successful transition to a service oriented architecture (SOA) requires the cooperation of business managers and I.T. people. SOA is not simply the latest and greatest approach to building distributed systems; SOA also re-conceives how business and I.T. should work in partnership to construct their software architecture. The authors warn that simply asking developers to design a set of reusable services may not result in the creation of the right sort of services. Developers need instead to work in close cooperation with businesspeople to make sure that the services being developed serve useful business purposes. This is sage advice that evidently comes from long experience consulting on I.T. projects.

That SOA is still a developing design philosophy becomes evident as the authors discuss some of its more advanced dimensions. The authors make a good case, for example, that as SOA evolves it will become necessary to guarantee certain levels of service and it will also be necessary to implement SOA supervisors to monitor the overall quality of service. However, they caution that most enterprises have not made it far enough along the road to worry about such things. It's also interesting to note that while they recommend setting up formal repositories and registries for services (using UDDI, for example), most of the companies in their case studies section are still using excel spreadsheets, web pages, and the like. The lack of implementation gives some of the authors' best practices a slight air of speculation. However, the authors repeatedly make the point that the best way to achieve SOA is not to turn everything into a service at once, but to begin with a key service and then iteratively develop new services as the value of having such services is recognized. Enterprises may implement the more advanced aspects of SOA down the line as the number of services grow and the complexity of their interaction increases.

The chief drawback to "Service Oriented Architecture for Dummies" is its aim to speak simultaneously to developers and businesspeople. The authors were almost apologetic for including a section titled "Nitty-Gritty SOA," which covered XML, SOAP, WSDL, UDDI, etc. They clearly did not want to put off their business readers by introducing too much technical jargon. However, this unwillingness to get into too much technical detail proved frustrating at times because some key topics lacked any detailed technical exposition. For example, the authors emphasize again and again the importance of having an enterprise service bus (ESB) but failed to provide a satisfying explanation of how precisely an ESB works to orchestrate services at a technical level. I also could have done without the quick listings of various vendors' offerings in SOA in Part V, although the accompanying case studies were valuable. I imagine that the majority of this book's readers will be software architects who will appreciate having this kind of high-level overview to use as a touchstone for discussion both with developers and business managers.

"Service Oriented Architecture for Dummies" successfully makes the case that transition to a SOA will generally result in lower development costs, fewer redundancies across the enterprise, faster response times to market changes, and the development of more creative kinds of business services. It may provide just the kind of reassurance that many I.T. and business folk need to get started with SOA at their own companies.

The one thing that most people agree upon for SOA is that there is a lot of confusion. This book unfortunately adds to that confusion.

If you want to know what is going on today in what is being called SOA, this book is fine. It takes a look at what is out there, and reverse engineers it and describes the pieces. Unfortunately what is being done in general and what SOA is supposed to be is quite different.

If you were interested in what SOA is SUPPOSED to be, this book is very far off the mark. If you look at Thomas Erl's definitive books on SOA, you will see a vast difference from SOA as described in this book. Some of the chapters are overviews, for those with little or no existing knowledge of SOA, which is probably what you really wanted.

This SOA for Dummies book might be summarized as:
* SOA is good
* Everybody will be doing it
* Lots of companies are working in that area to implement SOA
* Lots of companies are creating SOA related products
* If you don't go SOA, your company will fail
* There is confusion
* We are a consulting company to help you

But my guess is you already knew this.

One aspect that is missing is an emphasis on open source SOA products. This book focuses primarily on commercial products. Even the commercial sources are continuing to donate parts of their systems to open source, so what was commercial is now open source. That is the continuing trend.

I would say take this book as light reading (even though it's 350 pages), but don't try to remember too much of it. Don't presume the people implementing SOA really know what SOA is all about. I've seen SOA described formally in detailed all the way to the other extreme where some people call everything on the Web as part of SOA, which it isn't. So when you hear someone talk about SOA, be really skeptical.

This book tells you what is going on, not what should be going on. The question for you is just what to you want to implement. Because you want to do it right the first time. Calling anything that has a "service" as part of SOA, won't get you there.

It's hard to imagine how anyone even remotely aware of SOA could be classified as a `dummy'. But, looked at another way, this book's title `SOA for Dummies' makes perfect sense. The authors - all from the consulting firm Hurwitz and Associates - strongly believe that SOA has the makings of one of those disruptive new technologies that have a way of sweeping quite suddenly into the broader market and abruptly upsetting the established order. If that turns out to be true, then at this moment we are all probably dummies about SOA and its future impact, and we better read this book right away.

But what makes SOA such a big deal? After all, the authors freely admit that the commercial SOA industry is just in its early stages. At the same time, however, they contend that SOA is important because it directly addresses one of the biggest problems that companies have today - how to make their computing environment nimble enough to keep up with the fast-changing needs of today's frenetically globalizing business environment.

Once upon a time, Hurwitz reminds us, your company's computers probably sat in a protected white room, serving a few privileged users inside your own enterprise. Those users were supported by a set of custom-built software applications sporting ugly, hard-to-use, text-based `green screens'. Each such application lived in its own little world or `silo', often hosted on its own mainframe partition or even a special set of hardware.

Maintaining and updating these applications was a major chore, and exchanging information among the various silos was a daunting task. Mergers and acquisitions compounded the problem, creating a veritable tower of techno-babble. As for opening those applications up to outside users, this was virtually unheard of and, as yet, thankfully uncalled for.

Fast-forward just a few years to our current Internet era. Your company's whole computing environment is now just a small fishing boat bobbing around in the enormous virtual, global computing sea called the Internet. Your outside users, particularly your on-line customers and partners, now probably rate a higher priority than your inside users, and they are almost certainly more diverse and numerous. Moreover, they expect to see a graphically attractive, client-centric view of your enterprise using a universal standard interface - the Web-enabled browser. What's a poor CIO to do?

Understandably, it is taking a while for most organizations to catch up. The big problem is not so much cranking out new Web-enabled applications. The real problem is breaking apart those old siloed applications, which unfortunately contain most of the critical data and business logic that the fancy new applications need to function. But building custom bridges between all the new applications and all the old ones they need just creates an even worse development and maintenance nightmare, as many organizations are now learning the hard way.

That's where SOA comes in. According to Hurwitz, SOA represents the best hope for reorganizing that legacy data and logic so it can be mined to meet the requirements of the new global computing order. With SOA, you break down the legacy applications into reasonable chunks based on functionality. These chunks are typically called `business services'. You provide each business service with a standard interface described in a universal interface language called Web Services Definition Language (WSDL). Using WSDL, those business services can be accessed readily by any new application (or other service) that needs them.

The WSDL interfaces actually live on a clever piece of middleware aptly dubbed the `enterprise service bus' (ESB). The ESB knows how to accept your service requests to a WSDL interface and forward it on to the actual business service. Since the ESB just happens to use Internet protocol, you can potentially allow access to your business service interfaces from anywhere in the world (subject, of course, to your security requirements). This solves the problem of how to make your brand new business services accessible to customers, suppliers, and partners, as well as internally.

The ESB also comes with a set of lower-level supporting system services that help you keep track of all the business services you have, identify the business services you need, identify clients for security purposes, enforce that security across the enterprise, manage complex transactions among service components, as so on. There are also `business process modeling' (BPM) tools to string together different business services into composite services, and to model business applications using those business services.

So far so good, and Hurwitz does a pretty good job explaining how all the various pieces of SOA are supposed to fit together. However, as the authors freely admit, the problem is that moving from no-SOA to SOA is not just a technical problem. According to Hurwitz, it requires a kind of `journey' for the whole organization. Ultimately, that journey will result in your company being much better able to respond to the fast-changing needs of today's maddening business world. To make this happen, however, both the `techies' and the `techno-dummies' in your organization will ultimately have to share a basic level of understanding about SOA.

That's because, as things stand today, most companies simply don't have much of an idea about how to organize, manage, or pay for the enormous effort that will be required to break down their existing applications into a SOA. As they do, they will also have to retrain their business analysts, developers and project managers to stop building custom, siloed applications, and start designing future applications around those reusable services. As if that wasn't enough, they'll have to figure how to do this without disrupting normal business operations. Good luck! Certainly that won't happen overnight, or for free.

Thankfully, this book doesn't gloss over these problems. Nor does it gloss over the fact that SOA itself is relatively new in the marketplace, and that overall adoption and maturity levels in the SOA industry are still in their infancy. The harsh reality is that, as an introduction to a new and potentially disruptive technology, this book has to straddle the line between being very enthusiastic about SOA, and remaining realistic about how difficult it can be - and how long it can take - to implement successfully. Remember: SOA is a journey, not a silver-bullet technology.

In this spirit, the book offers an overview of representative product and service offerings currently available from different SOA vendors. Of course, in this fast-developing field, these are likely to become out-of-date very quickly, and so they should largely be viewed as illustrative starting points. Similarly, the book provides a small set of end-user success stories, most of which describe a pretty early stage of SOA adoption. Unfortunately these stories come with little hard data, which makes them somewhat less compelling. However, this is not really the authors' fault: such hard data is notoriously difficult to obtain, especially for a new technology like SOA.

The book does make a noble attempt to help its readers evaluate how ready they are to take on SOA. For example, there is a cute 10-part `SOA Self-Test' that asks the reader to rank his organization's readiness (from 0-10) in a wide range of areas. Mimicking the personal self-tests we see in popular magazines, you total up your overall score to see just how `ready' your organization is for SOA. If indeed this is a book for `dummies', then this approach is in some danger of falling into the category of `brain-surgery self-taught'. However, if you don't take it too seriously, it's a clever way of getting people to start thinking about many issues they might not have otherwise considered.

In the end, the book makes clear that, no matter what hype they may read, companies interested in implementing SOA have their work cut out for them. On the technical side, they will have to grope through a minefield of arcane terminology and disparate offerings in order to figure out how to implement their SOA infrastructure. On the organizational side, they will have a steep education curve before they can seriously begin to ask - much less answer - the difficult questions about how best to manage the introduction of SOA across their whole company or business unit. Yes, Virginia, you may end up much the better for having SOA-sized your company, but there's no easy way to get there.

Therefore, and to its further credit, this book does not try to provide definitive answers about how to implement SOA, but rather focuses on providing enough information to help readers at many levels of a company begin to properly frame the right questions. After all, different organizations will have different needs and motivations for implementing a SOA, so there is no `one size fits all' path to SOA success. But, as the book itself declares, you have to start somewhere, and reading this book is a pretty good place to do so.
...........
Michael Guttman is CTO of The Voyant Group, an international consulting group specializing in advanced IT technologies such as BPM, SOA, and MDA. He is also co-author of the book "Real-Life MDA" (Morgan-Kaufman, 2006).

I have always been seriously put off by the "Dummies" series. I would like to buy books that assume some intelligence on the part of the reader. I don't like being talked down to.

But this book doesn't do that. Instead it explains concepts clearly, and has been a great help to me in understanding the clouds of jargon that surround this topic. The explanation of the components of SOA and how they hook together is excellent!

Because I am not yet directly involved, I cannot judge the accuracy of their details (and of course, they may change over time), but since the objective is to get the main concepts across, I believe the authors are successful.

I really wish, though, that the series were called "Achieving Buzzword Compliance in ...".

I've never written a book review, but I'll take a crack at this one. I've never read an "anything" for dummies, partly because I tried to educate myself past the dummy moniker, and also because I was already ahead of most of the dummy subjects before the book came out. I was a DOS and Internet experienced user years before the books. Not that I should brag, but I was a DOS giant going back to version 1.0 of which I used both IBM and Microsoft versions.

I'm not an SOA qualified person so this book is relevant to me on a number of levels. First, it is written by some analysts who I'm close to, Hurwitz and Associates, (disclaimer, although I should be less personal, you can't help but become close to the folks you work with, and this statement applies to most of the analysts I work with). Next, with the SaaS wave about to crash on the IBM beach, SOA is technology that is inherently ingrained in our strategy and offerings, so I'm working on this closely. Finally, I'm mentioned in the author's acknowledgements with some names of folks far more qualified than me. While I can't comment on the entire book, I'll bring out some excerpts that will give you a flavor of the book.

First, what I like about it is the first person style, like the first chapter, why you should care about SOA. I can hear Judith, Robin, Carol and Marcia's voices when I read it. It reminds me of an analyst briefing when they are setting us straight, which we frequently need. Next, it gets right to the salient points of what matters, like connecting programs and re-use. I like the catchy titles like Noah's Architecture and tongue in cheek comments like "It's so simple, it's only taken 40 years". It is an engaging style that deals with topics you need to know, but didn't know you didn't know or needed to know. It goes on further with Nitty-Gritty SOA and My Computer is a Lousy Linguist.

For those who know I like and respect the military, the SOA security chapter hit home with me. It has a funny caption about can you tell Robin wrote this? He's a Brit. It discusses the Dark Ages in Europe and using moats to surround your castle. It makes a nice transition from the Dark Ages of Computing, namely mainframes, through PC's and the internet. The author neatly transitions to Identity management software, authentication and other topics that help you "defend your castle".

The first time I was ever exposed to SOA, it revolved around the Enterprise Service Bus, chapter 9. If you are reading this, you fall into one of two categories. You either already know the discussion of the ESB, or you need to read SOA for dummies. While it doesn't say IBM is the end all here, we were one of the first to hammer this home and have done a good job of explaining why this is important. The chapter deals with metadata, mediation, messaging, security and the interface capability of the ESB. It also has a comparative description of a Bus is a Bus and actually mentioned ISA, PCI, USB and almost went to the Micro Channel Bus, the other book I was in the acknowledgements for.

I also thought the chapter on Do You Need a SOA was quite helpful. I won't discuss my score, but it's safe to say I'm not ready to be an enterprise. Of all the words I know, this chapter uses the word perspicacity, and the only other time I've heard this was in the Tour de France coverage.

So in the spirit of not ruining the book for the authors, I won't go into too much other detail, other than it's as good a reference book on a technical subject as I've read. In comparison, the Eclipse book I recently read was a serious yawner and SOA for dummies kept me engaged. Hats off to the four authors and I wish them luck and good sales.

I like this book because it is easy to read and it explains basic SOA concepts. This book will help you understand the major concepts but it is not a book that can get you started building services, SOA infrastructure and middleware.

And it is obviously not for dummies!

If you are not an IT guy and for a long time you have been thinking that SOA is only related to IT, then this book is a good starting point to understand, and make others understand, that SOA has everything to do with business.

Using simple examples, this book will guide you through the different elements of SOA and will help you to understant it's potential.

I have used this book and recommended to my staff to help clarify terms, get agreement on basic principles, and help everyone explain SOA better to those who need it explained. The authors have a wealth of experience and have really helped us cut through the jargon jungle which surrounds this area. I recommend it for pros and novices alike.

This is my first book in the dummies series.I being a technical guy, expected more working examples with explanation.But it is mostly theoretical. The case studies made interesting reading. This book will be suited for managers than technical persons.

This is a goog book to get the basics. Some of the analogies are really good, but they seem to repeat them over and over. Decent reference though

I suppose that, entering into any of the "Dummies" series, one should expect no more than introductory material, the corollary being that more detailed, technical knowledge would lie elsewhere. Thus it is with this book. If you are prepared for a surface buzzing of a broad range of topics relevant to SOA, including such useful matters as the business justification, the parts of an SOA necessarily to make it all work harmoniously, and even the different philosophies from various vendors (Oracle, SAP, etc.), then you'll be happy with this book. If, however, you're looking for a comprehensive treatment, that might begin with the business aspects and general structure, but then dive into the technologies, you'll find this book a disappointment.

I have two specific criticisms that cause my rating to be only three stars:
(1) while the textual coverage of SOA components--governance, security, the repository, and the registry, etc.--is clear, I quite wish that the diagrams were true architecture diagrams, UML-based. The material would have been clearer had it been represented with use case diagrams, activity diagrams, and sequence diagrams, instead of rectangles with lines between them.
(2) My other criticism goes to the gap between what the table of contents suggests, vs. what information the book delivers. That is, when a prospective reader is deciding whether to invest time in a book, typically the table of contents yields reliable information. Sometimes, though, a table of contents overreaches what the book itself is able to achieve. Such is the case here. For example, the Part V table of contents suggests that within would like a treatise on each major vendor's approach to SOA, including IBM, HP, BEA, Oracle, SAP, and JBoss. Alas, the details were too sketchy to be useful.

In brief, then, if the reader is willing to invest eight hours (that's how long this reader required, cover to cover) to gain a broad understanding of SOA, then this might be the book for you. If you're looking for a detailed treatment, or a comprehensive guide, look elsewhere.

It has been a few years since I worked with Web Services so I was looking for a book that would get me started again. This book did the trick. In addition to the ramp up, I also appreciated the end material including chapters for each major SOA vendor and a good glossary.

Reading this book may provide you with a few good buzzwords at IT cocktail parties, but forget about understanding what SOA is, and how it gets done in the real world.

Having worked in the IT industry as a consultant and executive for a long time, and having been on both sides of the business/technical divide, the title of this book intrigued me. So I thought I'd give it a shot, to see how SOA might be simply explained from a business, non technical point of view. But after reading the first 150 pages of the book and skimming through the rest, I quicky realized the book is useless. Both for business oriented people, and even more for technical people. In fact, the single web page SOA entry at Wikipedia will provide one with more knowledge and understanding of SOA than this whole book, in probably a 10th of the time.

SOA is real, (Amazon and Google are first rate implementation examples) but you would not know this from this book. Nor know how to go about implementing it. Extremely verbose and vague, the book contents seem to epitomize the bad rap executive level consultants sometimes get when they are accused of being payed large sums of money for essentially engaging in buzzwords compliance, all with dubious results.

Next time someone asks you if your enterprise is doing SOA, just say: "Of course we are! We have been re-orienting our IT infrastructure towards a business service centric architecture, with loosely coupled reusable software components!" And if you get paid for your answers, you can keep going on and on with similar language based on each of the words above.
Heck, if you are a consultant, you could even write an entire book! That will be good advertising for your business, and at 300+ pages, nobody will suspect that your understanding of SOA is conceptual and superficial.

This is a good SOA start book
I recommend it to beginners
Easy to read and flows nicely

A very good book for anyone starting on SOA.I have bought this book for IBM 669 SOA Certification and it is helping me quite a bit.REcommend to others also

Not really worth the time to read (let alone the expense). Covers the basics but not well enough to make a lasting impression and is somewhat miss guided towards a vendors rather than practitioners view of Service-oriented Architecture.

I have found more useful information free on the web - just started out with Wikipedia and went from there.