Architecture & DesignBook Review: Web Services and Service-Oriented Architectures: The Savvy Manager's Guide

Book Review: Web Services and Service-Oriented Architectures: The Savvy Manager’s Guide

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Web Services and Service-Oriented Architectures: The Savvy Manager’s Guide

By Douglas K. Barry
Morgan Kaufmann Publishers
ISBN:1-55860-906-7, $34.95, 200 pages

Service-Oriented Architecture (SOA) is an emerging technology. But it has not yet fully emerged out of the academic and research-labs closets. The book under review is the first accessible introduction to Service-Oriented Architecture (SOA) and brings the technology a step closer to limelight.

The book is directed towards managers, planners, and architects who may be in a state of FUDS (Fear, Uncertainty, Doubts, and Shock) at being suddenly confronted with a new paradigm. According to the author (and many other industry experts) SOA is going to change the way we develop and use software. This has implications for every aspect of an IT-professional’s life – social, psychological, and technical. The author addresses all these issues very well and does succeed in reducing the FUDS factor considerably.

The basic tenent of SOA is that at long last we should be able to develop and use software just as we develop and use hardware, namely, develop packaged and fully functional components and assemble them together just as we would do for hardware components of TV, stereo and so forth. This has always been the goal (the holy grail) of software but with hindsight we can say that objects, EJBs, and frameworks have been only steps in the right direction rather than “mission-accomplished”. The missing piece in the puzzle had been a concrete and universally accepted implementation of SOA. Web Services is this long-awaited implementation, which would usher in the era of packaged and pluggable software.

SOA can be implemented in many ways. Three common implementations are CORBA, JINI, and Web Services. Other implementations are possible. Thus the first thing to remember is that SOA is the basic idea and Web Services is a particular implementation of it. But the terminological confusion does not end here. Web Services themselves must be distinguished from services. Services have always been with us. Any software application worth its salt must provide some useful service. But till now these applications and services have been islands to themselves. Applications and the services they provided could not communicate with each other or use each other’s services in a mutually beneficial manner. Web Services (WS) has gate-crashed it way to change this. In other words, Web Services is a connecting technology, an integration technology. Before Web Services, there were zillions of applications and services but they could not talk to each other. Now, thanks to WS, they can talk to each other and use each others services like human beings do (“You serve me a hamburger and I will serve you a massage”). So the term Web Services does not make it clear that it is an integration technology on par with rivals like Java’s Connector Architecture and Jini, though in this respect term Jini is worse than term Web Service.

The reason WS is expected to be a winner implementation of SOA is that it is based on universally accepted technologies like XML and SOAP, which should now stand for Service-Oriented Architecture Protocol. Without universal acceptance (Universe = MS +SUN ) and standardization WS have no chance of success. I hope IBM won’t lynch me for being sidelined to the fringes of the universe!

The integration mechanism of Web Services is expressed by the now famous triangle: publish-find-bind. In short, a sevice publishes itself in a UDDI directory (yellow pages), another service which needs this service looks up its “address” in the yellow-pages (find), and then contacts it directly (bind).

Doug Barry goes to great length in encouraging managers, planners, and architects not to be afraid of new ideas and directions. To eliminate FUDS he suggests a step-by-step approach to WS. A team can start by using the web services available on the Internet, and then develop simple web services of their own which are not mission-critical. This would provide enough confidence to team members to finally start developing mature web services and integrating them with those available on the web. But even the mighty Barry cannot eliminate the ‘Fear’ factor in FUDS entirely. He admits that there is a genuine fear that jobs would be lost in the era of packaged and pluggable software and many experts would be made redundant. But this phenomenon has been with us since the arrival of the industrial revolution and the demise of the guild masters. But history has shown that the loss of some jobs is balanced by the creation of other jobs. How far history would repeat itself during the post-dotcom revolution remains to be seen.

The main thing I did not like in the book is that the author does not mention J2EE or JINI at all even though there are scores of references to CORBA and DCOM. I hope SUN lynches him for that.

Finally, I conclude with a “historical comment”. The publish-find-bind triangle of SOA predates modern science. Since time immemorial, arranged marriages have been executed using this mechanism. Thus this triangle should rightfully be called ” the holy matrimonial triangle”.

Rattan Mann,
Oslo, Norway

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories