Web Services are a new technology that could revolutionize the way business-to-business and business-to-consumer services are provided. Web Services use a variety of technologies to allow two applications to communicate. However, none of these are new claims; what makes Web Services different from other similar mechanisms are the technologies which provide the service.
Web Services have at their core XML as a mechanism for communication. Ultimately, Web Services are based on three specific technologies: a mechanism to register a service, a mechanism to find a service, and a mechanism for two parties to communicate. Today, developers can use the Java 2 Enterprise Edition APIs and XML to provide Web Services. Such developments leverage existing Web sites and provide simple methods to extend, interconnect and publish existing J2EE-based applications in new and exciting ways.
In this article we shall examine traditional approaches to electronic collaboration, see the various system services required to solve collaboration problems, and examine how Web Services and J2EE provide these services. In future articles we shall look at each service in detail and develop our own Web Services on top of existing Web applications, exporting these services to the Web community at large.
Over the past six to twelve months we've begun to see a new Web programming paradigm, that of the Web Service. But exactly what are these Web services anyway? In a nutshell, Web Services are the natural evolution of basic Remote Procedure Calls. In fact, we shall see that Web Services are in fact not a much more advanced technology than RPC of the past, but similar concepts applied in new ways!
But what exactly is a Web Service in the first place? Well, I'm sure BEA, Microsoft, Ariba, HP, Sun and others all have their own particular definitions; however, for the sake of argument, a Web Service is three specific things:
These three properties, when used in combination, provide a new form of Distributed Computing environment. The difference between this computing environment and DCEs of the past is in standards and implementations. A standard definition mechanism, standard lookup services, and standard transport definitions via Simple Object Access Protocol (SOAP). All of which are provided without concern for the underlying implementation mechanism. What makes Web Services so cool is that, at least in theory, a Web Service written in C and running on a Microsoft IIS can access a Web Service written in Java and running on BEA WebLogic Server. All without concern for how each Web Service is actually implemented.
These three components of our new DCE can be as simple or as far- reaching as required. For example, both UDDI and ebXML provide similar services, one for the more simple cases, the other the more complex. Before we get into more specifics on each of these services, let's look at the standard Web Services model.
Figure 1 shows a diagram many of us have seen in one form or another over the past few years. But what exactly does figure 1 represent? First and foremost we have a service provider. Service providers hosts any number of services, some of which are exposed as Web Services. Secondly, we need a centralized service repository for publishing information that clients can use to find information about published Web Services. And finally, we need various mechanisms to find and access the services.
Learn more about Web Services at the O'Reilly Peer-to-Peer and Web Services Conference, in Washington, D.C. on September 18-21, 2001. Network with the most innovative technologists, Internet business developers and lawmakers while exploring the next generation of the Internet.
In a moment, we'll look at each of the underlying standards that a Web Service relies on to function. But first, let's look at the figure in general and understand what's going on.
Nothing about Figure 1 is new. In fact Sun/RPC, DCE/RPE, DCOM and EJB all provide similar services. The difference, however, is in the how these services are provided. Traditional RPC services require similar underlying architecture, byte formats, etc. For example, in order for two divergent RPC implementations to interoperate, both must provide mechanisms for communication. Such communication was historically poorly defined and required a large amount of care and handling in order to make the two systems interoperate.
Web Services differ from traditional RPC mechanisms in many different ways:
All of this background is important and leverages why Web Services are as they are. However, we need to look closely at the underlying mechanisms which provide the basis for Web Services and why they are fundamentally different from past DCE and RPC mechanisms.
Web Services have as their core a fundamental set of functionality based on XML. XML is a wonderful technology, and it has really found a home in Web Services. Let's look for a moment at the process of data passing to understand just one area where XML excels. Historically, in order for two systems to communicate, they needed to be tightly bound. One area where such a tight binding occurred was with respect to data passing. Data needed to be placed onto the wire in a fashion such that both ends of the pipe could understand and read the information. Such problems let to a solution called "Network Normal Form." Network Normal Form was a format that allowed Bytes, Integers, Floats, Doubles, etc. to be placed on the wire in a format that both sides could understand. However, it had a number of drawbacks. Any number of complicated schemes had to be devised in order to make sure that data was packed together correctly: that each side knew how to pack and unpack the data; that everyone agreed on the format. All because no common data-representation and -definition mechanism existed. XML changed all that by providing a well-defined data representation as well as a well-defined set of validity and well-formed rules. As a result, XML is an excellent vehicle for packing data in a fashion that both ends of the pipe can easily read and understand. XML does have its drawbacks; for example, it's very verbose. But such verbosity is a rather small price to pay with today's high-speed networks.
Historically, defining what both ends of the pipe look like in a traditional RPC or DCE environment was problematic at best. Various incarnations of Interface Description Languages (IDLs) exist, but always start attempting to define the interface first, and then develop the implementation second. The Web Services Description Language (WSDL for short, and often pronounced wisdel) takes a different approach in that it fully specifies, in XML of course, the interface to an existing application, a new application, or anywhere in between. You needn't generate the interfaces from the IDL, as we did with CORBA and other RPCs, nor generate the interface from the code, but rather define the interface with WSDL. WSDL defines the syntax, the semantics, and all the various administrative aspects of a Web Services procedure call.
Specifically WSDL provides a number of key pieces of information:
<message>elements and appropriate schema definitions.
<service>element: that is, who provides the service.
<binding>element, that is how the service is accessed.
<element name="tickerSymbol" type="string"/>
<element name="price" type="float"/>
<part name="body" element="xsd1:TradePriceRequest"/>
<part name="body" element="xsd1:TradePrice"/>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
We now know how to pass data, and how to define interfaces, but we've neglected the client and how it finds and binds to a service. Enter UDDI and ebXML.
In order to actually use a service, a client must first find that service, retrieve information about how to use the service, and understand who might provide the service. The Universal Discover and Description and Integration specification, or UDDI, defines a number of lookup services aimed at allowing clients to look up and retrieve the required information to access a Web Service.
UDDI actually provides three specific services:
Vendors who provide UDDI services typically operate a service known as a UDDI Business Registry, or UBR, which can be accessed to both publish and request information about a given Web Service.
We now understand three things: how a Web Service is defined, and where it can be published and accessed. But we've left out one crucial aspect of the puzzle: how do we actually access the service once we've found it? Web Services become accessible using a protocol known as the Simple Object Access Protocol, or SOAP. In fact, you normally access a UDDI registry using well-defined SOAP calls! But what is SOAP? SOAP, at its simplest, is a protocol for encapsulating a request as an XML payload using standard communications protocols such as HTTP. The power of SOAP comes from the fact that is simple, easy to implement, and well supported in the industry.
Typically, a SOAP call is packaged as the body of an HTTP request. The listing below, from the W3C SOAP specification, shows an example of a SOAP call to access a service known as
GetLastTradePrice as an HTTP server might receive it.
POST /StockQuote HTTP/1.1
Content-Type: text/xml; charset="utf-8"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
SOAP supports both synchronous and asynchronous call semantics; that is, standard RPC as well as message-based, and can be used with a variety of protocols other than HTTP.
The first practical Web Services will be one-to-one, client/service provider-style interactions. The Web Services of tomorrow will be complete mutli-participant systems requiring security, transactions supporting very complex interactions. In our next article we will example the various Java APIs for using Web Services in a J2EE-compliant application server and begin developing our own custom Web services.
Return to ONJava.com.