A Review of Each Major Part of the Book

This book has been organized into three parts: a primer on Web services, an idea/strategic planning guide, and a buyer's guide. This chapter summarizes the highlights of each part, chapter by chapter.

PART I: A Web Services Primer

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 experienced limited acceptance. It also described shortcomings or "gotchas" related to state-of-the-art of Web services.

Definition

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 coupled applications to facilitate cross-platform program-to-program communications. These applications can use similar or diverse development languages and platforms to communicate with each other over the Internet.

Chapter 1 focused not only on the various technical components that make up Web services, but also on the ancillary programs and products sometimes needed to build complete and robust Web services environments. Web services architecture can consist of just the products and programs needed to implement a simple message-based architecture (UDDI, WSDL, SOAP with XML content and Internet delivery) or of all of these protocols plus other software to improve business process flow, make application development easier, ensure reliability/availability/security, and the like.

Program-to-Program Communications

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 garner tremendous market acceptance. This review of Web services history gives you, as a business manager or IS executive, the background you need to defend a decision to strategically embrace Web services architecture.

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 considered whether Web services are for real. For over 20 years, business executives and IS managers have heard vendors and standards organizations promise to make cross-platform program-to-program communications a reality and yet a simple, elegant, backed-by-the-major-players approach never materialized. Today, however, Web services hold great promise of becoming the simple, elegant, universally backed program-to-program approach to cross-vendor, cross-platform communications that we have long been waiting for.

How Web Services Work

Chapter 3 reviewed how Web services actually work from a technical perspective. This chapter was designed for business executives who desire to understand the basic Web services technologies and associated acronyms in greater detail.

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 partners, in many cases that data will be sent using EDI or CORBA protocols in lieu of Web services protocols. And this will continue to be the case until Web services reliability, security, and scalability mature.

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.

This chapter emphasized that using other protocols at this juncture is perfectly acceptable, given the comparative maturity of Web services versus the much stronger COM and CORBA programmatic interfaces and protocols. (The chapter also pointed out that these approaches were used because they were either expedient, preexisting, or cost-effective.)

Limitations, Shortcomings, and Gotchas

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 radically change the way that businesses can be structured and modeled. And, if properly designed and executed, Web services can help create additional business efficiencies, increase productivity, and provide new ways to bring products to market.

Also, note that most Web services shortcomings can be overcome using third-party hardware and/or software products. This is why this author believes that Web service can be used today in some mission-critical computing environments.

What Does Web Services Enable My Organization to Do?

Chapter 5 illustrated some things that are possible to do with Web services. This chapter offered theoretical examples to help you think about applying some of these ideas within your own organization.

Who Is Using Web Services: Real-World Examples

Chapter 6 is based on direct interviews with Web services users. And the research conducted to write this "real-world" chapter turned up some surprises. First, many early adopters were not using the whole Web services protocol and registry set to build their Web services applications. Second, no examples could be found to illustrate (a) how enterprises are using Web services to rapidly expand their existing applications portfolios, or (b) how enterprises are using Web services to create/overcome competitive pressure. The explanation seems to be that, at this juncture, Web services are not mature enough to warrant a complete redeployment of large enterprise application portfolios on a wide scale.

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 understood the importance of UDDI, was using Web services protocols, and was creating a whole new and competitive business model making use of new Web services technologies.

When?

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).

The next step is to find applications that your organization needs to implement and then determine if Web services could serve as a viable architecture for their deployment.

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 open new markets, and for certain consumer "valet" services. If your organization has initiatives such as these, and Web services is a viable architecture for the purpose of developing new applications to suit these initiatives, the time to start building Web services applications is now.

PART 3: A Business Executive's Buyer's Guide

The third part of this book focused on providing business decision makers with a description of the Web services/application server marketplace. It then examined products and services offered by many, randomly chosen vendors, focusing on market dynamics, architectures, competitive positioning, and related product offerings. The goal was not to declare "winners" and "losers," but to highlight the various approaches vendors are taking to bring Web services to market and then to review their respective product sets.

Vendor Selection Criteria: Three Approaches

In Chapter 8 you learned that there are three basic approaches you can use to build Web services:

  1. 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.)

  2. 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.

  3. 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.

J2EE versus .NET Market Dynamics

Chapter 9 discussed the market schism between Java 2 Enterprise Edition (J2EE) and Microsoft .NET. Essentially, vendors have centered on two approaches to delivering Web services a Java language-centered approach and a C# language approach manifest in Microsoft's .NET strategy. Vendors that have embraced the Java approach include Sun, Oracle, and IBM (and pretty much every other major player in the industry). Vendors that have embraced .NET include Microsoft and its many business partners. A few companies such as HP and Compaq do both.

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 differ.

Web Services Supplier Profiles

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 interoperate with).

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….



Web Services Explained. Solutions and Applications for the Real World
Web Services Explained, Solutions and Applications for the Real World
ISBN: 0130479632
EAN: 2147483647
Year: 2002
Pages: 115
Authors: Joe Clabby

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net