Web Services

Restaurant example

USER WEBSERVICE PROVIDER

WebService Example
 Web Service definition

A simple definition:

“a Web Service is an application component accessible over open protocols”.

 Web Service definition revisited

• A more precise definition:

• an application component that:
• Communicates via open protocols (HTTP, SMTP, etc.)
• Processes XML messages framed using SOAP
• Describes its messages using XML Schema
• Provides an endpoint description using WSDL
• Can be discovered using UDDI
 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
 The Web Service Model

The Web Services model follows the publish, find, and bind
paradigm.

Web Service
Registry

1. publish 2. find

Web Service 3. bind/invoke Web Service

Provider
Client
A purchase order application involving
interacting web services
Service Oriented Architecture(SOA)
 What is Service-Oriented Architecture?

• Service-Oriented Architecture (SOA) is an architectural style.

Applications built using an SOA style deliver functionality as services that
can be used or reused when building applications or integrating within the enterprise
or trading partners.
 SOA

• Uses open standards to integrate software assets as services

• Standardizes interactions of services
• Services become building blocks that form business flows
• Services can be reused by other applications
 What is a Service?

• A service is a reusable component that can be used as a building block

to form larger, more complex business-application functionality.

• A service may be as simple as “get me some person data,” or as complex

as “process a disbursement.”
 What is a Service?

• A service provides a discrete business function that operates on data. Its

job is to ensure that the business functionality is applied consistently,
returns predictable results, and operates within the quality of service
required.
 What is a Service?

• How the service is implemented, and how a user of the service accesses
it, are limited only by the SOA infrastructure choices of the enterprise.

• From a theory point of view, it really doesn’t matter how a service is

implemented.
 Characteristics of a Service

• Supports open standards for integration: Although proprietary

integration mechanisms may be offered by the SOA infrastructure,
SOA’s should be based on open standards. Open standards ensure the
broadest integration compatibility opportunities.
 Characteristics of a Service

• Loose coupling: The consumer of the service is required to provide

only the stated data on the interface definition, and to expect only the
specified results on the interface definition. The service is capable of
handling all processing (including exception processing).
 Characteristics of a Service

• Stateless: The service does not maintain state between invocations. It

takes the parameters provided, performs the defined function, and
returns the expected result. If a transaction is involved, the transaction
is committed and the data is saved to the database.
 Characteristics of a Service

• Location agnostic: Users of the service do not need to worry about

the implementation details for accessing the service. The SOA
infrastructure will provide standardized access mechanisms with service-
level agreements.
 Examples of SOA Frameworks

• Jini
• Java based
• Incorporates discovery, leasing, anonymous routing.
• Takes advantage of code mobility afforded by Java
• Web services
• Open standards based
• Uses XML as the data description format
• Usually runs on open transports such as http.
Distributed Computing Infrastructure
 Distributed Computing
• Distributed computing studies the models, architectures, and
algorithms used for building and managing distributed systems.
• As general definition of the term distributed system, we use the
one proposed by Tanenbaum
• A distributed system is a collection of independent computers that
appears to its users as a single coherent system.
• A distributed system is one in which components located at networked
computers communicate and coordinate their action only by passing
messages.
• As specified in this definition, the components of a distributed
system communicate with some sort of message passing. This
is a term the encompasses several communication models.
Maya Nair 7/29/2021 23
 Components of distributed System

Applications
Frameworks for
distributed programming

Middleware
IPC primitives for
control and data.

Operating System

Networking and
Parallel Hardware
Hardware
Maya Nair 7/29/2021

24
 Examples of Distributed Systems
• Banking systems
• Communication - email
• Distributed information systems
• WWW
• Federated Databases

• Manufacturing and process control

• Inventory systems
• General purpose (university, office automation)

Maya Nair 7/29/2021 25

 System Architectural Styles
• System architectural styles cover the physical organization of
components and processes over a distributed infrastructure.
• Two fundamental reference style
• Client / Server
• The information and the services of interest can be centralized and accessed
through a single access point : the server.
• Multiple clients are interested in such services and the server must be
appropriately designed to efficiently serve requests coming from different clients.
• Peer- to – Peer
• Symmetric architectures in which all the components, called peers, play the same
role and incorporate both client and server capabilities of the client/server
model.
• More precisely, each peer acts as a server when it processes requests from other
peers and as a client when it issues requests to other peers.

Maya Nair 7/29/2021 26

 Client / Server architectural Styles
request
Two Tier
(Classic Model)
client response server

