ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Ws Wiki] Update of "FrontPage/Axis/AxisGeneral" by JohnMGabriele
Date Thu, 04 Aug 2005 14:16:56 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by JohnMGabriele:

- '''Q: What is Axis? What is its relationship to Apache SOAP?'''
- A: Axis is essentially Apache SOAP 3.0. It is a from-scratch rewrite, designed around a
streaming model (using SAX internally rather than DOM). The intention is to create a more
modular, more flexible, and higher-performing SOAP implementation (relative to Apache SOAP
+ '''Q: What is a web service?'''
+ A: It's common to have 2 programs on one computer talk to each other. One's the server (waiting
and listening for requests), and the other's the client (contacting the server when it needs
something done that the server does). The client and the server may talk to each other in
a variety of ways: sockets, pipes, text files...
+ The server and the client don't have to be on the same machine. You can have, say, Apache
running on some web server machine, and Firefox running on your local machine. The client
and the server talk to each other -- in the case of Firefox and Apache -- using HTTP on top
of TCP.
+ Sometimes it's useful to have a server program do something more sophisticated than just
shoot html back at you when you ask for it. Sometimes it's useful for a client to be able
to pass data to a server, have the server do some complex processing on it, and then possibly
return something else to the client (possibly communicating back and forth multiple times
if necessary). We've already got programs to do this manually: You could use ftp to push a
file to an ftp server, then ssh to the remote machine and run some other commands to work
on the file you just ftp'd there. Then you could ftp the file back to your local machine.
You could even script all of that to make it automated. Your script might even work for a
different server than the one you originally wrote it for. ;)
+ The point of web services is to replace that messy contraption and provide a generic, standardized,
client and server paradigm for asking server programs on remote computers to do things for
you. The way most folks use web services (because it's the simplest, and the default for the
Axis toolkit -- discussed below) is by simply calling methods on objects residing on remote
computers (see JAX-RPC wrt Axis, below).
+ The idea is, somewhere there's a registry of web service descriptions; structured descriptions
telling exactly what services are provided by which web services (you might think of it as
a list of objects and their public instance methods). When you want to make use of one of
these services, you have a look at the web service description and then write a client that
can talk to that service. There are, of course, tools out there that will turn the description
into a bare-bones Java source code file (the skeleton of your client) for you to fill-in the
implementation details.
+ The grand plan at some point was for big corps like Microsoft to provide a web service registry,
and then you'd pay (on a per-use basis) for every web service you wanted to use (as opposed
to having individual apps installed on your computer, that you may or may not have paid MS
for). Companies like MS ''love'' the idea of pay-per-use. I don't have any idea if this grand
plan has panned out for them, but web services seem pretty useful regardless.
+ '''Q: How do web services work?'''
+ A: First, a diagram, then, some explanation:
+ {{{
+   +--------------------------------------+
+   |         web service registry         |
+   |         (aka service broker)         |
+   |                (UDDI)                |
+   +--------------------------------------+
+          ^                        ^
+          |                        |
+      (2) |                    (1) |
+          |  (the client           |  (the web service
+        WSDL  finds the          WSDL  provider publishes
+          |   service              |   the web service)
+          |   they want)           |
+          |                        |
+          v                        |
+    +-----------+            +-----------+
+    | service   |<---SOAP--->|  service  |
+    | requestor |            |  provider |
+    +-----------+     (3)    +-----------+
+ }}}
+ The numbers in parentheses indicate the order in which things happen. Step 1 is optional
if you don't want to tell the whole world about your web service. Step 2 is optional if you
(the client, the "service requestor") already know what service you want, and from whom. Step
3 is sometimes called, "binding to the web service". The "binding" we'll use here (and what's
most commonly used) is SOAP.
+  * WSDL -- Web Services description Language. Used to describe exactly (in XML) what a web
service does.
+  * UDDI -- The "Universal Description, Discovery and Integration" protocol. A protocol for
publishing web service descriptions. Somebody deploys a UDDI registry (it's just another web
service), and then folks looking for some web service check with that registry to see what
web services it knows about. Anybody can put up a web service registry.
+  * SOAP -- A transport protocol that sends XML messages using HTTP (which runs on top of
TCP, usually on port 80).
+ WSDL is a description language: using XML, it describes exactly what your web service does.
If you want a WSDL file for your web service, and you're using Apache Axis (mentioned below),
you don't need to manually write the WSDL file -- you just have Axis create it for you from
your Java code. More on that later.
+ When you create a web service -- one that you want other people to make use of -- you can
use a WSDL description of it to register your web service with some web service registry.
If you don't want anyone to be able to find out about your web service, then you don't have
to register it -- it's optional.
+ SOAP is just the usual way that web services and their clients talk to each other -- they
send XML text back and forth. You can watch it right on the wire (looking at the TCP packets
with something like Ethereal) if you like. 
+ '''Q: What is Apache Axis? What's its relationship to Apache SOAP?'''
+ A: As a client to a web service, encoding your requests to the web service, and decoding
the responses you get back, to and from XML would be a pain (not to mention implementing the
logic that deals with accepting requests and sending responses). The same goes if you're writing
the web service yourself. Most folks use Apache Axis to do all that for them. You could write
web service clients and servers without something like Axis, but it would be '''very''' tedious.
+ Axis was formerly known as "Apache SOAP". Currently, Axis is transitioning to version 2,
but there's still a lot of Axis 1.2 users out there, and an Axis 2 stable release is not yet
+ Axis is an implementation of the SOAP protocol. It shields you from the details of dealing
with SOAP and WSDL. You use Axis on the server side to write your web service (and deploy
it as a Tomcat webapp), and you use Axis on the client side to make writing your client a
snap.  Axis (''Axis2?'' '''XXX''') is essentially Apache SOAP 3.0. It is a from-scratch rewrite,
designed around a streaming model (using SAX internally rather than DOM). The intention is
to create a more modular, more flexible, and higher-performing SOAP implementation (relative
to Apache SOAP 2.0).
+ Using Axis, you can choose from 4 different "styles" of web service: RPC, "Document", "Wrapped",
and "Message". The Axis default is RPC -- and that's what we'll be using here. You'll often
see the acronym JAX-RPC: Java over XML to make Remote Procedure Calls. SOAP is XML, and (by
default) Axis sends SOAP messages to do RPC.
+ When using Axis to write your client, you don't need to directly deal with SOAP/XML/JAX-RPC.
All of that is handled for you by Axis -- all you need to do is make the method calls on the
web service object as if it were some local object. Same goes for your web service itself:
just write the class and its instance methods, and let Axis take care of the rest. :)
+ You install your web service just like any other Tomcat webapp. Your client that accesses
the web service can just be a regular Java command-line program.
  '''Q: Why call it "Axis"? '''
@@ -15, +81 @@

  A: See [ Axis vs Apache SOAP comparison].

View raw message