Java Web Services
Introduction
Web services, in the general meaning of the term, are services offered via the Web . Web Services is a technology applicable for computationally distributed problems, including access to large databases. In a typical Web services scenario, a business application sends a request to a service at a given URL using the SOAP protocol over HTTP. The service receives the request, processes it, and returns a response. Web services and consumers of Web services are typically businesses, making Web services predominantly business-to-business (B-to-B) transactions
A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols
Web Services Architecture
Simple Object Access Protocol (SOAP)
SOAP provides a standard packaging structure for transporting XML documents over
a variety of standard Internet technologies, including SMTP, HTTP, and FTP. It also
defines encoding and binding standards for encoding non-XML RPC invocations in
XML for transport. SOAP provides a simple structure for doing RPC: document
exchange. By having a standard transport mechanism, heterogeneous clients and
servers can suddenly become interoperable. .NET clients can invoke EJBs exposed
through SOAP, and Java clients can invoke .NET Components exposed through
SOAP.
Web Service Description Language (WSDL)
WSDL is an XML technology that describes the interface of a web service in a
standardized way. WSDL standardizes how a web service represents the input and
output parameters of an invocation externally, the function's structure, the nature of
the invocation (in only, in/out, etc.), and the service's protocol binding. WSDL allows
disparate clients to automatically understand how to interact with a web service.
Universal Description, Discovery, and Integration (UDDI)
UDDI provides a worldwide registry of web services for advertisement, discovery, and
integration purposes. Business analysts and technologists use UDDI to discover
available web services by searching for names, identifiers, categories, or the
specifications implemented by the web service. UDDI provides a structure for
representing businesses, business relationships, web services, specification metadata,
and web service access points.
A Web Service example in Java
The Java API for XML-based RPC(JAX-RPC) is the Java API for developing and using Web services.
An RPC-based Web service is a collection of procedures that can be called by a
remote client over the Internet. The service itself, a server application that implements the procedures that are available for clients to call, is deployed on a server-side container.
A Web service needs to make itself available to potential clients, which it does
by describing itself in a Web Services Description Language (WSDL) document.
A WSDL description is an XML document that gives all the pertinent information
about a Web service, including its name, the operations that can be called on it, the parameters for those operations, and the location of where to send requests. A consumer (Web client) can use the WSDL document to discover what the service offers and how to access it. WSDL allows disparate clients to automatically understand how to interact with a web service
The most important requirement for a Web service is that it be interoperable
across clients and servers. With JAX-RPC, a client written in a language other than the Java programming language can access a Web service developed and deployed on the Java platform and vice versa. What makes this interoperability possible is JAX-RPC’s support for SOAP and WSDL. SOAP defines standards for XML messaging and the mapping of data types so that applications adhering to these standards can communicate with each other. JAX-RPC remote procedure call is implemented as a request-response SOAP message.
JAX-RPC mercifully makes the underlying implementation details invisible to both the client and service developer. For example, a web services client simply makes Java method calls, and all the internal marshalling, unmarshalling, and transmission details are taken care of automatically. On the server side, the Web service simply implements the services it offers and, like the client, does not need to bother with the underlying implementation mechanisms. JAX-RPC focuses on point-to-point SOAP messaging, the basic mechanism that most clients of Web services use.
Creating a Web Service
The service itself is basically two files, an interface that declares the service’s remote procedures
and a class that implements those procedures.
simple example showing the methods a wholesale coffee distributor might want to make available to its prospective customers.
package coffees;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface CoffeeOrderIF extends Remote {
public Coffee [] getPriceList()
throws RemoteException;
public String orderCoffee(String coffeeName, int quantity)
throws RemoteException;
}
package coffees;
public class CoffeeOrderImpl implements CoffeeOrderIF {
public Coffee [] getPriceList() throws RemoteException; {
// database related tasks
}
public String orderCoffee(String coffeeName, int quantity)
throws RemoteException; {
// doing database related task
}
}
After writing the service’s interface and implementation class, the developer’s
next step is to run the mapping tool. The tool can use the interface and its implementation
as a basis for generating the stub and tie classes plus other classes as necessary. The developer can also use the tool to create the WSDL description for the service.
The final steps in creating a web service are packaging and deployment. Packaging
a Web service definition is done via a web application archive (WAR). A .war file is just a .jar file for Web applications, that is, a file that compresses all the files needed for the web application into one file. web.xml, contains information needed for deploying a service definition
Deploying our CoffeeOrder Web service example in a Tomcat container can be
accomplished by simply copying the jaxrpc-coffees.war file to Tomcat’s
webapps directory.
Coding a Client
Writing the client application for a Web service entails simply writing code that
invokes the desired method.
The following class definition is an example of a Web services client. It creates
an instance of CoffeeOrderIF and uses it to call the method getPriceList.
This Web services client creates
an instance of CoffeeOrderIF and uses it to call the method getPriceList.
Then it accesses the price and name fields of each Coffee object in the array
returned by the method getPriceList in order to print them out.
The class CoffeeOrderServiceImpl is one of the classes generated by the map-
ping tool. It is a stub factory whose only method is getCoffeeOrderIF; in other
words, its whole purpose is to create instances of CoffeeOrderIF. The instances
of CoffeeOrderIF that are created by CoffeeOrderServiceImpl are client side
stubs that can be used to invoke methods defined in the interface CoffeeOr
derIF. Thus, the variable coffeeOrder represents a client stub that can be used
to call getPriceList, one of the methods defined in CoffeeOrderIF.
The method getPriceList will block until it has received a response and
returned it. Because a WSDL document is being used, the JAX-RPC runtime
will get the service endpoint from it. Thus, in this case, the client class does not
need to specify the destination for the remote procedure call. When the service
endpoint does need to be given, it can be supplied as an argument on the com
mand line. Here is what a client class might look like:
package coffees;
public class CoffeeClient {
public static void main(String[] args) {
try {
CoffeeOrderIF coffeeOrder = new
CoffeeOrderServiceImpl().getCoffeeOrderIF();
Coffee [] priceList =
coffeeOrder.getPriceList():
for (int i = 0; i < priceList.length; i++) {
System.out.print(priceList[i].getName() + " ");
System.out.println(priceList[i].getPrice());
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
JAX-RPC runtime can determine the endpoint for the CoffeeOrder service (which is its URI) from its WSDL
description. If a WSDL document had not been used, you would need to supply
the service’s URI as a command line argument
.JAX-RPC runtime can determine the endpoint for the CoffeeOrder service (which is its URI) from its WSDL
description. If a WSDL document had not been used, you would need to supply
the service’s URI as a command line argument.
