Par: Charlie Calvert
Résumé: The first of a series, this article gives an overview of Web Services, Axis and Tomcat.
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.
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
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
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
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
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.
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
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
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.
This is the first in a multi-part series on creating Web Services. The
part will describe a simple process for creating a Web Service, and
part describes how to deploy the Web Service in the Borland Enterprise
Réponse serveur de: ETNASC02