Web Services & Java Server Pages

The strength behind the Extensible Markup Language (XML) is that its data structure is self describing. There are no proprietary keys or codes that distinguish data between vendors. The Simple Object Access Protocol (SOAP) is a communication protocol that defines how the self-describing XML data is transmitted from one point to another. Both technologies are based on open standards with endorsement from the World Wide Web Consortium (W3C). As Figure 1 illustrates, they bring developers with different backgrounds a standard means for developing services that fit into one universal Service-Oriented Architecture.

Web-service developers can produce services in various languages, including Java, C++, Python, or any of the Microsoft .NET-supported languages. Those connecting to web services can build desktop or web applications with the same flexibility and even operate on different server platforms — any platform that supports a SOAP client. Currently, server platforms supporting SOAP-based web services include IBM WebSphere, Apache Tomcat, and Microsoft .NET Enterprise Server.

Web services are foundation components for building open, distributed systems. Since web services are built on open standards such as SOAP and XML, any compliant web service can interact with any other. The days of converting between different distributed platforms are over. Now, data can be passed from one application or web service to another in a single self-describing XML document and passed from one SOAP-based client to another.

In this article, I'll present an example portal (available electronically; see "Resource Center," page 5) that demonstrates how web applications can tie together distributed web services to offer a single solution.

Assembling the Technology

For any desktop or web application to be able to call a remote web service, you need:

• An active connection to the Internet.

• Support for XML parsing.

• A SOAP client.

Class libraries offering both XML and SOAP support are available in several programming languages, including Java, C++, and Python.

When building a web-based application, such as this example portal, the main application code needs to reside on a server equipped for server-side programming. Such web servers include IBM's WebSphere, Apache's Tomcat, Microsoft's .NET Enterprise Server, and BEA's Weblogic server. Each offers some mechanism for building server-based web applications such as Servlets, JSP, ASP, and Python.

Apache's Tomcat server can be downloaded from http://www.apache.org/. It runs on both Windows and Linux, and supports server-side programming in the form of Java Servlets and JSPs. XML and SOAP client class libraries for Java can also be downloaded from the Apache site. After downloading the Java class libraries, install and configure them to be accessible to your Java-based web application. This often requires an addition to your Java classpath.

