WEB SERVICES NOTES - UNIT-1

● Extensible Markup Language (XML):

In February 1998, the Worldwide Web Consortium (W3C) officially

endorsed the Extensible Markup Language (XML) as a standard data
format. XML uses Unicode, and it is structured self-describing
neutral data that can be stored as a simple text document for
representing complex data and to make it readable. Today, XML is
the de facto standard for structuring data, content, and data format for
electronic documents. It has already been widely accepted as the
universal language lingua franca for exchanging information between
applications, systems, and devices across the Internet. In the core of
the Web services model, XML plays a vital role as the common wire
format in all forms of communication. XML also is the basis for
other Web services standards.

● Introduction to Web services:

Today, people use the Internet as an everyday service provider for reading headline news,
obtaining stock quotes, getting weather reports, shopping online, and paying bills, and also
for obtaining a variety of information from different sources. These Web-enabled
applications are built using different software applications to generate HTML, and their
access is limited only through an Internet browser or by using an application-specific client.
The emergence of Web services introduces a new paradigm for enabling the exchange of
information across the Internet based on open Internet standards and technologies. Using
industry standards, Web services encapsulate applications and publish them as services.
These services deliver XML-based data on the wire and expose it for use on the Internet,
which can be dynamically located, subscribed, and accessed using a wide range of computing
platforms, handheld devices, appliances, and so on. Due to the flexibility of using open
standards and protocols, it also facilitates Enterprise Application Integration (EAI), business
to-business (B2B) integration, and application-to-application (A2A) communication across
the Internet and corporate intranet. In organizations with heterogeneous applications and
distributed application architectures, the introduction of Web services standardizes the
communication mechanism and enables interoperability of applications based on different
programming languages residing on different platforms.

● What are Web Services:

Web services are based on the concept of service-oriented architecture (SOA). SOA is the
latest evolution of distributed computing, which enables software components, including
application functions, objects, and processes from different systems, to be exposed as
services. According to Gartner research (June 15, 2001), “Web services are loosely coupled
software components delivered over Internet standard technologies.” In short, Web services
are self-describing and modular business applications that expose the business logic as
services over the Internet through programmable interfaces and using Internet protocols for
the purpose of providing ways to find, subscribe, and invoke those services. Based on XML
standards, Web services can be developed as loosely coupled application components using
any programming language, any protocol, or any platform. This facilitatesdelivering business
applications as service accessible to anyone, anytime, at any location, and using any platform.
Consider the simple example shown in Figure 2.1 where a travel reservation services provider
exposes its business applications as Web services supporting a variety of customers and
application clients. These business applications are provided by different travel organizations
residing at different networks and geographical locations.

● Why Use Web services:

Traditionally, Web applications enable interaction between an end user and a Web site, while
Web services are service-oriented and enable application to- application communication over
the Internet and easy accessibility to heterogeneous applications and devices. The following
are the major technical reasons for choosing Web services over Web applications:
■Web services can be invoked through XML-based RPC mechanisms across firewalls.
■Web services provide a cross-platform, cross-language solution based on XML messaging.
■Web services facilitate ease of application integration using a lightweight infrastructure
without affecting scalability.
■Web services enable interoperability among heterogeneous applications

● SOA Architecture
Service-oriented architecture (SOA) allows different ways to develop
applications by combining services. The main premise of SOA is to
erase application boundaries and technlogy differences. As
applications are opened up, how we can combine these services
securely becomes an issue. Traditionally, security models have been
hardcoded into applications and when capabilities of an application
are opened up for use by other applications, the security models built
into each application may not be good enough.

Several emerging technologies and standards address different aspects

of the problem of security in SOA. Standards such as WS-Security,
SAML, S-Trust, S-SecureConversation and WS-SecurityPolicy focus
on the security and identity management aspects of SOA
implementations that use Web services. Technologies such as virtual
organization in grid computing, application-oriented networking
 (AON) and XML gateways are addressing the problem of SOA
security in the larger context.

XML gateways are hardware or software based solutions for enforcing

identity and security for SOAP, XML, and REST based web services,
usually at the network perimeter. An XML gateway is a dedicated
application which allows for a more centralized approach to security
and identity enforcement, similar to how a protocol firewall is
deployed at the perimeter of a network for centralized access control
at the connection and port level.
XML Gateway SOA Security features include PKI, Digital Signature,
encryption, XML Schema validation, antivirus, and pattern
recognition. Regulatory certification for XML gateway security
features are provided by FIPS and United States Department of
Defense.

