Documentation on Java Web Services:

25-10-2006
Ramarao G.v.

Introduction:

Web Service is an application that exists in multi-tired environment.

Q: Why should we use web services as solution?

A: To establish communication between different object references that has been written in different
languages even those object references are running in different OS’s.

Even we can use CORBA as solution to establish communication between different objects. But our
millions of clients need to be maintained CORBA software in their machines.

CORBA is using heavy weight protocol which is known as IIOP.

Even Web Services are acting as solution for the problems that are faced by CORBA.

Web Services using lightweight protocols to exchange the data over the net that help us to increase the
performance of an application.

XML:
Extensible Markup Language (XML) began as an extensible data format to address the limitations of
HTML (HyperText Markup Language), but has become a standard for communication between
applications. With XML, an application defines markup tags to represent the different elements of data in a
text file so that the data can be read and processed by any application that uses XML.

Using XML, it is possible for business persons to define policies and express them as XML documents.
These documents can have sections that are encrypted and the documents themselves can be digitally
signed, distributed, and then interpreted by the security mechanisms that configure the local software.
This allows various implementations to map from the XML description to a local platform-specific policy
enforcement mechanism without requiring changes to the infrastructure.

SOAP:
Simple Object Access Protocol (SOAP) is a simple, lightweight, and extendable XML-based mechanism
for exchanging structured data between network applications on top of widely used Internet standards such
as XML and HTTP (HyperText Transfer Protocol). SOAP consists of three parts: an envelope that defines a
framework for describing the contents of a message, a set of encoding rules for expressing instances of
application-defined data types, and a convention for representing remote procedure calls (RPC) and
responses. SOAP can be used in combination with a variety of network protocols such as HTTP, RMI/IIOP
(Remote Method Invocation/Internet Inter-ORB [Object Request Broker] Protocol), SMTP (Simple Mail
Transfer Protocol), FTP (File Transfer Protocol), or MQ (Message Queuing).
SOAP can potentially be used in combination with a variety of other protocols; however, the only
bindings we discuss here are SOAP in combination with HTTP and HTTP Extension Framework. The
usage of a particular protocol does not change the fundamentals of the security model but may change the
particular implementation.

The SOAP envelope is defined in XML and enables a large variety of meta-information to be added to
the message, such as transaction identifiers, message routing information, and message security. The
envelope consists of two parts: header and body. The header is a generic mechanism for adding features to
a SOAP message. All immediate child elements of the SOAP header element are called header entries.

The body is a container for application data intended for the ultimate recipient of the message. Thus,
SOAP can be considered as another layer, between the transport layer (e.g., HTTP) and the application
layer (e.g., business data), that is a convenient place for conveying message meta-information.

WSDL:

Web Services Description Language (WSDL) is essentially an XML IDL (interface definition language)
that provides a way to describe the function and interface of a service. It is a format for describing network
services as a set of endpoints operating on messages containing either document-oriented or procedure-
oriented information. The operations and messages are described abstractly, and then bound to a concrete
network protocol and message format to define an endpoint. Related concrete endpoints are combined into
abstract endpoints (services).

WSDL is extensible to allow description of endpoints and their messages regardless of what message
formats or network protocols are used to communicate; however, the only currently described bindings are
for SOAP 1.1, HTTP GET/POST, and MIME (Multipurpose Internet Mail Extensions).

The WSDL service information can be extracted from a UDDI (Universal Description, Discovery, and
Integration) business service entry, or may be obtained from other service repository sources.

The Web Services Model:

The Web Services architecture is based upon the interactions between three roles: Service Provider,
Service Registry and Service Requestor. The interactions involve publishing, finding and binding
operations.
 Service Description
Service Registry
.
Find Publish
WSDL, UDDI WSDL, UDDI
Service
Service Requestor Service Provider
Bind Service Description

Web Services roles, operations and

artifacts

The Web Services Stack:

To perform the three operations of publish, find and bind in an interoperable manner, there must be a Web
Services stack that embraces standards at each level. Figure shows a conceptual Web Services stack. The
upper layers build upon the capabilities provided by the lower layers. The vertical towers represent
requirements that must be addressed at every level of the stack. The text on the left represents standard
technologies that apply at that layer of the stack.

