This chapter has provided the background information you need to narrow your search for a Web services application development product suite or platform. Its aim is to steer you toward the best vendor with the best approach to meet your particular Web services application development needs.
In this chapter you learned that there are several ways to obtain Web services. First, you can buy a Web services application server environment (from either a hardware/software/services supplier or a software platform maker). Second, you can build one yourself, using a la carte programs or
If you look closely, you'll see that few vendors offer a comprehensive Web services development platform with full support for UDDI, WSDL, and SOAP. But
This book has addressed 10 questions that non-technical business executives would likely ask about Web services. The answers to these questions would help them understand the following:
The definition of Web services.
How Web services work.
What the benefits of using Web services would be to their respective organizations.
Who (what other accounts) are using Web services (and for what purpose).
Where the "gotchas" are with this evolving new architecture.
What the buying criteria and buying approaches are, should an organization wish to purchase the hardware, software, and/or services needed to build Web services solutions.
With this background business executives should now be prepared to make complex decisions like "when to deploy Web services" or "which applications are candidates to become Web services applications."
This book has been organized into three
This part focused on "setting the stage." It defined what Web services are, how they work, and why previous attempts at providing such services have
Chapter 1 presented a comprehensive view of the evolving Web services architecture.
From this author's perspective, the bottom-line simplest definition is that:
Web services are a distributed computing architecture that relies on loosely
Chapter 1 focused not only on the various technical
Chapter 2 explored how program-to-program communications work in order to offer business executives a better understanding of how programs can communicate with other programs over the Internet. It examined some of the previous program-to-program schemes of the past to show why they did not
This background should prepare you to: (1) handle objections that your company has "been here before" and (2) convince colleagues to get active in developing Web services applications for your company's strategic and competitive well-being.
This chapter also
Chapter 3 reviewed how Web services actually work from a technical perspective. This chapter was designed for business executives who
The most basic elements of a Web services architecture are (1) a common format, (2) a means for applications to "talk" with each other, and (3) a common network. XML, WSDL, and SOAP over an Internet network (using HTTP) enable these three things to happen. A UDDI registry is nice to have, but other work-arounds such as hard-coding the location of services applications can suffice when creating simple Web services application environments.
The big message to take away from this chapter is that, owing to certain immaturities in the overall readiness of Web services as an "enterprise-class" architecture, many early adopters are making use of other protocols or architectures to supplement Web services. For instance, if an enterprise wants to send XML transactional data to its business
The same holds true for directory/registry services. Many applications today are actually "hard-coded" (their location will be known by the requester program, because it will be written into the requester program itself). Over time, as UDDI registries mature and proliferate, Web services applications will be able to automatically find each other. Until then, however, a lot of manual coding will be taking place to enable applications to find and bind with each other.
All too often books on Web services overlook some of the shortcomings of today's state-of-the-art. In Chapter 4 you should have learned that Web services are great as a messaging architecture—but need improvements if they are to be used in enterprise-class, robust, reliable application environments. Amid all of the excitement and hype about Web services it is important to ground one's hopes and expectations for this architecture. Web services hold great promise—but they have quite a bit of maturing to do.
From a "great-promise perspective" Web services are expected to
Also, note that most Web services shortcomings can be
Chapter 6 is based on direct interviews with Web services users. And the research
On the "pleasant surprise" side, the example of InterPro Partners was quite exciting. It showed InterPro using Web services protocols and registries not only to build Web services but also to create a radically new business model. (And this model gives InterPro very distinct advantages over its competition.)
Other examples were also exciting, but InterPro stood out because the company
Chapter 7 discussed "when" the appropriate time is to implement Web services.
To get started, business executives need to determine the technical competence of their own application development staff (particularly in the areas of object-oriented programming as well as in messaging architecture).
To help illustrate when Web services should be used, this chapter asked, "Where are they being used now?" Enterprises are using Web services now for B2B transactions, for consolidating vast libraries of object code, to help reduce application development expenses, to
The third part of this book focused on providing business decision
In Chapter 8 you learned that there are three basic approaches you can use to build Web services:
Buy a complete application server environment . These come in two flavors: (a) a complete hardware, software, and services platform (from companies like IBM, Sun, and HP); and (b) a software (and sometimes services) approach that involves purchasing a complete application development environment that can be run on various hardware and operating systems environments (from companies like BEA and Microsoft). (Note: Microsoft will someday make its .NET products available on Linux.)
Buy a series of point products and build your own Web server environment . This "a la carte approach" can be considerably less expensive but usually involves more integration work on the buyer's part in order to build sophisticated Web services applications. Also note that open-source Web services software can be obtained, serving to further lower the cost and expense of developing and deploying Web services applications.
Buy professional services . This approach advocates finding a professional services company that has expertise in Web services (a bit of a challenge at the time of this writing) and letting that company design, build, deploy, and possibly manage (outsource) your Web services applications. Though this approach does not quite have legs at present, expect Web services application development to be a high-growth area over time for professional services companies. (And the more professional services firms that participate, the more competition there will be—which should help lower your development costs.)
You should have walked away from this chapter with an understanding of your purchase options.
Chapter 9 discussed the market
The basic market belief is that the Java approach already offers cross-platform capabilities (because cross-platform code portability is central to Java's design goal), whereas Microsoft's .NET is focused on Intel platforms and has not been designed to promote code portability. This belief may or may not be true—but one of the key points in this chapter is: "It doesn't matter!" Why not? Because Web services enable applications to talk with other applications regardless of the platform on which the respective applications are running, and regardless of the application development language each application uses. So, to this author, the J2EE versus .NET discussion is a bit of a red herring.
Having said this, the chapter offers third-party Java opinion and a Microsoft response as to how the two approaches
Chapter 10 explicitly set out to avoid declaring winners and losers in the Web services race. It is this author's basic belief that consumers of Web services win when there are many vendors that have rich Web services offerings—we don't win when one or two vendors lead the pack (because then there is no one to really
Having this as a goal, some vendors are further along in the sophistication of their product offerings and the level of integration between Web services development environments and ancillary software, such as business process management, personalization, and the like. This chapter presented individual vendor profiles that portrayed each vendor's market strategy, the status of each vendor's product set, and the respective competitive positioning—then concluded with a short summary evaluation of each vendor. No winners or losers were chosen….