Architecting Web Services

Rating:
Summary: This is a five star architecture/design book
Review: Apparently there is some confusion regarding the purpose of this book and Web services in general. Web services are code neutral and should be treated as a design paradigm. At the coding level, you are only required to know two things: how to utilize a transport protocol operating on top of IP, and XML basics. Therefore, this book focuses on architecture and design processes and not code.

The introductory chapters quickly cut through the hype and define the scope and definition of a Web service. Like COM and CORBA, they allow the sharing of processes between remote applications. Unlike COM and CORBA, the communication is stateless and the specification is text-based and not binary. This is the primary strength of Web services, as it removes the barriers imposed by various operating systems. All you need to implement them is an HTTP server with a scripting language. After the definition, the book provides a quick primer on XML and schemas. It then covers the design issues involved with Web services and security. The next couple chapters cover the creation and use of three different services. The book ends with a current (as of July 2001) description of the emerging technologies and competing Web service standards.

One final thing should be noted. The author has actually hosts a server exposing Web services for the reader to code clients against. ... The site also provides all sample code and test clients to test with. I have never had a book provide me with a server to test against. Given this, along with the superb content, I give the book 5 stars.

Rating:
Summary: Long-winded, tied to Websphere and VAJ
Review: If you want to learn how to architect a web system instead of slapping one together start here. Some of the advantages of reading and applying this book is it is not tied to a specific web service platform and it views web architectures as a series of building blocks called services. This accomplishes two things: it allows the architect to pay attention to architecture instead of development, and it allows the architecture to proceed without the distraction of system limitations and constraints. Done right the constraints, performance and scalability issues and other real world details will be handled by the technical design team, where trade-offs in development and platform specifications are made.

I like the way Mr. Oellermann compares Web services to CORBA in such a way that those familiar with object request brokers in general will see that web services at the architectural level should be treated as objects that are the building blocks of a total system, with services managed and arbitrated in a controlled fashion that not only promotes Mr. Oellermann's premise for reusability and efficient development, but in finer detail in matters such as configuration management, effective build analysis and streamlined regression testing. These alone show the author's high level of real world experience and his deep knowledge of software engineering. Another strong point is the wide array of architectural models that are given. This, and the fact that all of the examples are independent of a single platform, show that a good architecture is not based on an single magic solution, but does involve trade-offs and an intelligent review of constraints even at the level of abstraction that architects work at. This is reinforced by the way business models and other realities are treated at a high level because no single book could hope to cover all possible architecture/business model or system goals combinations.

This book hands you the process and a lot of examples, but it does not promise to do your thinking for you. Like any profession, tools alone will not produce a masterpiece--you have to have a blueprint, understand how to use those tools and apply logic and deep thought. Architects with more than one project in their portfolio will see the beauty in this book's message and should appreciate the blueprint and tools that Mr. Oellermann is sharing in the form of this book. If you have no exposure to process, architectural principles or have no interest in proven blueprints and tools that require your effort to intelligently adapt them to a given situation you are not going to be happy with this book. On the other hand, if professionalism, process and methods are important and you are a web architect this book will save you a lot of time and transfer to you a lot of the author's knowledge and experience.

Rating:
Summary: Turns theory into practice
Review: If you want to learn how to architect a web system instead of slapping one together start here. Some of the advantages of reading and applying this book is it is not tied to a specific web service platform and it views web architectures as a series of building blocks called services. This accomplishes two things: it allows the architect to pay attention to architecture instead of development, and it allows the architecture to proceed without the distraction of system limitations and constraints. Done right the constraints, performance and scalability issues and other real world details will be handled by the technical design team, where trade-offs in development and platform specifications are made.

I like the way Mr. Oellermann compares Web services to CORBA in such a way that those familiar with object request brokers in general will see that web services at the architectural level should be treated as objects that are the building blocks of a total system, with services managed and arbitrated in a controlled fashion that not only promotes Mr. Oellermann's premise for reusability and efficient development, but in finer detail in matters such as configuration management, effective build analysis and streamlined regression testing. These alone show the author's high level of real world experience and his deep knowledge of software engineering. Another strong point is the wide array of architectural models that are given. This, and the fact that all of the examples are independent of a single platform, show that a good architecture is not based on an single magic solution, but does involve trade-offs and an intelligent review of constraints even at the level of abstraction that architects work at. This is reinforced by the way business models and other realities are treated at a high level because no single book could hope to cover all possible architecture/business model or system goals combinations.

