Foreword
OK, Rome wasn't built in a day, but once they got the sucker up and running, it was magnificent and, hey, it's still there and functioning quite nicely. Having first heard about Web services toward the end of the last century, I would have thought by now they would be ubiquitous. At this point in time, I should be able to replace My Yahoo with a personalized Web services portal uniquely suited to my quixotic needs and desires. Years ago, I started planning this portal when I heard Bill Gates waxing poetically about Hurricane a.k.a. "My Services" which was Microsoft's vision of creating a suite of personalized Web services for early adopters like me. Unfortunately, Microsoft abandoned this effort when critics complained it was really an insidious plot to own people's personal information. Mostly by pure dumb luck, I've been at the forefront of technology for most of my life. As a young man just out of college, I was working in Albuquerque, New Mexico, at a small company called MITS which, with a little help from a then 19-year old Bill Gates and his buddy Paul Allen, started the personal computing revolution. Taking advantage of this happy situation, I leveraged my background in media to launch a magazine called Personal Computing. These experiences led me to found a number of other magazines including PC Magazine, PC World, Macworld, Publish, NewMedia, and BioWorld. Most recently I was CEO and Editor of Upside Media, Inc. Throughout the years, I have been fortunate to have had a first-hand involvement in the evolution of many revolutionary new innovations, including the first personal computer (Altair), the first portal computer (Osborne), the first spreadsheet (VisiCalc), the Macintosh Computer, Multi-Media, the Internet, and even Biotechnology. To say that I have seen my share of "paradigm shifts" is an understatement. Technology innovation has been all around me. Who would have thought that a couple of guys in a small company in Albuquerque would start what would later become the PC revolution? Shouldn't it have come out of IBM or Xerox or some other big technology company? That's exactly the rub. Innovative ideas don't always come from the big companies, sometimes they spring out from the big guys and at other times they spring out from the little guys. Based on all the above, I am completely convinced that Web services will level the playing field between the little guy and the big guy as no technology has ever done before. Thanks to this new revolution, the mom-and-pop company down the street can market their innovative software and services to the neighborhood, to the global masses, as well as to the largest companies in the world. But, we're not only talking about the new and interesting. Even the most mundane and boring is supported. The procurement system of the mom-and-pop company can seamlessly interface with the billing system of a global multinational company and here's where things get really interesting. The systems of the multinational can also interface with the systems of the mom-and-pop company. The most innovative new systems to the most boring, existing tasks are all available on an anybody-to-anybody basis. This will ultimately happen but like many great technologies, it will require a lot of work and patience before the dream is truly realized. As Sandeep Chatterjee and James Webber so eloquently and clearly explain in this book, real world Web services and Web services-based applications can't simply be put together in a haphazard manner by merely reading through one of the Web services technology specifications. You need to be familiar with these standards and they are extremely important, but they only represent the basic building blocks. To "architect" and construct world-class enterprise services, developers need a much deeper knowledge of a number of different standards and tools plus their "inter-relationships" and best practices for use. Web services are small segments of larger applications and as such, quality-of-service issues loom large if they are to be truly useful and scalable. When building them, you have to factor in such considerations as: Availability (how often is the service available for consumption); Accessibility (can it serve a client's request now); Performance (how long does it take to respond); Compliance (is it really "standard"); Security (is it safe to interact with this service); Energy (suitable for mobile apps); and Reliability (how often does it fail). Like building Rome, building Web services gets complicated fast. So how do you architect an application to be reliable if some of the Web services you are depending on become unavailable? Can an application be written to seamlessly scale to support new Web services from an expanding group of strategic partners? What about transactional guarantees or atomic coordination between multiple, independent services? And can you accomplish your design goal and still provide adequate safeguards for corporate and individual information and intellectual property? I imagine that the software world would have given up in disgust by now, moved on to some new paradigm, except for two factors. The first is that all the major software companies are committed to Web services to the tune of several billion dollars, and the second is that Web services are, gosh darn-it, actually revolutionary. They are so revolutionary they represent a whole new amazing way of doing business, which will transform the software industry forever and change the very nature of the corporate IT department, thrusting it into the heart of strategic thinking. Web services build on and extend the Web application model by allowing any client application to access and use its capabilities. By implementing capabilities that are available to other applications (or even other Web services) via industry standard network and application interfaces and protocols, Web services represent reusable software building blocks that are URL addressable. We're talking here about a concept called "anybody-to-anybody" communications quoting from this book, "a person who implements a Web service can be almost one hundred percent certain that anybody else can communicate with and use the service." Chatterjee and Webber aren't so concerned, however, about Web services for the masses. They tackle a much more difficult topic, which is Web services for enterprises. These are services that have to be totally reliable, absolutely secure and extremely functional. Referring back to the "building Rome" analogy, these guys aren't really talking about building foot paths or neighborhood streets, rather they are more interested in the avenues, aqueducts, and other major arteries that seamlessly and safely interconnect the Porticus of Gaius to the Forum of Caesar the House of the Vestal Virgins to the Temple of Saturn, and back again. They are talking about the communication and transportation systems that made Rome the most magnificent functioning city of the Ancient World. In today's global marketplace, world class enterprises need to interconnect with their customers and partners internationally using legacy systems that are mostly incompatible with each other, and they need to do this relatively fast and as inexpensive as possible. Web services provide the solution but not without overcoming some fairly difficult obstacles. In the Web services world, nothing is as simple as it may seem. Take transactions, for example. Transactions are the bedrock on which B2B interactions rise or fall, they are a fundamental abstraction or requirement for what we sometimes refer to as "fault-tolerant computing." In a lucid and detailed style, the authors point out that the choices for transactions are scarce and, in fact, the OASIS Business Transaction Protocol (or simply BTP) is the "only Web services transaction protocol with implementation we can use today." They explain BTP and how to implement it, but just in case you get in over your head, they also suggest that unless you have specialist knowledge in this area, you should give "serious consideration" to buying or outsourcing it. As with transactions, this book goes into great detail to describe the Web services technologies and standards that can be used in the real world today. These address the most challenging enterprise requirements including conversations, workflow, security, the challenges inherent in the development of mobile systems, how to build user-facing portals by aggregating back-end Web services, and how to manage an ever growing number and type of Web services within the enterprise. But more than this, the authors tell you in a concluding section filled with source code and a step-by-step guide how to put this together. You'll learn how to actually develop a Web service application and deploy it onto the Tomcat application server and the Axis SOAP server (both freely available). The ambitious goal of Developing Enterprise Web Services: An Architect's Guide is to give readers a "thorough understanding" of the steps necessary to build and deploy Web services and client applications that meet enterprise requirements. This is a lofty goal indeed, and you'll want to spend some serious time going through all the clear and concise content that the authors have spent well over a year developing. I found it really amazing. Fortunately, with the publication of this book, the Web services vision is about to take a giant leap forward. We are building our "Rome" and the end is finally in sight. Chatterjee and Webber, drawing on their own impressive experiences building Web services, painstakingly provide their readers with concise, yet thorough understanding of the most important issues and their solutions. They unabashedly recommend best practices in application architectures, put key technologies together and show their readers step-by-step how to build world-class, enterprise Web services-based e-business applications. And darn it, it's about time we had a book like this! David Bunnell |
EAN: 2147483647
Pages: 141