What is SOAP:-

SOAP is the standard messaging protocol used by Web services. SOAP’s

primary application is inter application communication. SOAP codifies
the use of XML as an encoding scheme for request and response
parameters using HTTP as a means for transport.

SOAP covers the following four main areas:

– A message format for one-way communication describing

how a message can be packed into an XML document.

– A description of how a SOAP message should be transported

using HTTP (for Web- based interaction) or SMTP (for e-mail-
based interaction).

– A set of rules that must be followed when processing a

SOAP message and a simple classification of the entities
involved in processing a SOAP message.
– A set of conventions on how to turn an RPC call into a SOAP message and
back.

Simple Object Access Protocol, or SOAP, is a standard for a

lightweight XML-based messaging protocol. It enables an exchange
of information between two or more peers and enables them to
communicate with each other in a decentralized, distributed
application environment. Like XML, SOAP also is independent of
the application object model, language, and running platforms or
devices. SOAP is endorsed by W3C and key industry vendors like
Sun Microsystems, IBM, HP, SAP, Oracle, and Microsoft.

In the core of the Web services model, SOAP is used as the

messaging protocol for transport with binding on top of various
Internet protocols such as HTTP, SMTP, FTP, and so on. SOAP uses
XML as the message format, and it uses a set of encoding rules for
representing data as messages. Although SOAP is used as a
messaging protocol in Web services, it also can operate on a
request/response model by exposing the functionality using
SOAP/RPC based on remote procedural calls. SOAP also can be
used with J2EE-based application frameworks.
SOAP Envelope

The SOAP envelope is the primary container of a SOAP message’s

structure and is the mandatory element of a SOAP message. It is
represented as the root element of the message as Envelope. As we
discussed earlier, it is usually declared as an element using the XML
namespace ttp://schemas .xmlsoap.org/soap/envelope/. As per SOAP
1.1 specifications, SOAP messages that do not follow this namespace
declaration are not processed and are considered to be invalid.
Encoding styles also can be defined using a namespace under
Envelope to represent the data types used in the message. Listing 4.3
shows the SOAP envelope element in a SOAP message.

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://
schemas.xmlsoap.org/soap/envelope/
xmlns:xsi=”http://www.w3c.org/2001/X
MLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/X
MLSchema”

SOAP-ENV:

encodingStyle=”http://schemas.xmlsoap.org/soap/enc ding/”/>

<!--SOAP Header elements - -/>

<!--SOAP Body element - -/>

</SOAP-ENV:Envelope>

SOAP Header
The SOAP header is represented as the first immediate child element
of a SOAP envelope, and it has to be namespace qualified. In addition,
it also may contain zero or more optional child elements, which are
referred to as SOAP header entries. The SOAP encoding Style
attribute will be used to
define the encoding of the data types used in header element entries.
The SOAP actor attribute and SOAP must Understand attribute can be
used to indicate the target SOAP application node
sender/Receiver/Intermediary) and to process the Header entries.
Listing

4.4 shows the sample representation of a SOAP header element in a SOAP

message.

<SOAP-E V:Header>

<wiley:Transaction

xmlns:wiley=”http://jws.wiley.com/2002/booktx”

SOAP-E V:mustUnderstand=”1”>
<keyValue> 5 </keyValue>

</wiley:Transaction>

</SOAP-ENV:Header>

27
SOAP Body
A SOAP envelope contains a SOAP body as its child element, and it
may contain one or more optional SOAP body block entries. The
Body represents the mandatory processing information or the
payload intended for the receiver of the message. The SOAP 1.1
specification mandates that there must be one or more optional
SOAP Body entries in a message. A Body block of a SOAP message
can contain any of the following:
■ RPC method and its parameters

■ Target application (receiver) specific data

■ SOAP fault for reporting errors and status information

Listing 4.5 illustrates a SOAP body representing an RPC call for

getting the book price information from www.wiley.com for the book
name Developing Java Web Services.

<SOAP-ENV:Body>

<m:GetBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList/”>

<bookname xsi:type=’xsd:string’>

Developing Java Web services</bookname>

</m:GetBookPrice>

</SOAP-ENV:Body>

SOAP Encoding

SOAP 1.1 specifications stated that SOAP- based applications can represent
their data either
as literals or as encoded values defined by the “XML Schema,
Part -2” specification (see ww.w3.org/TR/xmlschema-2/). Literals
refer to message contents that are encoded according to the W3C
XML Schema. Encoded values refer to the messages encoded
based

on SOAP encoding styles specified in SOAP Section 5 of the SOAP 1.1

specification. The

namespace identifiers for these SOAP encoding styles are defined in

http://schemas.xmlsoap.org/soap/encoding/(SOAP1.1)and
http://www.w3.org/2001/06/soap-encoding (SOAP 1.2). The SOAP
encoding defines a set of rules for expressing its data types. It is a
generalized set of data types that are represented by the
programming languages, databases, and semi-structured data
required for an application. SOAP encoding also defines
serialization rules for its data model using an encoding Style
attribute under the SOAP-ENV namespace that specifies the
serialization rules for a specific element or a group of elements.
SOAP encoding supports both simple- and compound-type values.
SOAP Messaging
SOAP Messaging represents a loosely coupled communication model
based on message notification and the exchange of XML documents.
The SOAP message body is represented by XML documents or
literals encoded according to a specific W3C XML schema, and it is
produced and consumed by sending or receiving SOAP node(s). The
SOAP sender node sends a message with an XML document as its
body message and the SOAP receiver node

28
● Web Services Defination Language (WSDL)

The Web Services Definition Language (WSDL) standard is an XML

format for describing the network services and its access
information. It defines a binding mechanism used to attach a
protocol, data format, an abstract message, or set of endpoints
defining the location of services.

In the core of the Web services model, WSDL is used as the

metadata language for defining Web services and describes how
service providers and requesters communicate with one another.
WSDL describes the Services Oriented Architecture; nctionalities
offered by the service provider, where the service is located, and how
to access the service. Usually the service provider creates Web
services by generating WSDL from its exposed business
applications. A public/private registry is utilized for storing and
publishing the WSDLbased information.

The Web Services Description Language, or WDDL, is an XML

schema based specification for describing Web services as a collection
of operations and data input/output parameters as messages. WSDL
 also defines the communication model with a binding mechanism to
attach any transport
protocol, data format, or structure to an abstract message, operation, or endpoint.
Listing
3.2 shows a WSDL example that describes a Web service meant for
obtaining a price of a book using a GetBookPrice operation.

<?xml version=”1.0”?>

<definitions name=”BookPrice”
targetNamespace=”http://www.wiley.com/bookprice.wsdl ”
xmlns:tns=http://www.wiley.com/bookprice.wsdl

● WSDL Limitations

There are some limitations to consider when using the WSDL-first

approach and svcutil to create Contract files.
Declared Faults
When the WSDL contains declared faults:

•Specify the /UseSerializerForFaults argument during proxy code generation. For

example:

svcutil /UseSerializerForFaults *.wsdl *.xsd.

If a port type of an operation includes Fault child node, the operation must use
Document

•style.

•The fault part should refer to element but not type. For example:
Supported
<message name="SimpleTypeFault">
<part name="SimpleTypeFault" element="ns2:StringFaultElement" />
</message>
The following is incorrect for faults:
Not Supported
<message name="SimpleTypeFault">
<part name="SimpleTypeFault" type="xs:string" />
</message>
 Removing OperationFormatStyle.Rpc Attribute
The OperationFormatStyle.Rpc attribute is not supported if the operation
also has the fault contract attribute.
If the generated proxy code contains an attribute
OperationFormatStyle.Rpc, then you must regenerate the WSDL from the
code after deleting the attribute.
Identical part Elements
The part elements of messages cannot be same. If the elements are
identical, svcutil throws an error. For example, this definition is allowed:
Supported
<message name="MultipartInputElement">
<part name="Fortune" element="ns2:PersonDetailsElementsOne" />
<part name="Person" element="ns2:PersonDetailsElementsTwo" />
</message>

This definition, where the parts refer to same element, is incorrect:

Not Supported
<message name="MultipartInputElement">
<part name="Fortune" element="ns2:PersonNestedElements" />
<part name="Person" element="ns2:PersonNestedElements" />
</message>
Mixed Type Messages
Mixed type messages are not supported. All message parts must refer to
either element or type.
For example, the following definition is not permitted:

Not Supported

<message name="MultipartInputElement">
<part name="Fortune" element="ns2:PersonDetailsElementsOne" />
<part name="Person" type="xs:string" />
</message>

● Universal Description, Discovery and Integration (UDDI):

Universal Description, Discovery, and Integration, or UDDI, defines

the standard interfaces and mechanisms for registries intended for
publishing and storing descriptions of network services in terms of
XML messages. It is similar to the yellow pages or a telephone
directory where businesses list their products and services. Web
services brokers use UDDI as a standard for registering the Web
service providers. By communicating with the UDDI registries, the
service requestors locate services and then invoke them.

In the core Web services model, UDDI provides the registry for Web
services to function as a service broker enabling the service providers
to populate the registry with service descriptions and service types
and the service requestors to query the registry to find and locate the
services. It enables Web applications to interact with a UDDI-based
registry using SOAP messages. These registries can be either private
services within an enterprise or a specific community, or they can be
public registries to service the whole global business community of
the Internet. The UDDI working group includes leading technology
vendors like Sun Microsystems, IBM, HP, SAP, Oracle, and
Microsoft.

Universal Description, Discovery and Integration (UDDI)

is a platform-independent, extensible world markup language(XML)-
based registry by which businesses worldwide can list themselves on
the Internet, and a mechanism to register and locate web service
applications. UDDI is an open industry initiative, sponsored by the
Organization for the Advancement of Structured Information Standards
(OASIS), for enabling businesses to publish service listings and
discover each other, and to define how the services or software
applications interact over the Internet.

UDDI was originally proposed as a core Web service standard .[1] It is

designed to be interrogated by SOAP messages and to provide access
to Web Services Description Language (WSDL) documents describing
the protocol bindings and message formats required to interact with the
web services listed in its directory.

A UDDI business registration consists of three components:

· White Pages — address, contact, and known identifiers;

 · Yellow Pages — industrial categorizations based on standard taxonomies;
· Green Pages — technical information about services exposed by the
business.

White Pages

White pages give information about the business supplying the service.
This includes the name of the business and a description of the
business - potentially in multiple languages. Using this information, it
is possible to find a service about which some information is already
known (for example, locating a service based on the provider's

name).[6]

Contact information for the business is also provided - for example the
businesses address and phone number; and other information such as
the Dun & Bradstreet Universal umbering System number.
Yellow Pages

Yellow pages provide a classification of the service or business, based

on standard taxonomies. These include the Standard Industrial
Classification (SIC), the North American Industry Classification
System (NAICS),[6] or the United Nations Standard
Products and Services Code (UNSPSC) and geographic taxonomies.

Because a single business may provide a number of services, there

may be several Yellow Pages (each describing a service) associated
with one White Page (giving general information about the business).
Green Pages

Green pages are used to describe how to access a Web Service, with
information on the service bindings. Some of the information is related
to the Web Service - such as the address of the service and the
parameters, and references to specifications of interfaces.[6] Other
information is not related directly to the Web Service - this includes
e-mail, FTP,CORBA and telephone details for the service. Because a
Web Service may have multiple bindings (as defined in its WSDL
description), a service may have multiple Green Pages, as each binding
will need to be accessed diferently.
 ● SOAP Vs REST:

● JAXB:

JAXB tutorial provides concepts and API to convert object into XML and XML into object.
Our JAXB tutorial is designed for beginners and professionals.

JAXB stands for Java Architecture for XML Binding. It provides mechanism to marshal
(write) java objects into XML and unmarshal (read) XML into object. Simply, you can say it
is used to convert java object into xml and vice-versa.
 ● Features of JAXB 2.0

JAXB 2.0 includes several features that were not present in JAXB 1.x. They are as follows:

1) Annotation support: JAXB 2.0 provides support to annotation so less coding is required to
develop JAXB application. The javax.xml.bind.annotation package provides classes and
interfaces for JAXB 2.0.

2) Support for all W3C XML Schema features: it supports all the W3C schema unlike JAXB
1.0.

3) Additional Validation Capabilities: it provides additional validation support by JAXP 1.3

validation API.

4) Small Runtime Library: it required small runtime library that JAXB 1.0.

5) Reduction of generated schema-derived classes: it reduces a lot of generated schema-

derived classes.