Understanding Web Services

At its very simplest, a Web service is a Web-based application that can communicate and exchange data with other such applications over the Internet without regard for application, platform, syntax, or architecture. The Web Services technology is a new, standardized way of communicating betweenand integrating withapplications that connect to the Internet. Web services are made possible by industry standards such as the Transport Content Protocol/Internet Protocol (TCP/IP) and Hypertext Transfer Protocol (HTTP). Web services use additional agreed-upon standards such as XML for representing structured data; Simple Object Access Protocol (SOAP) for communicating data; Web Services Description Language (WSDL) for describing data and services; and Universal Description, Discovery, and Integration (UDDI) for locating published Web services in public or private registries.

Due in part to the attention Web Services has received, some of the biggest names in the IT industry are making these applications an important component in their platform architecture:

• Microsoft is reinventing its entire company around the .NET application architecture, of which XML Web Services is a significant part.

• IBM is striving to deliver the standards-based platforms needed to build and manage enterprise Web Services and integrated applications.

• BEA has incorporated significant support for Web Services in its flagship WebLogic Java Application Server.

Architecture is only one piece of the puzzle. Web services possess many capabilities that have the technology and business world excited. If a single "killer app" exists for the Web Services concept, it is probably in the arena of corporate integration. Linking business units, divisions, or related entities that utilize incompatible legacy platforms can be an extremely difficult job. Companies will often use a single vendor in an attempt to simplify Enterprise Application Integration (EAI) projects.

Web Services isn't a replacement for EAI, but may end up being the genesis of new and better EAI systems in the future. Web Services can streamline the integration of new applications among vendors, partners, and customers without the need for the centralized or proprietary software of EAI. Middleware is sometimes needed to bridge legacy applications and a Web Services interface. This middleware is not proprietary and need only support a limited set of protocols, such as XML and SOAP, in order to interact with the rest of the Web Services world. This allows disparate systems within a company to communicate with each other more easily than before and can also allow communication among incompatible systems across companies. This can significantly lower the cost of doing business, especially with companies that have adopted technology different from your own.

To get to where we are today, we need to look back at the evolution of the Web to see how the Web Services concept is a natural next step.

Evolution of the Web

In the beginning, people used their Internet browsers to access static information from university libraries or read brochures at commercial Web sites. Such was the earliest era of the Web. Soon every company needed to establish a "Web presence." The Internet at that time was something for people to "see." Figure 24.1 shows the type of interaction during that period.

Figure 24.1. Internet interaction of old.

Eventually people began using their browsers to interact. Message boards and email became more mainstream. Companies began to develop applications that provided useful functions, as opposed to the simple brochureware that had been so prevalent. These newer applications included e-commerce and customer service, as well as business intranets. The Internet was becoming something to "do." Figure 24.2 shows an interaction typical of today.

Figure 24.2. Internet interaction today.

With the advent of Web Services, the Internet may soon be seen just as much for interapplication communication as for e-commerce. In the not-too-distant future, virtually all business applications should be able to communicate and interact with all other applications via Web services using industry-standard protocols. The Internet will simply "be." Figure 24.3 shows a multitude of possible interactions available through and because of Web services.

Figure 24.3. Possible Internet interactions.

Business Models

Web services are attractive to businesses because they foster better communication within companies, and between companies and their customers and suppliers. As markets tighten and businesses need the capability to link up their systems quickly with those of other companies, Web services may give them the edge they need to survive.

There are many models for integrating Web Services technology into the enterprise. Here is a list of a few examples of these common business models.

Provider Model

The Web Services provider model describes a company that builds an application enabling the company to provide a value-added business service to other companies. As a Web service, the company can provide this service to any company capable of communicating via baseline protocols. This is advantageous because the provider can widen its base of potential customers while increasing efficiency and providing better customer service through enhanced communication with customers.

Consumer Model

The Web Services consumer model describes a company that uses existing Web services by incorporating them into new applications the company is building. This allows it to get its products or services to market faster while reducing operational and startup expenses.

Syndication Model

The partner or syndication model describes a company that sells a product using its own outlets and makes the product available via Web services to partners who can sell the product themselves or bundle complementary products or services together. This helps increase market penetration, and allows the repackaging of products and services in an almost infinite number of ways while taking advantage of a partner's customer loyalty.

Core Technologies

Web Services is based on an open set of ever-expanding industry standards and protocols. While more than a dozen technologies or methodologies could be considered core to the distributed architecture of Web Services, only a few of these technologies are absolutely central. Among these are HTTP, XML, and SOAP. Additionally, two descendant technologies, WSDL and UDDI, standardize the syntax for describing a Web service and its operations and allow for the querying and cataloging of corresponding files.

HTTP (Hypertext Transfer Protocol)

HTTP is a communications protocol for exchanging information over the Internet. It is the common transport mechanism that allows Web service providers and consumers to communicate.

XML (eXtensible Markup Language)

XML is similar to HTML in that it uses tags to describe and encode information for transmission over the Internet. HTML has preset tags that define how information is displayed. XML lets you create your own tags to represent not only data but also a multitude of data types. This ensures accurate data transmission among Web service providers and consumers.

SOAP (Simple Object Access Protocol)

SOAP is a lightweight protocol for the exchange of information in a distributed environment. SOAP can be used in messaging systems or for invoking remote procedure calls. It is based on XML and consists of three logical parts:

• A framework for describing what is in a message and how to process it

• A set of encoding rules for interpreting application-defined data types

• A convention for representing remote procedure calls and responses

SOAP handles the onerous job of translating data and converting data types between consumers and Web service providers.

WSDL (Web Services Description Language)

WSDL defines an XML-based syntax for describing network services as a set of endpoints that accept messages containing either document- or procedure-related information. See the "WSDL" section coming up.

UDDI (Universal Description, Discovery, and Integration)

UDDI defines a SOAP-based Web service for locating WSDL documents. UDDI was proposed by IBM and Microsoft and is supported by many other software vendors. Public UDDI registries allow you to publish your Web services and query existing WSDL documents. Macromedia ColdFusion MX does not directly support UDDI, so you must register a service or search a registry manually.

NOTE

For more information on UDDI, visit www.UDDI.org. To search existing UDDI registries, visit http://uddi.microsoft.com/, www.ibm.com/services/uddi/, and www.xmethods.net/.

Figure 24.4 shows http://Xmethods.net, a public UDDI registry.

Figure 24.4. The Xmethods.net UDDI registry.