Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

The Web at your (machine's) service

Use Web services to deliver information to a cell phone via SMS

By Sonal Bansal and Gaurav Pal, JavaWorld.com, 09/28/01

The World Wide Web changes constantly. Since its inception, it has expanded exponentially, grown easier to navigate, and adapted effortlessly to new and innovative uses. However, thus far the Web's interface has been largely friendly to humans but unfriendly to machines.

Current technologies open up the Web only to humans through HTML links and URLs. Just imagine the services we could provide if machines could suddenly discover, traverse, and navigate the myriad of Web servers to facilitate true wide-area collaboration. Current approaches prove somewhat awkward: a common technique screen-scrapes HTML and mimics HTTP sessions to transfer data. Techniques such as these are not only incomplete (e.g., they lack a discovery mechanism) and unscalable (e.g., if one field on an HTML form changes, the whole interface can crash, so each server needs its own custom coding); they also prove difficult to maintain. Web services, on the other hand, provide a well-defined discovery and communication framework based on XML and HTTP that facilitates interaction between machines; they offer true peer-to-peer distributed computing over the Web. The advent of Web services has made the World Wide Web truly complete; they provide the missing link -- a machine-friendly user interface (UI) to the Web.

Admittedly, these concepts are not entirely new; distributed object-oriented technologies like CORBA and Remote Method Invocation (RMI) sought to provide similar services. Such core concepts as a service registry and TCP/IP-based communication protocol are common to both CORBA (registry/agent and Internet Inter-ORB Protocol (IIOP)) and Web services (UDDI and SOAP). But CORBA failed because it proved quite complicated and expensive to implement -- both in terms of cost and performance. Furthermore, the object bus could not create a genuine heterogeneous environment consisting of multiple hardware and software platforms. Web services, on the other hand, rely on ubiquitous technologies like XML and HTTP, and thus stand a fighting chance of being that ultimate Web glue.

This article develops a clearer understanding of Web services and illustrates a hands-on approach to developing an example service. We use our CellQuotes application presented in "Deliver Cellular Text Messages with SMS" (JavaWorld, March 2001) and demonstrate how to publish it as a Web service. Many expect SMS to be the next killer app for mobile phones; if Web services can provide a seamless coupling between the Web and mobile phones, we'll have an application that rocks, don't you think?

Web services 101

Web services offer the following advantages:

  • They are based on open and ubiquitous standards: Web services use omnipresent protocols such as HTTP for communication and XML for information exchange. Thus, they can work across hardware and software boundaries. For example, a Java Web service could easily talk to a COBOL Web service as long as HTTP and XML are in the mix.
  • They allow creation of business service stacks: By simply adding another layer, Web services expose software systems over the Internet. That allows the creation of value-added service stacks by melding discrete Web services over a network.
  • They enjoy broad-based industry support: Efforts like Microsoft's Hailstorm and Sun's ONE (Open Net Environment) are slowly turning Web services into a reality. IBM and Oracle are also major players in the Web services space. In addition, the open source movement's solid support ensures widespread developer interest.


Web services' greatest potential lies in their ability to provide business service stacks that truly integrate individual offerings. Imagine writing your own Web service agent that every morning collects and delivers information relevant to you (e.g., the HP-Compaq merger) from resources like the Wall Street Journal, the Economist, and BusinessWeek. Similar services exist today, but Web services help standardize machine-to-machine interaction to create new service breeds that integrate the Web as one large computer. On the supply side, you could publish your revolutionary service to millions of people worldwide without worrying about custom coding and interoperability issues.

Core enabling technologies

Several new technologies support Web services, but because they build on pre-existing technologies like XML and HTTP, they're not as new as you might think. Lets briefly look at some:

SOAP (Simple Object Access Protocol)
SOAP is the transport that facilitates the exchange of XML messages between machines. It performs business method requests as XML documents and supports a variety of lower-level protocols, such as HTTP(S) and SMTP (Simple Mail Transfer Protocol). The communication mechanism consists of request and response XML documents that have an envelope over them.

WSDL (Web Services Description Language)
An XML language that permits standardized description of Web services, WSDL describes the interface, semantics, and administration-related information of a Web service call. It allows simple services to be quickly and easily described, documented, and discovered. Several freely available tools permit automatic WSDL generation from actual code (such as a Java class), thus making the developer's job easier.

UDDI (Universal Description Discovery and Integration)
UDDI provides a specification that permits the publication and location of services in a universal service registry. It publishes an available service along with its call interface and semantics, thereby providing a discovery and meeting point for service providers and consumers. The UDDI specification defines four key types of information that might be needed to facilitate service use:

  1. Business information (businessEntity element): Contains information such as the business name, contact details, and so on. It might also include information categorized in a way similar to the format of the Yellow Pages.
  2. Service information (businessService element): Contains information about services relevant to a particular business function or a given service category. Each businessEntity might hold several businessServices.
  3. Binding information (bindingTemplate element): Contains information required to call a Web service, such as network access point, supported interfaces, and so on. Each businessService might hold several bindingTemplates.
  4. Specification information (tModels): To invoke a Web service, you must know a service's location and the kind of interface the service supports. The bindingTemplate indicates the specifications or interfaces a service supports through references to specification information. Such a reference is called a tModelKey, and the data structure encapsulating the specification information is called a tModel. tModels are reusable due to their use of references.


Figure 1 illustrates the relationship between the different components explained above.

Figure 1. UDDI data structures and their relationships. Click on thumbnail to view full-size image.

WSDL and UDDI

WSDL and UDDI together provide a powerful mechanism for the automatic description, discovery, and integration of Web services. UDDI features a universal registry that can hold any information about a Web service. Different people might use this information for different purposes. For example, a developer could use the registry to obtain the technical information required to build her own service and/or consume an existing service. A market researcher could use it to understand what services are most in demand. WSDL enables the uniform description of a Web service in an open manner -- it is UDDI's lingua franca. Thus, when used together, UDDI (which provides global visibility and accessibility) and WSDL (which provides standardized and portable service descriptions) pack quite a punch. Usually, developers use WSDL to describe Web services' semantics, such as method signatures, return types, and so on, in an implementation-independent way. This WSDL description is then embedded in the service's UDDI entry (usually through tModels) along with the information needed to actually call that service (through bindingTemplates).

The process for using a Web service consists of discovery, connection, and consumption. We outline the steps here in greater detail:

  1. A service provider creates a Web service and uses WSDL to publish the service in the UDDI registry.
  2. A service consumer locates and requests the registered service by querying the UDDI registry.
  3. Using SOAP, the service consumer writes an application to bind to the registered service and establishes a communication channel. The WSDL description provides the method signatures.


Figure 2 illustrates the steps outlined above.

Figure 2. Web services: Discovery to consumption. Click on thumbnail to view full-size image.

SMS Web service

Now, let's get back to the nitty-gritty of developing a real-world Web service -- namely, a service that sends text messages to cellular phones. To this end, we will convert the CellQuotes application presented in "Deliver Cellular Text Messages with SMS" into an application that exploits Web services. For the benefit of those unfamiliar with the application, a brief recap follows.

Resources