When the server environment is configured and you have a clear vision of what your web or desktop application will do, the next step is to locate existing web services to connect to. There are a number of solutions available to help locate existing web services, ranging from directory web sites (http://www.serviceforge.com/, http://www.x-methods.com/, and http://www.salcentral.com/, for instance) to the Universal Dynamic Discovery Integration (UDDI) registry.

Each web-service directory should provide a description of the web service, its Endpoint URL, Methods Namespace URI, and Parameter information (normally in WSDL format). The Endpoint URL identifies the location of the remote service's client connection point. The Methods Namespace URI is a unique identifier that identifies the remote web service. The SOAP endpoint and namespace identifier are required to establish a remote connection. The Web Service Description Language (WSDL) is an XML document that describes the web service's input parameters and return type.

By browsing the web-service directory sites, you can select which existing web services to connect to in order to bring the sample portal to life. Keep notes on which services to call, their endpoints, namespaces, and parameters. These details will be needed to layout the portal.

The Portal Layout

Although distributed web services have far more potential use than simple portal development, implementing this portal with web services illustrates the variety of uses that web services can offer. For many Internet users, a commercial web portal acts as the first point of contact to the Internet. For others, it's more of an Internet dashboard with all relevant information in one place, with links to surf in different directions.

The portal I present here offers a starting point for surfing the Internet with a single interface that provides access to a search engine, news headlines, weather updates, traffic information, and stock quotes. This portal is implemented as a Java Server Page (JSP) and uses a SOAP client to connect to remote web services. By implementing this portal as a JSP, you can start with a simple HTML page, add Java statements, and let the server compile the JSP into a Java Servlet class that is optimized to process HTTP requests.

Commercial portals would normally be designed to let the portal users personalize the portal. Cascading Style Sheets (CSS) would be one technology that enables portal users to configure the general look-and-feel of the portal, including colors and fonts. These preferences could be stored in a configuration file and loaded on demand. Additionally, portal users would be able to select which content they want to see and in what order they want to see it in. For the sake of simplicity, the portal will not be customizable.

Begin the portal development with the basic page layout using an HTML editor, such as Microsoft's FrontPage. You know what content you want to display on the portal, so you can layout the HTML with special notes like $$HEADLINES$$ or $$STOCKQUOTES$$. Some web services require user input. You can add HTML form fields to capture that input from portal users. You should end up with a simple HTML page that looks like Listing One. Save this page as "index.html" to be the first page served by the web server.

Once you have the static HTML template for the portal, you can turn it into a Java Server Page to enable the dynamic content. Take index.html and convert it into a JSP by renaming "index.html" to "index.jsp". Open the JSP with a text editor and add the JSP declarations like Example 1(a) at the top of the page.

When the JSP is requested by a web browser, the server first compiles this page into a Java Servlet class. As described by the declaration, this Servlet will be threadsafe and import the SOAP-related Java classes. Next, add a global variable declaration to the JSP and declare the SOAP-related objects used to interact with the remote web services; see Example 1(b).

As mentioned, to connect to a remote web service, you only need to know about its endpoint and namespace. You are not concerned about the implementation details, such as which programming language or host server is used The remaining objects abstract us from the details of building a request XML document filled with parameter and method details. The resulting XML document will eventually be delivered to the remote server for processing. The last two objects abstract the response XML document that is eventually returned to the web application from the remote web service.

Once you have the basic template for the portal's Java Server Page, the next step is to connect the remote web services.

Connecting Web Services

When performing the layout step of creating the portal, you leave placeholders to mark where the dynamic content appears. Within the Java Server Page, those placeholders will be replaced with Java code that calls a remote service and retrieves dynamic content for display. Edit the JSP and replace the $$HEADLINES$$ placeholder with Java code that connects to the Headline News web service; see Example 2(a). This designates which remote server and web service to connect to. Since each web service may contain multiple methods, specify which method the portal should invoke. This aspect of the XML request is abstracted by the Call class and implemented like Example 2(b).

For those web services requiring additional parameters, the portal creates a Vector of Parameter objects. The entire Vector is passed to the Call object as supplementary information. Each Parameter object contains information such as name, data type, and value; see Example 3.

Once the Java Server Page has been properly declared, the SOAP client imported, and the Call object and any necessary parameters set, you can invoke a method from the remote web service. Begin with a try/catch block to trap any thrown exceptions. Within the try/catch block, call the invoke() method and assign the results to a Response object. The Response object tells you if there was a problem invoking the method on the remote web service. If an error was detected, you can read the FaultCode to determine what went wrong. If no errors occurred, you can instantiate another Parameter object to contain the result value for additional processing within the portal. The code that performs this processing might look like Example 4.

Working with the SOAP client classes makes it straightforward to interact with remote web services. These client classes take the object settings and turn them into well-formed XML documents. This XML document is delivered to the remote web service where it is processed by the web service. In the case implemented here, that requesting XML document appears in Listing Two.

Now that the portal is ready to connect to the News web service, it is fairly easy to implement the rest of the web-service invocations. Review the web service's connection and parameter information again, fill in the necessary information, and call their invoke methods. Repeat this step for each web service that the portal connects to.

When all of the portal's placeholders are replaced with JSP code, it should look something like Listing Three (available electronically). Move the index.jsp file to an accessible directory on the web server. The web server needs to be capable of processing Java Server Pages and must be able to access the XML and SOAP Java classes. Now you should be able to point your web browser to the index.jsp page on the web server. After a few seconds to compile the JSP into the Servlet class, you should be able to see the portal and all of the dynamic content pulled from remote web services.

To make this a more well-rounded portal, add customization features to let portal users define the look and feel. Additionally, the portal should support browser cookies to remember the portal user's preferences, such as favorite stocks, local zip code, and preferred headlines.

Conclusion

Web services offer great potential to the world of distributed computing. Connecting to web services can be done quickly and painlessly with the right tools. However, web services are still in their infancy, with a cloud of issues hovering above them.

Although many web services are public and available for all to use, the most useful web services will be business related and need some method to restrict their access to only authorized users. Currently, there is no definition of how this security will be implemented, to what extent, and how other services will dynamically support these layers of security.

Another issue involves how two-phased commit transactions will be handled. If one service requires a great deal of time to complete a transaction, the other depending services cannot sit idle waiting for a response. Some type of roll-back mechanism needs to be available where the task performed by a web service can be later undone if necessary.

Also, there needs to be a universal approach for web services to announce themselves to potential consumers. There also needs to be an approach to inform existing consumers when the service changes or moves, once published. WSDL and UDDI are two technologies, also in an infancy stage, that address this.

Finally, certain web services will be more reliable than others. There needs to be a consistent measurement of reliability that helps web-service consumers determine which services to purchase. There also needs to be a way to react to the case in which a web service shuts down. Web-service consumers need to decide if they should connect to an alternative service or wait for their subscribed service to return.

With an increasing number of supported platforms, languages, and tools, web services are bound to become a standard method for deploying domain-specific functionality over the Internet. Web services benefit service developers with greater customer reach and benefit service consumers with faster time to market with imported features.

DDJ

Listing One

<html>
<head>
<title>Web Services Portal</title>
</head>
<body>
<form action="index.jsp">
<div align="left">
<table border="0" cellpadding="0" cellspacing="0" width="800">
<tr>
<h2>JSP / Web Services Portal</h2>
</tr>
<tr>
<td> </td>
</tr>
<tr>
<td>
<div align="left">
<table border="0" cellpadding="0" cellspacing="0" width="800">
<tr>
<td width="200" valign="top">
<div align="left">
<table border="1" cellpadding="0"
cellspacing="0" width="100%">
<tr>
<td width="100%">STOCKS
<div align="left">
<table border="0" cellpadding="0"
cellspacing="0" width="100%">
<tr>
<td width="50%" height="21">Apple</td>
<td width="50%" height="21">
$$APPLE$$
</td>
</tr>
<tr>
<td width="50%" height="21">AOL</td>
<td width="50%" height="21">
$$AOL$$
</td>
</tr>
<tr>
<td width="50%" height="19">Cisco</td>
<td width="50%" height="19">
$$CISCO$$
</td>
</tr>
<tr>
<td width="50%" height="21">Citigroup</td>
<td width="50%" height="21">
$$CITIGROUP$$
</td>
</tr>
<tr>
<td width="50%" height="21">Oracle</td>
<td width="50%" height="21">
$$ORACLE$$
</td>
</tr>
</table>
</div>
<p align="center">Symbol <input type="text" name="T3" size="6">
<input type="submit" value="Get Quote" name="B2"></p>
<p align="center">
$$USER_STOCK_SYMBOL$$
</p>
<p align="center"> </p>
</td>
</tr>
<tr>
<td width="100%">
<p align="center">
$$CURRENT_TEMPERATURE$$
</p>
<p align="center">ZIP
<input type="text" name="T2" size="5">
<input type="submit"
value="Get Temperature" name="B3"></p>
<p align="center"> </p>
</td>
</tr>
<tr>
<td width="100%">
$$HIGHWAY_TRAFFIC$$
<p align="center">HWY NUMBER
<input type="text" name="T4" size="5">
<input type="submit"
value="Get Traffic" name="B4"></p>
<p> </p>
</td>
</tr>
</table>
</div>
</td>
<td width="600" valign="top">
<div align="left">
<table border="1" cellpadding="0"
cellspacing="0" width="100%">
<tr>
<td width="100%">
<p align="center"> </p>
<p align="center">Key Words <input type="text" name="T1"
size="25">
<input type="submit" value="Search" name="B1"><br>
<input type="radio" value="V1" checked
name="R1">Google  
<input type="radio" name="R1"
value="V2">Lycos  
<input type="radio" name="R1" value="V3">Alta Vista</p>
<p>
$$SEARCH_ENGINE_RESULTS$$
</p>
</td>
</tr>
<tr>
<td width="100%">
<p>
$$NEWS_HEADLINES$$
</p>
</td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
</form>
</body>
</html>

Back to Article

Listing Two

<SOAP-ENV:Envelope xmlns:SOAP-ENV=("http://services.xmethods.net:80/soap">
<SOAP-ENV:Body>
<ns1:getQuote xmlns:ns1="urn:xmethods-delayed-quotes">
<symbol xsi:type="xsd:string">ORCL</symbol>
</ns1:getQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Back to Article