Java and Web Services Primerby Al Saganich
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.
What are Web Services, Anyway?
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:
- A way to find and register interest in a service.
- A transport mechanism to access a service.
- A way to define what the input and output parameters are for such a service.
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.
- 1 represents a service provider publishing a service to an external repository. Once such a service has been exported to a registry, it can then be used by a client.
- 2 and 3 represent looking up a service from a repository and returning information about a service, respectively. Information, such as the format of the procedure calls and the address of a service provider, would normally be provided, amongst other details.
- 4 and 5 represent the client binding to an underlying service and then accessing that service to use whatever functionality the service provides.
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:
- Data is formatted for transfer using XML, improving or eliminating marshalling, unmarshalling, and various other translation-related requirements normally coded by a developer.
- Data is passed using standardized protocols such as HTTP or SMTP, which have published well-defined standards.
- The underlying exposed service is well-defined using a known accepted mechanism, WSDL.
- Services are found using a well-defined standard, UDDI, and the more advanced ebXML.
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.
First and Foremost, XML
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.
Defining a Service, Web Services Description Language
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:
- A definition of the format of the messages that are passed between two endpoints using its
<message>elements and appropriate schema definitions.
- The semantics of the service: how it might be called to make a synchronous request/reply, synchronous reply-only or asynchronously communicate.
- The end point and transport of the service via the
<service>element: that is, who provides the service.
- An encoding via the
<binding>element, that is how the service is accessed.
Pages: 1, 2