A simple webservice using Apache CXF

I have modified the previous application in http://cuppajavamattiz.com/2012/11/09/a-simple-restful-service/, to include a webservice using Apache CXF. The jars I included from the CXF distribution were:
httpclient-4.2.1.jar
httpcore-4.2.2.jar
httpcore-nio-4.2.2.jar
jaxb-impl-2.2.5.jar
neethi-3.0.2.jar
cxf-manifest.jar
geronimo-javamail_1.4_spec-1.7.1.jar
geronimo-jaxws_2.2_spec-1.1.jar
geronimo-jms_1.1_spec-1.1.1.jar
geronimo-servlet_3.0_spec-1.0.jar
httpasyncclient-4.0-beta3.jar
xmlschema-core-2.0.3.jar
I modified the web.xml to look this
Remove the REST specific configurations below so that the app only works with REST.

<?xml version=”1.0″ encoding=”UTF-8″?>
<web-app xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns=”http://java.sun.com/xml/ns/javaee&#8221; xmlns:web=”http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd&#8221; xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd&#8221; id=”WebApp_ID” version=”2.5″>

<display-name>REST Service</display-name>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/rest-services-config.xml
</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>restservices</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value></param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>restservices</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>spring-ws</servlet-name>
<servlet-class>>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>CXFServlet</servlet-name>
<servlet-class>
org.apache.cxf.transport.servlet.CXFServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>CXFServlet</servlet-name>
<url-pattern>/webservice/*</url-pattern>
</servlet-mapping>
</web-app>

Added applicationContext.xml

Added cxf-servlet.xml

Added two classes:

package com.mattiz.ws.service;

import java.rmi.Remote;
import javax.jws.WebService;

@WebService(targetNamespace = "http:/com.mattiz/wsdl")
public interface MattizWebService extends Remote {
	public String getWelcomeString();
}
package com.mattiz.ws.service;

import javax.annotation.PostConstruct;
import javax.jws.WebMethod;
import javax.jws.WebService;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.web.context.support.SpringBeanAutowiringSupport;

import com.mattiz.rest.service.MattizService;

@Service("mattizWebService")
@WebService(serviceName = "/MattizWebService", portName = "MattizWebServicePort", targetNamespace = "http:/com.mattiz/wsdl", endpointInterface = "com.mattiz.ws.service.MattizWebService")
public class MattizWebServiceImpl implements MattizWebService {

	@Autowired
	private MattizService mattizService;
	@WebMethod(operationName = "getWelcomeString", action = "urn:getWelcomeString")
	public String getWelcomeString() {
		String welcomeString = null;
		try {
			welcomeString = mattizService.getWelcomeString();
			return welcomeString;
		} catch (Exception e) {
			e.printStackTrace();
			return null;
		}
	}
	@PostConstruct
	public void init() {
	    SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this);
	}
	public MattizService getMattizService() {
		return mattizService;
	}
	public void setMattizService(MattizService mattizService) {
		this.mattizService = mattizService;
	}
}

Note that the webservice is not created by Spring, so the mattizService bean is not autowired through spring directly, hence the init method to enable spring autowiring.

The wsdl can be viewed using the following url:

http://localhost:8080/RestServiceExampleWithJson/webservice/mattiz?wsdl

To test the webservice I have modified a client module described elsewhere on this blog http://cuppajavamattiz.com/2011/07/10/an-ejb3-webservice-with-generated-client-code/.

build-client.xml

The test class:

package com.mattiz.ws.client;

import com.mattiz.ws.test.bean.MattizWebService;
import com.mattiz.ws.test.bean._002fMattizWebService;

public class MattizWSClientTest {
	public static void main(String[] args) {
		try {
			MattizWebService port = new _002fMattizWebService().getMattizWebServicePort();
			System.out.println(port.getWelcomeString());
		} catch (Exception ex) {
			ex.printStackTrace();
		}
	}
}

The classes under com.mattiz.ws.test.bean package are automatically generated web service stubs by the build xml.
Run the client class as a standalone to test.
The result is:
Hallo Mattiz World!

Web Services and RESTFul Services

Q# Describe the structure of a SOAP request/ response

The soap request/ response consists of a SOAP envelope. The soap envelope contains the soap header and soap body. The SOAP header gives you an option of putting some stuff in that would be evaluated before the body is processed. The SOAP header may contain authentication information, namespace and method-name invoked, etc. Soap body may contain request and response content.
From
http://java.sun.com/developer/technicalArticles/xml/webservices/ #Message Format
SOAP performs operations in the context of a standardized message format. The primary part of this message has a MIME type of “text/xml” and contains the SOAP envelope. This envelope is an XML document. The envelope contains a header (optional) and a body (mandatory). The body part of the envelope is always intended for the final recipient of the message, while the header entries may target the nodes that perform intermediate processing, such as endpoint. Attachments, binary or otherwise, may be appended to the body.
..
Headers, for example, may be used to provide digital signatures for a request contained in the body. In this circumstance, an authentication or authorization server could process the header entry — independent of the body — stripping out information to validate the signature. Once validated, the rest of the envelope would be passed on to the SOAP server, which would process the body of the message.

Q# How do you authenticate a SOAP request?

I have used weblogic.xml.crypto.wss.provider.CredentialProvider to set the user credentials that will be added to the request header after encryption. This information is stripped from the soap header to authenticate the request. The authorization data is passed to the server through the request header each and every time a request is made. The authorization policy is defined in an xml file that is kept in the META-INF folder of the SOAP war/ ear file. The policy.xml says that user should always send username/ password token. The request should then always contain username/ password token.
We implemented “Standard Web Services Security” using username and password tokens passed in the soap header and a policy xml was deployed on the server which executed an EJB that did authentication.
The method itself was exposed as a webservice using annotations in the javax.jws package which is implemented in weblogic jar. Also jboss-ejb3.jar.

Describe how you have created various web services

In one of our previous project we used ejb3 annotations to expose ordinary pojo methods with annotations such as

@WebService(serviceName = "SomeService", portName = "SomeServicePort", targetNamespace = "http://mattiz.com/calculateInterest")

which seems to be in the import javax.jws.WebService; package of weblogic.jar.
The wsdl was automatically created and client stubs were generated using the ant clientgen task.
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/ is a rather a simplistic introduction, but similar to one described above.
In another project we created the wsdl manually and generated stubs using something like wsconsume ant task. The generated stubs are used both client side and server side.

Q# What is the difference between restful services and soap?

From here http://stackoverflow.com/questions/19884295/soap-vs-rest-differences
REST is an architecture. REST is not restricted to HTTP alone. It can use any protocol that follows the URI scheme. SOAP on the other hand uses HTTP alone. The consumer need not know a lot about the services exposed by the Rest service provider. In case of SOAP any undocumented change on either server or client side will break the communication. i.e. Web Service client and server are more tightly coupled than REST. The soap client requires detailed previous knowledge of the web service provider. However, once the entry point is known in REST, the resources are supposed to return links that the client can follow. Rest has a much simpler request and can use JSON as well as XML. It does not have the soap envelope and the headers and can be used for protocols that don’t support these.

From my brief reading, it looks like the main difference between SOAP and RESTful webservices is :
* SOAP exposes a function (or a method call) as an HTTP web service. The method can contain complex business logic etc.
* RESTful web service provides pieces of data as an HTTP web service. Think of RESTful web service as exposing a bunch of getter methods as webservice. The client can invoke the getter functions to retrieve pieces of data and then do what it pleases with the retrieved data. The restful web service provides data similar to how a database would provide data. Each invocation is very light since the web service provider doesn’t have any logic. It just retrieves and sends data.
I found this article useful http://137.254.16.27/enterprisetechtips/entry/implementing_restful_web_services_in
“Instead of providing just one endpoint for a particular web service and having that endpoint perform various operations, you provide access to resources.” So the soap web service client can be thin – service provider has lot of logic and data access and does lot of work while in RESTful web service, the provider is very thin – just provides resources (e.g. data). The client can do whatever it likes with the data – complex logic etc. So thin server/ thick client model is implemented and separate uri’s for each resource (or piece of data) are in place. RESTful services looks different from SOAP. SOAP has a method call which takes params and returns params while RESTful service just has separate uri’s for each resource (piece of data).
Here’s an example of how a RESTful service would look different from soap:
A soap service could expose a service that looks like this String doComplexStuff(param1, param2, param3, param4) while a RESTful service would look like this http://blah/resource/param1, http://blah/resource/param12 where it is just giving the values asked for and the RESTful service will return param1 and param12 without doing complex processing.
The difference is not whether “light” or “heavy”; the difference is whether you are executing a method call or getting access to resources.Typically RESTful services are supposed to be “light” without complex logic though that’s not to say that it can’t access the db or that it can’t use hibernate.
Restful service provider can use any technique to provide access to resources. The “resource” could be a value retrieved from db using hibernate, DTO, or anything else. For example the client may ask for all a list of DTOs and is returned list of DTOs; its just getting a resource or a list of resources. You can access db resources and return a dto or list of dtos and that would still be RESTful. The difference between SOAP and RESTful services is whether you are exposing a method or exposing your resources. Restful means simply access to resources. You can ignore how the RESTful service is implemented, just focus on the interface exposed to the client. Soap service looks like this – String doComplexStuff(param1, param2, param3, param4) while RESTful service looks like this
http://blah/resource/param1
http://blah/resource/param
It exposes multiple URI’s each URI exposing a single resource. For soap, each url would expose a method that performs some complex task and it’s not just exposing a resource. The difference is philosophical more of a design difference. We can use one technology on one end of a RESTful service and another at the consumer side, its just like a soap webservice – the mechanism is the same.

https://www.upwork.com/hiring/development/soap-vs-rest-comparing-two-apis/

Because SOAP is a protocol, and REST is an architectural style. SOAP is its own protocol, and is a bit more complex by defining more standards than REST—things like security and how messages are sent. For many of the reasons SOAP is a good choice rarely apply to web services scenarios, which make it more ideal for enterprise-type situations that require more comprehensive features in the way of security, transactions, and ACID (Atomicity, Consistency, Isolation, Durability) compliance.
SOAP is a protocol. REST is an architectural style. An API is designed to expose certain aspects of an application’s business logic on a server, and SOAP uses a service interface to do this while REST uses URIs.
REST APIs access a resource for data (a URI); SOAP APIs perform an operation. REST is an architecture that’s more data-driven; SOAP is a standardized protocol for transferring structured information that’s more function-driven.
REST permits many different data formats including plain text, HTML, XML, and JSON, which is a great fit for data and yields more browser compatibility; SOAP only uses XML.
Security is handled differently. SOAP supports WS-Security, which is great at the transport level and a bit more comprehensive than SSL, and more ideal for integration with enterprise-level security tools. Both support SSL for end-to-end security, and REST can use the secure version of the HTTP protocol, HTTPS.
SOAP requires more bandwidth; REST requires fewer resources (depending on the API). There’s a little more overhead with SOAP out of the gate, on account of the envelope-style of payload transport. Because REST is used primarily for web services, its being lightweight is an advantage in those scenarios.
REST calls can be cached, SOAP-based calls cannot be cached. Data can be marked as cacheable, which means it can be reused by the browser later without having to initiate another request back to the server. This saves time and resources.
An API is built to handle your app’s payload, and REST and SOAP do this differently. A payload is data sent over the internet, and when a payload is “heavy,” it requires more resources. REST tends to use HTTP and JSON, which lighten the payload; SOAP relies more on XML.
SOAP is tightly coupled with the server; REST is coupled to a lesser degree. In programming, the more layers of abstraction between two pieces of technology, the less control you have over their interaction, but there’s also less complexity and it’s easier to make updates to one or the other without blowing up the whole relationship. The same goes for APIs and how closely they interact with a server. This is a key difference between SOAP and REST to consider. SOAP is very closely coupled with the server, having a strict communication contract with it that makes it more difficult to make changes or updates. A client interacting with a REST API needs no knowledge of the API, but a client interacting with a SOAP API needs knowledge about everything it will be using before it can even initiate an interaction.

Q# What is the difference between JAX-WS, JAX-RS,JAX-RPC and what is JAX-B?

From http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html
Web services have been around a while now. First there was SOAP. JAX-rpc
The industry was not merely doing RPC web services, they were also doing message-oriented web services. So “RPC” was removed from the name and replaced with “WS” (for web Services). Thus the successor to JAX-RPC 1.1 is JAX-WS 2.0 – the Java API for XML-based web services.
What is different between JAX-rpc and JAX-ws?
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.
The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.
JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today’s web services novices.
JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
JAX-WS’s data mapping model is JAXB. JAXB promises mappings for all XML schemas.
JAX-WS’s dynamic client model is quite different from JAX-RPC’s. Many of the changes acknowledge industry needs:
It introduces message-oriented functionality.
It introduces dynamic asynchronous functionality.
JAX-WS also adds a dynamic server model, which JAX-RPC does not have.
JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification.

Differences: JAX-RS and JAX-WS; and why JAX-RS is preferrred in modern web applications

Soap is service based while REST is resource based and lighter with less overhead since it doesn’t include authentication, security, transaction, message types and ACID (Atomicity, Consistency, Isolation, Durability) by defining more standards. Soap is resource intensive on the client side(thin client) while REST isn’t which makes REST useful on devices such as mobile phones. Rest is the preferred web service.

REST is particularly useful for limited-profile devices, such as PDAs and mobile phones. It’s not that JSON is so significantly smaller than XML by itself. It’s mostly that JAX-WS specification includes lots overhead in how it communicates. On the point about WSDL and API definitions, REST will more frequently use the URI structure and HTTP commands to define the API rather than message types, as is done in the JAX-WS. This means that you don’t need to publish a WSDL document so that other users of your service can know how to talk to your service. With REST you will still need to provide some documentation to other users about how the REST service is organized and what data and HTTP commands need to be sent. JAX-RS refers to Rest services while JAX-WS is related to web services.

Q# What web services have you used?
Lately I have used Apache CXF with Spring for creating WebServices using annotations – bottom up. Prior to this I used the EJB3 web services using annotations – bottom up. Apache Axis for both bottom up and top down web service creation. Top-down means you start with a WSDL and then create all the necessary scaffolding in Java all the way down. Bottom-up means you start with a Java method, and generate the WSDL from it.

An EJB3 WebService with Generated Client Code

This is an example of an EJB3 webservice. I am using jboss-5.0.1.GA.
My workspace has the following structure:


     

     
          
               
                    TestEjbWS.java
                    
                         TestEjbAPI.java


     javaee.jar
     javax.jws-1.0.jar

     application.xml
     jboss-app.xml
build.xml

The ejb class that is exposed as a web service looks like this:


package com.mattiz.ejb.ws;

import javax.ejb.Remote;
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;
import com.mattiz.ejb.ws.api.TestEjbAPI;

@Stateless(name = "TestEjbWS", mappedName = "ejb/TestEjbWS")
@Remote(TestEjbAPI.class)
@WebService(serviceName = "TestEjbWS", portName = "TestEjbWSPort", targetNamespace = "http://mattiz.com/test/testejbws")
public class TestEjbWS implements TestEjbAPI {
	@WebMethod(operationName = "testMe", action = "urn:testMe")
	public String testMe() {
		return "Hallo World!!";
	}
}

The interface that this ejb implements looks like this:

package com.mattiz.ejb.ws.api;

import java.rmi.Remote;

public interface TestEjbAPI extends Remote {
	public String testMe();
}

contains two jars required for compiling the app and is NOT bundled with the ear.

application.xml looks like this



 My Application
 
 mattiz-test.jar
 
 lib

jboss-app.xml looks like this:




 
 mattiz:archive=mattiz-test.ear


The build file for creating the ear is reproduced below:



    
    
        
            
        
    
    
        
        
        
        
        
        
    
    
        
    
    
        
        
    
    
        
            
                
            
            
        
    

The ejbs are packaged in a jar and wrapped in a ear.
The ear file is generated and located in the

dist

folder.

Once the generated ear is deployed in jboss, verification of proper deployment is done by typing the following url in the browser:
http://localhost:8080/mattiz-test/TestEjbWS?WSDL
This will display the wsdl file for this web service.

Now for generating the client for this web service.

I have another application to generate the web service client stubs with the following folder structure:



     

          
               
                    
                         MattizWSClientTest.java
                         
                              
                              

     jaxb-impl-2.1.8.jar
     jaxb-xjc-2.1.6.jar
     jaxws-rt-2.1.4.jar
     jaxws-tools-2.1.4.jar
     saaj-impl.jar
     stax-ex-1.2.jar
     streambuffer-0.8.jar
build-client.xml

MattizWSClientTest.java looks like this:

package com.mattiz.ws.client;

import com.mattiz.ws.test.bean.TestEjbWS;
import com.mattiz.ws.test.bean.TestEjbWS_Service;

public class MattizWSClientTest {
	public static void main(String[] args) {
		try {
			TestEjbWS port = new TestEjbWS_Service().getTestEjbWSPort();
			System.out.println(port.testMe());
		} catch (Exception ex) {
			ex.printStackTrace();
		}
	}
}

TestEjbWS_Service is not yet generated so the class would give a compile time error.

the build xml for generating the client stubs is reproduced below:



	
		
		
			
		
	
	
		
	
	
		
		
		
		
		
	
	
		
	
	
		
			
		
	
	
		
		
	

The generated stubs have the following package structure:

com.mattiz.ws.test.bean

Place the generated client jar, mattiz-test-client.jar, on the classpath of MattizWSClientTest and run it as a standalone.
You would see the following message on the console:
Hallo World!!

Please note that the java6 version you have installed on your system may give a problem while generating the client from the WSDL.
To solve this problem you might need to point JAVA_HOME to a newer installation that might be got here->Java SE 6 Update 4.

More on SOAP, Axis and Web Services

While it is only xml in SOAP format that goes over the wire we can do anything with the SOAP xml on either side(client or server) such as bind it to java objects etc. The Axis library can do this for instance. On client/server sides you can pass objects and expect objects in return, similar to java serialization.
Server war + wsdd deployment descriptor = SOAP server.
wsdd is the depl descriptor.
Let’s say you have a java class that you want to expose as a web service (the “server” side of web services). So the java class that we want to expose as a web service we put in WEB-INF/classes of a war file or package in WEB-INF/lib as a jar file.
You put the axis.jar in WEB-INF/lib of a war for instance, edit the web.xml to add an entry for the AxisServlet and package the war and deploy. So the war contains your code and it also contains axis.jar. The axis servlet can be invoked from outside (like http://localhost:8080/AxisServlet), since we added AxisServlet in web.xml. But now the problem is Axis doesn’t know about your java class though they are in the same war. So you write a wsdd, which is like an xml configuration file that tells Axis about your java class at deploy time/ runtime. So when an incoming request comes using http Axis parses the request xml, extracts values from it and converts the parameters to java objects and invokes your class. So the ‘server’ part of webservice is ready.
If we are exposing a service which may not be a simple class but a complex application you can put your java application in a war containing axis.jar or you can put axis.jar in your existing complex app which is pretty much the same thing. If the service has ejb too, the war can be inside the ear and AxisServlet can still be accessed externally. There can be ejbs that can be invoked by your java class, but that’s all back end processing.
So once you have your webservice ready it is available for client applications to invoke it.
The wsdl is a description of your webservice. wsdl creation is automatic. If you are successful in creating your web service, the client can just do http://localhost:8080/AxisServlet/foo?wsdl to get the wsdl.The client programmer takes the wsdl from you and runs wsdl2java tool to create stub java classes. wsdl2java tool can be used to create client side java objects(stub and skeleton) from the web service wsdl and the client code can invoke the stub’s method as usual, and unbeknownst to it the stub will convert the java call to a webservice call over the network in xml.
wsdl+ axis jar file+java proxy = SOAP client.
The client programmer would need axis.jar to access the wsdl2java tool inside the axis.jar The client programmer uses wsdl + axis.jar to create the stub and once the stub is ready he uses the stub + axis.jar to invoke the webservice.
The server side can be java and client side be any technology, or vice versa. As SOAP is technology agnostic and since it is xml going back and forth it could be any technology on either side. You could write the web service with whatever tools .net provides for instance. The soap response format is the same whether its java .net or C++ (basically xml).
Example of a web service using Axis 1.4 http://cuppajavamattiz.com/2013/10/04/creating-a-simple-web-service-using-apache-axis-1-4/

SOAPing it Up

Introduction to Web Services
In distributed computing, the geeks like to see the world divided into various “service providers” and “service users”. The service provider typically is the owner of a “software component” that does some unit of work. The service user has a system that does a complete task (involving many units of work)for which it needs the service of one or many such service providers.
Let us take the example of Google (which effectively uses Web Services currently). Google provides the service of searching the Internet. This service is being used by multiple other clients either directly or integrated with other functionality inside its applications. Google charges clients on a per-search basis (maybe just a few cents per search, but adds up to a substantial amount if traffic is good).
The beauty of it is that Google can provide the service over the Internet using Web Services technology. These other clients who use Google’s search engine need not be connected to Google’s services through LAN or WAN. Other companies like Reuters (to provide real-time news on a per-demand basis), Amazon (to provide e-commerce through web-sites) could also provide web services. Some Wall Street firms can provide a service that would provide stock quotes over the Internet.
Any applications that need to incorporate these function into their design simply act as clients to the web-service.
The mechanics of Web Services
To access the Google Web Services, the essential information that a client needs to provide is the “search string” (the text that you provide the search engine). The string should travel from the client’s machine across the Internet to Google’s server. Google’s server would do its searching business and get some content which would be the result of the search. This result needs to travel from the Google’s server back to the client’s machine.This is essentially the equivalent of executing the method
String doGoogleSearch(String searchString).
The essential difference here is that the logic for the method would exist on Google’s servers while the method needs to be executed from some client location. The two are only connected through the Internet.
To make this work, the Web-Service client and provider need to communicate using HTTP (the language of the Internet of course). Whoaaa… You would say … HTTP is used for browsers to communicate with applications.. what this all about two applications talking to each other using HTTP? Thats the new way that HTTP is being used by the Web Services.
So let us imagine that Google’s clients send it information pertaining to what method it wants to execute, and the parameters to the method. The http traffic would look like this:

POST /EndorsementSearch HTTP/1.1
Host: www.google.com
Content-Type: text/xml; charset="utf-8"
Content-Length:261
SOAP Action: "http://www.google.com/Search"
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schema.xmlsoap.org.soap/envelope/"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <SOAP-ENV:Body>
        <u>
            <m:DoGoogleSearch xmlns:m="http://google.com/service/Search">
                <searchString>Sammy Sosa</searchString>
            </m:DoGoogleSearch>
        </u>
    </SOAP-ENV Body>
    </SOAP-ENV: Envelope>

As you can see, SOAP is just a specific XML format to make the content understandable to service providers and users.
If you ignore the rest of the extraneous material, you’ll see that the essential information is the name of the Web Service http://google.com/service/Search, the method to be executed is doGoogleSearch() and parameter passed is “searchString” whose value is “Sammy Sosa”.
You’ll admit that this HTTP traffic looks pretty different from a regular HTTP traffic coming from the browser which will be more like

<html> <head>blah.. blah.. </head></html>

The Google servers should have an outward facing Web Service that can interpret this kind of traffic coming in, parse out essential information and execute relevant method and transmit back information.This is done by the “soap engine” . In Java, the soap engine is usually a special servlet which would trap all HTTP messages that hit a specified url pattern. Let’s say our Google Web Server’s soap engine interprets all URLs that end with service /* and assumes that it’s a soap request (as opposed to an HTML request).
The soap engine would execute the relevant method doGoogleSearch(…) and get the result (in this case it is “LARGE STRING SEARCH RESULT”) and transmit it back as HTTP response. The return transmit would look like this:

<?xml:namespace prefix = soap-env />
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:DoGoogleSearchResponse xmlns:m="http://google.com/service/Search">
<searchResults>LARGE STRING SEARCH RESULT</searchResults>
</m:DoGoogleSearchResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Enve1ope>

The client can extract the search result from the SOAP message and do whatever it likes with it.
If you look at the http traffic, you will see that
1. It is normal text traffic travelling on tcp/ip (HTTP) (no custom data formatting)
2. It follows http request/response style protocol(so soap engines can use servlet/php/asp architecture)
3. It can flow through regular http ports 80. etc… that normal webservers use.(this makes Web Services very pervasive to firewalls)
4. The interpretation of messages going back and forth is in XML and can be standardised and shared (between Web Service providers and users) by using commong DTDs. All Java, .NET, ASP, PHP languages are capable of doing the above four things, so Web Services can effectively connect components between these disparate systems together.
That’s what all these guys are harping about. The Web Services can connect components in disparate worlds together to build a complete application.
Some caveats however-
1. Web Services make sense only if disparate systems are involved connected by the Internet. If you need two servers both using Java to talk to each other on a LAN, there is no need of Web Services, we can might as well use RMI or CORBA.
2. The Web Service provider should build a Web Service only if it is likely to be useful to many external entities. There’s no point in creating Web Services that the clients don’t need (they could write their own code to do it).
3. Web Services are slow. The slow response that we normally experience for traffic between browsers and applications will now appear within and between applications performing their tasks. Web Service defines only the structure to communicate. It does not provide inbuilt infrastructure for security and payment.For example Google will have to figure out the security/ authentication required to identify the service users who are allowed o use its service. Because this service is available only out on the world wide web anyone can become a user of the service unless restricted by specific means.
Also Google will figure out how to charge its customers for providing the service.

A deeper look at Java Web Services and SOAP

Let us say you invoke a method Foo getFoo(String blah). In this scenario the code that invokes getFoo() is called the client while the class that implements this method is called the server. This is easily done when both client and server objects reside on the same JVM. (Please note client and Server are relative terms).
However if the client and server reside on separate JVMs as maybe in the case of EJBs, in Java we need to to do a remote invocation using RMI-IIOP. However RMI is a proprietary protocol in Java and will not work when say the client uses Java and the server uses say, .NET.
This is where web services comes in. With Web Services you have different technologies communicating with each other. This kind of communication is useful when integrating different systems as in EAI (Enterprise Architecture Integration).
Web Services use http, the same protocol between browser and server, except that here there is no browser as client, the client and server are both application servers communicating via HTTP protocol.
If the client system needs to invoke a method on the server system, let’s say, Foo getFoo(String blah), then the client needs to send the server the “blah” parameter and in return get the “Foo” object, that is through HTTP.
So as you can see it is pretty much a request- response model.
So let’s say the client creates a small xml

<param1>blah</param1>

and sends it across via http to the Server which reads it and creates a Foo object and sends back a response again as xml.
So as you can see the data is sent as Strings embedded in an xml file which both server and client can construct into a java object. (Here we are dealing with both server and client using Java technologies, not disparate systems). This conversion to xml is also serialization, just that it is easier to read than what RMI does during serialization. This process is called XML over HTTP.
The problem with this technique is the client and server need to come up with some agreement on the XML syntax being used for data transfer.
This is where SOAP comes in. It is basically structured XML which tells you how the xml will look like, which part of the xml holds the parameters, where the result lies in the XML, etc. It’s just an envelope around the real data xml and hence called the SOAP envelope. It structures the data so both client and server can interpret the http requests and responses.
The way it works is-
The server creates a file called wsdl(pronounced visdel) – which describes the structure of the xml for specific data involved.
If there is a service available at a server with url say http://myserver.com/abc then the client gets the wsdl from the server by typing http://myserver.com?wsdl, and creates a java class using java utility classes and a SOAP client, usually a jar file. The java class is like the RMI stub for EJBs and acts as a proxy class – you invoke methods on the stub and it will do the communication for you; so you don’t need to worry about what is on the server, you just work with the wsdl you got. The SOAP client (a jar file) needs to be on the client classpath when running as well, not only for creating the proxy.
The server party has a tougher job that includes installing the web service (the SOAP engine). Just as there is a SOAP client on the client side, the SOAP engine, usually a war file, acts as the SOAP server on the server side.
The Server guy has written a java class manually with the implementation of the getFoo() method which he intends to make available through the web service. For this he deploys the war file on the web server. Then he writes a deployment descriptor called wsdd where he describes the java class containing the getFoo() method and configures the server war file to read it and make it available. So it is the war file that reads the deployment descriptor file(wsdd) and makes the service available.
When the web server, say Tomcat, with the SOAP server, is running, it is listening to http. The client makes a http request to the SOAP server after opening the http port on the server side, just like a standalone application can. The configuration for the deployment descriptor can be done through a web console similar to weblogic or websphere.
Sometimes you would not need a deployment descriptor, wsdd file, in case you rename .java to .jws. The SOAP engine (SOAP server) can read the .jws file and analyze it, after you point out your jws file through the web console configuration apparatus. You could also use the configuration console to point out your deployment descriptor to the SOAP engine, too.
UDDI
This is an optional feature and allows you to dynamically discover web services. For example if you want to know today’s interest rates, there may be multiple web services providing that information – so to get one you like, you look up it in the UDDI – it is like a registry. UDDI is not practical mostly, because usually the client has to know very well which server it’s going to talk to and what is the format of the SOAP request it expects, and so it’s hard to dynamically search and use web service this way.