Why Web Services, while I have created Web Application using Servlets/JSPs?
If both applications are in Java then you have choices like Socket Programming, RMI etc for establishing a
communication between them. But what if two different technologies want to communicate e.g. .NET wants
to invoke some functionality of our EJB components.
Still we have choices like CORBA or writing some application specific code like .NET makes an http call to
call your servlet, you returned the desired results in string or binary stream format. But there will be n number
of issues related to the data format, security, encoding, data posting etc.
Whatever can be accomplished by CORBA can be accomplished using Web service technologies and vice
versa, although the amount of effort required would be noticeably different. CORBA is complex and in
CORBA, there is a tight coupling between the client and the server. In Web services, everything is decoupled.
The client sends a message and receives a message. See the comparison –
Aspect CORBA Web services
Data model Object model SOAP message exchange model
Client-Server coupling Tight Loose
Location transparency Object references URL
Type system IDL XML schemas
static + runtime checks runtime checks only
Error handling IDL exception SOAP fault messages
Serialization built into the ORB can be chosen by the user
Parameter passing by reference by value (no notion of objects)
by value (valuetype)
Transfer syntax CDR used on the wire XML used on the wire
binary format Unicode
State Stateful stateless
Request semantics at-most-once defined by SOAP
Runtime composition DII UDDI/WSDL
Registry Interface Repository UDDI/WSDL
Implementation repository
Service discovery CORBA naming/trading service UDDI
RMI registry
Language support any language with an IDL binding any language
Security CORBA security service HTTP/SSL, XML signature
When the user selects a book from one of MyXMLBooks.com's web pages, the HTTP request generated is
routed via a controlling servlet on the MyXMLBooks.com web server, which determines that it needs to
retrieve raw book data from Amazon.com. The servlet obtains this data by using a web service client
implemented by MyXMLBooks.com's developers. This client uses the web service interface published by
Amazon.com to invoke a method on its server that returns the required information. The method invocation is
performed by creating an XML message that contains the method name and any required parameters and then
sending it to Amazon.com's server using some standard protocol (SOAP ;-)
Have you realized how two different applications communicating to each other over internet without knowing
the underlying technologies of other side?
WSDL – Web Service Description Language (A XML document having info about your services)
UDDI – Universal Description, Discovery & Integration (like JNDI where we bind WSDL for client access)
Creating Services - We will write our java class that we want to make a service. The functions inside this
class are the service functionalities.
Registering Services - Then we will create a WSDD file. A web service deployment descriptor contains a
bunch of things you want to "deploy" into Axis - i.e. make available to the Axis engine. Once we have this
file, we need to send it to an Axis server in order to actually deploy the described service. We do this with the
AdminClient, or the "org.apache.axis.client.AdminClient" class.
Requesting Services – we will write some code to access them. There are APIs those provide the
functionality for calling the deployed web services.
Axis Setup –
1. Unzip axis-1_4.zip downloaded from apache.
2. Copy its webapps folder to tomcat; now tomcat has axis web application.
3. Start tomcat >Catalina start and access http://localhost:8080/axis
Note - Before running the example, you'll need to make sure that your CLASSPATH includes
axis/WEB-INF/lib contained all the required jars, add activation and mail.jar for avoid
warnings.
Step 1 – HelloWorld.java
package org.test.ws;
public class HelloWorld {
public String sayHello(String name) {
return "Hello " + name;
}
}
Note - Tomact must be running when you are executing this command.
package org.test.deploy;
import org.apache.axis.client.AdminClient;
public class DeployHello {
public static void main(String[] args) {
AdminClient.main(new String[] { "deploy.wsdd" });
}
}
Step 4 – Copy org/test/ws/HelloWorld.class in axis/WEB-INF/classes and restart tomcat.
Access http://localhost:8080/axis then click on List link.
http://localhost:8080/axis/services/hello?method=sayHello&name=Sumit
hello.html
<form action="http://localhost:8080/axis/services/hello">
<input type="hidden" name="method" value="sayHello">
<input type="text" name="name">
<input type="submit">
</form>
Repeating again ;-) Web Services are for program to program interaction, but what we did
here User to Program interaction.
Client Program - HelloClient.java
package org.test.ws;
import java.net.URL;
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
public class HelloClient {
public static void main(String[] args) {
try {
URL url = new URL("http://localhost:8080/axis/services/hello");
A WSDL document is a kind of structured language to describe a Web Service; it contains set of definitions to
define a web service
1. The <types> element defines the data type that are used by the web service
2. The <message> element defines the data elements of an operation. Each message can consist of one or
more parts. The parts can be compared to the parameters of a function call in a traditional programming
language
3. The <portType> element is the most important WSDL element. It defines a web service, the
operations that can be performed, and the messages that are involved
4. The <binding> element defines the message format and protocol details for each port
5. The <services> element defines the URL for the available services
So, if Amazon.com provides WSDL for its services then anyone can write client program for accessing these
services by figuring out the things from this WSDL file.
There are several eclipse and other plugins which generate client program, if WSDL provided to them. Even
you can get more automation from these plugins. These will make your life easier.
<soapenv:Envelope 1
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body> 4
<sayHelloResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<sayHelloReturn xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
Hello Sumit
</sayHelloReturn>
</sayHelloResponse>
</soapenv:Body>
</soapenv:Envelope>
SOAP is an XML based protocol for exchange of information
• Encoding rules for data type instances
• Convention for representing RPC invocations
Transport independent
SOAP RPC:
• Encode and bind data structures into xml.
• encode an RPC call
1. The SOAP Envelope element is the root element of a SOAP message. It defines the XML document
as a SOAP message.
2. The optional SOAP Header element contains application specific information (like authentication)
about the SOAP message.
3. If the Header element is present, it must be the first child element of the Envelope element.
4. The required SOAP Body element contains the actual SOAP message intended for the ultimate
endpoint of the message
5. An error message from a SOAP message is carried inside a Fault element. If a Fault element is
present, it must appear as a child element of the Body element. A Fault element can only appear once
in a SOAP message.
3.
1. SW companies, standards
bodies, and programmers
populate the registry with
Marketplaces, search
descriptions of different types
engines, and business
of services
apps query the registry
to discover services at
other companies
2.
UDDI Registry 4.
Business Service
Businesses populate
Descripti Types
the registry with ons Business uses this
descriptions of the
data to facilitate
services they
easier integration
support
with each other over
the Web
Currently we have not used UDDI; we used an axis servlet http://localhost:8080/axis/services/hello?wsdl that
generate and send WSDL in response.
Use http://ws.apache.org/juddi/ an open source API for UDDI specification. Just imagine it like LDAP is
specification and Sun’s iPlanet or Microsoft Active Directory etc. is an implementation.
Note - Set the required jars into the classpath, you will all required jars from axis/WEB-INF/lib folder.
Java2WSDL.main(a);
}
}
Where:
The output WSDL document will contain the appropriate WSDL types, messages, portType, bindings and
service descriptions to support a SOAP rpc, encoding web service. If your specified interface methods
reference other classes, the Java2WSDL tool will generate the appropriate xml types to represent the classes
and any nested/inherited types. The tool supports JAX-RPC complex types (bean classes), extension classes,
enumeration classes, arrays and Holder classes.
It will generate same WSDL file as we have earlier. So now you know the logic behind hello (wsdl) link ;-)
2. There are several ways for invoking a web service the way we used recently called Dynamic
Invocation Interface (DII). Another way using generated Stubs from Service WSDL.
This tool will generate all these stubs and required file for you.
Step 1 – Generate required files by using WSDl2Java command
>java org.apache.axis.wsdl.WSDL2Java
-o . 1
–d Session 2
-s -S true 3
-Nhttp://localhost:8080/axis/services/hello org.test.ws 4
hello.wsdl 5
Or public class WSDL2Java {
public static void main(String[] args) {
String a = new String[] { "-o", ".",
"-d", "Session",
"-s", "-S", "true",
"-Nhttp://localhost:8080/axis/services/hello", "org.test.ws",
"hello.wsdl" };
WSDL2Java.main(a);
}
}
We need to tweak one of the output source files to tie the Web service to HelloWorld.java.
HelloSoapBindingImpl.java is waiting for us to add the stuff into the methods that it created. The lines
that we added are in bold:
package org.test.ws;
public class HelloSoapBindingImpl extends HelloWorld {
HelloWorld h = new HelloWorld();
We are simply tying in to the existing class. We could have hard-coded the methods in this class, but in the
real world, we probably want to wrap logic as Web services, and not just enable access via that interface or
class.
Now our hello Web service is alive and running in the server!
All we need to do in the code is to get access to the service via the ServiceLocator, and then call methods on
the remote handle that we have to the service.
package org.test.ws;
It looks just like normal Java; none of that SOAP or RPC code is in sight. Isn't that nicer? (Take another look
at the HelloClient that we used at the beginning, and compare it to this code.)
Hope, Now you will be comfortable with this web service stack
SOA (Service Oriented Architecture) - SOA is an architectural style for building software applications that
use services available in a network such as the web. It promotes loose coupling between software components
so that they can be reused. Applications in SOA are built based on services. A service is an implementation of
well-defined business functionality, and such services can then be consumed by clients in different
applications or business processes.
;-)
1. Build a class that implements the business method of your Web Service. Note that this class is
categorized as a Servlet, but it does not need to extend the Servlet or HttpServlet class.
2. Build a Remote interface for the service that lists all of the methods that the service exposes.
3. Create a Servlet mapping in your web.xml file that maps a URL pattern to your service Servlet.
4. Build or generate a WSDL file. This file is part of the Web Services standard and it describes the
services that you publish, complete with parameter types and return values, in a platform-independent
way.
5. Build or generate a JAX-RPC mapping file. Your application server uses this file to map Web
Service requests to your Servlet.
7. Assemble a WAR file containing your compiled service code and the configuration files that we
mentioned thus far.
In the end, the deployment structure of your WAR file should resemble the following:
WEB-INF/
WEB-INF/classes
WEB-INF/mapping.xml
WEB-INF/web.xml
WEB-INF/webservices.xml
WEB-INF/wsdl
WEB-INF/wsdl/MyWebService.wsdl
As with all Web applications, the classes directory contains all of the compiled classes, which in this case
includes your compiled Web Service Servlet and Remote interface. The web.xml configuration has all of your
Servlets, resource mappings, etc., as well as a Servlet Mapping entry for your Web service.
And thankfully, the Java Web Services Developer Pack (WSDP) includes a tool, wscompile, that generates
the other configuration files: mapping.xml, webservices.xml, and *.wsdl. You need to provide it with a
relatively simple configuration file to tell it how to build those files.
The configuration requirements for building a Web Service out of a Stateless Session Bean are similar to the
Servlet requirements. The following are the steps required to publish a Stateless Session Bean as a Web
Service:
1. Build a Stateless Session Bean (as you normally would) containing the service method you want to
expose.
2. In the ejb-jar.xml file, add a <session-endpoint> node to the <session> node in the <enterprise-
beans> section that references the Stateless Session Bean's remote interface.
3. Build or generate a webservices.xml file; but, in the <service-impl-bean> node insert an <ejb-link>
instead of a <servlet-link> (more on these details later).
The JAR file looks a little different from the WAR file; the configuration files are all in the META-INF folder
instead of the WEB-INF folder. For example:
META-INF/
META-INF/ejb-jar.xml
META-INF/mapping.xml
META-INF/webservices.xml
META-INF/wsdl
META-INF/wsdl/MyWebService.wsdl
And as with all EJB JAR files, your compiled code goes in the root of the JAR file (in the appropriate
package-defined folders).
Now think web services are for what? ;-) Basically we are doing EAI using web services, there can be other
ways but web services are the simplest one.
In B2B (business to business) communication, we require interoperability, asynchronous calling means JMS
and management (like monitoring) of all these happening. Again need of some server like jboss, weblogic etc
which provide all these functionalities and ease development of the application. Here is the birth of EAI
servers like WebMethods (I like this), Tibbco, BizTalk etc. These servers are based on JMS and web services.