O'Reilly logo

Java Web Services: Up and Running by Martin Kalin

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

What’s Clear So Far?

The first example is a web service with two operations, each of which delivers the current time but in different representations: in one case as a human-readable string, and in the other case as the elapsed milliseconds from the Unix epoch. The two operations are implemented as independent, self-contained methods. From the service requester’s perspective, either method may be invoked independently of the other and one invocation of a service method has no impact on any subsequent invocation of the same service method. The two Java methods depend neither on one another nor on any instance field to which both have access; indeed, the SIB class TimeServerImpl has no fields at all. In short, the two method invocations are stateless.

In the first example, neither method expects arguments. In general, web service operations may be parameterized so that appropriate information can be passed to the operation as part of the service request. Regardless of whether the web service operations are parameterized, they still should appear to the requester as independent and self-contained. This design principle will guide all of the samples that we consider, even ones that are richer than the first.

Key Features of the First Code Example

The TimeServerImpl class implements a web service with a distinctive message exchange pattern (MEP)—request/response. The service allows a client to make a language-neutral remote procedure call, invoking the methods getTimeAsString and getTimeAsElapsed. Other message patterns are possible. Imagine, for example, a web service that tracks new snow amounts for ski areas. Some participating clients, perhaps snow-measuring electrical devices strategically placed around the ski slopes, might use the one-way pattern by sending a snow amount from a particular location but without expecting a response from the service. The service might exhibit the notification pattern by multicasting to subscribing clients (for instance, travel bureaus) information about current snow conditions. Finally, the service might periodically use the solicit/response pattern to ask a subscribing client whether the client wishes to continue receiving notifications. In summary, SOAP-based web services support various patterns. The request/response pattern of RPC remains the dominant one. The infrastructure needed to support this pattern in particular is worth summarizing:

Message transport

SOAP is designed to be transport-neutral, a design goal that complicates matters because SOAP messages cannot rely on protocol-specific information included in the transport infrastructure. For instance, SOAP delivered over HTTP should not differ from SOAP delivered over some other transport protocol such as SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), or even JMS (Java Message Service). In practice, however, HTTP is the usual transport for SOAP-based services, a point underscored in the usual name: SOAP-based web services.

Service contract

The service client requires information about the service’s operations in order to invoke them. In particular, the client needs information about the invocation syntax: the operation’s name, the order and types of the arguments passed to the operation, and the type of the returned value. The client also requires the service endpoint, typically the service URL. The WSDL document provides these pieces of information and others. Although a client could invoke a service without first accessing the WSDL, this would make things harder than they need to be.

Type system

The key to language neutrality and, therefore, service/consumer interoperability is a shared type system so that the data types used in the client’s invocation coordinate with the types used in the service operation. Consider a simple example. Suppose that a Java web service has the operation:

boolean bytes_ok(byte[ ] some_bytes)

The bytes_ok operation performs some validation test on the bytes passed to the operation as an array argument, returning either true or false. Now assume that a client written in C needs to invoke bytes_ok. C has no types named boolean and byte. C represents boolean values with integers, with nonzero as true and zero as false; and the C type signed char corresponds to the Java type byte. A web service would be cumbersome to consume if clients had to map client-language types to service-language types. In SOAP-based web services, the XML Schema type system is the default type system that mediates between the client’s types and the service’s types. In the example above, the XML Schema type xsd:byte is the type that mediates between the C signed char and the Java byte; and the XML Schema type xsd:boolean is the mediating type for the C integers nonzero and zero and the Java boolean values true and false. In the notation xsd:byte, the prefix xsd (XML Schema Definition) underscores that this is an XML Schema type because xsd is the usual extension for a file that contains an XML Schema definition; for instance, purchaseOrder.xsd.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required