II. Introduction
--------------------------------------------------------------------------------
The next generation of distributed computing has arrived. Over the past few years, XML has enabled heterogeneous computing environments to share information over the World-Wide Web. It now offers a simplified means by which to share process as well. From a technical perspective, the advent of web services is not a revolution in distributed computing. It is instead a natural evolution of XML application from structured representation of information to structured representation of inter-application messaging. The revolution is in the opportunities this evolution affords.
Businesses have been offering products and services on the World-Wide Web for the past few years. Have they not then been offering web services? In what way are web services actually new? In an article entitled The Web Services (R)evolution - Applying Web Services to Applications" Graham Glass, the CEO and Chief Architect of The Mind Electric defines a web service as:
"A collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide."3
Prior to the advent of web services, enterprise application integration was very difficult due to differences in programming languages and middleware used within organizations. The chances of any two business systems using the same programming language and the same middleware was slim to none, since there has not been a de-facto winner. These 'component wars' spelled headaches for integration efforts, and resulted in a plethora of custom adapters, one-off integrations, and integration 'middlemen'. In short, interoperability was cumbersome and painful.
With web services, any application can be integrated so long as it is Internet-enabled. The foundation of web services is XML messaging over standard web protocols such as HTTP. This is a very lightweight communication mechanism that any programming language, middleware, or platform can participate in, easing interoperability greatly. These industry standards enjoy widespread industry acceptance, making them very low-risk technologies for corporations to adopt. With web services, you can integrate two businesses, departments, or applications quickly and cost-effectively.
The vision for web services predicts that services will register themselves in public or private business registries. Those web services will fully describe themselves, including interface structure, business requirements, business processes, and terms and conditions for use. Consumers of those services read these descriptions to understand the abilities of those web services. Web services will be smart, in that once a service has been invoked, it will spontaneously invoke other services to accomplish the task and to give users a completely personal, customized experience. In order for these services to dynamically interact, they need to share information about the user's identity, or context information. That context information should only need to be typed in once, and then made available at the user's discretion to selected web services.
Building web services with technologies that have gained the most acceptance
Now that we've seen the general philosophy behind web services, let's look at how to build and use a web service. Web services are in reality simply XML-based interfaces to business, application, and system services, and are really old technologies wearing a new hat. The following technologies that have gained the most industry acceptance, and is one possible way to perform web services:
A provider creates, assembles, and deploys a web service using the programming language, middleware, and platform of the provider's own choice.
The provider defines the web service in WSDL (the Web Services Description Language4 ). A WSDL document describes a web service to others5.
The provider registers the service in UDDI (Universal Description, Discovery, and Integration6 ) registries. UDDI enables developers to publish web services and that enables their software to search for services offered by others.
A prospective user finds the service by searching a UDDI registry.
The user's application binds to the web service and invokes the service's operations using SOAP (the Simple Object Access Protocol7 ). SOAP offers an XML format for representing parameters and return values over HTTP. It is the communications protocol that all web services use.
Note that the above technologies are only sufficient for simple web services. Extended business exchanges require an agreed-upon structure for business transactions, multi-request transactions, schemas, and document flow. These application requirements often stretch the limits of a purely SOAP based implementation. This is the motivation for ebXML, which is a suite of XML specifications and related processes and behavior designed to provide an e-infrastructure for B2B collaboration and integration.
Note that the above approach is but one way of making web services work. There are other choices as well, but we feel that these technologies are the most important and will achieve the widest industry adoption. Because of this, in reality, we really haven't reached complete consensus on building web services, and there are still a lot of issues to be resolved. For example, there is vendor disagreement on SOAP extensions, ebXML, and service flow descriptions. The good news is that:
For once, all major players, including Sun and Microsoft, generally agree that SOAP, WSDL, and UDDI are good things and that they (or their standard derivatives) will provide a foundation for the future.
All the vendors are working together to establish web services standards, and a foundation is emerging.
The J2EE and Microsoft.NET approach to Web Services
If you want to build a usable web services system, there is more than meets the eye. Your web services must be reliable, highly available, fault-tolerant, scalable, and must perform at acceptable levels. These needs are no different than the needs of any other enterprise application.
J2EE and .NET are evolutions of existing application server technology used to build such enterprise applications. The earlier versions of these technologies have historically not been used to build web services. Now that web services has arrived, both camps are repositioning their solutions as platforms that you can also use to build web services.
The shared vision between both J2EE and .NET is that there is an incredible amount of 'plumbing' that goes into building web services, such as XML interoperability, load-balancing, and transactions. Rather than writing all that plumbing yourself, you can write an application that runs within a container that provides those tricky services for you.
This paradigm allows you to specialize in your proficiencies. If you were a financial services firm, for example, you'd have proficiency in financial services, but likely very little proficiency in web services plumbing compared to a specialist such as Sun, IBM, BEA, Oracle, or Microsoft. By purchasing the container off-the-shelf, you won't need to be an expert at plumbing to build a financial services-based web service. Rather you just need to understand their business problem at hand, and leave the web service plumbing to the container.
With that said, let's take a look at the details of each vision.
