Copyright © 2003 by Charlie Calvert

This article contains an overview of Web Services in JBuilder. The next article in the series describes a simple Wizard based technology for building Web Services. The third article in the series includes a short description of how to use your Web Service in the Borland Enterprise Server (BES).

This article begins with a relatively lengthy overview of Web Services, SOAP and Tomcat. Future articles will cover the technology in more depth. If you are anxious to get started, or if you feel you already understand Web Services, then you can skip the overview and jump right to the technical bits.

Overview

For the purposes of this article, Web Services can be thought of as means for one process to call the methods or functions of another process across the Internet. More generally, Web Services can be thought of as reusable, loosely coupled, software components that are deployed on a network or on the World Wide Web. Because they are loosely coupled, Web Services can be linked one to another dynamically at run time, and need not be linked at design time. After a Web Service has been created and deployed, someone else can come along after the fact and link to the service dynamically. There are security measures that can be put in place to prevent this, but it is technically possible to allow anyone to access your Web Services. The key point, however, is simply that individual Web Service components can be freely linked together in multiple ways that were not even considered at design time.

Web Services are not a unique or new type of technology. Other similar technologies include RMI, DCOM, CORBA, XML-RPC, EJB and RPC. Each of these technologies have certain unique traits that set them apart from the others. However, Web Services are not fundamentally different from preceding technologies such as CORBA or RPC.

Web Services are, however, very different from CGI, Java ServerPages, or Servlets. These three latter technologies generate HTML to be shown in a Browser, while Web Services allow you to call methods in a class, to pass parameters to a method, and to see the return values from a method call. More particularly, Web Services are designed to create discreet objects which can be combined and reused in multiple ways depending on the needs of an application developer. Even more abstractly, Web Services can be described simply as a means of enabling interprocess communication across the Internet. CGI, Java SeverPages, and Servlets, on the other hand, are meant primarily as a means of generating HTML.

Web Services differ from RMI, DCOM, CORBA, and RPC in that they are specifically designed to work with an XML based technology called SOAP. The great advantage of an XML based technology is that it need not be language or platform specific. This gives the technology a good deal of flexibility.

Not all the technologies we are discussing are as flexible as Web Services. DCOM, for instance, is (for the most part) a Windows specific technology. RPC, on the other hand, is a fairly flexible technology. It is, for instance, platform neutral. Though usually associated with the C programming language, there are RPC bindings for many different languages. RPC does not, however, have good support for objects.

RMI was traditionally a Java only solution, but it has recently been expanded to interact with CORBA. As you will learn in the next paragraph, CORBA is a very flexible and powerful solution. The combination of RMI and CORBA is interesting, primarily because RMI is so easy to use, and CORBA is so flexible. There is, however, a strong binding between Java and RMI.

There is nothing inherent in Web Services that sets it apart from CORBA. Both sets of tools are neither language nor platform specific. Both tools are inherently object-oriented, and both tools have a number of high level services for sharing and discovering objects. There are open source implementations of both CORBA and Web Service protocols, so money is not necessarily an issue when choosing between them. There are many adherents of Web Services who claim that their XML based protocol is inherently simpler than CORBA. This may indeed be the case, but both protocols are large enough to benefit from the use of high level tools that hide their inherent complexity. Since there are powerful tools available for both CORBA and Web Services, the complexity of specific implementation details is not necessarily as important as it might seem at first.

If there is an advantage that Web Services have over CORBA, it would be the wide degree of acceptance that this new technology has generated. In particular, the Microsoft Corporation has thrown its weight behind their version of Web Services. The Microsoft marketing team has the power to convince developers that Web Services are the wave of the future. Microsoft marketing, combined with a huge effort by the open source community, has helped generate many tools and much enthusiasm for SOAP and Web Services. The presence of so many good open source tools, and the enthusiasm of the Web Services community, are probably the best reasons to use Web Services rather than some other technology such as CORBA or RPC.

I should add that there is probably nothing that you can do with tools like CORBA or Web Services that you could not do with the raw TCP/IP or HTTP protocols. However, it would take considerably more work to achieve the same goals if one dropped down to a low level protocol such as TCP/IP or HTTP.

In summary, Web Services are a protocol based on XML that allow developers to promote loose coupling by calling the methods of an object that resides on a remote machine. It is one of many different protocols for achieving this goal. Reasons to use this technology include the fact that it is language and platform independent, and that it is a widely accepted technology with a lot of enthusiasm behind it. It would certainly be a good thing if the development community decided to standardize on Web Services. However, the advantage would lie primarily in the act of standardization itself, and not in any particular feature of Web Services.

Axis and SOAP

There are a number of different ways to create Web Services, and a number of different tools that you can use to help speed the process. In this series of articles, I will begin by working with the Axis SOAP implementation, which is part of the Apache Web Services project. Axis is a tool that helps to automate one of the more complicated steps in the development of a Web Service.