Three Tier

client Server/client server

N Tier
server

Server/clie Server/clien
client
Maya Nair nt t server
7/29/2021 27
 Peer-to-Peer architectural Style

peer
peer

peer
peer

peer
peer
peer
Maya Nair 7/29/2021 28
Communication Technologies for Distributed computing

• Remote Procedure Call (RPC)

• A remote process hosts a server component, thus allowing client
processes to request the invocation of methods, and returns the result
of the execution.
• Distributed Object Frameworks
• This is an implementation of the RPC model for the object-oriented
paradigm and contextualizes this feature for the remote invocation of
methods exposed by objects
• Common Object Request Broker Architecture (CORBA):
• Distributed Component Object Model (DCOM/COM+)
• Remote Method Invocation(RMI)
• .NET Remoting
• Service Oriented Architecture(Webservices)
Maya Nair 7/29/2021 29
 Remote Procedure Call(RPC)
RPC allows extending the concept of a procedure call beyond the boundaries of a
process and a single memory address space. The called procedure and calling procedure
may be on the same system or they may be on different systems in a network

7/29/2021 30

Maya Nair
 Distributed object frameworks
Distributed object frameworks extend object-oriented programming systems by allowing
objects to be distributed across a heterogeneous network and provide facilities so that they
can coherently act as though they were in the same address space
1. The server process maintains a registry of active objects that are made available to other
processes. According to the specific implementation, active objects can be published using
interface definitions or class definitions.
2. The client process, by using a given addressing scheme, obtains a reference to the active
remote object. This reference is represented by a pointer to an instance that is of a shared
type of interface and class definition.
3. The client process invokes the methods on the active object by calling them through the
reference previously obtained. Parameters and return values are marshaled as happens in
the case of RPC.
Ex:
• Common Object Request Broker Architecture (CORBA):
• Distributed Component Object Model (DCOM/COM+)
• Remote Method Invocation(RMI)
• .NET Remoting

Maya Nair 7/29/2021 31

Types of Webservices
• SOAP Web service-
• It’s based on SOAP protocol which stands for Simple Object Access
protocol.
• It’s completely XML based protocol which uses SOAP envelope(header
and body) to communicate between 2 parties.
• It provides additional security with its Web Service security.
• Standardized by W3C (World Wide Web consortium )
• Restful web service(Rest stands for Representational state
transfer.)-
• Restful web service are architectural based services unlike SOAP which
is protocol based.
• In Rest architecture, everything is treated as resource and which is
identified by unique URI.
• It can handle any type of data which could be XML, JSON or anything.
 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.
Example – A simple SOAP Web Service
• A buyer (which might be a simple client) is ordering goods from a seller
service.
• The buyer finds the seller service by searching the UDDI directory.
• The seller service is a Web Service whose interface is defined using Web
Services Description Language (WSDL).
• The buyer is invoking the order method on the seller service using Simple
Object Access Protocol (SOAP) and the WSDL definition for the seller
service.
• The buyer knows what to expect in the SOAP reply message because this is
defined in the WSDL definition for the seller service.
 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.
 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 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.
• 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 Message structure
• Consider an example of a client making the request for price of a stock
maintained by the provider using a function GetStockPrice() defined in
WSDL. Let the stock name be ‘IBM ‘. From clients end a SOAP request
message goes to Provider’s end.
• Provider executes the function and its result is provided back to the
client using a SOAP response message .
 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 Structure (contd.)

• An Envelope element that identifies the XML document as a SOAP

message – This is the containing part of the SOAP message and is
used to encapsulate all the details in the SOAP message. This is the
root element in the SOAP message.
• A Header element that contains header information – The header
element can contain information such as authentication credentials
which can be used by the calling application. It can also contain the
definition of complex types which could be used in the SOAP
message. By default, the SOAP message can contain parameters which
could be of simple types such as strings and numbers, but can also be
a complex object type.
 Soap Structure (contd.)
• Body − Contains the XML data comprising the message being sent. It is a mandatory
element. The SOAP body is a mandatory element that contains the application-defined
XML data being exchanged in the SOAP message. The body must be contained within
the envelope and must follow any headers that might be defined for the message. The
body is defined as a child element of the envelope, and the semantics for the body are
defined in the associated SOAP schema .The body contains mandatory information
intended for the ultimate receiver of the message.
• Fault − An optional Fault element that provides information about errors that occur
while processing the message. If an error occurs during processing, the response to a
SOAP message is a SOAP fault element in the body of the message, and the fault is
returned to the sender of the SOAP message. The SOAP fault mechanism returns
specific information about the error, including a predefined code, a description, and the
address of the SOAP processor that generated the fault . For HTTP binding, a
successful response is linked to the 200 to 299 range of status codes. SOAP Fault is
linked to the 500 to 599 range of status codes.
 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.
 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
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
 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