The SOAP Message processing cycle :

The Java Web Services addresses the following technology areas:

The Java Architecture for XML Web Services (JAX-WS).

The Java Architecture for XML Binding (JAXB).

The STAX APIs and the Sun Java Streaming XML Parser implementation.

SOAP with Attachments API for Java (SAAJ).

The Java Architecture for XML Registries.

XML Digital Signature.

Security in the Web Tier.

Building Web Services with JAX-WS

JAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for building web
services and clients that communicate using XML.

JAX-WS allows developers to write message-oriented as well as RPC-oriented web services.

In JAX-WS, a remote procedure call is represented by an XML-based protocol such as SOAP. The
SOAP specification defines the envelope structure, encoding rules, and conventions for representing remote
procedure calls and responses. These calls and responses are transmitted as SOAP messages (XML files)
over HTTP.

Although SOAP messages are complex, the JAX-WS API hides this complexity from the application
developer. On the server side, the developer specifies the remote procedures by defining methods in an
interface written in the Java programming language. The developer also codes one or more classes that
implement those methods. Client programs are also easy to code. A client creates a proxy (a local object
representing the service) and then simply invokes methods on the proxy. With JAX-WS, the developer does
not generate or parse SOAP messages. It is the JAX-WS runtime system that converts the API calls and
responses to and from SOAP messages.
With JAX-WS, clients and web services have a big advantage: the platform independence of the Java
programming language. In addition, JAX-WS is not restrictive: a JAX-WS client can access a web service
that is not running on the Java platform, and vice versa. This flexibility is possible because JAX-WS uses
technologies defined by the World Wide Web Consortium (W3C): HTTP, SOAP, and the Web Service
Description Language (WSDL). WSDL specifies an XML format for describing a service as a set of
endpoints operating on messages.

Now we will look at an example using JAX-WS.

The webservice Add.java looks like:

If you deployed to the Sun Java System Application Server, type two numbers in the tester page, as
shown below:
The sum of the two numbers is displayed:

Now that we have deployed our web service, we need to create a client to make use of the web service's
add method.
We can call the Web Service Operation through any no. of clients. The client may be of servlet or JSP or
any Java SE application.

Binding between XML Schema and Java Classes:

The Java Architecture for XML Binding (JAXB) provides a fast and convenient way to bind between XML
schemas and Java representations, making it easy for Java developers to incorporate XML data and
processing functions in Java applications. As part of this process, JAXB provides methods for
unmarshalling XML instance documents into Java content trees, and then marshalling Java content trees
back into XML instance documents. JAXB also provides a way to generate XML schema from Java
objects.

A JAXB implementation consists of the following architectural components:

1. schema compiler: binds a source schema to a set of schema derived program elements. The
binding is described by an XML-based binding language.
2. schema generator: maps a set of existing program elements to a derived schema. The mapping
is described by program annotations.
3. binding runtime framework: provides unmarshalling (reading) and marshalling (writing)
operations for accessing, manipulating and validating XML content using either schema-derived
or existing program elements.

The general steps in the JAXB data binding process are:

1. Generate classes. An XML schema is used as input to the JAXB binding compiler to
generate JAXB classes based on that schema.
 2. Compile classes. All of the generated classes, source files, and application code must
be compiled.
3. Unmarshal. XML documents written according to the constraints in the source schema
are unmarshalled by the JAXB binding framework. Note that JAXB also supports unmarshalling
XML data from sources other than files/documents, such as DOM nodes, string buffers, SAX
Sources, and so forth.
4. Generate content tree. The unmarshalling process generates a content tree of data
objects instantiated from the generated JAXB classes; this content tree represents the structure and
content of the source XML documents.
5. Validate (optional). The unmarshalling process optionally involves validation of the
source XML documents before generating the content tree. Note that if you modify the content
tree in Step 6, below, you can also use the JAXB Validate operation to validate the changes before
marshalling the content back to an XML document.
6. Process content. The client application can modify the XML data represented by the
Java content tree by means of interfaces generated by the binding compiler.
7. Marshal. The processed content tree is marshalled out to one or more XML output
documents. The content may be validated before marshalling.