Introduction

The industry's need for Web services first dawned on me in November of 1999. My realization of their potential has been growing ever since.

At the time I was a consultant struggling with the issues around B2B adoption. I was trying to figure out why, despite the obvious value of B2B automation on paper, only a very few organizations were actually using it. Having grown up with the Web professionally, I related it directly to the massive rush that occurred once companies felt the need to build Web sites. Why wasn't the same rush occurring in B2B?

I identified two main barriers to B2B adoption, one political and the other technical. The political barrier is that B2B takes two sides working together, which always bogs things down. This is made even more complicated by the technical information that has to be communicated between organizations.

The technical barrier is that building these programmatic links between organizations is neither standardized nor easy to implement. Whereas Web pages are easy to build, B2B partnerships are not. HTML is one of the easiest technologies for non-technical people to pick up. Countless people have become IT professionals by first dabbling in HTML and then expanding into other technologies. While anyone can view a Web page, a business transaction is a concept that has to be envisioned. That makes it difficult for business professionals to understand and technical professionals to consistently implement meaningful Web services.

Since becoming aware of Web services and their value, I have been very focused on this area. I have had the privilege of speaking with many organizations on this topic, giving several technical presentations and even designing and deploying a few Web services. I have collected quite a bit of information on the topic and wanted to share my experiences and opinions with the industry to help contribute to the understanding and appreciation for Web services. This book is a culmination of those efforts.

Why Architecting Web Services?

Several vendors are planning and releasing tools and services for their approach to Web services. While each has benefits and shortcomings, there is one area that applies to all of these implementations: architecture. I don't believe that people can rush out and build successful Web services without thinking about the architecture for this new development paradigm.

This book addresses these architecture-level issues, or at least the ones I have identified up to this point. This paradigm borrows a lot of its behavior from Web sites and a lot of its behavior from application development. Web services is a blend of these two areas, and people need to have a good understanding of which concepts can and should be applied from each to build meaningful Web services.