This book hands you the process and a lot of examples, but it does not promise to do your thinking for you. Like any profession, tools alone will not produce a masterpiece--you have to have a blueprint, understand how to use those tools and apply logic and deep thought. Architects with more than one project in their portfolio will see the beauty in this book's message and should appreciate the blueprint and tools that Mr. Oellermann is sharing in the form of this book. If you have no exposure to process, architectural principles or have no interest in proven blueprints and tools that require your effort to intelligently adapt them to a given situation you are not going to be happy with this book. On the other hand, if professionalism, process and methods are important and you are a web architect this book will save you a lot of time and transfer to you a lot of the author's knowledge and experience.

Rating:
Summary: Finally! Something for Architects
Review: One thing that I really liked about this book was the fact that it was not your typical "Here's how you build a Web Service and you can learn how in less than a lunch break!" This book is for those who are serious about building Web Services. Not only does William show you different implementations, but gives you the architectural guidance that most (if not all) other books on the subject lack. This book is definitely not a re-hash of some help file or article, but a clear, concise way of designing and architecting Web Service solutions. Not only do I have a book for myself, but have another one for my team I work with. This is one book you must get if you are serious about building Web Services.

Rating:
Summary: No coverage of SOAP, WSDL, UDDI, or standard Java APIs
Review: The author has chosen to build his own completely customized web services architecture. He doesn't even mention SOAP, WSDL, UDDI, or any of the standard Java APIs: JAX-RPC, JAXR, or JAXM. Instead, he designs his own protocols using XML and servlets. Unless you're looking for job security by writing software noone else understands, skip this book.

At this point (June 2002), your best bet for learning Java web services is to download Sun's Java Web Services Developer Pack and go through the tutorial. The best book I've seen is "Building Web Services With Java" (Sams) but the book just skims most of the APIs because they're so new. But it has good coverage of SOAP, WSDL, and UDDI.

Rating:
Summary: Not a How-to-Code Book
Review: The theme of this outstanding book is not coding, although developers will find the contents useful. The ideal audience includes (1) architects who are seeking a coherent paradigm against which web-based systems can be designed, (2) developers who are seeking an approach to developing reusable code, and (3) 'software factories' and integration companies that develop components for resale of license.

Key strengths of this book include: Clearly defined definitions of web services, which set the context of the book, code examples that are provided using Websphere and ASP (the dual examples remove any bias towards any specific vendor, especially since the Websphere examples are generic enough for any shop using Java), all code and accompanying artifacts are provided from the author's web site (ensures ongoing updates, errata and emerging information that was not available when the book was published), and text insets on almost every page that give the author's advice, his experience in a particular topic and clarifications of terms and approaches - these alone make the book a treasure.

What I like most about this book is the fact that it is comprehensive in that the services described are the foundation of any well-designed web architecture. The author does not pretend to have all of the answers or provide solutions, but he does give one of the best frameworks for designing a web architecture based on services that I've encountered. The framework itself is straightforward: Objective-> Solution-> Implementation-> Services, with the focus on services. If your interest is component-based software engineering or reuse economics you'll probably appreciate this book's value more than developers and architects whose objective is to design, build and implement a web-based system.

If you are working in an environment where you seem to be reinventing the wheel for each project the ideas in this book will give you a clear path for breaking that cycle. If you are an architect this book will provide you with a clear view of web-based architectures as a collection of services. If, on the other hand, you are a developer looking for completed code or how to do the basics this book will not meet your needs. I personally think that the author has provided a valuable addition to the growing body of knowledge of web software engineering, and I also applaud his success in tackling the daunting task of clearly articulating a complex topic and providing valuable example from two different development environments.

Rating:
Summary: Web services: beyond standards and tools
Review: There have been a lot of books on Web services and related technologies lately. Most of them are at about the same level of abstraction: focused on SOAP, UDDI and WSDL and the particulars about .NET, J2EE, etc. Those are good and useful books but there is also a need for books that get unstuck from that level. Architecting Web Services is one of those. Just as the name states, it discusses architecture more than other books out there. The implementation examples are oriented toward understanding principles rather than technical nuance (the geekier books are better for that). I also found the final chapter useful in summarizing the state of standards and product directions.

