10 of 12 people found the following review helpful:
3.0 out of 5 stars
Not, December 15, 2002
This review is from: Web Services Explained, Solutions and Applications for the Real World (Paperback)
This book contains some useful information, but has several serious flaws. The useful information in the book can also be found in several other books and online sources, including the online excerpts from the book. The marketing hype for this book qualifies as false advertising, in my opinion. For example, "All you need to know to plan an intelligent Web services strategy", "Detailed guidance for choosing the right vendor", and "Up-to-the-minute comparisons of Microsoft's .NET and Sun's J2EE".
The book purports to offer a non-technical explanation of topics which are inherently technical. It contains a few simplifications of technical matters which are misleading in important ways. For example:
"The use of 'objects' is a fundamental concept in Web services, because it enables the assembly of large, compound applications faster than by today's monolithic methods. And, because programmers do not need to constantly recreate objects from scratch (they just plug in the appropriate object and away we go)..." (pg. 24)
Anyone who knows much about software engineering will know that this is very misleading. Code re-use is facilitated by object-oriented methods, but reuse is possible with non-object oriented methods, and is by no means guaranteed to be successful with object-oriented methods (...and away we go).
The book defines a Web service as an application or application component which makes use of XML, UDDI, WSDL, and SOAP. UDDI is "a 'registry standard' that allows applications to be listed and located". UDDI would allow applications to find services or components on the web in an automated fashion. Support for and use of UDDI is currently very limited. The author suggests that the current limited use of UDDI is a major drawback for web services in general. This too is misleading: there are many valuable web services which have been and will be implemented without using UDDI. For most current applications, UDDI would be of little value, because the task would remain for an analyst or programmer to determine whether and how the available services might be used.
The most serious flaw in this book is the editorial disaster which is Chapter 9, "Should We Adopt .NET, or J2EE?".
The 'objective comparison' of these 2 competing platforms for web services begins with excerpts from a white paper by the Middleware Company, which specializes in Java server-side application development. The author describes the paper as "fairly objective", an assessment with which I firmly disagree. Microsoft apparently sent a memo to the author, stating a number of disagreements with the Middleware paper. The author, Mr. Clabby, pastes excerpts from the Microsoft memo, mixed in with repetitions of the previously included material from the Middleware paper, in a confusing jumble. In my opinion, the Microsoft response incorporates some good points. Mr. Clabby should have taken the time to rewrite (and then proof-read) Chapter 9.
In the end, the book does not deliver "specific recommendations", but states (correctly, in my opinion) that what any enterprise should do about web services depends very much on the specific circumstances of that enterprise. These circumstances will include the particulars of the enterprise's business, and the readiness of the enterprise's technical staff to deal with web services. One recommendation I would make, and which this book implies but does not state explicitly is that for any enterprise, the time to start learning about web services is probably now. This book can contribute to that process, but parts need to be taken with a grain of salt, and it certainly does not provide "all you need to know"...
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No