1. SOAP specification can be implemented using different programming languages such as JAVA,.NET,etc.
  2. It is up to the service Provider to choose Programming language for writing Web service and appropriate SOAP Runtime environment(For language specific bindings)i.e.,to use Java as a Programming language to develop soap based web services,the corresponding SOAP runtime environment should be implemented in java.
  3. A long list of Open source communities(such as Apache AXIS2),Web Services platform providers(Such as JAVA,.NET),J2EE Vendors(such as Weblogic,Websphere)have released their SOAP runtime environments.
  4. Out of many vendors who provided SOAP runtime environment in java,most popular among all is AXIS2.
  5. Apache AXIS2 is an open source SOAP implementation that provides environment for writing soap based web services i.e.,it is runtime environment for SOAP.

As a packaged solution,the AXIS2 provides following:

  • SOAP Runtime Environment.
  • Java based API for developing SOAP RPC and SOAP Document based clients and services
  • A transport-independent means of protocols such as HTTP,SMTP,FTP,etc..
  • Automatic Serialization and DeSerialization for Java objects to and from XML in SOAP format.
  • Tools for generating Java classes from WSDL and vice-versa
  • Tools for Deploying ,Monitoring,and Testing the Web services
  • Support for JAX-PRC and SAAJ
  • Support for the RESTful web services.
  • Exposing EJBs as Web services.
  • Send and receive SOAP message with attachments(SAAJ).


  1. Apache AXIS supports both SOAP1.1 and SOAP1.2
  2. Apache AXIS supports both WSLD1.0 and WSDL2.0
  3. Apache AXIS is built on Apache AXIOM, a new high performant,pull-based XML object model.
  4. Apache AXIS2 supports JSON(Java Script Object Notation).
  5. AXIS2 supports HTTP,SMTP,JMS,TCP,etc transport protocals.

Implementing Web Service using AXIS2


Fault Response in Axis2

To return an exception to the client ,WebService sends fault message,Which is very much like an output message
The following changes are required in wsdl file for fault messages:

	<xsd:element name="invalidProductId" type="xsd:string">
	<xsd:element name="invalidQty" type="xsd:int">
<wsdl:message name="queryInvalidProductId">
<wsdl:part name="parameters" element="tns:InvalidProductId"/>
<wsdl:message name="queryInvalidQty">
	<wsdl:part name="parameters" element="tns:InvalidQty"/>
<wsdl:portType name="BizService">
	<wsdl:operation name="query">
		<!--Unlike an input or output message which doesn't need a name, a fault needs a 
		unique name because there can be multiple fault messages.Later this name is used-->
		<wsdl:fault name="f01" message="tns:queryInvalidProductId"/>
		<wsdl:fault name="f02" message="tns:queryInvalidQty"/>
					<wsdl:fault name="f01">
							<soap:fault name="f01" use="literal"/>
					<wsdl:fault name="f02">
							<soap:fault name="f02" use="literal"/>

In the generated SOAP response message,the fault message is included into SOAP <Fault>element.

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelop xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope">
	  <ns6:InvalidQty xmlns:ns6="http://bar.org/purchasing">-200</ns6:invalidQty>

Where <faultcode> is an error code ,<faultstring> is an error description for human reading.
Now generate the service stub and client stub and refresh the files in eclipse,we will see new java classes.

public class QueryInvalidProductId extends Exception {
		InvalidProductId fault Message;
public class InvalidProductId {
		String invalidProductId;
public class QueryInvalidProductId extends Exception {
		InvalidQty fault Message;
public class InvalidQty {
		int invalidQty;

The method signature in BizSkeletonInterface has also been updated to throw such exceptions:

public interface BizServiceSkeletonInterface {
public ProductQueryResult query(ProductQuery prouctQuery)throws QueryInvalidProductId,QueryInvalidQty;