Customer Reviews

Service Oriented Architecture For Dummies (For Dummies (Lifestyles Paperback))

5 star:		(9)
4 star:		(1)
3 star:		(3)
2 star:		(1)
1 star:		(2)

 

 

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.

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 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 ...".

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.

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).

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

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.

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.

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.