SOAP is a standardized technology for describing the XML that gets sent between two processes that want to communicate across a network. The developers of SOAP describe their tools as follows: "SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment." This is technically correct, but so generalized as to be hard for beginners to parse. SOAP can indeed be used in many different contexts. For the purposes of this article, however, SOAP can be thought of as protocol for allowing one class to remotely call the methods found in another class. The classes are often separated by both process and machine boundaries. SOAP "marshals" the data passed as parameters or return values during a method call. Marshaling the data involves defining a transmission protocol that allows you to pass parameters and return values in a platform and language neutral manner. This is where XML comes into play.

When used in a non-technical context, the word marshal has several different meanings. The primary meaning usually has to do with arranging troops for a military parade or maneuver. It can, however, also refer to the act of escorting or ushering someone to a destination. It should not be hard to see why developers found such a word to be an apt metaphor for the act of transporting data from one machine to another.

In many introductions to Web Services, the writer would now show you a specific example of how XML is used to marshal the data necessary for a function or method call. However, I'm going to make a point of not showing it to you in order to emphasize the fact that such matters are simply internal plumbing that you need not, and should not, concern yourself with when using Web Services. Each of the protocols we have been discussing have their own technologies for marshalling data across machine or process boundaries. Becoming an expert in all of them would be a daunting task. One should not need to know the specific details of how a method call is made in CORBA, a Web Service, or in RMI, any more than one should have to know how a function or method call is made in Java, C++, or Pascal. This is not to say that such information is not useful at times, but it should not be necessary information critical to the performance of your task. In particular, most introductory courses in Java, C++ or Pascal don't begin by discussing the details of how a CDECL or Pascal function call works. By the same measure one need not know the details of how Web Services marshal data.

XML-RPC is very similar to SOAP. The primary difference lies in the fact that XML-RPC aims to makes the syntax for creating procedures calls as simple as possible, while SOAP aims to resolve all possible issues that might come up between clients that want to communicate over a distributed computing environment. In particular, SOAP makes extensive use of namespaces, and has well defined types, while XML-RPC has a more sparse protocol that is less well defined. XML-RPC has the advantage of being simple, and things that are simple usually work better than things that are complex. I would suggest, however, that XML-RPC is not necessarily as appealing a choice as it might at first seem. The tools for creating Web Services are now so advanced that the need to simplify the protocol is not particularly strong.

In future articles, I will show you how to create Web Services without using AXIS. However, for now, this open source tool offers a simple, well tested, and powerful solution to a complex problem. Axis ships with JBuilder, so you will not need to install it.

Tomcat

Before we begin exploring the specifics about how Web Services work, there is a need to discuss one more technology. You have learned that Axis is an implementation of the SOAP protocol. Axis is designed to run inside a container. In the examples I will show you, that container is Tomcat.

Tomcat is a tool originally create to support Java Servlets and JavaServer Pages. These latter technologies play a support role in Java's implementation of Web Services. Axis can work with any valid Servlet container, but it is frequently teamed with Tomcat. If you put Tomcat and Axis together, then you have platform that can support Web Services.

Tomcat is the official reference implementation for JSP and Servlet containers. When other venders want to create a JSP or Servlet container, Sun offers Tomcat as an example of how these containers ought to behave. Other containers may be more powerful in terms of performance, but Tomcat is the gold standard when it comes to defining how such tools ought to behave. (In saying this, I do not mean to imply that Tomcat cannot be used in a production environment.)

I like to think of Tomcat as fitting into a hierarchy of web based server side tools. A simple Web Server such as Apache or IIS is meant primarily to serve up HTML pages and to handle CGI based programs. A Servlet and JSP container is more powerful in that it adds additional features such as the ability to keep objects in memory, and even to compile code on the fly under certain circumstances. When combined with Axis or another SOAP implementation, Tomcat can support Web Services.

One step further up the hierarchy from a tool like Tomcat are the full blown Application Servers such as the open source tool JBOSS, or those developed by big companies. Examples of these latter tools include the Borland Enterprise Server, The IBM WebSphere Application Server, or the BEA Web Logic Server. These tools generally do everything that Tomcat does, and then more. In particular, they provide load balancing, fault tolerance, transactions, resource pooling, caching, process management, etc. You can think of these tools as a superset of what is offered by a web server or by a tool like Tomcat. In fact, some of them come with a copy of the Aphache Web Server, Axis and Tomcat. In a very rough analogy, you can think of an Application Server being related to a tool like Tomcat in much the way a Swiss Army Knife is related to a normal pocket knife.

The lines I have drawn here between web servers, servlet containers, and application servers should be considered to be a bit fuzzy around the edges. For instance, web servers typically add at least a few features found in the other tools, and vice versa. But I think it helps to have sense of what each of these tools can do.

The main point to get from this section, however, is that Java Web Services of the kind we will be exploring are based on two large, complicated technologies: Axis and Tomcat. Both tools need to be installed on the server side before you can use the kind of Java Web Services that I am about to show you.

Fortunately, JBuilder includes both Tomcat and Axis. These tools should be set up automatically during the JBuilder install. The next article in this series will explain how to set up these tools if you want to work from the command line without the aid of JBuilder.

Summary

This is the first in a multi-part series on creating Web Services. The second part will describe a simple process for creating a Web Service, and the third part describes how to deploy the Web Service in the Borland Enterprise Server.