Web Services

What is Web Service?

 A Web service is a self-describing, self-contained

software module available via a network, such as the
Internet, which completes tasks, solves problems, or
conducts transactions on behalf of a user or
application. Web services constitute a distributed
computer infrastructure made up of many different
interacting application modules trying to communicate
over private or public networks (including the Internet
and Web) to virtually form a single logical system.
Web Service definition

A simple definition:

“a Web Service is an application component

accessible over open protocols”.
 Web Services

• Its purpose is to complete certain task, solves

problems, or conducts transactions on behalf
of a user or application.
• It constitute a distributed computer
infrastructure made up of many different
interacting application modules communicating
over a network (private, public or a single
logical system)
Web Services

Web services perform encapsulated business functions

such as:
 a self-contained business task – a funds withdrawal or
funds deposit service;
 a full-fledged business process – the automated
purchasing of office supplies;
 an application – a life insurance application or demand
forecasts and stock replenishment; or
 a service-enabled resource – access to a particular
back-end database containing patient medical records.
Web Services
 Can be mixed and matched to create a complete process:
 Enable integration with decreased human interaction, e.g., create
complete enterprise processes, such as supply chain
management, procurement, logistics, etc.
 Both new and extensions to existing applications
 Available to a variety of clients (platform independent)
 Pricing (rating) model determines subscriber rates based on
subscription and usage events, e.g., calculate charges for services
based on the quality and precision of the service.
 Billing model:
 “pay per use”, “lease it”, “pay for it” basis
A purchase order application
involving interacting web services
Webservices vs Websites

Web Service Website

A web service doesn't have a A website has a user interface
user interface or GUI
Web services are meant for
Websites are meant for use by
other applications to be
humans
interacted with over internet
Websites are cross platform as
Web services are platform
they require tweaking to
independent as they use open
operate on different browsers,
protocols
operating systems etc.

Web services are accessed by Websites are accessed by

HTTP methods - GET, POST, using their GUI components -
PUT, DELETE etc buttons, text boxes, forms etc.
Service Oriented
Applications(SOA)
 A service-oriented architecture (SOA) is an
architectural pattern in computer software design in
which application components provide services to
other components via a communications protocol,
typically over a network. The principles of service-
orientation are independent of any product, vendor or
technology.
 SOA just makes it easier for software components over
various networks to work with each other.
 Web services which are built as per the SOA
architecture tend to make web service more
independent.
The Web Service Model(SOA)

 The Web Services architecture is based upon

the interactions between three roles:
– Service provider
– Service registry
– Service requestor
 The interactions involve the:
– Publish operations
– Find operation
– Bind operations.
The Web Service Model (cont)

The Web Services model follows the publish,

find, and bind paradigm.
Service
Registry

1. publish 2. find

Service
3. bind/invoke
Service
Provider Client
Webservices Characteristics(Based
on SOA)

 Standardized Service Contract - Services adhere to

a service description. A service must have some sort of
description which describes what the service is about.
This makes it easier for client applications to
understand what the service does.
 Loose Coupling – Less dependency on each other.
This is one of the main characteristics of web services
which just states that there should be as less
dependency as possible between the web services and
the client invoking the web service.
Webservices
Characteristics(Cont..)

 Service Abstraction - Services hide the logic

they encapsulate from the outside world. The
service should not expose how it executes its
functionality; it should just tell the client
application on what it does and not on how it
does it.
 Service Reusability - Logic is divided into
services with the intent of maximizing reuse
 Service Autonomy - Services should have
control over the logic they encapsulate.
Webservices
Characteristics(Cont..)

 Service Statelessness - Ideally, services should be

stateless. This means that services should not withhold
information from one state to the other.
 Service Discoverability - Services can be discovered
(usually in a service registry).
 Service Composability - Services break big problems
into little problems.
 Service Interoperability - Services should use
standards that allow diverse subscribers to use the
service
Types of Webservices

 SOAP(Simple Object Access Protocol) Based

Webservices
 REST-style Web
Services( REpresentational State Transfer)
Slide 2.3

Distributed Computing

• A distributed system is characterized as a collection of

heterogeneous networked computers, which communicate
and coordinate their actions by passing messages.
– Distribution is transparent to the user so that the system appears
as a single integrated facility.

• One important characteristic of a distributed system is that

processes are not executed on a single processor, but rather
span a number of processors.
– This requires inter-process communication mechanisms.
Slide 2.4

Internet Protocols

• Internet protocols are essentially methods of data transport across

the Internet. They define the standards by which the different
components in a distributed system communicate across the
Internet with each other & with remote components.
• The most prominent of the Internet protocols is transport control
protocol over Internet protocol (or TCP/IP), which provide for the
reliable delivery of streams of data from one host to another across
the Internet:
– The Internet protocol (IP) enables the unreliable delivery of individual
packets from one host to another.
• IP makes no guarantees as to whether the packet will be delivered, how
long it will take, or if multiple packets will arrive in the order they were sent.
– The transport control protocol (TCP) adds the notions of connection
and reliability.
Slide 2.6

Middleware

• Middleware provides a functional

set of interfaces to allow an
application to
– locate applications transparently
across the network;
– shield software developers from
low-level, tedious and error- prone
platform details;
– provide a consistent set of higher
level abstractions that are much
closer to application requirements;
– leverage previous developments
and reuse them;
– provide services such as reliability,
availability, authentication, and
security.
Slide 2.8

Client–server model

• A client/server architecture is an architecture in which processing and storage

tasks are divided between two classes of network members, clients & servers.
• Client/server architecture involves client processes (service consumers)
requesting service from server processes (service providers). Servers may in turn
be clients of other servers.
– The client machine runs software and applications that are stored locally. The client makes
requests to servers and is also responsible for the user interface.
– Some of the applications may be stored and executed on the server, but most of it is on the
client. The server also provides the data for the application.
Slide 2.10

Messaging

• Distributed systems and applications communicate by exchanging

messages. Messaging enables high-speed, asynchronous, program-
to-program communication with reliable delivery.
• Message passing between a pair of processes is supported by two
message communication operations: send and receive, defined in
terms of destinations and messages.
• Marshalling (serialization) is the process of taking any form of
structured data items and breaking up so that it can be transmitted as
a stream of bytes over a communications network in such a way that
the original structure can be reconstructed easily on the receiving
end.
• Unmarshalling (deserialization) is the process of converting the
assembled stream of bytes on arrival to produce an equivalent form
of structured data at the destination point.
Slide 2.11

Synchronous and asynchronous messaging

•There are two basic modes of message communication:

•Synchronous communication – synchronized between two communicating application
systems, which must both be up and running.
– Execution flow at the client’s side is interrupted to execute the call.
•Asynchronous communication – the caller employs a send and forget approach that
allows it to continue to execute after it sends the message.
– Here an application sends a request to another while it continues its own processing
activities.
Slide 2.13

Remote procedure calls

• RPC is a basic mechanism

for inter-program
communication, where the
application elements use a
request/wait-for-reply
(synchronous) model of
communication.
Slide 2.14

Tightly coupled RPC point-to-point

integrations

• RPC-style programming leads to tight coupling of interfaces and

applications.
• In an RPC environment each application needs to know the intimate
details of the interface of every other application – the number of
methods it exposes and the details of each method signature it
exposes.
History (Distributed Systems)

 Web services evolved from previous

technologies that served the same purpose
such as RPC, ORPC (DCOM, CORBA and
JAVA RMI).
Interoperability

 Earlier distributed systems suffered from

interoperability issues because each vendor
implemented its own on-wire format for
distributed object messaging.
 Development of DCOM apps strictly bound to
Windows Operating system.
 Development of RMI bound to Java
programming language.
Firewall traversal

 Collaboration across corporations was an issue

because distributed systems such as CORBA
and DCOM used non-standard ports.
 Web Services use HTTP as a transport
protocol and most of the firewalls allow access
though port 80 (HTTP), leading to easier and
dynamic collaboration.
Complexity

 Web Services is a developer-friendly service

system.
 Most of the above-mentioned technologies
such as RMI, COM, and CORBA involve a
whole learning curve.
 New technologies and languages have to be
learnt to implement these services.
 JAX-WS

 All of the libraries required to compile, execute,

and consume web services are available in
core Java 6, which supports JAX-WS (Java
API for XML-Web Services). JAX-WS supports
SOAP-based and REST-style services. JAX-
WS is commonly shortened to JWS for Java
Web Services
 Metro
 SEI and SIB
 A SOAP-based web service could be implemented as a single
Java class but, following best practices, there should be an
interface that declares the methods, which are the web service
operations, and an implementation, which defines the methods
declared in the interface.
 The interface is called the SEI: Service Endpoint Interface.
 The implementation is called the SIB: Service Implementation
Bean. The SIB can be either a POJO or a Stateless Session EJB
(Enterprise Java Bean).
 JAX-WS annotations

 Java API for XML-Based Web Services (JAX-

WS) relies on the use of annotations to specify
metadata associated with Web service
implementations and to simplify the
development of Web services. Annotations
describe how a server-side service
implementation is accessed as a Web service
or how a client-side Java class accesses Web
services.
Steps to Program the JWS File

No Step Description
1 Import the standard JWS The standard JWS annotations are in either
annotations that will be used in the javax.jws or javax.jws.soappackage. For
your JWS file. example:

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
2 Import additional annotations, as
required.
3 Add the standard
required @WebService JWS
annotation at the class level to
specify that the Java class exposes
a Web Service.
No Step Description
4 Add the In particular, use this annotation to specify
standard @SOAPBinding JWS whether the Web Service is document-literal,
annotation at the class level to document-encoded, and so on. Although this
specify the mapping between the JWS annotation is not required, Oracle
Web service and the SOAP recommends you explicitly specify it in your
message protocol. (Optional) JWS file to clarify the type of SOAP bindings a
client application uses to invoke the Web
Service.
 No Step Description
5 Add the JAX-
WS @BindingType JWS annotation
at the class level to specify the
binding type to use for a Web
Service endpoint implementation
class. (Optional)
6 Add the Optionally specify that the operation takes
standard @WebMethod annotation only input parameters but does not return any
for each method in the JWS file value by using the
that you want to expose as a standard @Oneway annotation.
public operation. (Optional)
No Step Description
7 Add @WebParam annotation to customize
the name of the input parameters of the
exposed operations. (Optional)

8 Add @WebResult annotations to customize

the name and behavior of the return value
of the exposed operations. (Optional)

9 Add your business code. Add your business code to the

methods to make the WebService
behave as required.
Specifying that the JWS File Implements a
Web Service (@WebService Annotation)

 Use the standard @WebService annotation to specify, at the class level, that the JWS file
implements a Web Service, as shown in the following code excerpt:
 @WebService(name="SimpleWS",
serviceName="SimpleService",
targetNamespace="http://example.org")
 In the example, the name of the Web Service is SimpleWS, which will later map to
the wsdl:portType element in the WSDL file generated by the jwsc Ant task. The service name
is SimpleService, which will map to the wsdl:service element in the generated WSDL file. The
target namespace used in the generated WSDL is http://example.org.
 You can also specify the following additional attributes of the @WebService annotation:
– endpointInterface—Fully qualified name of an existing service endpoint interface file. This annotation
allows the separation of interface definition from the implementation. If you specify this attribute,
the jwsc Ant task does not generate the interface for you, but assumes you have created it and it is in
your CLASSPATH.
– portname—Name that is used in the wsdl:port.
 None of the attributes of the @WebService annotation is required.
Specifying the Mapping of the Web Service to the SOAP
Message Protocol (@SOAPBinding Annotation)

 It is assumed that you want your Web Service to be available over

the SOAP message protocol; for this reason, your JWS file should
include the standard @SOAPBinding annotation, at the class
level, to specify the SOAP bindings of the Web Service (such as,
document-encoded or document-literal-wrapped), as shown in the
following code excerpt:
 @SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
 Attributes of the @SOAPBinding Annotation
Attribute Possible Values Default Value
Style SOAPBinding.Style.RPC SOAPBinding.Style.DOCUMENT
SOAPBinding.Style.DOCUMENT

Use SOAPBinding.Use.LITERAL SOAPBinding.Use.LITERAL

parameterStyle SOAPBinding.ParameterStyle.BARE SOAPBinding.ParameterStyle.WRAPP
SOAPBinding.ParameterStyle ED
.WRAPPED
Specifying That a JWS Method Be Exposed as a Public Operation
(@WebMethod and @OneWay Annotations)

 Use the standard @WebMethod annotation to specify that a

method of the JWS file should be exposed as a public operation of
the Web Service, as shown in the following code excerpt:
 public class SimpleImpl {
@WebMethod(operationName="sayHelloOperation")
public String sayHello(String message) {
System.out.println("sayHello:" + message);
return "Here is the message: '" + message + "'";
}
 You can specify that an operation not return a value to the calling
application by using the standard @Oneway annotation, as shown in the
following example:
 public class OneWayImpl { @WebMethod()
@Oneway() public void ping() {
System.out.println("ping operation");
}... If you specify that an operation is one-way, the implementing method
is required to return void, cannot use a Holder class as a parameter, and
cannot throw any checked exceptions.
 None of the attributes of the @WebMethod annotation is required.
 If none of the public methods in your JWS file are annotated with
the @WebMethod annotation, then by default all public methods are
exposed as Web Service operations.
Customizing the Mapping Between Operation
Parameters and WSDL Elements (@WebParam
Annotation)

 Use the standard @WebParam annotation to customize the mapping between

operation input parameters of the Web Service and elements of the generated
WSDL file, as well as specify the behavior of the parameter, as shown in the
following code excerpt:
 public class SimpleImpl { @WebMethod()
@WebResult(name="IntegerOutput",
targetNamespace="http://example.org/docLiteralBare")
public int echoInt(
@WebParam(name="IntegerInput",
targetNamespace="http://example.org/docLiteralBare")
int input) {
System.out.println("echoInt '" + input + "' to you too!");
return input;
}
...
Customizing the Mapping Between the
Operation Return Value and a WSDL Element
(@WebResult Annotation)

 Use the standard @WebResult annotation to customize the mapping

between the Web Service operation return value and the corresponding
element of the generated WSDL file, as shown in the following code
excerpt:
 public class Simple { @WebMethod()
@WebResult(name="IntegerOutput",
targetNamespace="http://example.org/docLiteralBare")
public int echoInt(
@WebParam(name="IntegerInput",
targetNamespace="http://example.org/docLiteralBare")
int input) {
System.out.println("echoInt '" + input + "' to you too!");
return input;
}
...
Specifying the Binding to Use for an Endpoint
(@BindingType Annotation)

 Use the JAX-WS @BindingType annotation to customize the binding to use for a web service
endpoint implementation class, as shown in the following code excerpt:
 import javax.xml.ws.BindingType;
import javax.xml.ws.soap.SOAPBinding;
public class Simple { @WebService()
@BindingType(value=SOAPBinding.SOAP12HTTP_BINDING)
public int echoInt(
@WebParam(name="IntegerInput",
targetNamespace="http://example.org/docLiteralBare")
int input) {
System.out.println("echoInt '" + input + "' to you too!");
return input;
}
... In the example, the deployed endpoint would use the SOAP1.2 over HTTP binding. If not specified, the binding defaults to SOAP 1.1 over HTTP.

 You can also specify the following additional attributes of the @BindingType annotation:
– features—An array of features to enable/disable on the specified binding. If not specified, features are
enabled based on their own rules.
Rules for methods on classes
annotated with @WebService

The following rules apply for methods on classes annotated with the @WebService
annotation.
 If the @WebService annotation of an implementation class references an SEI, the
implementation class must not have any @WebMethod annotations.
 All public methods for an SEI are considered exposed methods regardless of
whether the @WebMethod annotation is specified or not. It is incorrect to have an
@WebMethod annotation on an SEI that contains the exclude attribute.
 For an implementation class that does not reference an SEI, if the @WebMethod
annotation is specified with a value of exclude=true, that method is not exposed. If
the @WebMethod annotation is not specified, all public methods are exposed
including the inherited methods with the exception of methods inherited from
java.lang.Object.
The basic steps for creating a web service
and client are as follows:

 Code the implementation class.

 Compile the implementation class(Interface is automatically
generated if endpointInterface element is not added).
 Package the files into a WAR file.
 Deploy the WAR file. The web service artifacts, which are used to
communicate with clients, are generated by the GlassFish Server
during deployment.
 Code the client class.
 Use a wsimport Ant task to generate and compile the web service
artifacts needed to connect to the service.
 Compile the client class.
 Run the client.
Service Endpoint Interface for the TimeServer
package ts; // time server
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
**
* The annotation @WebService signals that this is the
* SEI (Service Endpoint Interface). @WebMethod signals
* that each method is a service operation.
*
* The @SOAPBinding annotation impacts the under-the-hood
* construction of the service contract, the WSDL
* (Web Services Definition Language) document. Style.RPC
* simplifies the contract and makes deployment easier.
*/
@WebService
@SOAPBinding(style = Style.RPC) /
public interface TimeServer {
@WebMethod String getTimeAsString();
@WebMethod long getTimeAsElapsed();
}
Service Implementation Bean for the TimeServer
package ts;
import java.util.Date;
import javax.jws.WebService;

/**
* The @WebService property endpointInterface links the
* SIB (this class) to the SEI (ts.TimeServer).
* Note that the method implementations are not annotated
* as @WebMethods.
*/
@WebService(endpointInterface = "ts.TimeServer")
public class TimeServerImpl implements TimeServer {
public String getTimeAsString() { return new Date().toString(); }
public long getTimeAsElapsed() { return new Date().getTime(); }
}
Publish the Web Service
Once the SEI and SIB have been compiled,

the web service is ready to be published.

In full production mode, a Java Application
Server such as BEA WebLogic,
GlassFish,JBoss, or WebSphere might be
used;
but in development and even light production
mode, a simple Java application can be used.
SOAP Web Services Components
 XML – eXtensible Markup Language – A uniform data
representation and exchange mechanism.
 SOAP – Simple Object Access Protocol – A standard
way for communication.(Service Oriented Architecture
Protocol)
 UDDI – Universal Description, Discovery and
Integration specification – A mechanism to register and
locate WS based application.
 WSDL – Web Services Description Language – A
standard meta language to described the services
offered.
XML

 XML stands for EXtensible Markup Language.

 XML is a markup language much like HTML.
 XML was designed to describe data.
 XML tags are not predefined. You must define
your own tags.
 The prefect choice for enabling cross-platform
data communication in Web Services.
XML vs HTML
<html>example:
An HTML
<body>
<h2>John Doe</h2>
<p>2 Backroads Lane<br>
New York<br>
045935435<br>
[email protected]<br>
</p>
</body>
</html>
XML vs HTML
 This will be displayed as:
John Doe

2 Backroads Lane
New York
045935435
[email protected]
 HTML specifies how the document is to be
displayed, and not what information is contained
in the document.
 Hard for machine to extract the embedded
XML vs HTML
 Now look at the following:
<?xml version=1.0?>
<contact>
<name>John Doe</name>
<address>2 Backroads Lane</address>
<country>New York</country>
<phone>045935435</phone>
<email>[email protected]</email>
</contact>
 In this case:
– The information contained is being marked, but not for
displaying.
– Readable by both human and machines.
SOAP
 SOAP originally stood for "Simple Object Access
Protocol" .
 Web Services expose useful functionality to Web users
through a standard Web protocol called SOAP.
 Soap is an XML vocabulary standard to enable
programs on separate computers to interact across any
network. SOAP is a simple markup language for
describing messages between applications.
 Soap uses mainly HTTP as a transport protocol. That
is, HTTP message contains a SOAP message as its
payload section.
SOAP Characteristics

 SOAP has three major characteristics:

– Extensibility – security and WS-routing are among
the extensions under development.
– Neutrality - SOAP can be used over any transport
protocol such as HTTP, SMTP or even TCP.
– Independent - SOAP allows for any programming
model .
SOAP Building Blocks

A SOAP message is an ordinary XML document

containing the following elements:
– A required Envelope element that identifies the XML document
as a SOAP message.
– An optional Header element that contains header information.
The header element can be used to contain information such
as authentication information or the definition of complex data
types.
– A required Body element that contains call and response
information.
– An optional Fault element that provides information about
errors that occurred while processing the message.
SOAP building blocks
SOAP Envelope Element

 The SOAP Envelope is used to encapsulate all of the necessary

details of the SOAP messages, which are exchanged between the
web service and the client application.
 Every SOAP message needs to have a root Envelope element. It
is absolutely mandatory for SOAP message to have an envelope
element.
 Every Envelope element needs to have at least one soap body
element.
 If an Envelope element contains a header element, it must contain
no more than one, and it must appear as the first child of the
Envelope, before the body element.
 The envelope changes when SOAP versions change.
SOAP Communication Model
 The client would format the information regarding the procedure
call and any arguments into a SOAP message and sends it to the
server as part of an HTTP request. This process of encapsulating
the data into a SOAP message was known as Marshalling.
 The server would then unwrap the message sent by the client, see
what the client requested for and then send the appropriate
response back to the client as a SOAP message. The practice of
unwrapping a request sent by the client is known
as Demarshalling.
SOAP Request
POST /InStock HTTP/1.1
Host: www.stock.org
Content-Type: application/soap+xml; charset=utf-8 Content-Length: 150

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding”>

<soap:Body xmlns:m="http://www.stock.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
SOAP Response
HTTP/1.1 200 OK
Content-Type: application/soap; charset=utf-8
Content-Length: 126

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.stock.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
SOAP Security

 SOAP uses HTTP as a transport protocol and

hence can use HTTP security mainly HTTP
over SSL.
 But, since SOAP can run over a number of
application protocols (such as SMTP) security
had to be considered.
 The WS-Security specification defines a
complete encryption system.
WSDL
 WSDL stands for Web Services Description Language.
 WSDL is an XML vocabulary for describing Web
services. It allows developers to describe Web
Services and their capabilities, in a standard manner.
 WSDL specifies what a request message must contain
and what the response message will look like in
unambiguous notation. In other words, it is a contract
between the XML Web service and the client who
wishes to use this service.
 In addition to describing message contents, WSDL
defines where the service is available and what
communications protocol is used to talk to the service.
The WSDL Document Structure

 Definition
 TargetNamespace
 DataTypes
 Messages
 Porttype
 Bindings
 service
The WSDL Document Structure

 <!-- WSDL definition structure -->

 <definitions
 name=“SampleWebService"
 targetNamespace=http://example.org/math/
 xmlns=http://schemas.xmlsoap.org/wsdl/>
 <!-- abstract definitions -->
 <types> ...
 <message> ...
 <portType> ...

 <!-- concrete definitions -->

 <binding> ...
 <service> ...
 </definition>
WSDL Document
<message name="GetStockPriceRequest">
<part name="stock" type="xs:string"/>
</message>
<message name="GetStockPriceResponse">
<part name="value" type="xs:string"/>
</message>

<portType name=“StocksRates">
<operation name=“GetStockPrice">
<input message=“GetStockPriceRequest"/>
<output message=“GetStockPriceResponse"/>
</operation>
</portType>
WSDL Structure
The main structure of a WSDL document looks like this:

<definitions>
<types>
definition of types........
</types>
<message>
definition of a message....
</message>
<portType>
<operation>
definition of a operation.......
</operation>
</portType>

<binding>
definition of a binding....
</binding>
<service>
definition of a service....
</service>
</definitions>
Sections of WSDL

 The <types> tag is used to define all the complex

datatypes, which will be used in the message
exchanged between the client application and the web
service. This is an important aspect of the client
application, because if the web service works with a
complex data type, then the client application should
know how to process the complex data type. Data
types such as float, numbers, and strings are all simple
data types, but there could be structured data types
which may be provided by the web service.
 The <messages> tag is used to define the message
which is exchanged between the client application and
the web server. These messages will explain the input
and output operations which can be performed by the
web service. An example of a message can be a
message which accepts the EmployeeID of an
employee, and the output message can be the name of
the employee based on the EmpoyeeID provided.
The <portType> tag is used to encapsulate
every input and output message into one logical
operation. So there could be an operation called
"GetEmployee" which combines the input
message of accepting the EmployeeID from a
client application and then sending the
EmployeeName as the output message.
 The <binding> tag is used to bind the
operation to the particular port type. This is so
that when the client application calls the
relevant port type, it will then be able to access
the operations which are bound to this port
type. Port types are just like interfaces. So if a
client application needs to use a web service
they need to use the binding information to
ensure that they can connect to the interface
provided by that web service.
 The <service> tag is a name given to the web service
itself. Initially, when a client application makes a call to
the web service, it will do by calling the name of the
web service. For example, a web service can be
located at an address such
as http://localhost/WS/Tutorial.asmx . The service
tag will actually have the URL defined
as http://localhost/WS/Tutorial.asmx, which will
actually tell the client application that there is a web
service available at this location
JWS supports both rpc and document styles, with
document as the default.

Advantages of RPC style

 The automatically generated WSDL is relatively short and simple
because there is no types section.
 Messages in the WSDL carry the names of the underlying web
service operations, which are @WebMethods in a Java-based
service. The WSDL thus has a what you see is what you get style
with respect to the service’s operations.
 Message throughput may improve because the messages do not
carry any type encoding information.

https://www.ibm.com/developerworks/library/
ws-whichwsdl/
 Disadvantages of RPC style

 The WSDL, with its empty types section, does not provide an XSD against which
the body of a SOAP message can be validated.
 The service cannot use arbitrarily rich data types because there is no XSD to
define
such types. The service is thus restricted to relatively simple types such as
integers,strings, dates, and arrays of such.
 This style, with its obvious link to the request/response pattern, encourages tight
coupling between the service and the client.

 Java services written in this style may not be consumable in other frameworks,
thus undermining interoperability. Further, long-term support within the web

service community and from the WS-I group is doubtful .

Advantages of Document style

 The body of a SOAP message can be validated against the XSD in the
types section of the WSDL.
 A service in this style can use arbitrarily rich data types, as the XML
Schema language supports not only simple types such as integers,
strings, and dates, but also arbitrarily rich complex types.
 There is great flexibility in how the body of a SOAP message is structured
so long
as the structure is clearly defined in an XSD.
 The wrapped convention provides a way to enjoy a key upside of the rpc
style—
naming the body of a SOAP message after the corresponding service
operation—
without enduring the downsides of the rpc style
Disadvantages of Document style

 In the unwrapped variant, the SOAP message does not carry the name of
the service operation, which can complicate the dispatching of messages
to the appropriate program code.
 The wrapped variant adds a level of complexity, in particular at the API
level.
Writing a client against a wrapped-document service can be challenging.
 The wrapped variant does not support overloaded service operations
because the
XML wrapper element in the body of a SOAP message must have the
name of
the service operation. In effect, then, there can be only one operation for
a given
element name.
Code First Versus Contract First

 The issue can be expressed as a question:

should the web service code be used to
generate the WSDL automatically or should the
WSDL, independently designed and created,
be used to guide web service coding?
WSDL Patterns of Operation

 One-way
 The service receives a message. The
operation therefore has a single input element.
The grammar for a one-way operation is:
 <wsdl:definitions .... > <wsdl:portType .... > *
<wsdl:operation name="nmtoken"> <wsdl:input
name="nmtoken"? message="qname"/>
</wsdl:operation> </wsdl:portType >
</wsdl:definitions>
WSDL Patterns of Operation
 Request-response
 The service receives a message and sends a response. The
operation therefore has one input element, followed by one output
element. To encapsulate errors, an optional fault element can also
be specified. The grammar for a request-response operation is:
 <wsdl:definitions .... > <wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/> <wsdl:output
name="nmtoken"? message="qname"/> <wsdl:fault
name="nmtoken" message="qname"/>* </wsdl:operation>
</wsdl:portType > </wsdl:definitions>
WSDL Patterns of Operation
 Solicit-response
 The service sends a message and receives a response. The
operation therefore has one output element, followed by one input
element. To encapsulate errors, an optional fault element can also
be specified. The grammar for a solicit-response operation is:
 <wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation
name="nmtoken" parameterOrder="nmtokens"> <wsdl:output
name="nmtoken"? message="qname"/> <wsdl:input
name="nmtoken"? message="qname"/> <wsdl:fault
name="nmtoken" message="qname"/>* </wsdl:operation>
</wsdl:portType > </wsdl:definitions>
WSDL Patterns of Operation

 Notification
 The service sends a message. The operation therefore
has a single output element. Following is the grammar
for a notification operation:
 <wsdl:definitions .... > <wsdl:portType .... > *
<wsdl:operation name="nmtoken"> <wsdl:output
name="nmtoken"? message="qname"/>
</wsdl:operation> </wsdl:portType >
</wsdl:definitions>
UDDI

 UDDI stands for Universal Description, Discovery

and Integration.
 UDDI is a directory for storing information about web
services , like yellow pages.
 UDDI is a directory of web service interfaces
described by WSDL.
 UDDI Business Registry (UBR)
– "white pages" – contact info, description
– "yellow pages" – classification info, details
– "green pages" – technical data
– uddi.microsoft.com
 WSDL  UDDI
WSDL UDDI
Service Implementation
BusinessEntity
<import>

<service>
BusinessService
<port>

<port>
BindingTemplate

BindingTemplate

Service Interface

<types>
<message>
tModel
<portType>
<binding>
 What is UDDI?
– Directory service where businesses can register and search
for Web services
 Directory for storing information about web services
 Directory of web service interfaces described by WSDL
– UDDI communicates via SOAP
 What is UDDI Based On?
– Uses W3C Internet standards such as XML, HTTP, and DNS
protocols
– UDDI uses WSDL to describe interfaces to web services
How can UDDI be Used?
UDDI Benefits

 Making it possible to discover the right

business from the millions currently online
 Defining how to enable commerce once the
preferred business is discovered
 Reaching new customers and increasing
access to current customers
 Expanding offerings and extending market
reach
Types of UDDI nodes (1/3)

 Internal Enterprise Application UDDI node

– Web Services for use within a company for internal
enterprise application integration
– The scope can be single application, departmental,
corporate
– Sit behind the firewall
– Allow the service providers more control over their
service registry and its accessibility
Types of UDDI nodes (2/3)
 Portal UDDI node
– Web Services published by a company for external partners to
find and use
– Runs outside the service provider’s firewall
– Contains only those service descriptions that a company
wishes to provide to service requestors from external partners
 Partner catalog UDDI node
– Web services to be used by a particular company
– Runs behind the firewall
– Contains only approved, tested and valid Web service
descriptions for legitimate business partners
Types of UDDI nodes (3/3)

 E-Marketplace UDDI node

– Web Services that the service provider intends to
compete for requestors’ business with other Web
Services
– Hosted by an industry standards organization or
consortium
– Contains service descriptions from businesses in a
particular industry