Consider this book if you're responsible not just for programming Web services but if you are responsible for, well...architecting Web services.

Rating:
Summary: Not about architecture or about web services
Review: There is a serious need for a book on architecting web services (WS) application. Unfortunately, this is not it. The author ignores standard industry architectures and protocols. He develops his own, non-standard technology architecture. He dismisses standards - essential for interoperability and reusability - in a short chapter at the end of the book. If you want to understand how to architect web services, and even how they work, you will have to look elsewhere.

The emerging architectural paradigm for web service applications is based on SOA - Service-Oriented Architectures. This matches the approach taken to the industry technology standards which are designed to promote loosely coupled, distributed, componentized applications built from services. This architecture is closely related to the emergence of business modeling using domain ontologies which leverage the semantic web to help discovery of appropriate services. These may seem like academic buzz words now, but they are in actual use now in progressive companies and will shape application architectures over the next ten years.

Unfortunately, this author seems completely unaware of these cutting edge developments. Instead, he takes the OSI communications layering protocol and tries to apply that. But the OSI stack is inappropriate: it was developed for a completely different job; it has no concept of business processes; the relationship between the layers are tightly bound, not loosely bound (as they are with WS); there is absolutely no notion of components. So instead of helping us architect web services, it actually forces us back into precisely the architecture paradigm WS were designed to avoid!

On the other hand, at the technology level, except for a cursory survery, he completely ignores UDDI, SOAP, WSDL etc, and builds a proprietary technology. Any good architect must understand these technologies: when we build houses from wood, we use one architecture; when we use concrete, we employ a different architecture. Brick buildings are designed differently from prefabricated ones. So it goes with Web Services. In order to adequately architect and design WS applications, a detailed knowledge of WS technologies is essential. And our author is no help here either!

Rating:
Summary: Disappointment
Review: There is a serious need for a book which really gives good architectural guidelines for the design and construction of web services. This is not that book.

While 'Web Services' remains ill-defined, industry consensus is gathering around a cluster of technologies which include HTTP, XML, SOAP, WSDL, UDDI and others. Obviously a bunch of technologies does not make an architecture. However, the author has chosen to ignore this consensus until the last chapter and step out on his own. So, if you want to learn about 'Web Services' technology as commonly understood, this book will not help you.

Perhaps its discussion of architecture compensates? Perhaps the technology is secondary? As is pointed out in some of the reviews below, technology is not enough. However, the author again decides to take his own idiosyncratic course. 'Web services' have emerged from the need *at the business level* to have a flexible, loosely coupled architecture in order to facilitate business process integration. Any serious architecture must therefore begin from this premise. Instead the author plunges into a discussion which is firmly rooted in legacy paradigms. In place of the Web Services 'Service-Oriented Architectures' (SOA) which are emerging, the author tries to take a networking architecture - the ISO stack - and apply it to Web Services. The result is only a partial, technology architecture, not a true software architecture.

There is not enough space to fully detail just how widely this book diverges from current industry direction and consensus. There is no mention of ontologies, RDF or the semantic web, all of which are major aspects of web services architecture and technology. Suffice it to say that this book addresses neither software architecture or Web Services as either are generally understood. If you rely on this book, you will end up performing the web equivalent of attempting to write object-oriented programs using structured programming techniques and COBOL. This is a serious exercise in driving into the future looking only into the rear-view mirror.

You would be much better advised to check out David Carlson's 'Modeling XML Applications with UML' for architectural insights and Steve Graham et al. 'Building Web Services with Java' for the technology.

Finally a word on the relationship between architecture and technology. There is undoubtedly a need for some abstraction beyond implementation technology, if a well designed application is to be built. However, every architect has to take account of the building materials which will be used: the architecture of a wood house differs from that built of brick and both in turn differ from one built from glass, concrete and steel. The software architect risks disaster if he or she believes the implementation technology is irrelevant to the architecture. Sometimes an ounce of practice is worth a ton of theory and an architect who tries to stay aloof from technology is endangering his or her project and the ability of the entire team to deliver. This doesn't mean that a software architect has to be the best developer, but it does mean that we have a responsibility to our customers and to our team to understand the tools and materials we shall be working with.

Rating:
Summary: Save your money
Review: This book is horrible. Save your money and buy a good book. Check out either Developing Java Web Services or Java Web Services Architecture.