( Universal Description, Discovery and Integration)

⚫ 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
– Ex. IBM® WebSphere® UDDI Registry, uddi.microsoft.com

⚫ 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 does UDDI work ?
SW companies, standards
1. 4.
bodies, and programmers
populate the registry with
descriptions of different types
of services

Marketplaces, search
2. engines, and business
apps query the registry to
discover services at other
companies

Business Service Type

Businesses Registrations Registrations 5.
populate
the registry
with
descriptions of
3. UBR assigns a programmatically unique
identifier to each service and business
the services registration Business uses this
they support data to facilitate
easier integration
with each other over
the Web
UDDI Business Registry
• Business individually register information
about the Web services to it.

• Provides programmatic description of web

services

• Physically distributed with multiple root nodes

• Data replicated on each server

 Registry Data
➢Businesses register public information about
themselves.
White pages
address, contact and known identifies

Yellow pages
contains industrial categorization

Green pages
Technical information about the services that are exposed
by the businesses

➢ Standards bodies, Programmers, Businesses register

information about their Service Types
 Structure
<business Entity>
name, contacts,
descriptions, categories

<t Model>
<business Service> Name
(1..n) Description
URL pointers

<binding Template>

➢Business Entity is a top level information manager for the business unit
– serves as white and yellow pages
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

⚫ 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
⚫ 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
⚫ 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
 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
 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.
 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="SimplePortType", serviceName="SimpleService",
targetNamespace="http://example.org")
• In the example, the name of the Web Service is SimplePortType, 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 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;
}
...
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.
Endpoint publisher for the TimeServer
package .ts;
import javax.xml.ws.Endpoint;
/**

* This application publishes the web service whose

* SIB is ts.TimeServerImpl
public class TimeServerPublisher {
public static void main(String[ ] args) {
// 1st argument is the publication URL
// 2nd argument is an SIB instance
Endpoint.publish("http://127.0.0.1:9876/ts", new TimeServerImpl());
}
}
 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. WS-Security, or WSS for short, is a collection of
protocols that specify how different levels of security can be
enforced within the SOAP-messaging infrastructure rather than
through a particular transport (for instance, HTTPS) or through a
particular service container (for instance, Tomcat). For
example,WSS specifies how digital signatures and encryption
information can be inserted into SOAP headers.
 WS-Security
• Enhancement to SOAP
• Uses
• XML Encryption xmlenc
• XML Digital Signatures xmlsig
• SSL/TLS SOAP Envelope
Security Feeder

Security Token
SOAP Envelope
SOAP Body
Signature

SOAP Body
Enables the scenario

The firewall is a “SOAP-firewall” not a traditional firewall

 Requester

SOAP

“WSS-module”
Secure
SOAPSOAP
…and this:

“WSS-module”
SOAP

Web Service
WS Security specification
• WS-Policy
This specification describes general security capabilities, constraints, and policies.
For example, a WS-Policy assertion could stipulate that a message requires security
tokens or that a particular encryption algorithm be used.

• WS-Trust
This specification deals primarily with how security tokens are to be issued,
renewed, and validated. In general, the specification covers brokered trust
relationships.

• WS-Privacy
This specification explains how services can state and enforce privacy policies. The
specification also covers how a service can determine whether a requester intends
to follow such policies.
• WS-SecureConversation
This specification covers, as the name indicates, secure web service
conversations across different sites and, therefore, across different security
contexts and trust domains. The specification focuses on how a security
context is created and how security keys are derived and exchanged.
• WS-Federation
This specification addresses the challenge of managing security identities
across different platforms and organizations. At the heart of the challenge
is how to maintain a single, authenticated identity (for example, Alice’s
security identity) in a heterogeneous security environment.
• WS-Authorization
This specification covers the management of authorization data such as
security tokens and underlying policies for granting access to secured
resources.
WS-Security is often associated with federated security in the broad sense,
which has the goal of cleanly separating web service logic from the high-
level security concerns, in particular authentication/authorization, that
challenge web service deployment. This separation of concerns is meant to
ease collaboration across computer systems and trust realms.