Web Services and Java

Elsa Estevez, Tomasz Janowski

and Gabriel Oteniya
UNU-IIST, Macau
e-Macao-16-5-2
The Course
1) objectives - what do we intend to achieve?
2) outline - what content will be taught?
3) resources - what teaching resources will be available?
4) organization - duration, major activities, daily schedule
e-Macao-16-5-3
Course Objectives
1) explain the concept of web services
2) present three XML technologies comprising web services:
a) Simple Object Access Protocol (SOAP)
b) Web Services Description Language (WSDL)
c) Universal Description Discovery and Integration (UDDI)
3) present the best practices in developing web services with Java
4) motivate the use of web services for e-government
e-Macao-16-5-4
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-5
Introduction Outline
An overview of web services (WS).
Main points:
1) WS definition, components, process, properties
2) Service-Oriented Architectures (SOA)
3) WS and SOA
4) WS architecture stack and interoperability
5) WS implementation
e-Macao-16-5-6
SOAP Outline
SOAP = Simple Object Access Protocol
A protocol for exchanging XML messages in a distributed environment.
Main points:
1) introduction to SOAP
2) messaging framework: envelope and its components, processing rules
3) data structures and rules for encoding data and service requests
4) protocol binding framework
5) using SOAP to send binary data
e-Macao-16-5-7
WSDL Outline
WSDL = Web Services Description Language.
A language for describing web services with XML.
Main points:
1) introduction to WSDL
2) WSDL language structure
3) transmission primitives
4) WSDL extension mechanisms
5) WSDL and Java
e-Macao-16-5-8
AXIS Outline
Presentation of a particular SOAP engine - Apache AXIS.
Open source project.
Main points:
1) AXIS concepts and architecture
2) web service invocation
3) AXIS tools and configuration
4) web service deployment
5) service lifecycle
e-Macao-16-5-9
UDDI Outline
UDDI = Universal Description, Discovery and Integration
An open, platform-independent framework for describing, discovering and
integrating business services.
Main points:
1) introduction
2) concepts
3) data types
4) registries
e-Macao-16-5-10
Security Outline
WS-Security describes enhancements to SOAP messaging in order to
provide message integrity and confidentiality.
Main points:
1) basic security concepts
2) web service security
3) digital signatures
e-Macao-16-5-11
Course Resources - Books
1) Building Web Services with Java, Making sense of XML, SOAP, WSDL,
and UDDI (2
nd
ed.) Steve Graham, et. al. Sams Publishing, 2004
2) Java Web Services Unleashed Robert J. Brunner et al Sams, 2002
3) Web Services Concepts, Architectures and Applications Gustavo
Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju Springer, 2004
4) WebSphere Application Developer Web Services Handbook
http://publib-b.boulder.ibm.com/abstracts/sg246891.html
e-Macao-16-5-12
Course Resources - Organizations
1) W3C World Wide Web Consortium, http://www.w3.org
2) OASIS Organization for the Advancement of Structured Information
Standards, http://www.oasis-open.org
3) Apache Apache Software Foundation, http://www.apache.org
e-Macao-16-5-13
Course Resources - Specifications
1) SOAP - http://www.w3.org/TR/soap/
2) AXIS - http://ws.apache.org/axis/
3) WSDL - http://www.w3.org/TR/wsdl
4) UDDI - http://www.uddi.org/
5) WS-Security - http://www.oasis-open.org/
e-Macao-16-5-14
Course Logistics
1) duration - 42 hours
2) activities - lectures and development
3) timing
4) sessions - 7 morning, 5 afternoon
5) style - interactive and tutorial
9:00-13:00 Friday e)
14:30-17-45 9:00-13:00 Thursday d)
9:00-13:00 Wednesday c)
14:30-17-45 9:00-13:00 Tuesday b)
14:30-17-45 9:00-13:00 Monday a)
e-Macao-16-5-15
Course Prerequisite
1) basic Java
2) distributed Java
3) XML, XML namespaces, XML Schema
e-Macao-16-5-16
Introduction
e-Macao-16-5-17
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-18
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-19
Service Definition
Definition by W3C:
A service is an abstract resource that represents a capability of
performing tasks that form a coherent functionality from the point of
view of providers entities and requestors entities.
To be used, a service must be realized by a concrete provider agent.
[Web Services Glossary
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/]
e-Macao-16-5-20
Service Concepts
A service:
1) is a resource and has an owner
2) is provided by a person or an organization
3) must be realized by a (software) provider agent
4) performs one or more tasks
5) is used by a requestor agent
Example: a service for updating software
e-Macao-16-5-21
Web Service (WS)
A web service is a software application that applies XML to exchange data
with other applications on other computers.
Features of web services:
1) Web services operate over any network (the Internet or a private Intranet)
to achieve specific tasks.
2) The tasks performed by a web service are methods or functions that
other applications can invoke and use.
3) Web service requests/responses can be sent/received between different
applications on different computers belonging to different businesses.
e-Macao-16-5-22
Web Service Definition
Definition by W3C:
A Web Service is a software system designed to support interoperable
machine-to-machine interaction over a network:
1) It has an interface described in a machine-processable format
(specifically WSDL).
2) Other systems interact with the web service in a manner prescribed by
its description using SOAP messages, typically conveyed using HTTP
with an XML serialization in conjunction with other Web standards.
[Web Services Glossary
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/]
e-Macao-16-5-23
Web Service Example
A Google web service for Internet search - http://www.google.com/apis:
e-Macao-16-5-24
Task 1: Google Search
Copy from the server in \WebServices the folder demos to your local
PC, in drive E: under a folder with your own name.
Objective: automatic search in Google using a WS
1) cd demos\Ws\FirstExample
2) dir
googleapi.jar
GoogleApiDemo.class
GoogleSearch.wsdl
1) copy googleapi.jar \j2sdk1.4.2_04\jre\lib\ext
2) java cp \demos\WS\FirstExample GoogleApiDemo Macao
e-Macao-16-5-25
Service Description
A service description is data describing the capabilities of a web service:
1) all information needed in order to invoke the web service
2) the key concept for Service-Oriented Architectures (SOA)
The standard for writing service descriptions is WSDL.
e-Macao-16-5-26
Task 2 : Google Description
1) cd demos\Ws\FirstExample
2) double-click GoogleSearch.wsdl
3) the following window appears:
4) open the file with a browser - WSDL document describing the service
applying a web
service
e-Macao-16-5-27
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-28
SOA = Service-Oriented Architecture
SOA is a software architecture where all software-implemented tasks and
processes are designed as services to be consumed over a network.
Keywords:
1) architecture
2) service
SOA Definition
e-Macao-16-5-29
SOA approach:
The focus of design is the service interface.
A service:
1) has a well-defined interface
2) can be potentially invoked over a network
3) can be reused in multiple business contexts
An application:
1) is integrated at the interface and not implementation level
2) is built to work with any implementation of a contract, resulting in a
loosely coupled and more flexible system
SOA Approach
e-Macao-16-5-30
SOA Components
Service
Registry
Service
Requestor
Service
Provider
find publish
bind
1) roles
a) service provider
b) service requestor
c) service registry
2) operations
a) publish
b) bind
c) find
e-Macao-16-5-31
SOA Roles: Service Provider
What a service provider does?
1) creates a service description
2) deploys the service in a runtime environment to make it accessible
to other entities over the network
3) publishes the service description to one or more services registries
4) receives messages invoking the service from service requestors
Any entity that hosts a network-available web service is a service provider.
e-Macao-16-5-32
SOA Roles: Service Requestor
What a service requestor does?
1) finds a service description published in a service registry
2) applies the service description to bind and invoke the web service
hosted by a service provider
A service requestor can be any consumer of a web service.
e-Macao-16-5-33
SOA Roles: Service Registry
What a service registry does?
1) accepts request from service providers to publish and advertise web
service descriptions
2) allows service requestors to search the collection of service
descriptions contained within the service registry
The role of service registry is to enable match-making between service
providers and service requestors.
Once the match has been found, the interactions are carried out directly
between the service requestor and the service provider.
e-Macao-16-5-34
SOA Operations: Publish
The publish operation is an act of service
registration or service advertisement.
When a service provider publishes its web
service in a service registry, it is advertising
the service to the whole community of
potential service requestors.
The details of the publish operation depends
on how the service registry is implemented.
Service
Registry
Service
Provider
publish
e-Macao-16-5-35
SOA Operations: Find
The find operation is an act of looking for a
service satisfying certain conditions:
1) service requestor states a search
criteria, such as: the type of the
service, its quality, etc.
2) service registry matches the search
criteria against the published web
service descriptions
The result is a list of service descriptions
that match the search criteria.
Details of the operation depend on the
implementation of the service registry.
Service
Registry
Service
Requestor
find
e-Macao-16-5-36
SOA Operations: Bind
The bind operation creates the client-
server relationship between service
requestor and service provider.
The operation can be:
1) dynamic - creating a client-
side proxy on-the-fly based on
the service description to
invoke the web service
2) static - the developer hard-
codes the way the client
invokes the web service
Service
Requestor
Service
Provider
bind
e-Macao-16-5-37
SOA Properties 1
SOA is a form of distributed systems architecture.
It is characterized by:
1) logical view - a service is an abstraction is what actual programs,
databases, businesses processes etc. are able to do.
2) message exchange a service is defined in terms of the messages
exchanged between provider and requestor agents and not in terms of
the properties of the agents themselves
e-Macao-16-5-38
SOA Properties 2
3) abstraction SOA hides the implementation details of the underlying
languages, process and database structures, etc.
4) meta-data a service is described by machine-processable meta-data
5) small number of operations a service tends to rely on a small number
of operations with relatively large and complex messages
6) network orientation - services are oriented to their use over a network
7) platform-neutral - messages are sent in a standardized format delivered
through the interfaces. XML is typically used.
e-Macao-16-5-39
SOA Benefits 1
SOA enables the agents participating in the message exchange to be
loosely coupled, which in turn allows for more flexibility:
1) a client is only coupled to a service, not to a server - the integration of
the server takes place outside the scope of the client application
2) functional components and their interfaces are separated - new
interfaces can be easily added
3) old and new functionality can be encapsulated as software components
that provide and receive services
e-Macao-16-5-40
SOA Benefits 2
4) the control of business processes can be isolated:
a) business-rule engine can control the workflow of a business process
b) depending on the state, the engine invokes different services
5) services can be incorporated dynamically during runtime
6) service bindings are specified using configuration files and can be easily
adapted to satisfy new needs
e-Macao-16-5-41
Service Description in SOA
The key to SOA is service description:
1) it is published by the service provider in the service registry
2) it is returned to the service requestor as a result of the search operation
3) it specifies to the service requestor:
a) how to bind and invoke the web service
b) what information is returned as a result of the invocation
e-Macao-16-5-42
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-43
WS Components
A web service includes three basic components:
1) a mechanism to find and register interest in a service
2) a definition of the services input and output parameters
3) a transport mechanism to access a service
Web services also include other technologies that can be used to provide
additional features such as security, transaction processing and others.
e-Macao-16-5-44
WS Process
1) a service provider
publishes a service to an
external repository
2) a client looks up for a
service in the repository
3) the repository returns
information about the
service:
- call format
- provider address
4) the client binds to the
underlying service
5) the client calls and
accesses the service
[courtesy Al Saganich]
e-Macao-16-5-45
WS and Others
Web services do not introduce new functionality.
Similar functionality is provided by:
1) Sun/RPC
2) DCOM
3) Enterprise Java Beans
4) etc.
The difference is how this functionality is provided.
e-Macao-16-5-46
CORBA Application
Recall the application developed in the Distributed Programming course.
A client requests a file from the server. The server sends the file to the
client. When received, the client saves the file on the local machine.
The steps involved:
1) define a service interface in IDL
2) map the IDL interface to Java (done automatically)
3) implement the interface (FileInterface.idl)
4) develop the server (FileServer.java)
5) develop a client (FileClient.java)
6) run the naming service, the server, and the client
e-Macao-16-5-47
CORBA Example 1
Running the application:
1) the server is running on the auxiliary PC:
- run the CORBA naming service:
tnameserv -ORBInitialPort 2500
- start the server:
java FileServer ORBInitialPort 2500
2) the client is running on the current PC:
run
run_CORBA_Client.bat
asking to download a
file
sending the file
e-Macao-16-5-48
CORBA Example 2
What happens if we enable a firewall on the server side?
Lets try again to run the client application:
firewall
e-Macao-16-5-49
Web Service Application
Consider the same application, but built as a web service.
A client requests a file from the server. The server sends the file to the client.
When received, the client saves the file on the local machine.
The steps involved:
1) setup the SOAP server
2) develop the server
3) develop the client
4) start the web server
5) deploy the server as a web service
6) run the client application
e-Macao-16-5-50
Web Service Example 1
Running the application:
1) the server is running on the auxiliary PC - start the web server
2) the client is running on the current PC
run_client.bat
asking to download a file
sending the file
SOAP messages
e-Macao-16-5-51
What happens if we enable a firewall on the server side?
Lets try again to run the client application:
Web Service Example 2
requesting to download a file
sending the file
SOAP messages
firewall
e-Macao-16-5-52
Comparison: Communication
What is the observable difference between CORBA and WS applications?
With the firewall enabled, the CORBA application was unable to run.
One advantage of SOAP is its explicit definition of HTTP binding through the
process of hiding another protocol inside HTTP messages.
This allows SOAP messages to pass through a firewall unimpeded.
Firewalls will usually allow HTTP protocol through port 80, while they will
restrict the use of other protocols or ports.
e-Macao-16-5-53
Comparison: Functionality
The same functionality in CORBA and WS.
The difference is how WS provides this functionality:
1) data is formatted for transfer using XML
2) data is passed using standard communication protocols
3) the exposed service is well defined in an XML vocabulary
4) services are found in standard ways with XML vocabularies
WS provides more a flexible design than CORBA.
e-Macao-16-5-54
Comparison: Standards
The main difference with past Distributed Computing Environments
is adopted standards and implementations:
1) a standard lookup service UDDI
2) a standard definition mechanism WSDL
3) a standard way for two parties to communicate SOAP
The foundation technology for all three (and more) is XML.
e-Macao-16-5-55
Web Service: Request Message
A request message looks as follows:
<soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<soapenv:Body>
<ns1:downloadFile
soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
xmlns:ns1=http://soapinterop.org/>
<ns1:arg0
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/
xsi:type=soapenc:string> name_of_file
</ns1:arg0>
</ns1:downloadFile>
</soapenv:Body>
</soapenv:Envelope>
e-Macao-16-5-56
Web Service Implementation
The standards used by web services are defined with little concern for the
underlying implementation mechanism.
Therefore: a web service written in C and running on Microsoft IIS can
access a web service written in Java, running on BEA WebLogic Server.
MS-IIS
WS
written in
C
WS
written in
Java
BEA-Weblogic
Server
e-Macao-16-5-57
Web Service Environments
Several environments exist to build, deploy and access web services.
Best known:
1) Microsofts .Net Platform
2) Suns Java 2 Platform
We rely on Java Web Services.
e-Macao-16-5-58
Traditional Communication
Traditional system communication:
1) systems must be tightly bound
2) data must be transferred in such a way that two systems agree
beforehand on the format
3) various network normal forms were created to decide how bytes,
integers, etc. were to be encoded for transfer
e-Macao-16-5-59
XML-Based Communication
Before - no common data-definition mechanism.
With XML:
1) common, well-defined data and representation
2) well-defined set of validity and well-formedness rules
Web service communication relies on XML syntax to write messages.
e-Macao-16-5-60
WS - Business Perspective
Web services and business processes/goals:
1) a web service is an implementation of a business process or a step within
such a process
2) a web service is made available over a network to internal and/or
external business partners to achieve specific business goals
Web services promote integration of applications within an organization and
between different business partners.
Key feature: to allow for rapid construction of business applications by
combining web services built internally with those of business partners.
e-Macao-16-5-61
Web Service Usage
Two main scenarios of web service usage:
1) application integration
2) B2B partner integration over the Internet
e-Macao-16-5-62
WS Usage: Application Integration
Legacy systems can be wrapped as web services and made available for
integration with other systems.
Applications exposed as web services are accessible by other applications
running on different hardware platforms and written in different
languages.
e-Macao-16-5-63
WS Usage: B2B Integration
Business-to-business (B2B) partner integration over the Internet.
B2B integrates business systems of two or more companies to support
cross-enterprise business processes, e.g. supply chain management.
Company A
Company B
e-Macao-16-5-64
WS Properties 1
1) self-contained - no additional software is required for WS:
a) client-side: a programming language with XML/HTML client support
b) server-side: a web server and a SOAP server are needed
2) loosely coupled - client and server only knows about messages - a
simple coordination level that allows for more flexible re-configuration
3) web-enabled WS are published, located and invoked across the web,
using established lightweight Internet standards
4) language-independent and interoperable - client and server may be
implemented in different environments and different languages
e-Macao-16-5-65
WS Properties 2
5) composable - WS can be aggregated using workflow techniques to
perform higher-level business functions
6) dynamically bound - with UDDI and WSDL, the discovery and binding of
web services can be automated
7) programmatic access - the web services approach does not provide a
graphical user interface but operates at the command level
8) wrap existing applications - stand-alone applications can easily be
integrated by implementing a web service as an interface
e-Macao-16-5-66
Web Service Benefits
1) platform integration - the platform-neutrality of WS allows combining
business systems using different devices (PDAs, cell phones, desktops)
with service providers of all sizes and shapes
2) software integration - systems supporting new or modified business
processes can be rapidly delivered by wrapping the existing functionality
3) standard technology - open standards enable developers to choose
among different products, avoiding vendor-dependence
4) small businesses integration - the low cost of WS allows small
businesses to deploy and participate in WS applications
5) easy integration - interface-based development using web service
descriptions reduces the time to integrate applications
e-Macao-16-5-67
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-68
SOA and WS
Service-Oriented Architecture:
1) provides an approach for building systems focused on a loosely coupled
set of components (services) that can be dynamically composed
2) promotes seamless software integration as a business benefit
Web Services:
1) one approach to building SOA
2) provide a standard for a particular set of XML-based technologies that
can be used to build SOA systems
e-Macao-16-5-69
WS-Based Approach to SOA
[courtesy IBM]
e-Macao-16-5-70
Using SOA and WS
SOA and WS are most appropriate for the applications that:
1) can operate over the Internet, accepting that reliability and performance
of communication cannot be guaranteed in this case
2) do not require that all service requestors and providers are upgraded at
the same time
3) consist of the components running remotely on different execution
platforms and vendor products
4) were designed using legacy technology but need to be exposed for use
over a network, using a web service wrapping
e-Macao-16-5-71
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-72
Web Services Architecture Stack
[courtesy W3C]
e-Macao-16-5-73
Communications Layer
Web Services are essentially transport-neutral.
A web service message can be transported using HTTP or HTTPS, as
well as more specialized transport mechanisms, such as e.g. JMS.
Web services insulate the designer from most of the details and
implications of the message transport layer.
e-Macao-16-5-74
Messaging Layer
SOAP = Simple Object Access Protocol
A protocol to exchange structured information in a distributed environment.
SOAP extensions:
1) WS-ReliableMessaging - a standard for web services messaging to
guarantee the receipt of messages for WS requestors and providers
2) WS-Transactions - a series of standards related to WS invocations in
transactions (atomicity, consistency, isolation and durability semantics)
e-Macao-16-5-75
Descriptions Layer
WSDL = Web Services Description Language
A language that allows a service provider to specify the functional
characteristic of its web services.
WSDL extensions:
1) WS-Policy - augment WSDL with non-functional constraints on WS
2) WS-ResourceProperties describes how to define and access
properties of resources through WS
e-Macao-16-5-76
Processes Layer: Discovery
Discovery - locating a machine-processable description of a web service that
may have been previously unknown and that meets certain criteria.
UDDI = Universal Description, Discovery and Integration
UDDI defines a way to store and retrieve information about web services.
e-Macao-16-5-77
Processes Layer: Choreography
Choreography - defines how multiple cooperating independent agents
exchange messages in order to perform a task to achieve a given goal.
WS-CDL = WS Choreography Description Language
WS-CDL describes peer-to-peer collaborations where ordered message
exchanges result in accomplishing a common business goal.
e-Macao-16-5-78
WS Interoperability
Web Services tackle the set of problems related to loosely coupled,
dynamically configured heterogeneous distributed computing.
WS Specifications:
1) A series of smaller, purpose-focused specifications dealing with narrow
problems (security, transactions, etc.) in isolation.
2) Each WS specification is designed to be composed with the others.
3) WS designers determines which specifications their system needs and
implement them accordingly.
e-Macao-16-5-79
WS-I Organization
Web Services Interoperability organization (WS-I):
1) WS-I is to standardize combinations of WS specifications that can be
used to increase the level of interoperability between web services.
2) WS-I promotes the Basic Profile - implementation guidelines for how
non-proprietary WS specifications, such as SOAP, WSDL, UDDI, should
be used together for best interoperability.
WS-I website - http://www.ws-i.org/
e-Macao-16-5-80
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-81
Apache Axis
Apache and Axis:
1) Apache is an open-source HTTP server - http://ws.apache.org/
2) Axis is an Open Source SOAP engine - http://ws.apache.org/axis/
Axis converts Java objects to SOAP data for sending/receiving messages.
e-Macao-16-5-82
Apache Axis - Modules
Axis implements the standard Java API for Web Services - JAX-RPC.
Axis:
1) is compiled in the JAR file axis.jar
2) implements the JAX-RPC API declared in:
a) jaxrpc.jar
b) saaj.jar
All these files can be packaged into a web application called axis.war
that can be deployed in a servlet container.
Servlet - Java class that can respond to HTTP requests.
e-Macao-16-5-83
Apache Axis - Requirements
What is needed?
1) Java 1.4
2) Tomcat 4.x
New versions of Java and Tomcat are not supported yet.
e-Macao-16-5-84
Tomcat
What is Tomcat?
1) Servlet container used in the official Reference Implementation of the
Java Servlet and JavaServer Pages technologies.
2) A free, open-source implementation.
3) Was developed under the Jakarta project at the Apache Software
Foundation.
4) Tomcat reference - http://jakarta.apache.org/tomcat
e-Macao-16-5-85
Installing Apache Axis
Steps for installing Apache Axis:
1) update the JAVA_HOME variable
2) install Tomcat
3) install Apache Axis
4) deploy Axis
5) validate the installation
e-Macao-16-5-86
Task 3: Update JAVA_HOME
1) pointing at My Computer press the
right bottom and select Properties
2) select Advanced and
Environment Variables
3) select System Variables and modify
JAVA_HOME to contain the path to
the j2sdk1.4 installation directory
e-Macao-16-5-87
Task 4: Installing Tomcat
1) visit http://jakarta.apache.org/tomcat
2) select Download - Binaries
3) select Download - Tomcat
4) select Tomcat 4
5) select Binary - 4.1.31.exe
6) save the file:
jakarta-tomcat-4.1.31.exe
on your own directory
e-Macao-16-5-88
Task 5: Installing Tomcat
7) execute: jakarta-tomcat-4.1.31.exe
8) Answer the following:
a) Using Java Development Kit found in j2sdk1.4.2_04 OK
b) To the window about Apache License I Agree
c) Setup Installation Options:
1)Tomcat
2)JSP Development Shell Extensions
3)Tomcat Start Menu Group
4)Documentation and Examples Next
d) Destination Folder: D:\Tomcat 4.1 or E:\Tomcat 4.1
Install Next
e) HTTP/1.1 Connector Port: 8080
User name: admin Finish
e-Macao-16-5-89
Task 6: Verifying Installation
e-Macao-16-5-90
Task 7: Installing Axis 1
1) visit http://ws.apache.org/axis/
2) select Axis 1.2 RC2 release
e-Macao-16-5-91
Task 8: Installing Axis 2
3) select the Apache download mirrors
4) download the file: axis-1_2RC2-bin.zip to your own directory
e-Macao-16-5-92
Task 9: Installing Axis 3
5) uncompress: axis-1_2RC2-bin
e-Macao-16-5-93
Task 10: Verify Installation
e-Macao-16-5-94
Task 11: Deploy Axis
In order to deploy Apache Axis in Tomcat:
1) in E:\axis-1_2RC2\webapps, copy the folder: axis
2) in E:\jakarta-tomcat-4.1.31\webapps, paste the folder: axis
e-Macao-16-5-95
Task 12: Validate Installation 1
Start Tomcat - double-click E:\jakarta-tomcat-4.1.31\bin\startup.bat
e-Macao-16-5-96
Task 13: Validate Installation 2
Starting Tomcat will cause the following window to appear:
(colors are inverted)
e-Macao-16-5-97
Task 14: Validate Installation 3
Navigate to the start page of the webapp http://localhost:8080/axis
e-Macao-16-5-98
Task 15: Validate Installation 4
Validate Axis installation - follow the link Validate
e-Macao-16-5-99
Task 16: Validate Installation 5
If the installation was successful then the following page is displayed:
e-Macao-16-5-100
Task 17: Executing WS 1
Navigate to the start page of http://localhost:8080/axis and click on View to
list the deployed web services:
e-Macao-16-5-101
Task 18: Executing WS 2
This page is displayed:
Click on AdminService (wsdl).
e-Macao-16-5-102
Task 19: Executing WS 3
Here is a web service description in WSDL:
e-Macao-16-5-103
Task 20: Testing WS 1
We are going to invoke the getVersion service which returns a message
with the version number of the Axis installation.
Open the browser at
http://localhost:8080/axis/services/Version?method=getVersion
e-Macao-16-5-104
Task 21: Testing WS 2
In response, the following message is obtained:
A SOAP envelope!
e-Macao-16-5-105
Deploying a Web Service
Axis uses a deployment descriptor to deploy a web service.
A deployment descriptor is an Axis-specific XML file that tells Axis how to
deploy (or undeploy) a web service, and how to configure Axis itself.
Deploying a web service:
1) copy the class that is being deployed as a web service to
\Tomcat 4.1\webapps\axis\WEB-INF\classes
2) write the deployment descriptor
3) run AdminClient
e-Macao-16-5-106
WS Deployment: Descriptor 1
To deploy a web service, the root of the XML deployment descriptor
document must be the tag <deployment>.
The mandatory child of the <deployment> element is:
<service name=name provider=provider>

</service>
It is used to deploy/undeploy an Axis Service, where:
1) name - name of the web service
2) provider - specifies the particular provider of the web service such
as: Java-RPC, Java-EJB, etc.
e-Macao-16-5-107
WS Deployment: Descriptor 2
The different options of the service may be specified as follows :
<parameter name="name" value="value"/>
and common ones include:
1) className - the backend implementation class
2) allowedMethods - each provider can determine which methods are
allowed to be exposed as web services
e-Macao-16-5-108
WS Deployment: Descriptor 3
<deployment
xmlns="http://xml.apache.org/axis/wsdd/
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="FileDownloadService" provider="java:RPC">
<parameter name="className value="FileDownload"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>
e-Macao-16-5-109
WS Deployment: AdminClient
With Tomcat running, execute AdminClient:
java org.apache.axis.client.AdminClient deploy.wsdd
where:
1) deploy.wsdd is the name of the deployment descriptor.
2) AdminClient is a tool that comes with Axis that allows to
deploy/undeploy web services and to configure the Axis engine.
e-Macao-16-5-110
WS Deployment Example
We developed a web service that allows to download a file:
1) Java class is FileDownload.
2) The class has one method downloadFile that transmits a file.
3) The name of the web service is FileDownloadService.
FileDownload.java
public downloadFile(args)
FileDownloadService (wsdl)
o downloadFile published as
e-Macao-16-5-111
Task 22: WS Deployment 1
1) change and check directory
> cd demos\WS\deployWebService
> dir
deploymentDescriptor.wsdd
deployService.bat
FileDownload.class
2) Copy the Java class
demos\WS\deployWebService\FileDownload.class
to \Tomcat 4.1\webapps\axis\WEB-INF\classes
e-Macao-16-5-112
Task 23: WS Deployment 2
3) Edit the file deploymentDescriptor.wsdd:
changing name_of_the_service to FileDownloadService
changing name_of_the_class to FileDownload
and save it as FileDownloadDescriptor.wsdd
4) Edit the file deployService.bat
changing deploymentdescriptor.wsdd into
FileDownloadDescriptor.wsdd
and save it as deployFileDownload.bat
5) Execute deployFileDownload.bat.
e-Macao-16-5-113
Task 24: WS Testing
1) view the list of the deployed web services at http://localhost:8080/axis
2) select View
3) click on the wsdl corresponding to FileDownloadService
4) this is the service description prepared by Axis for your service
5) in the address of the browser, remove ?wsdl at the end of the line
6) this is the execution of your web service
e-Macao-16-5-114
Introduction Outline
1) Definitions
2) Service-Oriented Architecture
3) Web Services (WS)
4) Relating SOA and WS
5) WS Architecture Stack
6) Implementation Details
7) Summary
e-Macao-16-5-115
Introduction Summary 1
SOA is a Service-Oriented Architecture where software business processes
are defined as services to be consumed over a network.
SOA defines three roles for agents: service provider, service requestor and
service registry, and three operations: publish, find and bind.
Web Services (WS) is one approach to implementing SOA.
WS-based SOA produce a loosely coupled and flexible applications.
e-Macao-16-5-116
Introduction Summary 2
Web Services are software applications that use XML to exchange data with
other applications.
Web Services provide a seamless integration framework of software,
execution platforms and businesses.
Web Services use open standards technologies such as HTTP and SOAP
for communication, WSDL for definition and UDDI for identification.
e-Macao-16-5-117
Introduction Summary 3
WS are build on three technologies:
1) SOAP - a protocol for exchanging structured information in a distributed
system based on XML
2) WSDL - a language for describing web services
3) UDDI - a specification that defines a way to store and retrieve
information about web services
Other purpose-focused specifications are available, such as WS-Security,
WS-Reliable Messaging and others.
A system designer has to determine which specifications are needed for
the system and implement or deploy them accordingly.
e-Macao-16-5-118
Introduction Summary 4
Axis is a SOAP engine, a free and open-source product from Apache.
Axis runs as an application of the Tomcat web server.
Axis provides a deployment descriptor that allows to deploy web services.
e-Macao-16-5-119
SOAP
e-Macao-16-5-120
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-121
SOAP Outline
1) Introduction
2) Messaging
a) envelope
b) headers
c) processing model
d) error handling
3) Data Structures
a) data model
b) data encoding
c) request encoding
4) Protocol Binding
a) binding
b) features and modules
c) communication patterns
5) SOAP and Binary Data
6) Summary
e-Macao-16-5-122
SOAP History 1
SOAP 1.0 appeares, entirely based on HTTP. 1999
Userland publishes a version of the SOAP specification as XML-RPC. 1998
DevelopMentor (a Microsoft ally) and Userland (a private company) joined
the discussion inventing the SOAP name.
Within Microsoft, the process was stalled: some people promoted the
DCOM wire protocol via HTTP tunneling, instead of pursuing XML.
1998
Microsoft considers supporting XML-based distributed computing
consisting of applications communicating via RPC using standard data
types on top of XML/HTTP.
1997
e-Macao-16-5-123
SOAP History 2
SOAP 1.2 becomes a W3C recommendation. 2003
First draft of SOAP 1.2 is presented. 2001
SOAP 1.1 is submitted as a note to W3C with IBM as a coauthor a more
generic version including other protocols:
1) IBM immediately releases a Java SOAP implementation that was
donated to the Apache XML Project for open source development.
2) Sun voices support to SOAP and started working on integrating Web
Services into J2EE platform.
3) Many vendors also begin working on WS implementations.
2000
e-Macao-16-5-124
SOAP Definition
W3C (World Wide Web Consortium) definition:
SOAP is a lightweight protocol intend for exchanging structured
information in a decentralized, distributed environment.
SOAP uses XML technologies to define an extensible messaging
framework, which provides a message construct that can be exchanged
over a variety of underlying protocols.
The framework has been designed to be independent of any particular
programming model and other implementation specific semantics.
[SOAP Version 1.2 Part1:Messaging Framework
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/]
e-Macao-16-5-125
SOAP Features
SOAP defines a way to move XML messages from point A to point B:
It does this by providing an XML-based messaging framework that is:
1) extensible
2) usable over a variety of underlying networking protocols
3) independent of programming models
[courtesy Aaron Skonnard]
e-Macao-16-5-126
Features: Extensible
1) SOAP is simple by design
2) SOAP lacks various distributed system features:
security
routing
transactions
etc.
3) SOAP defines a communication framework that allows additional
features to be added as layered extensions.
e-Macao-16-5-127
Features: Protocol-Independent
4) SOAP can be used over any protocol:
TCP
HTTP
SMTP
etc.
5) SOAP provides a flexible framework for defining bindings to arbitrary
protocols to maintain interoperability.
6) SOAP provides an explicit binding for HTTP.
e-Macao-16-5-128
Features: Model-Independent
SOAP is independent of any distributed programming model:
7) allows for any programming model not tied to RPC
8) defines a model for processing individual, one-way messages, or
combine multiple messages into an overall message exchange
9) allows for any number of message exchange patterns:
request/response, solicit/response, notifications, peer-to-peer
[courtesy Aaron Skonnard]
e-Macao-16-5-129
SOAP and ebXML
SOAP:
1) messaging framework
2) encoding rules
3) binding to HTTP protocol
ebXML:
1) messaging framework
2) SOAP bindings
3) own encoding rules
e-Commerce solutions with XML.
SMTP
SMTP
Binding
ebXML
Transport,
Routing,
and
Packaging
HTTP
HTTP
Binding
Message Framework
(Envelope)
Encoding
rules
SOAP
RPC
e-Macao-16-5-130
SOAP Toolbox
SOAP is like a toolbox.
SOAP requests could be made:
with the SOAP envelope, HTTP
binding and some encoding or
with the SOAP envelope, SOAP
encoding and SMTP or
any other combinations
SMTP
SMTP
Binding
ebXML
Transport,
Routing,
and
Packaging
HTTP
HTTP
Binding
Message Framework
(Envelope)
Encoding
rules
SOAP
RPC
e-Macao-16-5-131
SOAP Implementation Model
client
implementation
client
stub
SOAP
engine
HTTP
engine
invokes SOAP engine to
prepare a SOAP message
packages SOAP into HTTP
and passes to an HTTP client
invokes the service locally
service
requestor
service
implementation
server
stub
SOAP
router
HTTP
server
router parses the message and
delivers to the identifies stub
server passes the content of the
message to the router
server invokes the service
implementation locally
service
provider
e-Macao-16-5-132
SOAP Outline
1) Introduction
2) Messaging
a) envelope
b) headers
c) processing model
d) error handling
3) Data Structures
a) data model
b) data encoding
c) request encoding
4) Protocol Binding
a) binding
b) features and modules
c) communication patterns
5) SOAP and Binary Data
6) Summary
e-Macao-16-5-133
SOAP Message
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getVersionResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<getVersionReturn xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
Apache Axis version: 1.2RC2 Built on Nov 16, 2004
</getVersionReturn>
</getVersionResponse>
</soapenv:Body>
</soapenv:Envelope>
An XML document!
e-Macao-16-5-134
SOAP Messaging
The SOAP messaging framework defines a suite of XML elements for
packaging arbitrary XML messages for transport between systems:
1) envelope
2) header
3) body
4) fault
5) etc.
e-Macao-16-5-135
SOAP Namespaces
All XML elements belong to the following namespaces:
1) SOAP 1.1 - http://schemas.xmlsoap.org/soap/envelope
2) SOAP 1.2 - http://www.w3.org/2003/05/soap-envelope
e-Macao-16-5-136
SOAP Envelope 1
A SOAP message is an envelope with
zero or more headers and one body:
1) envelope is a container for control
information, recipient address and the
message itself
2) headers contain control information
3) body contains the message information
[courtesy IBM]
e-Macao-16-5-137
SOAP Envelope 2
Envelop is always the root element of a SOAP message:
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope /">
<soap:Header>...</soap:Header>
<soap:Body>...</soap:Body>
</soap:Envelope>
The namespace is specified in the envelope for:
1) defining the envelope elements
2) controlling the SOAP version
Additional namespaces may be defined as well.
e-Macao-16-5-138
SOAP Header
Header is a generic place-holder for application independent information.
A header:
1) provides a mechanism for extending SOAP messages in a decentralized
and modular way
2) allows to pass control information to the receiving SOAP server
e-Macao-16-5-139
SOAP Header: Example
This header introduces a namespace and two elements:
<soap:Envelope xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
<soap:Header>
<t:transaction xmlns:t=http://example.org/transac>
<t:loginTime>10:20:00</t:loginTime>
<t:logoutTime>10:21:00</t:logoutTime>
</t:transaction>
</soap:Header>
...
</soap:Envelope>
e-Macao-16-5-140
SOAP Header Attributes
SOAP 1.2 provides mechanisms to specify who should deal with headers
and what to do with them.
For this purpose it includes attributes:
1) role
2) mustUnderstand
3) relay
Also it is possible to define:
4) encodingStyle
SOAP 1.1 has actor attribute instead of role, with the same semantic.
e-Macao-16-5-141
Mandatory/Optional Headers
Headers may be mandatory or optional.
If a header is mandatory:
1) the receiver must process the header
2) if the receiver is unable to process the header, it must fail
mustUnderstand attribute indicates if a header is mandatory or optional.
e-Macao-16-5-142
SOAP Body
The SOAP Body element represents a mechanism for exchanging
information intended for the ultimate recipient of the message.
Body represents the message payload a generic container that includes
any number of elements from any namespace.
In the simplest case the body of a SOAP message includes:
message name
reference to a service instance
parameters with values and optional type references
e-Macao-16-5-143
SOAP Body: Request Example
Request message to transfer funds between bank accounts:
<soap:Envelope xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
<soap:Body>
<x:TransferFunds xmlns:x=urn:examples-org:banking>
<x:from>983-23456</x:from>
<x:to>672-24806</x:to>
<x:amount>1000.00</x:amount>
</x:TransferFunds>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-144
SOAP Body: Response Example
Response message send back to the sender:
<soap:Envelope xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
<soap:Body>
<x:TransferFundsResponse xmlns:x=urn:examples-org:banking>
<x:balances>
<x:account>
<x:id>983-23456</x:id>
<x:balance>34.98</x:balance>
</x:account>
<x:account>
<x:id>672-24806</x:id>
<x:balance>1267.14</x:balance>
</x:account>
</x:balances>
</x:TransferFundsResponse>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-145
Task 25: Sending Request 1
Objective:
Send a SOAP message to FileDownloadService deployed in the
Introduction, asking to download a file.
The request message contains:
1) a header - contains user name and password
2) body - contains the method invocation
The client application has two command-line parameters:
1) the path to the downloaded file
2) the name to save this file on the client machine
e-Macao-16-5-146
Task 26: Sending Request 2
> cd demos\SOAP\Request
> dir
FileTransferRequest.class
MacaoNews.txt
> mkdir E:\WebServices
> copy MacaoNews.txt to \WebServices
> java cp \demos\SOAP\Request FileTransferRequest
E:\WebServices\MacaoNews.txt
news.txt
e-Macao-16-5-147
Task 27: Sending Request 3
Based on the request message:
1) what is the SOAP version?
2) what is the structure of the header?
3) what is the user name?
4) what is the password?
5) what is the structure of the body?
> dir
e-Macao-16-5-148
Task 28: Receiving Response
Objective: receive a response to the message sent.
> cd demos\SOAP\Response
> dir
FileTransferResponse.class
> java cp \demos\SOAP\Response FileTransferResponse
\WebServices\MacaoNews.txt
news.txt
e-Macao-16-5-149
SOAP Fault
The Fault element is used to represent errors:
1) processing errors
2) errors understanding a mandatory header
3) all abnormal situations
Faults are specified within the body of a SOAP message.
e-Macao-16-5-150
SOAP Fault: Example
Response message with the Insufficient funds error:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>soap:Sender</soap:Value>
</soap:Code>
<soap:Reason>Insufficient funds</soap:Reason>
<soap:Detail>
<x:TransferError xmlns:x="urn:examples-
org:banking">
<x:sourceAccount>22-342439</x:sourceAccount>
<x:transferAmount>100.00</x:transferAmount>
<x:currentBalance>89.23</x:currentBalance>
</x:TransferError>
</soap:Detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-151
Task 29: Generating a Fault 1
Objective:
Generate a fault message when looking for the service FileService
instead of FileDownloadService.
> cd demos\SOAP\Fault
> dir
FileTransferResponse.class
> java cp \demos\Soap\Fault FileTransferResponse
\WebServices\Macao.txt
news.txt
e-Macao-16-5-152
Task 30: Generating a Fault 2
Based on the response message:
1) Where is the fault element located?
2) What is the structure of the fault element?
e-Macao-16-5-153
Extending SOAP: Wrong Way
Suppose we want to add authentication information to the message:
<soap:Envelope>
xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
<soap:Body>
<x:TransferFunds xmlns:x=urn:examples-org:banking>
<x:from>983-23456</x:from>
<x:to>672-24806</x:to>
<x:amount>1000.00</x:amount>
<credentials>
<username>dave</username>
<password>evad</password>
</credentials>
</x:TransferFunds>
</soap:Body>
</soap:Envelope>
Not the right way: other applications in need of security must develop their
own solutions to the problem. Ultimately, interoperability suffers.
e-Macao-16-5-154
Extending SOAP: Right Way
An envelope wraps whatever XML content
is sent in a message.
The header is used to insert message
extensions without modifying its body.
Each individual header represents one
piece of extensibility information that
travels with the message.
Body
Header n
Header 1
Header 2
. . .
ENVELOPE
e-Macao-16-5-155
Use of Headers
Headers can contain any kind of data.
They are generally used to:
1) extend the messaging infrastructure:
a) infrastructure headers are processed by middleware
b) the application does not see the headers, only their effects
c) examples: security credentials, reliable messaging, etc.
2) define additional data:
a) these headers are defined by the application
b) called: vertical extensibility
c) for instance extra-data to accompany non-extensible schemas
e-Macao-16-5-156
Headers for Extensions
For common needs such as security, it makes more sense to define
standard SOAP headers that everyone agrees on.
Then, vendors can build support for the extended functionality into their
generic SOAP infrastructure and everyone wins.
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<s:credentials xmlns:s="urn:examples-org:security">
<s:username>dave</s:username>
<s:password>evad</s:password>
</s:credentials>
</soap:Header>
<soap:Body>...</soap:Body>
</soap:Envelope>
e-Macao-16-5-157
mustUnderstand Attribute
A global SOAP attribute mustUnderstand indicates whether or not a
receiver is required to understand the header block before processing.
For example:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<s:credentials
xmlns:s="urn:examples-org:security"
soap:mustUnderstand="1">
...
</s:credentials>
</soap:Header>
...
</soap:Envelope>
e-Macao-16-5-158
mustUnderstand Values
Two values:
1) mustUnderstand="1 if a receiver cannot support the header, a
fault should be returned with soap:mustUnderstand status code.
2) mustUnderstand="0 or mustUnderstand attribute is absent, the
receiver can ignore those headers and continue processing.
It may also have values false (0) and true (1).
e-Macao-16-5-159
SOAP Processing Model
SOAP defines a processing model that outlines rules for processing a
SOAP message as it travels from a SOAP sender to a SOAP receiver.
The model allows for architectures with multiple intermediary nodes:
[courtesy Aaron Skonnard]
e-Macao-16-5-160
SOAP Nodes
A SOAP node can be:
1) initial SOAP sender
2) ultimate SOAP receiver
3) SOAP intermediary
e-Macao-16-5-161
SOAP Intermediaries
SOAP intermediaries:
1) they are applications that can process parts of a SOAP message as it
travels from its origination point to its final destination point
2) can accept and forward SOAP messages, and usually they do carry out
some form of message processing
The route taken by a SOAP message, including all intermediaries it passes
through, is called the SOAP message path.
e-Macao-16-5-162
Reasons for Intermediaries 1
There are three major reasons for using intermediaries:
1) crossing-trust domains
nodes that allow some requests to cross the trust domain boundary and
deny access to others
2) ensuring scalability
a) nodes that provide flexible buffering and routing of messages based
on message parameters
b) nodes that provide information about network traffic and the
availability and load of network nodes
e-Macao-16-5-163
Reasons for Intermediaries 2
3) providing special services:
a) encrypting and digitally signing a message, or decrypting and
checking the digital signature
b) making a persistent copy of the request message, providing
a token that can be used to reference the transaction in the future
(notarization or non-repudiation)
c) enabling to find out the path that the message has followed, with
arrival and departure times to and from intermediaries
e-Macao-16-5-164
Intermediaries: Sender-View
Message senders may or may not be aware of intermediaries:
1) transparent intermediary - the client knows nothing about it, it believes
the message is sent to the service end-point.
The security intermediary would likely be transparent.
2) explicit intermediary it involves specific knowledge on the part of the
client. The client knows the message will pass through the intermediary.
The notarization intermediary would likely be explicit.
e-Macao-16-5-165
Intermediaries: Process-View
Intermediaries also differ with respect to processing:
1) forwarding intermediaries - nodes doing specific processing based on the
contents of the incoming message.
For instance a notarization node making a copy of the message
based on what is defined on a particular header.
2) active intermediaries - nodes doing processing and eventually modifying
the message in the ways not defined by the message contents.
For instance a node at a boundary of a company to the outside world
adding digital signatures to all outbound messages.
e-Macao-16-5-166
Nodes and Roles
While processing a message a SOAP node assumes one or more roles that
influence how the headers are processed.
A SOAP node has its role declared.
When it receives a message for processing:
1) it must process all mandatory headers targeted at one of its roles
2) it may process any optional headers targeted at one of its roles
e-Macao-16-5-167
Role Attribute
The role attribute is defined optionally in the header element:
1) The value of role is a URI that identifies the name the intermediary
who should handle the header entry.
2) The URI might mean:
a) a particular node - the server XY or
b) a class of nodes - any cache manager along the message path
3) A node can play multiple roles, e.g. XY server as a cache manager.
e-Macao-16-5-168
Predefined Roles
SOAP defines three special values for role:
1) http://www/w3.org/2002/06/soap-envelope/role/next
Each SOAP intermediary and the ultimate SOAP receiver must act in this
role and MAY additionally assume zero or more other roles.
2) http://www/w3.org/2002/06/soap-envelope/role/ultimateReceiver
The final recipient of the SOAP message - processes the body. The end-
receiver must act in this role. Intermediaries must not act in this role.
3) http://www/w3.org/2002/06/soap-envelope/role/none
SOAP nodes must not act on this role. Headers addressed to this role
should never be processed. They are used to carry data.
e-Macao-16-5-169
Roles: Example 1
A SOAP message with roles:
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
<soap:Header>
Mandatory header targeted at a SOAP node that plays the
http://example.org/security role:
<a:Security
xmlns:a=http://example.com
soap:role=http://example.com/security
soap:mustUnderstand=true >

</a:Security>
e-Macao-16-5-170
Roles: Example 2
Optional header targeted at the next node in the message path:
<b:NextExample xmlns:b=http://example.com
soap:role=http://www.w3.org/2003/05/soap-envelope/role/next
soap:mustUnderstand=false >

</b:NextExample>
Header targeted at a SOAP node with the ultimateReceiver role:
<c:NoRoleDef xmlns:c=http://example.com>

</c:NoRoleDef>
</soap:Header>

</soap:Envelope>
e-Macao-16-5-171
Processing Rules
The contract implied by a header is between the sender and the first node
satisfying the role at which it is targeted.
Two rules:
1) if a SOAP node successfully processes a header, it is required to
remove the header from the message
2) if the SOAP node happens to be the ultimate receiver, it must also
process the SOAP body.
SOAP nodes are allowed to reinsert headers, but doing so changes the
contract parties its now between the current and the next node.
e-Macao-16-5-172
Processing Rules: Example 1
<h1 role=notary>

</h1>
<h2 role=cacheMgr>

</h2>
header
body
<h2 role=cacheMgr>

</h2>
header
body
roles: notary
known headers:
h1
h1 and h2 are optional headers
h1 is processed and removed
h2 is forwarded untouched
intermediary
e-Macao-16-5-173
Processing Rules: Example 2
<h1 role=notary>

</h1>
<h2 role=notary>

</h2>
header
body
header
body
roles: notary
known headers:
h1
h1 and h2 are optional headers
h1 is processed and removed
h2 is not understood and removed
intermediary
e-Macao-16-5-174
Processing Rules: Example 3
<h1 role=notary>

</h1>
<h2 role=notary>

</h2>
header
body
header
body
roles: notary
known headers:
h1
h1 and h2 are mandatory headers
h1 is processed and removed
h2 is not understood and a fault is generated
intermediary
<h2> fault header
not understood
</h2>
e-Macao-16-5-175
Relay Attribute
The relay attribute is used to indicate to the intermediaries that:
if a header they do not understand is targeted at them
then this header should still be passed through
The attribute may equal true or false.
When a header targeted at a given intermediary has relay=true, it
forwards the header regardless of whether it understands it.
e-Macao-16-5-176
Relay Attribute: Example
<h1 role=notary>

</h1>
<h2 role=next
relay=true>

</h2>
header
body
header
body
roles: notary
known headers:
h1
h1 is processed and removed
h2 is forwarded due to the relay attribute
intermediary
<h2 role=next
relay=true>

</h2>
e-Macao-16-5-177
Versioning
SOAP applies XML namespaces to define the protocol version.
The SOAP version is the URI of the SOAP envelope namespace:
1) http://schemas.xmlsoap.org/soap/envelope for SOAP 1.1
2) http://www.w3.org/2003/05/soap-envelope for SOAP 1.2
An engine supporting a later SOAP version should know previous versions.
The SOAP specification defines processing rules related to SOAP versions.
e-Macao-16-5-178
Versioning: Processing Rules
Rules to follow by the SOAP engine:
If the message version is the same as a version the engine knows, it
should process the message.
If the message version is older than the one the engine knows, the
engine should generate a VersionMismatch fault and attempt to
negotiate the protocol version with the client.
If the message version is newer than the one the engine knows, the
engine must generate a VersionMismatch fault.
e-Macao-16-5-179
Error Handling
A SOAP fault message is a normal SOAP message with a single Fault
element inside the body.
Components of the Fault element include:
1) Code - mandatory
2) Subcodes - optional
3) Reason - mandatory
4) Node - optional
5) Role - optional
6) Details - optional
e-Macao-16-5-180
Fault Elements: Code
The Code element includes two sub-elements: a mandatory Value element
and an optional Subcode element.
1) Value specifies the type of a fault
2) Subcode specifies additional information
e-Macao-16-5-181
Fault Elements: Value 1
Here are the possible values of the Value sub-element:
1) VersionMismatch
The namespace of the received SOAP envelope is not compatible with
the SOAP version of the receiver.
2) mustUnderstand
The node does not recognize the block that includes the
mustUnderstand attribute.
3) Sender
The node cannot process the message because of incorrect or missing
data from the sender, e. g. the message is not properly formatted.
e-Macao-16-5-182
Fault Elements: Value 2
4) Receiver
The error is not due to the message itself but rather to the state in which
the server was when processing the message.
5) DataEncodingUnknown
The node does not understand the encoding style.
For example:
<soap:Fault>
<soap:Code>
<soap:Value>soap:Sender</soap:Value>
<soap:Code>
. . .
</soap:Fault>
e-Macao-16-5-183
Fault Elements: Subcode 1
SOAP allows developers to specify an arbitrary hierarchy of fault subcodes
for providing further details about the fault cause.
The Subcode element contains:
1) a mandatory Value element and
2) an optional Subcode sub-element
Each subcode may contain another subcode, to whatever level of nesting.
e-Macao-16-5-184
Fault Elements: Subcode 2
For example:
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>soap:Sender</soap:Value>
<soap:Subcode>
<soap:Value>bk:InvalidAccount</soap:Value>
</soap:Subcode>
</soap:Code>
</soap:Fault>
</soap:Body>
e-Macao-16-5-185
Fault Elements: Reason
The Reason element contains human-readable descriptions of the fault.
It contains the Text sub-element which includes the fault description.
Text may appear several times inside Reason.
<soap:Fault>
<soap:Code></soap:Code>
<soap:Reason>
<soap:Text xml:lang=en>Processing Error</soap:Text>
<soap:Text xml:lang=cn></soap:Text>
<soap:Text xml:lang=es>Error de Procesamiento</soap:Text>
</soap:Reason>
</soap:Fault>
e-Macao-16-5-186
Fault Elements: Node and Role
Two subelements of Fault:
1) The Node element specifies which SOAP node was processing the
message when the fault has occurred.
It contains a URI.
2) The Role element specifies which role the node was playing when the
fault has occurred.
Role behaves in the same way as the headers role attribute.
e-Macao-16-5-187
Fault Elements: Detail
The Detail element includes machine-readable data related to the fault.
<soap:Envelope
xmlns:soap=http:www.w3.org/2003/05/soap-envelope
xmlns:ac=http://www.example.com>
<soap:Body>
<soap:Fault>
<soap:Code> . . . </soap:Code>
<soap:Reason>
<soap:Text xml:lang=en>
Invalid account!
</soap:Text>
</soap:Reason>
<soap:Detail>
<ac:LineNumber>10</ac:LineNumber>
<ac:ColumnNumber>57</ac:ColumnNumber>
</soap:Detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-188
Task 31: Generate Sender Fault
Objective:
Send a SOAP message that will generate a fault caused by the wrong
operation name specified - downloadf instead of downloadFile.
> cd demos\Soap\SenderFault
> dir
FileTransferSenderFault.class
> java cp \demos\Soap\SenderFault
FileTransferSenderFault
\WebServices\MacaoNews.txt news.txt
e-Macao-16-5-189
Task 32: Generate Receiver Fault
Objective:
Send a SOAP message that will generate a fault because the server
could not find the service FileService.
> cd demos\SOAP\ReceiverFault
> dir
FileTransferReceiverFault.class
> java cp \demos\Soap\ReceiverFault
FileTransferReceiverFault
\WebServices\MacaoNews.txt news.txt
e-Macao-16-5-190
Faults in Headers
Since a fault is a SOAP message, it can also carry headers.
Problem:
1) a message may contain several mandatory headers
2) one node fails to understand one header
3) how can the header causing the fault be identified?
Solution: SOAP introduces the NotUnderstood header:
1) NotUnderstood is included for each header in the original message
that was not understood.
2) The qname attribute of NotUnderstood specifies the name of the
header that was not understood.
e-Macao-16-5-191
Faults in Headers: Example 1
Suppose a SOAP node receives the following message:
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
<soap:Header>
<a:Header1
xmlns:a=http://example.com/header1
soap:mustUnderstand=true/>
<b:Header2
xmlns:b=http://example.com/header2
soap:mustUnderstand=true/>
</soap:Header>
<soap:Body></soap:Body>
</soap:Envelope>
If the SOAP node does not understand Header2,
it would return a message as follows
e-Macao-16-5-192
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
xmlns:xml=http://www/w3.org/XML/1998/namespace>
<soap:Header>
<soap:NotUnderstood
qname= b:Header2
xmlns:b=http://example.com/header2/>
</soap:Header>
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>soap:mustUnderstand</soap:Value>
</soap:Code>
<soap:Reason>
<soap:Text xml:lang=en>
One or more mandatory headers not understood!
</soap:Text>
</soap:Reason>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Faults in Headers: Example 2
e-Macao-16-5-193
Upgrade Header
SOAP provides a standard mechanism to indicate which versions of SOAP
are supported by a node when generating a VersionMismatch fault.
1) An Upgrade header is used when a version mismatch fault occurs,
to specify which SOAP versions are supported by the node.
2) The different supported version are specified in the
SupportedEnvelope sub-element of Upgrade.
3) The SupportedEnvelope elements are ordered by preference,
from the most preferred to the least.
e-Macao-16-5-194
Upgrade Header: Example
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
xmlns:xml=http://www/w3.org/XML/1998/namespace>
<soap:Header>
<soap:Upgrade>
<soap:SupportedEnvelope qname=ns1:Envelope
xmlns:ns1=http://www.w3.org/2003/05/soap-envelope />
<soap:SupportedEnvelope qname=ns2:Envelope
xmlns:ns2=http://schemas.xmlsoap.org/soap/envelope/ />
</soap:Upgrade>
</soap:Header>
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>VersionMismatch</soap:Value>
</soap:Code>
<soap:Reason>
<soap:Text xml:lang=en>Version Mismatch </soap:Text>
</soap:Reason>
</soap:Fault>
</soap:Body>
e-Macao-16-5-195
SOAP Outline
1) Introduction
2) Messaging
a) envelope
b) headers
c) processing model
d) error handling
3) Data Structures
a) data model
b) data encoding
c) request encoding
4) Protocol Binding
a) binding
b) features and modules
c) communication patterns
5) SOAP and Binary Data
6) Summary
e-Macao-16-5-196
Data Model and Encoding
In order to be able to send Java and others programming
language objects inside SOAP envelopes, SOAP defines:
1) SOAP Data Model - an abstract representation of the data structures
such as the ones handled by Java or C#
2) SOAP Encoding - a set or rules to map the data model into XML for
sending the data inside SOAP envelopes
e-Macao-16-5-197
Data Model
SOAP data model
class Account {
int number;
String owner;
String type;
double balance;
int lastTrnDate;
}
Java object
lastTrnDate
Account
1358.25
saving
account
18-01-
2005
John
Smith
balance
type
owner
234
50935
number
The SOAP data model represents data structures as connected graphs,
where nodes represent values and edges represent labels.
e-Macao-16-5-198
Simple Values
Simple values are nodes with only incoming edges.
They correspond to basic data types found in most programming languages,
such as int, string, etc.
For instance type, balance, lastTrnDate, number, or owner below are
all simple values:
lastTrnDate
Account
1358.25
saving
account
18-01-
2005
John
Smith
balance
type
owner
234
50935
number
e-Macao-16-5-199
Compound Values
Compound values are nodes with outgoing edges.
There are two types of compound values:
1) structures
2) arrays
e-Macao-16-5-200
Compound Values: Structures
Structures are compound values where the outgoing edges have names.
They correspond to the named aggregated types.
Each element has a unique name called accessor, which is an XML tag.
Account below is a structure:
lastTrnDate
Account
1358.25
saving
account
18-01-
2005
John
Smith
balance
type
owner
234
50935
number
e-Macao-16-5-201
Compound Values: Arrays
Arrays are compound values where the outgoing edges are only
distinguished by their position (first edge, second edge, etc.).
For instance:
Person
Account
2
Account
1
Account
3
Account
4
e-Macao-16-5-202
Multirefs
Multirefs is a value which is referred from more than one value.
For instance: John Smith is the owner of two different accounts below
Person
John
Smith
Account
Account
234
50935
234
67493
number
number
owner
owner
name
e-Macao-16-5-203
Encoding
SOAP encoding describes how the SOAP data model is written with XML.
SOAP encoding is identified by the URI
http://www.w3.org/2003/05/soap-encoding.
When serializing XML using encoding rules, processors should use the
encodingStyle attribute to indicate the SOAP encoding in use.
The encodingStyle attribute can appear in:
1) message headers
2) message bodies
3) Detail sub-element of Fault
or any of their children.
e-Macao-16-5-204
Encoding Example
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:downloadFileResponse
soapenv:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://soapinterop.org/">
<downloadFileReturn
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xsi:type="soapenc:base64>
TW9..QogDQo=
</downloadFileReturn>
</ns1:downloadFileResponse>
</soapenv:Body>
</soapenv:Envelope>
e-Macao-16-5-205
Task 32: Encoding
1) browse: http://www.w3.org/2003/05/soap-encoding
2) Based on the encoding rule definitions:
a) what are the different values of a node type?
b) what are the possible attributes for an array?
c) what is base64?
e-Macao-16-5-206
Encoding Rule
Each outgoing edge becomes an XML element which contains:
1) a text value, if the edge points to a terminal node
2) further sub-elements, if the edge points to a node which itself has
outgoing edges.
e-Macao-16-5-207
Encoding Rule Example
lastTrnDate
Account
1358.25
saving
account
18-01-
2005
John
Smith
balance
type
owner
234
50935
number
<account
soapenv:encodingStyle=http://www/w3.org/2003/05/soap-encoding>
<number>23450935</number>
<owner>John Smith</owner>
<type>saving account</type>
<balance>1358.25</balance>
<lastTrnDate>20050118</lastTrnDate>
</account>
e-Macao-16-5-208
Encoding a Simple Value
For example, in a SOAP message containing:
<arg0 xsi:type="xsd:string">
c:\WebServices\MacaoNews.txt
</arg0>
1) xsi:type means that <arg0> will take string values
2) xsd:string is the XML schema string type
In general, all encoded elements provide the xsi:type attribute to help
recipients decode a message.
e-Macao-16-5-209
Simple Value Example
Java:
float balance=1358.25;
String owner=John Smith;
SOAP Encoding:
<balance xsi:type=xsd:float>
1358.25
</balance>
<owner xsi:type=xsd:string>
John Smith
</owner>
e-Macao-16-5-210
Encoding Multirefs
Person
John
Smith
Account
Account
234
50935
234
67493
number
number
owner
owner
name
An ID attribute is used to identify objects that are referred to elsewhere.
<person id=1
soapenv:encodingStyle=http://www/w3.org/2003/05/soap-encoding>
<name>John Smith</name>
<account id=2>
<number>23450935</number>
<owner>ref=1</owner>
</account>
<account id=3>
<number>23467493</number>
<owner>ref=1</owner>
</account>
</person>
e-Macao-16-5-211
Encoding Arrays
An array in the SOAP object model is encoded in XML using a compound
element with two attributes:
1) itemType - specifies the data type of the array elements
2) arraySize - specifies how many elements are in the array
For example:
<myAccounts
soapenc:itemType=xsd:integer
sopaenc:arraySize=3>
<item>23450935</item>
<item>23467493</item>
<item>23426741</item>
</myAccounts>
e-Macao-16-5-212
Encoding Multidimensional Arrays
Multidimensional arrays are supported by listing each dimension in the
arraySize attribute separated by spaces.
The values are serialized as a single list of items in row-major order:
pink
yellow
green red
white blue
<myArray
soapenc:itemType=xsd:string
sopaenc:arraySize=2 3>
<item>blue</item>
<item>yellow</item>
<item>white</item>
<item>red</item>
<item>pink</item>
<item>green</item>
</myArray>
e-Macao-16-5-213
Task 33: Encoding 1
Objective:
Send a request to receive the creation date, contents, size and name of a
given file. Accept an object of the FileAttribute class in response.
Serialize and encode the FileAttribute object before sending.
> cd SOAP\Encoding
> dir
deployFileDownloadEncodedService.wsdd
deployService.bat
FileAttribute.class
FileDownloadEncoded.class
FileTransferRequestEncoding.class
FileTransferResponseEncoding.class
responseFormatted.txt
e-Macao-16-5-214
Task 34: Encoding 2
Deploy the web service:
> copy FileAttribute.class
Tomcat 4.1\webapps\axis\WEB-INF\classes
> copy FileDownloadEncoded.class
Tomcat 4.1\webapps\axis\WEB-INF\classes
Double-click deployService.bat
Test the web service: browse http://localhost:8080/axis and View.
e-Macao-16-5-215
Task 35: Encoding 3
Run the request and send the output to a log file (request.txt):
> java cp \demos\SOAP\Encoding
FileTransferRequestEncoding
\WebServices\MacaoNews.txt > request.txt
> notepad request.txt
Run the response and send the output to a log file (response.txt):
> java cp \demos\SOAP\Encoding
FileTransferResponseEncoding
\WebServices\MacaoNews.txt > response.txt
> notepad response.txt
Analize the response:
> notepad responseFormatted.txt
e-Macao-16-5-216
Encoding a Request
A SOAP request message is modeled as a structure with an accessor
element for each input and output parameter:
<getBalance
encodingStyle=http://www/w3.org/2003/05/soap-encoding>
<accountNumber xsi:type=xsd:int>
23450935
</accountNumber>
</getBalance>
1) the only accessor is accountNumber
2) accessor names correspond to the names of parameters, their type
attributes correspond to the programming language data types
3) parameters must appear in the same order as in the method signature
4) the name of the structure element is the procedure or method name
e-Macao-16-5-217
Encoding Specific Faults
SOAP defines some fault codes specifically for encoding problems.
These are recommended values to be sent in the Subcode value when the
Sender code is used.
They all relate to problems with the senders data serialization.
1) MissingID generated when a ref attribute in the received message
does not correspond to any of the id attributes in the message
2) DuplicateId generated when more than one element in the
message has the same id attribute value
3) UntypedValue generated optionally to indicate that a type in the
received message could not be determined by the receiver
e-Macao-16-5-218
Encoding RPC Request
Using a SOAP structure to represent a method call:
public float getBalance(int arg)
A request message representing a call to this method in SOAP is:
<soap:Envelope>
<soap:Body>
<orgNS:getBalance
xmlns:orgNS=http://myOrganization.com/
soap:encodingStyle=http://www/w3.org/2003/05/soap-encoding>
<arg0 xsi:type=xsd:int>23450935</arg>
</orgNS:getBalance>
</soap:Body>
</soap:Envelope>
The structure contains one accessor for each argument.
The content of the arg element is the value for the argument.
e-Macao-16-5-219
Encoding RPC Response
The response is also modeled as a structure which name is the method
name with Response element appended.
Here is a possible response to the previous message:
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<soap:Body>
<orgNS:getBalanceResponse
xmlns:orgNS=http://myOrganization.com/
xmlns:rpc=http://www.w3.org/2003/05/soap-rpc
soap:encodingStyle=
http://www/w3.org/2003/05/soap-encoding>
<rpc:result>ret</rpc:result>
<ret xsi:type=xsd:decimal>1358.25</ret>
</orgNS:getBalanceResponse>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-220
Encoding RPC Return Values
SOAP specifies that an RPC response structure containing a return value
must contain an accessor element called result.
The value of this element specifies the accessors name containing the
return value for the invocation.
<soap:Body>
<orgNS:getBalanceResponse
xmlns:orgNS=http://myOrganization.com/
xmlns:rpc=http://www.w3.org/2003/05/soap-rpc
soap:encodingStyle=http://www/w3.org/2003/05/soap-
encoding>
<rpc:result>ret</rpc:result>
<ret xsi:type=xsd:decimal>1358.25</ret>
</orgNS:getBalanceResponse>
</soap:Body>
e-Macao-16-5-221
Encoding RPC Out Parameters
Suppose we have this Java method:
public float getBalance(int arg, out String status)
The method now returns the account balance and the status.
The request message is as the one shown previously.
e-Macao-16-5-222
Encoding RPC Out Parameters
The response looks as follows:
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<soap:Body>
<orgNS:getBalanceResponse
xmlns:orgNS=http://myOrganization.com/
xmlns:rpc=http://www.w3.org/2003/05/soap-rpc
soap:encodingStyle=
http://www/w3.org/2003/05/soap-encoding>
<rpc:result>ret</rpc:result>
<ret xsi:type=xsd:decimal>1358.25</ret>
<status xsi:type=xsd:string>active</status>
</orgNS:getBalanceResponse>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-223
RPC In-Out Parameters
In web services, all parameters are passed by value.
Therefore the notion of in-out and out parameters does not involve
passing objects by reference, but exchanging copies of the data.
The client code should create the perception that the state of the object that
has been passed to the method has been modified.
e-Macao-16-5-224
Communication Styles
SOAP enables two communication styles:
1) document-style
The message has no fixed structure, so the interacting applications must
agree beforehand on this structure.
2) RPC-style
Synchronous method invocation - pre-defined message structure.
e-Macao-16-5-225
Document Style
Also known as a message-oriented style:
1) a request is an XML document
2) an optional response is also an XML document
Two interacting applications agree beforehands upon the structure of
the documents exchanged, then use SOAP messages to transport them.
Very flexible communication style that provides the best interoperability,
using synchronous or asynchronous communication.
e-Macao-16-5-226
Document Style Example
The response message in document-style:
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
xmlns:xsd=http://www.w3.org/2001/XMLSchema>
<soap:Body>
<orgNS:returnBalance
xmlns:orgNS=http://myOrganization.com/
soap:encodingStyle=http://www/w3.org/2003/05/soap-encoding>
<orgNS:balance orgNS:type=xsd:float>1235.95
</orgNS:balance>
</orgNS:returnBalance>
</soap:Body>
</soap:Envelope>
e-Macao-16-5-227
Task 36: Document Style 1
Objective:
Generate a SOAP message in a document style, with a purchase
order for two XML books with ISB-12345 and the total price 125.12.
1) cd demos\SOAP\DocumentStyle
2) dir
deployDocumentStyleService.wsdd
deployService.bat
DocumentStyleClient.class
DocumentStyleService.class
e-Macao-16-5-228
3) deploy DocumentStyleService:
a) copy documentStyleService.class
to Tomcat/webapps/axis/WEB-INF/classes
b) execute deployService
4) test the service: http://localhost:8080/axis View
5) what is the difference with the previous service deployed?
a) methods?
b) WSDL?
Task 37: Document Style 2
e-Macao-16-5-229
6) execute the client sending the output to a log file:
java cp \demos\SOAP\DocumentStyle DocumentStyleClient
> log.txt
7) notepad log.txt
Task 38: Document Style 3
e-Macao-16-5-230
RPC Style
RPC-style is a synchronous invocation of an operation returning a result:
1) One SOAP message encapsulates the request.
The body of the request message contains the actual call including the
name of the procedure being invoked and the input parameters.
2) Another SOAP message encapsulates the response.
The body of the response contains the result and output parameters.
The two interacting applications agree upon the RPC method signature.
e-Macao-16-5-231
RPC Style Example
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<soap:Body>
<orgNS:getBalanceResponse
xmlns:orgNS=http://myOrganization.com/
xmlns:rpc=http://www.w3.org/2003/05/soap-rpc
soap:encodingStyle=http://www/w3.org/2003/05/soap-encoding>
<rpc:result>ret</rpc:result>
<ret xsi:type=xsd:decimal>1358.25</ret>
<status xsi:type=xsd:string>active</status>
</orgNS:getBalanceResponse>
</soap:Body>
</soap:Envelope>
The response message in RPC-style:
e-Macao-16-5-232
Task 39: RPC Request
Objective: generate a SOAP message in the RPC-style.
1) cd demos\SOAP\RPCStyle
2) dir
FileTransferRequest
3) Java cp demos\SOAP\RPCStyle FileTransferRequest
e:\webservices\macaonews.txt news.txt > log.txt
4) notepad log.txt
e-Macao-16-5-233
SOAP Outline
1) Introduction
2) Messaging
a) envelope
b) headers
c) processing model
d) error handling
3) Data Structures
a) data model
b) data encoding
c) request encoding
4) Protocol Binding
a) binding
b) features and modules
c) communication patterns
5) SOAP and Binary Data
6) Summary
e-Macao-16-5-234
Protocol Binding Framework
SOAP enables exchange of messages using a variety of protocols.
The set of rules for carrying a SOAP message within or on top of another
protocol for the purpose of exchange is called binding.
SOAP protocol binding framework:
1) provides general rules for the specification of protocol bindings
2) describes the relationship between bindings and SOAP nodes that
implement those bindings
e-Macao-16-5-235
Binding and Transfer
For instance, SOAP HTTP binding describes how to take a SOAP infoset at
one node and serialize it across an HTTP connection to another node.
The job of the binding is to move the infoset from one node to another. The
way the infoset is represented in the wire is up to the binding author.
Bindings have the freedom to specify custom serializations in order to
improve efficiency, security, etc.
e-Macao-16-5-236
Binding URI
Communicating parties must agree on what binding to use.
Thus, bindings are named with URIs.
SOAP HTTP binding URI:
http://www.w3.org/2003/05/soap/bindings/HTTP
e-Macao-16-5-237
SOAP Features
A feature extends SOAP with some specific functionality.
SOAP poses no constraints on the potential scope of features.
A feature description is identified by a URI, so that all applications
referencing it are assured the same semantics.
e-Macao-16-5-238
SOAP Feature Examples
Examples of features:
1) reliability
2) security
3) routing
4) Message Exchange Patterns (MEPs):
a) request/response
b) one-way
c) peer-to-peer conversations
e-Macao-16-5-239
Expressing Features
The SOAP extensibility model provides two mechanisms through which
features can be expressed:
1) SOAP Processing Model
2) SOAP Protocol Binding Framework
e-Macao-16-5-240
Features with SOAP Processing
Describes the behavior of a single SOAP node with respect to the
processing of an individual message
Characteristics:
1) features are expressed by modules
2) a module is a way to perform functions using the SOAP processing
model via headers
e-Macao-16-5-241
Features with Protocol Binding
Mediates the act of sending and receiving SOAP messages by a SOAP
node via an underlying protocol.
Characteristics:
1) features are expressed by bindings
2) a binding is a way to perform functions below the SOAP processing
model
e-Macao-16-5-242
Features Method Comparison
Processing Model:
1) enables SOAP nodes, that
are able to implement
features to express them
within the SOAP envelope as
SOAP headers
2) header can be intended for
any SOAP node along the
SOAP message path
Protocol Binding Framework:
1) a protocol binding operates
between two adjacent SOAP
nodes along the message path
2) different protocols can be used
along the path
3) some protocols are equipped,
either directly or through an
extension, with mechanisms for
providing certain features
e-Macao-16-5-243
SOAP Modules
SOAP modules define the syntax and semantics of the extensions provided
by headers, including constraints, rules, preconditions, and data formats .
A SOAP module realizes zero or more SOAP features.
SOAP modules are named with URIs so they can be referenced, versioned,
and reasoned about.
e-Macao-16-5-244
Feature Specification
The specification of a feature must include:
1) a URI used to name the feature
2) the information required at each node to implement the feature
3) processing required at each node to implement the feature including
handling of communication failures that might occur
4) the information to be transmitted from node to node
e-Macao-16-5-245
Feature Example
Suppose an application requires a secure channel feature.
The URI for this feature is http://www.myOrganization.com/secureChannel
The abstract feature describes that messages must travel from node to
node in an unsnoopable fashion (reasonable level of security).
Alternatives:
1) Since HTTPS meets the security requirement specified by the feature,
the feature would be satisfied by this protocol binding.
2) We can use a SOAP module (e.g. WS-Security) that provides encryption
and signing of SOAP messages across any binding.
We can decide in some situations to engage the SOAP module, and not to
do so in others (e.g. when using the HTTPS binding).
e-Macao-16-5-246
Message Exchange Patterns
MEP is a common type of feature.
A MEP specifies:
1) how many messages are involved in interaction
2) where the messages originate
3) where they end up
Each binding must support one or more MEP.
SOAP specifies two standard MEPs:
1) request-response
2) SOAP-response
e-Macao-16-5-247
Request-Response MEP
Request-Response MEP involves two nodes:
1) requesting node sends a SOAP message to the responding node
2) responding node replies with a SOAP message that returns to the
requesting node
Important features:
1) the response message is correlated to the request message
2) if a fault is generated at the responding node, the fault is delivered
as part of the response message
Requesting
SOAP
Node
Responding
SOAP
Node
SOAP
Request
SOAP
Response
e-Macao-16-5-248
SOAP Response MEP
SOAP Response MEP involves two nodes:
1) the requesting message is not a SOAP message
2) the responding node replies to the request with a SOAP message
Important features:
1) the request does not trigger the execution of the SOAP processing
model on the receiving node
2) it allows a request to be something as simple as an HTTP GET
Requesting
SOAP
Node
Responding
SOAP
Node
SOAP
Response
Non-SOAP
Request
e-Macao-16-5-249
Request-Response MEP Example
One alternative is to implement the request-response MEP by an HTTP
binding. Another one is using SOAP headers:
<soap:Envelope
xmlns:saop=http://www.w3.org/2003/05/soap-envelope>
<soap:Header>
<r:replyTo
soap:mustUnderstand=true
xmlns:r=http://myOrganization/requestResponse>
<destination>udp://anotherHost.com:6777</destination>
</r:replyTo>
<r:correlationID
soap:mustUnderstand=true
xmlns:r=http://myOrganization/requestResponse>
1202
</reqresp:correlationID>
</soap:Header>
<soap:Body></soap:Body>
</soap:Envelope>
e-Macao-16-5-250
MEPs with HTTP Binding
The SOAP HTTP binding supports both MEPs.
1) request/response MEP with HTTP binding:
SOAP request message HTTP request
SOAP response message HTTP response
2) SOAP response MEP with HTTP binding:
non-SOAP request HTTP GET request
SOAP response message HTTP response
HTTP binding also specifies how to map faults to particular HTTP status
codes and status codes to the web services invocations.
e-Macao-16-5-251
SOAP HTTP Protocol Binding
Example rules:
1) SOAP request/response maps
naturally to the HTTP model
2) content-type header for HTTP
request/response messages must be
set to application/soap+xml
3) request messages must use
POST and the URI identifying the
SOAP processor
4) HTTP response should use 200
status if no errors occurred or 500 if
the body contains a fault
[courtesy Aaron Skonnard]
e-Macao-16-5-252
SOAP HTTP Binding Details
HTTP GET request does not have a payload area and therefore cannot be
used to carry SOAP messages.
The SOAP HTTP binding also implements two features:
1) SOAP action feature
2) web method feature
e-Macao-16-5-253
SOAP 1.1 Action Feature
In SOAP 1.1 HTTP binding, a custom header SOAPAction is required to:
1) let know the receiver that the content of the message is SOAP
2) convey the intent of the message via a URI
The decision to use a value for the SOAPAction header field is up to the
web service designer.
Many implementations use this URI dispatching a particular piece of code on
the backend, especially for document-style communication.
For instance, the same body content may be sent to two different methods,
and the SOAPAction URI may be used to differentiate between them.
e-Macao-16-5-254
SOAP 1.2 Action Feature
SOAP 1.2 uses the application/soap+xml media type. The SOAPAction
header is no longer needed to identify SOAP messages.
This media type specifies an optional action parameter used in SOAP 1.2,
instead of an HTTP-specific header to carry the SOAPAction URI.
The binding implementing this feature must place the value of the URI in the
action parameter. The message looks like:
POST /axis/TheService.jws
Content-Type: application/soap+xml; charset=utf-8
Action=http:// myOrganization.com/specificAction
...
e-Macao-16-5-255
Web Method Feature
The web method feature was defined to integrate the semantics of SOAP
with the semantic of HTTP.
Bindings to HTTP should use this feature to give control to applications over
the web methods (GET, POST, PUT, ) used sending SOAP message.
When sending a message, the HTTP binding will use the verb specified in
this property instead of the default POST.
e-Macao-16-5-256
SOAP Outline
1) Introduction
2) Messaging
a) envelope
b) headers
c) processing model
d) error handling
3) Data Structures
a) data model
b) data encoding
c) request encoding
4) Protocol Binding
a) binding
b) features and modules
c) communication patterns
5) SOAP and Binary Data
6) Summary
e-Macao-16-5-257
SOAP and Binary Data
Suppose that in the bank application we would like to send an image of the
account statement.
Since XML cannot encode binary data, a solution might be to use the XML
Schema type base64binary and encode images as base64 text:
<soap:Envelope xmlns:soap=... xmlns:xsi=...>
<soap:Body>
<accountData>
<number>23450935</number>
<owner>John Smith</owner>
<statement imageType=jpg xsi:type=base64binary>
4f3t68j
</statement>
</accountData>
</soap/Body>
</soap:Envelope>
Not efficient! E-mail is using the MIME standard.
e-Macao-16-5-258
SOAP with Attachments 1
In 2000, HP and Microsoft released a specification SOAP with Attachments.
SwA describes a simple way to use the multiref encoding in SOAP 1.1 to
reference MIME-encoded attachment parts.
Here is the previous example in SwA:
MIME-Version:1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type=application/soap+xml;start=<account@myOrganization.com>
--MIME_boundary
Content-Type: application/soap+xml: charset=UTF-8
Content-Transfer-Encoding: 8 bit
Content-ID:<account@myOrganization.com>
e-Macao-16-5-259
SOAP with Attachments 2
<soap:Envelope
xmlns:soap=http://www.w3.org/2003/05/soap-envelope
<soap:Body>
<accountData>
<number>23450935</number>
<owner>John Smith</owner>
<statement href=cid:statemet@myOrganization.com/
</accountData>
</soap/Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID:<statement@myOrganization.com>
. . . Binary JPG image . . .
--MIME_boundary
The problem is that this approach introduces a data structure that is explicitly
outside the realm of the XML data model.
e-Macao-16-5-260
Task 40: SOAP with Attachments
Objective: send a request for uploading an attached file.
1) cd \demos\SOAP\WithAttachments
2) dir
deployFileUploadService.wsdd
deployService.bat
FileUploadRequest.class
FileUploadService.class
e-Macao-16-5-261
Task 41: SOAP with Attachments
Deploy the web service:
3) copy FileUploadService.class
to Tomcat 4.1\webapps\axis\WEB-INF\classes
4) double-click: deployService.bat
Test the web service:
5) http://localhost:8080/axis --> View
e-Macao-16-5-262
Task 42: SOAP with Attachments
Run the request and send the output to a log file (request.txt):
6) java cp \demos\SOAP\WithAttachments FileUploadRequest
\WebServices\MacaoNews.txt macao.txt > request.txt
7) notepad request.txt
e-Macao-16-5-263
SOAP Outline
1) Introduction
2) Messaging
a) envelope
b) headers
c) processing model
d) error handling
3) Data Structures
a) data model
b) data encoding
c) request encoding
4) Protocol Binding
a) binding
b) features and modules
c) communication patterns
5) SOAP and Binary Data
6) Summary
e-Macao-16-5-264
SOAP Summary 1
SOAP is a lightweight protocol that allows to move XML messages in a
distributed environment.
SOAP provides:
1) a messaging framework
2) data model and encoding rules
3) bindings to various communication protocols
SOAP is extensible.
SOAP is independent of any protocol or programming language.
e-Macao-16-5-265
SOAP Summary 2
1) XML messages are packed in envelopes for transmission.
2) A SOAP envelope contains zero or more headers and a body.
3) A header is a container for control information or application data sent to
a SOAP server. It provides a mechanism to extend SOAP messages.
4) A body is a container to exchange information.
5) A fault is a structure to inform a sender that something went wrong while
processing the message by the receiver.
e-Macao-16-5-266
SOAP Summary 3
1) A SOAP message can visit several intermediaries before it reaches the
ultimate receiver. All these nodes constitute the message path.
2) SOAP defines a processing model that outlines rules for processing a
message through the message path.
3) Headers may be addressed to specific intermediaries.
4) Headers may include four attributes:
a) role: the name of the intermediary who should handle the header
b) mustUnderstand: is processing the header mandatory?
c) relay: should the header be passed to the next node?
d) encodingStyle: a URI for the SOAP encoding
e-Macao-16-5-267
SOAP Summary 4
1) SOAP data model defines an abstract representation of the common
data structures handled by programming languages.
2) SOAP encoding provides a set of rules to map the data model to XML.
3) SOAP also provides the rules for encoding requests, faults and RPC.
4) SOAP supports two communication styles for invoking a service:
a) document style: interacting applications must agree upon the
structure of the documents exchanged
b) RPC style: synchronous service invocation, defined message
structure
e-Macao-16-5-268
SOAP Summary 5
1) SOAP protocol binding framework provides the general rules for
specification of protocol bindings.
2) A SOAP protocol binding describes how to take a SOAP infoset at one
node and serialize it across the protocol connection to another node.
3) A feature is a unit of SOAP extension, implemented via SOAP modules
or bindings. Message Exchange Pattern (MEP) is a common binding.
4) Two standard MEPs: request-response and SOAP response.
5) SOAP HTTP binding satisfies both standard MEPs.
6) Binary data may be sent by SOAP using a text encoding or using SOAP
with attachments.
WSDL
e-Macao-16-5-270
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-271
WSDL Outline
1) Introduction
2) The Language
a) structure
b) definitions
c) types
d) message
e) part
f) port type
g) operation
h) binding
i) port
j) service
k) documentation
l) import
3) Transmission Primitives
a) one way
b) request-response
c) notification
d) solicit-response
4) WSDL Extensions
a) functional extensions
b) non-functional extensions
5) WSDL and Java
6) Summary
e-Macao-16-5-272
Service Description
A client needs to use a web service to exchange SOAP messages, but:
1) what to include on the body of the message?
2) is any security SOAP header required?
3) what is the format of the response message?
4) what protocol is required?
5) where to send the message?
e-Macao-16-5-273
Service Description Need
A service description is needed.
Service descriptions are needed for the three SOA operations:
1) publish
2) find
3) bind
e-Macao-16-5-274
Service Description Components
A service description has two major components:
1) functional description - defines details of how the service is invoked,
where is invoked, etc.
2) non-functional description - provides other details that are secondary to
the message but instructs the requestors runtime environment to add
SOAP headers, such as: security policy
e-Macao-16-5-275
Functional Description
The functional description describes the operations available in the web
service and the syntax of the messages required to invoke them.
The functional description is composed of:
1) service interface definition - describes:
a) what messages must be sent
b) how to use the various messaging protocols
c) which encoding schemes must be used in order to format
messages acceptable by the service provider
2) service implementation definition - describes where the service is
located
Both definitions use the Web Service Description Language (WSDL).
e-Macao-16-5-276
Non-Functional Description
The non-functional description adds more information about the service:
1) why a service requestor should invoke the service - what business
function the web service addresses and how it fits into a broader
business process
2) who is the service provider, if the service provider carries out
auditing, ensures privacy, etc.
3) specific aspects of the service not dependent on the domain, such
as security
Currently, the most widely adopted approach to describing non-functional
requirements is the combination of: WS-Policy and WS-PolicyAttachment.
e-Macao-16-5-277
Service Description Layers
service interface and non-functional description how ?
non-functional description why ?
service implementation where ?
service interface what ?
non-functional description who ?
A web service is described using a combination of techniques.
These are the questions that a service description should answer and
which layer is providing this information:
e-Macao-16-5-278
WSDL History
Two prior IDL languages for web services:
1) IBMs Network Accessible Service Specification Language (NASSL)
2) Microsofts SOAP Contract Language (SCL)
WSDL is the result of merging NASSL and SCL.
e-Macao-16-5-279
WSDL Recommendation
IBM, Microsoft and other companies submitted WSDL 1.1 to the W3C for
standardization in March 2001.
The specification is available at: http://www.w3.org/TR/wsdl
On 2004, the Web Services Description Working Group has released the
First Public Working Draft of WSDL 2.0.
Still, not a recommendation.
e-Macao-16-5-280
WSDL Service Description
A WSDL service description is an XML document conformant to the WSDL
schema definition.
This document, without any extensions, is not a complete service description,
since it only covers the functional part.
WSDL is the IDL for Web Services describing:
1) what a service does - the operations (methods) the service provides, and
the data (arguments and returns) needed to invoke them
2) how a service is accessed - details about data formats and protocols
necessary to access the service operations
3) where a service is located - details of the protocol-specific network
address, such as a URL
e-Macao-16-5-281
WSDL and IDLs
As WSDL describes service interfaces, it has a role and purpose similar to
that of an IDL in conventional middleware platforms, but:
1) IDL only specifies a service
interface: name and signature
2) the location of the requested
object is transparent and
unknown to the client
3) describes a single entry point
(single RPC interaction)
4) objects are accessed through
a concrete middleware platform
1) WSDL also defines the
mechanisms to access the
service
2) the WS middleware at the
client site should be able to
identify the location of the service
3) involves the exchange of
several asynchronous messages
4) services are accessed using
different protocols
e-Macao-16-5-282
Repositories of WSDL Documents
Public repositories of WSDL documents:
1) http://www.salcentral.com
2) http://www.xmethods.com
3) http://www.grandcentral.com/
e-Macao-16-5-283
WSDL Outline
1) Introduction
2) The Language
a) structure
b) definitions
c) types
d) message
e) part
f) port type
g) operation
h) binding
i) port
j) service
k) documentation
l) import
3) Transmission Primitives
a) one way
b) request-response
c) notification
d) solicit-response
4) WSDL Extensions
a) functional extensions
b) non-functional extensions
5) WSDL and Java
6) Summary
e-Macao-16-5-284
WSDL Structure
WSDL specifications include:
1) abstract part - conceptually
analogous to conventional IDL
2) concrete part - defines protocol
binding and other information
services and ports
interface bindings
concrete part
types
messages
operations
port types
abstract part
WSDL specification
e-Macao-16-5-285
WSDL Structure - Abstract
1) port type - logical collection of related
operations
2) operation - abstract description of an
action supported by the service
3) message - data exchanged in a single
logical transmission
4) types - data structures that
will be exchanged as parts of messages
There is no:
1) concrete binding
2) encoding specified
3) service implementing the set of ports
The abstract part includes:
types
messages
operations
port types
abstract part
what ?
e-Macao-16-5-286
WSDL Structure - Concrete
1) interface bindings - message encoding
and protocol binding for all operations
and messages defined in a given port-
type
2) ports - combine the interface binding
information with a network address
specified by a URI
3) services - are logical groupings of ports
These allow:
1) a specific web service at different web addresses (different servers)
2) different ports (interface bindings) for the same port type, allowing
the same functionality to be accessible via multiple transport
protocols and interaction styles
services and ports
interface bindings
concrete part
The concrete part includes:
where?
how ?
e-Macao-16-5-287
WSDL Information Model
(abstract)
message
(abstract)
operation
abstract interface
portType
(concrete)
message
(concrete)
operation
concrete
implementation
binding
part
type
concrete endpoint
port
service
contains zero
or more
made concrete by
e-Macao-16-5-288
WSDL Document Example 1
<?xml version=1.0?>
<definitions
name= Orders"
targetNamespace="http://www.example.com/orders"
xmlns="http://schemas.xmlsoap.org/wsdl/
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns:tns=http://www.example.com/orders>
<message name=OrderMsg>
<part name=productId type=xsd:string/>
<part name=quantity type=xsd:integer/>
</message>
<portType name=OrderPortType>
<operation name=orderProductRequest>
<input message = OrderMsg/>
</operation>
</portType>
abstract part
messages
operation and
port type
e-Macao-16-5-289
WSDL Document Example 2
concrete part
<service name=OrderService>
<port name=OrderPort binding=tns:OrderSOAPBinding>
<soap:address location=http://example.com/orders />
</port>
</service>
<binding name=OrderSOAPBinding type=tns:OrderPortType
<soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/>
<operation name=orderProductRequest>
<soap:operation
soapAction=http://example.com/orderProductRequest/>
<input>
<soap:body use=literal/>
</input>
</operation>
</binding>
</definitions>
binding
port and
service
e-Macao-16-5-290
WSDL Document Structure
The root element of a WSDL document is a definitions element.
This element can contain:
1) an optional types element
2) zero or more message elements
3) zero or more portType elements (usually one)
4) zero or more binding elements (usually one)
5) zero or more service elements (usually one)
6) zero or more documentation elements
7) zero or more import elements
A WSDL document must conform to the XML Schema defined at:
http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd
e-Macao-16-5-291
Definitions Element
The definitions element contains:
1) name attribute - corresponds to the name of the web service. It is
only for documentation and is optional
2) targetNamespace attribute - a URI for the entire WSDL file
3) default namespace - all elements without a namespace prefix, such
as message or portType, are assumed to be part of the default
WSDL namespace: http://schemas.xmlsoap.org/wsdl/
4) other XML namespace declarations
e-Macao-16-5-292
Definitions Example
A Web Service that converts temperature in Fahrenheit to Celsius.
The service supports a single operation FahrenheitToCelsius, deployed
using the SOAP protocol over HTTP.
<definitions
name= "TemperatureConverterService"
targetNamespace="http://www.converter.com/TemperatureConverter"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns=http://www.converter.com/TemperatureConverter
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
...
</definitions>
e-Macao-16-5-293
Task 43: Definitions Element
Objective: Write a WSDL file describing a web service that will send an
email with a custom message and error description to a developer or help
desk. Two bindings will be provided: SOAP and HTTP-GET
1) cd \demos\WSDL\Example1
2) create a document Myexample.wsdl and add:
a) the XML declaration
<?xml version="1.0" encoding="utf-8" ?>
b) the root element for the WSDL document
<wsdl:definitions
e-Macao-16-5-294
Task 44: Definitions Element
3) add the definitions of namespaces for:
targetNamespace="http://example.com/ErrorMailer"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/
and:
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://example.org/ErrorMailer"
4) save the file
e-Macao-16-5-295
Types Element
The types element encloses the definitions of user-defined XML types and
elements for later use in the contents of the message.
A WSDL document can have at most one types element, and when
present, it typically contains a single schema definition.
XML Schema is the predominant type system used, although types allows
to describe other type systems.
In order to build interoperable web services, WSDL should only use the
datatypes defined with XML Schema.
e-Macao-16-5-296
Types Example
<types>
<xsd:schema
targetNamespace=http://www.converter.com/TemperatureConverter>
<xsd:element name=tempCelsius type=xsd:float />
<xsd:element name=tempFahrenheit type=xsd:float />
</xsd:schema>
</types>
Using the schema element to define XML datatypes and elements requires
to include a targetNamespace attribute.
Many designers use the same value as the one used in WSDL
definitions element.
e-Macao-16-5-297
Task 45: Types
Objective: Add the types definition to MyExample.wsdl
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and add:
a) the type and the schema elements:
<wsdl:types>
<s:schema targetNamespace="http://example.com/ErrorMailer">
e-Macao-16-5-298
Task 46: Types
b) element SendError defined as a complex type with two elements
LicenseKey and ErrorMessage, both of type string:
<s:element name="SendError">
<s:complexType>
<s:sequence>
<s:element name="LicenseKey" type="s:string" />
<s:element name="ErrorMessage" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
e-Macao-16-5-299
Task 47: Types
c) element SendErrorResponse defined as a complex type, with an
element SendErrorResult of type string:
<s:element name="SendErrorResponse">
<s:complexType>
<s:sequence>
<s:element name="SendErrorResult
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
3) no more type definitions are needed. Add:
</s:schema>
</wsdl:types>
4) save the file
e-Macao-16-5-300
Message Element
A message is the construct that describes the abstract form of an input,
output or a fault message.
A message describes the data being communicated.
Each message has a unique name within the WSDL document and contains
a collection of parts.
<message name=FahrenheitToCelsiusRequest">
<part name=tempFahrenheit" type=xsd:float />
</message>
<message name=FahrenheitToCelsiusResponse">
<part name=tempCelsius" type=xsd:float />
</message>
A message may have several parts.
A part may belong to several messages.
e-Macao-16-5-301
Part Element
Parts provide a flexible mechanism for describing the logical content of
messages.
A part element has two properties:
1) name - represented by the name attribute, which must be unique
among all the part elements of the message element
2) kind - defined as either a type or an element attribute:
a) element - the payload of the message on the wire is precisely
the XML element
b) type - any element conforming to the type
e-Macao-16-5-302
Message Part Example
These are messages for the operation asking for information about weather:
<message name=WeatherRequest>
<part name=userID type=xsd:string />
<part name=city type=xsd:string />
</message>
<message name=WeatherResponse>
<part name=weather element=tns:weatherData />
</message>
e-Macao-16-5-303
Task 48: Message Parts
Objective: Add the message definitions to MyExample.wsdl. Four messages
are needed to formulate a request and response for both bindings.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and add:
a) two messages SendErrorSoapIn and SendErrorSoapOut. Each
message has a part parameters. Both parts are elements of type
SendErrorand SendErrorResponse respectively.
b) two messages SendErrorHttpGetIn and
SendErrorHttpGetOut. The first has two parts: LicenseKey and
ErrorMessage, both of type string. The other message has only one
part Body of type string.
3) save the file
e-Macao-16-5-304
PortType Element
portType is a collection of one or more related operations describing the
interface of a web service.
portType definition is a collection of operation elements.
Generally, WSDL documents contain only one portType element, because
different web service interface definitions are written with different documents.
portType has a single name attribute.
The name of portType together with the namespace of the WSDL document
define a unique name for the portType.
e-Macao-16-5-305
Operation Element
operation defines a method of a web service, including the name of the
method, input parameters, and the output or return type of the method.
All operations in a portType must have different names.
Each operation may define:
1) input message
2) output message
3) fault message
An operation in WSDL is the equivalent of a method signature in Java.
e-Macao-16-5-306
PortType Operation Example
The example defines one port type with one operation:
<portType name="TemperatureConverter_Service">
<operation name="FahrenheitToCelsius">
<input message="FahrenheittoCelsiusRequest"/>
<output message="FahrenheittoCelsiusResponse "/>
</operation>
</portType>
Notes:
1) operations and messages are modeled separately in order to support
flexibility and simplify reuse of existing information
2) two operations with the same parameters can share one abstract
message definition
e-Macao-16-5-307
Task 49: PortTypes and Operations
Objective: Add two portType definitions to MyExample.wsdl, one for each
binding. Both contain the operation sendError with the corresponding
messages.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and add:
a) one portType ErrorMailerSoap
b) other portType ErrorMailerHttpGet
3) save the file
e-Macao-16-5-308
Abstract Concrete Definitions
We already defined:
1) types
2) messages
3) portTypes
4) operations
We didnt define yet how to relate these definitions with SOAP headers,
SOAP bodies or SOAP encodings:
1) is this service invoked using a SOAP message or a simple HTTP
POST of an XML payload?
2) is the service invoked with an RPC or a document style?
These aspects relate to the concrete implementation and are defined using
the binding element.
abstract, reusable portions
of a WSDL definition
e-Macao-16-5-309
Binding Element 1
The binding element specifies how to format messages in a protocol-
specific manner:
1) message encoding
2) protocol binding
for all operations and messages defined in a given port type.
Each portType can have several binding elements associated with it.
Each binding specifies how to invoke operations using particular transport
protocols. For instance: SOAP over HTTP, SOAP over SMTP, etc.
e-Macao-16-5-310
Binding Element 2
The binding element has two attributes:
1) name - must be unique among all binding elements defined in the
WSDL document
2) type - identifies which portType the binding describes
e-Macao-16-5-311
Binding Example
<binding
name=TemperatureConverter_ServiceSOAPBinding
type=TemperatureConverter_Service
. . .
</binding>
Conventions:
1) the name of the binding is combined with:
a) the portType name (e.g.TemperatureConverter_Service),
b) the name of the protocol to which the binding maps (e.g.SOAP)
c) the word Binding
2) most WSDL documents contain only a single binding
relates the binding
with the portType
e-Macao-16-5-312
Binding Protocol
To which protocol is the portType mapped by the binding?
We need to inspect the definitions inside the binding element.
The definitions inside the binding element are standard WSDL extensions
that depends on the binding. WSDL specification describes extensions for:
1) SOAP/HTTP
2) HTTP GET/POST
3) SOAP with MIME attachments
Once the transport protocol is selected, find the WSDL convention that
corresponds to the pair and fill in the details.
Most web services define at least a SOAP binding.
e-Macao-16-5-313
SOAP Binding Protocol
The soap:binding element has two attributes:
1) style - specifies the communication style. The values include:
a) document operation is document-oriented; messages carry
documents that are agreed upon by the two applications
b) rpc operation is RPC-oriented; messages carry the input
parameters and return values of the procedure call
2) transport- specifies the communication protocol that is used to
transport the messages. The values include:
1) http://schemas.xmlsoap.org/soap/http
2) http://schemas.xmlsoap.org/soap/SMTP
3) http://schemas.xmlsoap.org/soap/ftp
4) other URI
e-Macao-16-5-314
SOAP Binding Protocol Example
This binding defines that the included operations will use a document-
oriented style and HTTP as the communication protocol.
<binding
name=TemperatureConverter_ServiceSOAPBinding
type= TemperatureConverter_Service >
<soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http />
. . .
</binding>
this declaration applies to the whole binding,
specifying that all operations defined will be
SOAP messages
e-Macao-16-5-315
Different Styles and Restrictions
1) if a portType references messages whose parts use the element
attribute, it should only use style=document
2) if a portType references messages whose parts use the type
attribute, only a style=RPC should be used.
e-Macao-16-5-316
Binding Protocol Operations
An operation element within a binding specifies the binding information for
that operation:
<operation name=FahrenheitToCelsius>
<soap:operation soapAction:urn:temperatureconverter-service/>
. . .
</operation>
The soap:operation element provides information for the operation:
1) soapAction attribute specifies the value of the soapAction in the
HTTP header for this operation.
e-Macao-16-5-317
Binding Protocol Encoding Rules
The binding also specifies the encoding rules used in serializing parts of a
message into XML:
1) literal encoding - takes the WSDL types defined in XML Schema
and literally uses those definitions to represent the XML content of
messages. Abstract WSDL types becomes concrete types
2) SOAP encoding - considers the XML Schema definitions as abstract
entities and translates them into XML using SOAP encoding rules
Literal encoding is used for document style interactions.
SOAP encoding is used for RPC style interactions.
One part of the message can be encoded literally in the header and other
part can use the SOAP encoding in the body.
e-Macao-16-5-318
Operation Encoding Example
<binding
name=TemperatureConverter_ServiceSOAPBinding
type= TemperatureConverter_Service>
<soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http />
<operation name=FarenheitToCelsius>
<soap:operation soapAction=urn:temperatureconverter-service />
<input>
<soap:body use=literal/>
</input>
<output>
<soap:body use=literal />
</output>
</operation>
</binding>
The content of the input and output messages are sent in the body of the
message. The content of the body is literally an XML element.
Only one part was defined for the input and output messages.
e-Macao-16-5-319
The input message that takes a data value 98.0, in the body of the message is
described below:
<?xml version=1.0 encoding=UTF-8?>
<soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi:http:// www.w3.org/2001/XMLSchema-instance>
<soapenv:Body>
<tempFarenheit xmlns=http://www/converter.com/TermperatureConverter>
98.0</tempFarenheit>
</soapenv:Body>
</soapenv:Envelope>
Binding Protocol Body Example
e-Macao-16-5-320
Task 50: SOAP Binding
Objective: Add the SOAP binding to MyExample.wsdl. The communication
style is document and messages are encoded literally.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and add the binding:
<wsdl:binding name=ErrorMailerSoap type=tns:ErrorMailerSoap >
<soap:binding
transport=http://schemas.xmlsoap.org/soap/http
style = document />
<wsdl:operation name=SendError>
<soap:operation
soapAction=http://example.com.ErrorMailer/SendError
style = document />
<wsdl:input> <soap:body use=literal /> </wsdl:input>
<wsdl:output> <soap:body use=literal /> </wsdl:output>
</wsdl:operation>
</wsdl:binding>
3) save the file
e-Macao-16-5-321
Port Element
The only purpose of the port element is to specify the network address of
the end-point hosting the web service.
port is a single end-point defined as a combination of a binding and a
network address.
There can be many ports for a binding, just like many implementations for
the same interface.
The soap:address element is used to give a port an address.
e-Macao-16-5-322
Port Example
<port
name=TemperatureConverter_ServicePort
binding=TemperatureConverter_ServiceSOAPBinding
<soap:address
location://localhost:8080/soap/servlet/TempConverter />
</port>
The name identifies the port.
reference to the binding
network address of the web service
e-Macao-16-5-323
Service Element
A service is a collection of ports.
Although a WSDL document can contain a collection of service elements,
by convention a WSDL document contains a single service.
Usage: group the ports that are related to the same service interface
(portType) but expressed by different protocols (binding).
e-Macao-16-5-324
Service Example
<service name=TemperatureConverter_Service>
<port
binding=TemperatureConverter_ServiceSOAPBinding
name=TemperatureConverter_ServicePort>
<soap:address
location://localhost:8080/soap/servlet/TempConverter />
</port>
<port> </port>
</service>
e-Macao-16-5-325
Task 51: Service and Ports
Objective: Add the service and port definitions to MyExample.wsdl. The
address of the service is: http://www.example.com/ErrorMailer/Errormail.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl adding the service and port definitions. The
location is
=http://www.example.com/ErrorMailer/Errormail
3) save the file
e-Macao-16-5-326
Documentation Element
The documentation element is used to provide useful, human-readable
information about the web service description.
Any WSDL element can contain a documentation element, usually as its
first child.
One conventional use is declaring that the WSDL file is an interoperable
description: it is compliant with the WS-I basic profile. This use of the
documentation element appears in the service element.
e-Macao-16-5-327
Documentation Example
<service name=TemperatureConverter_Service>
<port binding=TemperatureConverter_ServiceSOAPBinding
name=TemperatureConverter_ServicePort>
<documentation>
<wsi:Claim
conformsTo=http://ws-i.org/profiles/basic/1.0 />
</documentation>
<soap:address location://localhost:8080/soap/servlet/TempConverter />
</port>
</service>
e-Macao-16-5-328
Task 52: Documentation
Objective: Add documentation comments to MyExample.wsdl.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl adding a documentation element inside the service
definition.
3) save the file
e-Macao-16-5-329
Import Element
The import element is used to include other WSDL documents or XML
Schemas into a WSDL document.
The use of the import element allows to:
1) separate the different elements of a service definition into
independent documents
2) import these documents as needed
It helps writing clearer WSDL descriptions by separating the definitions
according to their level of abstraction and maximizing reusability.
For example, data structures modeled as XML Schemas can be imported by
several WSDL documents defining different services.
e-Macao-16-5-330
Import Example
<definitions
name= "TemperatureConverterService"
targetNamespace="http://www.converter.com/TemperatureConverter"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns=http://www.converter.com/TemperatureConverter
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<types>
<xsd:schema>
<import namespace=http://www.converter.com/schemas
location=http://converter.com/temperature.xsd"/>
</xsd:schema>
</types>
...
</definitions>
e-Macao-16-5-331
Import Conventional Use
Many designers split their WSDL design into two parts:
1) service interface definition
2) service implementation definition
Interface definition contains: types, message, portType and binding
elements and encapsulates the reusable components of a service
description.
Each organization wanting to implement a web service conformant to this
interface definition would describe an implementation definition containing
the port and service elements.
e-Macao-16-5-332
Interface versus Implementation
Service Interface
Definition
types
portType
message
binding
Service Implementation
Definition
import
service
port
reusable part
e-Macao-16-5-333
WSDL Outline
1) Introduction
2) The Language
a) structure
b) definitions
c) types
d) message
e) part
f) port type
g) operation
h) binding
i) port
j) service
k) documentation
l) import
3) Transmission Primitives
a) one way
b) request-response
c) notification
d) solicit-response
4) WSDL Extensions
a) functional extensions
b) non-functional extensions
5) WSDL and Java
6) Summary
e-Macao-16-5-334
Transmission Primitives 1
WSDL supports four basic operation patterns called transmission primitives:
The service sends a message.
The operation has a single output element.
Notification
The service sends a message and receives a response.
The operation has one output element and one input
element.
To encapsulate errors fault element can also be specified.
Solicit-Response
The service receives a message and sends a response.
The operation has one input and one output element.
To encapsulate errors fault elements can be specified.
Request-Response
The service receives a message.
The operation has a single input element.
One way
e-Macao-16-5-335
Transmission Primitives 2
[Courtesy Ethan Cerami]
e-Macao-16-5-336
Web Service Examples
Four different examples will be explained, one for each transmission
primitive.
All examples are related to a virtual organization providing informational
services about weather to its subscribed users.
e-Macao-16-5-337
WS Example One Way
1) CancelUser - a message is received asking to cancel the subscription
service for a user.
a) input message contains user identification and password
e-Macao-16-5-338
WS Example Request-Response
2) AskData - a user request for information related to the weather in a
particular city and for a date, and receives a response.
a) input message contains user identification, city and date
b) output message contains temperature and humidity
e-Macao-16-5-339
WS Example Solicit-Response
3) ServiceInterruption - the service provider notifies a user that the
service will be interrupted and waits for a response
a) output message contains notification
b) input message contains acknowledgement
e-Macao-16-5-340
WS Example Notification
4) NotifyBadWeather - the service provider sends a notification to a
user when bad weather is forecast in a city where the user lives
a) output message contains temperature, humidity and notification
e-Macao-16-5-341
WS Example Definitions
WSDL document structure:
<?xml version=1.0?>
<definitions name=WeatherServices
targetNamespace=http://www.example.com/WeatherService
xmlns=http://schemas.xmlsoap.org/wsdl/
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns:tns=http://www.example.com/WeatherService
xmlns:xsd=http://www.w3.org/2001/XMLSchema >
<types>
...
</types>
...
...
</definitions>
It will be reused for all four examples.
e-Macao-16-5-342
WS Example Types 1
Types for all four weather examples:
<types>
<xsd:schema
targetNamespace="http://www.example.com/WeatherService
<xsd:import namespace=http://schemas.xmlsoap.org/soap/encoding/
schemaLocation= =http://schemas.xmlsoap.org/soap/encoding/ />
<xsd:element name=notification type=xsd:string />
<xsd:element name=acknowledge type=xsd:string />
<xsd:element name=errorString type=xsd:string />
<xsd:complexType name=userData>
<xsd:sequence>
<xsd:element name=userId type=xsd:string />
<xsd:element name=password type=xsd:string />
</xsd:sequence>
</xsd:complexType>
e-Macao-16-5-343
WS Example Types 2
<xsd:complexType name=dataRequest>
<xsd:sequence>
<xsd:element name=city type=xsd:string />
<xsd:element name=date type=xsd:dateTime />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=weatherData>
<xsd:sequence>
<xsd:element name=temperature type=xsd:float />
<xsd:element name=humidity type=xsd:float />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</types>
...
</definitions>
e-Macao-16-5-344
One-Way Operations
A one-way operation has only an input message. It acts like a data sink.
No response message (output or fault) going back to the requestor.
Basic functionality - change the state of the service provider
Many one-way messages at this level end up being request-response
messages at the network transport level (response is the HTTP-level
acknowledgement).
For a one-way operation, the HTTP response must not contain a SOAP
envelope. Most clients will ignore it if it does appear.
e-Macao-16-5-345
One Way Example 1
Service Example: CancelUser - a message is received asking to cancel the
subscription service for a user.
<message name=cancelUser>
<part name=userCancel type=tns:userData />
</message>
<portType name=cancelUserPortType>
<operation name=cancelUser>
<input message=tns:cancelUser />
</operation>
</portType>
<binding name=CancelUserSOAPBinding
type=tns:cancelUserPortType>
<soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http />
e-Macao-16-5-346
One Way Example 2
<operation name=cancellation>
<soap:operation
soapAction= http://www.example.com/WeatherService/cancel />
<input>
<soap:body use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</input>
</operation>
</binding>
<service name=CancelUser>
<port name=CancelUser
binding=CancelUserSOAPBinding>
<soap:address
location=http://www.example.com/WeatherService />
</port>
</service>
</definitions>
e-Macao-16-5-347
Request-Response Operations
The most common form of operation because many web services are
deployed using SOAP over HTTP.
Defines:
1) input message (request)
2) output message (response)
3) optional collection of fault messages
Basic functionality:
1) retrieve information about a web service object
2) change the state of the service provider
3) include information about the new state in the response
Like input and output elements, the fault element refers to a message which
describes the data contents of the fault.
e-Macao-16-5-348
Request Response Example 1
Service Example: AskData - a user request for information related to the
weather in a particular city and for a date, and receives a response.
<message name=askDataRequest>
<part name=userIdent element=tns:userID />
<part name=userRequestData type=tns:dataRequest />
</message>
<message name=askDataResponse>
<part name=cityDateWeatherData type=tns:weatherData />
</message>
<message name=askDataLoginError>
<part name=errorString element=xsd:string />
</message>
<message name=askDataDataError>
<part name=errorString element=xsd:string />
</message>
fault messages
must have a
single part
e-Macao-16-5-349
Request Response Example 2
<portType name=askDataPortType>
<operation name=askData>
<input message=tns:askDataRequest />
<output message=tns:askDataResponse />
<fault message=tns:askDataLoginError
name=HeaderErrorMessage />
<fault message=tns:askDataDataError
name=BodyErrorMessage />
</operation>
</portType>
e-Macao-16-5-350
Request Response Example 3
<binding name=AskDataSOAPBinding
type=tns:askDataPortType>
<soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http />
<operation name=askData>
<soap:operation
soapAction= http://www.example.com/WeatherService/askData />
<input>
<soap:header message=tns:askDataRequest part=userIdent
use=literal >
<soap:headerfault message=tns:HeaderErrorMessage
part=errorString use=literal />
</soap:header>
<soap:body parts=userRequestData use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</input>
a part of the input
message on the header
best practice
e-Macao-16-5-351
Request Response Example 4
<output>
<soap:body use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</output>
<fault name=BodyErrorMessage>
<soap:fault name=BodyErrorMessage
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</fault>
</operation>
</binding>
<service name=AskData>
<port name=AskData
binding=AskDataSOAPBinding>
<soap:address
location=http://www.example.com/WeatherService />
</port>
</service>
</definitions>
e-Macao-16-5-352
Solicit-Response Operations
A solicit-response operation models a push operation similar to a notification.
It expects an input (response) from the service requestor.
Defines:
1) output message (solicit)
2) optional fault messages (solicit)
3) input message (response)
Basic functionality:
1) notify the service requestor about the result of some event by the
service provider
2) waits for an answer from the service requestor
e-Macao-16-5-353
Solicit Response Example 1
Service Example: ServiceInterruption - the service provider notifies
a user that the service will be interrupted and waits for a response
<message name=serviceInterruptionSolicit>
<part name=interruptionComment element=tns:notification />
</message>
<message name=serviceInterruptionResponse>
<part name=userAcknowledge element=tns:acknowledge />
</message>
<portType name=serviceInterruptionPortType>
<operation name=serviceInterruption>
<output message=tns:serviceInterruptionSolicit />
<input message=tns:serviceInterruptionResponse />
</operation>
</portType>
e-Macao-16-5-354
Solicit Response Example 2
<binding name=ServiceInterruptionSOAPBinding
type=tns:serviceInterruptionPortType>
<soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http />
<operation name=serviceInterruption>
<soap:operation
soapAction=http://www.example.com/WeatherService/Interruption/>
<input>
<soap:body use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</input>
<output>
<soap:body use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</ouput>
</operation>
</binding>
e-Macao-16-5-355
Solicit Response Example 3
<service name=ServiceInterruption>
<port name=ServiceInterruption
binding=ServiceInterruptionSOAPBinding>
<soap:address
location=http://www.example.com/WeatherService />
</port>
</service>
</definitions>
e-Macao-16-5-356
Notification Operations
A notification operation is like a one-way operation, but the message is
pushed by the service provider.
Output messages are pushed to the service requestor as the result of an
event occurring on the service provider side, such as: time-out or operation
completion.
Basic functionality - notify the service requestor about an event.
The notification style of interaction is commonly used in systems built around
asynchronous messaging.
It is not possible to describe the semantic of these operations in WSDL
(where to push the messages) without extensions, except by text
comments.
To ensure interoperability of web services, the use of notifications is not
recommended.
e-Macao-16-5-357
WS-Notification Example 1
Service Example: NotifyBadWeather - the service provider sends a
notification to a user when bad weather is forecast in a city where the user
lives
<message name=notifyBadWeather>
<part name=notifyWeatherData type=tns:weatherData />
<part name=notifyCommnent element=tns:notification />
</message>
<portType name=notifyBadWeatherPortType>
<operation name=notifyBadWeather>
<output message=tns:notifyBadWeather />
</operation>
</portType>
<binding name=NotifyBadWeatherSOAPBinding
type=tns:notifyBadWeatherPortType>
<soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http />
e-Macao-16-5-358
<operation name=notifyBadWeather>
<output>
<soap:body use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</output>
</operation>
</binding>
<service name=NotifyBadWeather>
<port name=NotifyBadWeather
binding=NotifyBadWeatherSOAPBinding>
<soap:address
location=http://www.example.com/WeatherService />
</port>
</service>
</definitions>
WS-Notification Example 2
e-Macao-16-5-359
Operation Default Names
OPSolicit OPResponse Solicit-Response
OP not applicable Notification
OPResponse OPRequest Request-Response
not applicable OP One-Way
Output Input
Default names for input and output elements for an operation OP:
Fault elements require a name, because several fault elements can be
associated with any operation and the fault name is used to distinguish
among them.
e-Macao-16-5-360
Operation Parameter Order
Operations using an RPC-binding can specify a list of parameter names via
the parameterOrder attribute.
The value of this attribute is a space-separated list of message part names
with the following rules:
1) the order reflects the order of parameters in the RPC signature
2) the return value is not present in the list
3) if a part name appears in both input and output messages, it is an
input/output parameter
4) if a part name appears in only the input message, it is an input
parameter
5) if a part name appears in only the output message, it is an output
parameter
e-Macao-16-5-361
Parameter Order Example
<message name=input">
<part name="A" element="xsd:int"/>
<part name="B" element="xsd:long"/>
</message>
<message name=output">
<part name="A" type="xsd:int"/>
</message>
<portType name=servicePortType">
<operation name=example" parameterOrder="B A">
<input message="tns:input"/>
<output message="tns:output"/>
</operation>
</portType>
e-Macao-16-5-362
WSDL Outline
1) Introduction
2) The Language
a) structure
b) definitions
c) types
d) message
e) part
f) port type
g) operation
h) binding
i) port
j) service
k) documentation
l) import
3) Transmission Primitives
a) one way
b) request-response
c) notification
d) solicit-response
4) WSDL Extensions
a) functional extensions
b) non-functional extensions
5) WSDL and Java
6) Summary
e-Macao-16-5-363
Functional Extensions
The WSDL language allows most of the WSDL elements to be extended with
elements from other namespaces.
The language specification defines standard extensions for:
1) SOAP
2) HTTP GET/POST operations
3) MIME attachments
SOAP was already explained.
e-Macao-16-5-364
WSDL HTTP Extension
The HTTP binding extends WSDL with the following elements:
<binding .... >
<http:binding verb="nmtoken"/>
<operation .... >
<http:operation location="uri"/>
<input .... >
<-- mime elements -->
</input>
<output .... >
<-- mime elements -->
</output>
</operation>
</binding>
<port .... >
<http:address location="uri"/>
</port>
WSDL
extensions
e-Macao-16-5-365
HTTP Binding
The http:binding element indicates that this binding uses HTTP.
<definitions .... >
...
<binding .... >
<http:binding verb="nmtoken"/>
</binding>
...
</definitions>
The value of the required verb attribute may be GET or POST, or others
HTTP requests.
e-Macao-16-5-366
HTTP Operation
An operation element within a binding specifies the binding information for
that operation.
The location attribute specifies a relative URI for the operation.
This URI is combined with the URI specified in the http:address element
(port definition) to form the full URI for the HTTP request.
The URI value must be a relative URI.
<binding .... >
<operation .... >
<http:operation location="uri"/>
</operation>
</binding>
e-Macao-16-5-367
HTTP urlEncoded
The urlEncoded element indicates that all message parts are encoded
into the HTTP request URI using the standard URI-encoding rules.
The names of parameters correspond to the names of the message parts.
Each value contributed by the part is encoded using a name=value pair.
This may be used with GET to specify URL encoding.
For GET, "?" character is automatically appended as necessary.
<http:urlEncoded/>
http://www.example.com/WeatherService/askData?userId=2289193
e-Macao-16-5-368
HTTP urlReplacement
The urlReplacement element indicates that all message parts are
encoded into the HTTP request URI using a replacement algorithm:
1) The relative URI value of http:operation is searched for a set of
search patterns.
2) The search occurs before the value of the http:operation is
combined with the value of the location attribute from http:address.
3) There is one search pattern for each message part. The search
pattern string is the name of the message part surrounded with
parenthesis.
4) For each match, the value of the corresponding message part is
substituted for the match at the location of the match.
5) Matches are performed before any values are replaced; replaced
values do not trigger additional matches.
Message parts MUST NOT have repeating values.
<http:urlReplacement/>
e-Macao-16-5-369
HTTP mime:content
The mime:content elements attribute type=valid_type indicates
that the message will appear in the HTTP code as the valid_type.
Examples:
1) the message is XML text in the HTTP response:
<output>
<mime:content type=text/xml />
</output>
2) the message is send as a gif file:
<output>
<mime:content type="image/gif"/>
</output>
e-Macao-16-5-370
HTTP Address
The location attribute of the http:address element specifies the base
URI for the port.
The value of the attribute is combined with the values of the location
attribute of the http:operation binding element.
<port name=...>
<http:address location=URI />
</port>
e-Macao-16-5-371
HTTP Binding Example
<binding name=AskDataHTTPBinding
type=tns:askDataPortType>
<http:binding verb=GET/>
<operation name=askData>
<http:operation location= askData />
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type=text/xml/>
</output>
</operation>
</binding>
<service name=AskData>
<port name=AskData
binding=AskDataHTTPBinding>
<http:address
location=http://www.example.com/WeatherService />
</port>
</service>
e-Macao-16-5-372
Task 53: HTTP/GET Binding
Objective: Add the HTTP/GET binding to MyExample.wsdl. The location is
/SendError, the verb is GET and the message parts in the HTTP request
are encoded.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and add the ErrorMailerHttpGet binding
3) save the file
e-Macao-16-5-373
Task 54: Port for HTTP Binding
Objective: Add the port definition of the service for the HTTP/GET binding, to
MyExample.wsdl. The location is:
http://www.example.com/ErrorMailer/Errormail.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and add the port definition and the final tag of the
definitions element
3) save the file
e-Macao-16-5-374
Functional Extensions
The WSDL language allows most of the WSDL elements to be extended with
elements from other namespaces.
The language specification defines standard extensions for:
1) SOAP
2) HTTP GET/POST operations
3) MIME attachments
SOAP and HTTP were already explained.
e-Macao-16-5-375
WSDL MIME Extension
WSDL also supports a standard extension to describe message parts as
MIME.
This extension could be used to include a GIF image as part of a message.
Example: we would like to add a map in a graphical file when sending data
about the weather.
The response message must include the new part:
<message name=askDataResponse>
<part name=cityDateWeatherData type=tns:weatherData />
<part name=weatherpicture type=xsd:binary />
</message>
e-Macao-16-5-376
WSDL with MIME 1
MIME extensions are only for the binding, indicating that the output is
modeled as multipart MIME.
<binding name=AskDataSOAPBinding
type=tns:askDataPortType>
<soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http />
<operation name=askData>
<soap:operation
soapAction= http://www.example.com/WeatherService/askData />
<input>
<soap:header message=tns:askDataRequest part=userIdent
use=literal >
<soap:headerfault message=tns:HeaderErrorMessage
part=errorString use=literal />
</soap:header>
<soap:body parts=userRequestData use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</input>
no changes
e-Macao-16-5-377
WSDL with MIME 2
<output>
<mime:multipartRelated>
<mime:part>
<soap:body use=encoded />
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</mime:part>
<mime:part>
<mime:content part=weatherpicture type=image/gif />
<mime:content part=weatherpicture type=image/jpeg />
</mime:part>
</mime:multipartRelated>
</output>
<fault name=BodyErrorMessage>
<soap:fault name=BodyErrorMessage
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</fault>
</output>
</binding>
changes
e-Macao-16-5-378
Task 55: WSDL Example 1
Objective: Access to a complete WSDL document published on the web.
1) browse: http://www.errormail.net/EM/ErrorMailer.asmx?wsdl
2) analyze the document
e-Macao-16-5-379
Task 56: WSDL Example 2
Objective: Access the WSDL document of FileDownloadService.
1) start Tomcat
2) browse: http://localhost:8080/axis
3) access: view FileDownloadService (wsdl)
4) analyze the document
e-Macao-16-5-380
Non-Functional Descriptions
How to describe:
a) security requirements
b) transactional capabilities
c) logging features for the invocation of the service
d) auditing realized by the service provider
Non-functional characteristics of a web service can be described using WS-
Policy and related specifications.
e-Macao-16-5-381
WS-Policy
WS-Policy version 1.0 was originally published in December 2002, by BEA,
IBM, Microsoft, and SAP.
In May 2003, version 1.1 was published.
The WS-Policy family of specifications has three major components:
1) framework
2) assertions
3) attachment
The basic component of the policy framework is a policy assertion.
e-Macao-16-5-382
Policy Assertion
Policy assertion is a concrete statement about requirements, preferences,
capabilities and other characteristic of a web service or its operating
environment.
Policy assertions describe certain qualities of service such as reliability of
messaging or security aspects.
A policy assertion may be a simply statement of fact:
<wsrm:DeliveryAssurance Value=wsrm:ExactlyOnce/>
Also, a policy assertion may be a complicated statement, indicating possible
sets of requestor-specifiable parameters, etc.
Policy assertions are grouped together to form a policy.
e-Macao-16-5-383
Policy Assertion Example
Two policy assertions are specified:
<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
1) the subject requires a Kerberos V5 service ticket token
<wsse:SecurityToken wsp:Usage="wsp:Required">
<wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
</wsse:SecurityToken>
2) an XML digital signature is required
<wsse:Integrity wsp:Usage="wsp:Required">
<wsse:Algorithm Type="wsse:AlgSignature"
URI="http://www.w3.org/2000/09/xmlenc#aes" />
</wsse:Integrity>
</wsp:Policy>
e-Macao-16-5-384
Policy and Policy Subject
A policy forms a named collection of policy assertions that can be referenced
using standard XML mechanisms, by other XML and Web service
components such as a WSDL definition.
One mechanism to reference a policy is to associate a policy with a policy
subject.
A policy subject can be:
1) web service
2) component of a web service description
3) part of a web services operating environment
4) other entities related to a web service
WS-PolicyAttachments specification describes how to associate policies with
policy subjects.
e-Macao-16-5-385
Policy and Policy Subjects
Policy Assertion
Policy Assertion
Policy Assertion
Policy
Policy
Subject
isAttached
e-Macao-16-5-386
WS-Policy Framework
WS-Policy defines how to group policy assertions into a named collection
that can be referenced by other components.
WS-Policy framework consists of:
1) an XML element to act as a container for one or more policy
assertions
2) a set of XML elements that describe how the policy assertions
grouped by the container are to be combined
3) a set of standard XML attributes that may be associated with policy
assertions
e-Macao-16-5-387
Policy Container
General Form:
<wsp:Policy ((name=... TargetNamespace= ...) | Id=...) >
<policy-specific assertion>
...
<policy-specific assertion>
<policy-specific security>
</wsp:Policy>
Defines:
1) the policy name
2) policy assertions
3) security policy assertions specific to this policy element
It is assumed that policy assertions are completely independent
Policy operators are needed to provide semantics to policy assertions
e-Macao-16-5-388
Policy Name
Two standard mechanisms to name a policy:
1) by XML QName
<wsp:Policy name=... TargetNamespace= ... >
2) by URI combined with the XML base of the document
<wsp:Policy xml:base=http://example.com Id=Pol1>
The URI will be: http://example.com#Pol1
One mechanism should be chosen and followed through all the policy work.
e-Macao-16-5-389
Policy Operators
Four operators exists to describe different combinations of policy
assertions:
1) All
2) ExactlyOne
3) OneOrMore
4) the basic policy element
e-Macao-16-5-390
Policy Operators Example 1
The following example:
1) defines a policy named Example1 in http://example.com namespace
2) states that all assertions A,B, and C are in effect
<wsp:Policy
name=Example1
TargetNamespace=http://example.com >
<wsp:All>
<Assertion A/>
<Assertion B/>
<Assertion C/>
</wsp:All>
</wsp:Policy>
For a policy assertion to be in effect is entirely dependent on the domain of
each policy assertion and the policy subject to which the policy is attached
e-Macao-16-5-391
Policy Operators Example 2
The following example:
1) defines a policy named Example2 in http://example.com namespace
2) states that exactly one of the assertions A,B, and C is in effect
<wsp:Policy
name=Example2
TargetNamespace=http://example.com >
<wsp:ExactlyOne>
<Assertion A/>
<Assertion B/>
<Assertion C/>
</wsp:ExactlyOne>
</wsp:Policy>
Operators can be nested any of the assertion elements can be replaced
by an operator.
e-Macao-16-5-392
Policy Attributes
WS-Policy framework provides a pair of global XML attributes : Usage and
Preference
These attributes can be added to the various policy assertions.
e-Macao-16-5-393
Usage Attribute
Usage describes how the policy assertion is to be interpreted in the context
of the policy. Possible values:
1) Required: the assertion must apply or an error occurs
2) Rejected: the assertion must not apply or an error occurs
3) Optional: the assertion may apply or may not apply
4) Observed: let the requestor know that a particular assertion will be
applied
5) Ignored: tell the requestor that if something happens to cause the
policy assertion to be in effect then no error message will be emitted
e-Macao-16-5-394
Usage Attribute Example
This policy specifies that assertion A must apply, assertion B must not apply,
and assertion C may or may not apply.
<wsp:Policy
name=Example3
TargetNamespace=http://example.com >
<wsp:ExactlyOne>
<Assertion A wsp:Usage=Required/>
<Assertion B wsp:Usage=Rejected />
<Assertion C wsp:Usage=Optional />
</wsp:ExactlyOne>
</wsp:Policy>
e-Macao-16-5-395
Preference Attribute
This attribute is used in conjunction with the ExactlyOne operator.
If there is a choice between a set of policy assertions, this value acts as a
hint to the requestor.
The value is integer. The higher the number, the stronger the preference.
e-Macao-16-5-396
Preference Attribute Example
This policy specifies that the requestor has a choice of assertions A, B, and
C, and that the service provider would much prefer the requestor to choice
assertion A.
<wsp:Policy
name=Example3
TargetNamespace=http://example.com >
<wsp:ExactlyOne>
<Assertion A wsp:Preference=100/>
<Assertion B wsp:Preference=50 />
<Assertion C wsp:Preference=10 />
</wsp:ExactlyOne>
</wsp:Policy>
e-Macao-16-5-397
Policy Example
This policy indicates that the subject requires exactly one security token,
either a UsernameToken, x509 security token or Kerberos.
<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
<wsp:ExactlyOne wsp:Usage="Required">
<wsse:SecurityToken>
<wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
</wsse:SecurityToken>
<wsse:SecurityToken wsp:Preference="10">
<wsse:TokenType>wsse:x509v3</wsse:TokenType>
</wsse:SecurityToken>
<wsse:SecurityToken wsp:Preference="1">
<wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
</wsse:SecurityToken>
</wsp:ExactlyOne>
</wsp:Policy>
The preference values indicate that the preferred token type is x509,
followed by Kerberos, followed by UsernameToken.
e-Macao-16-5-398
Referencing Policies
WS-Policy defines PolicyReference elements that allows to include the
contents of one policy in another.
The PolicyReference element can appear anywhere a policy assertion
can appear, and it refers to another policy.
The meaning is that the contents of the included policy element are wrapped
with an All operator element and inserted in the place of the reference.
e-Macao-16-5-399
Referencing Policies Example 1
Consider this policy specification:
<wsp:Policy
name=Example4
TargetNamespace=http://example.com
xmlns:tns=http://www.example.com/policies >
<wsp:ExactlyOne>
<wsp:PolicyReference Ref=tns:Example2 />
<Assertion X />
<Assertion Y />
</wsp:ExactlyOne>
</wsp:Policy>
e-Macao-16-5-400
Referencing Policies Example 2
It is equivalent to:
<wsp:Policy
name=Example4
TargetNamespace=http://example.com
xmlns:tns=http://www.example.com/policies >
<wsp:ExactlyOne>
<wsp:All>
<wsp:ExactlyOne>
<Assertion A/>
<Assertion B/>
<Assertion C/>
</wsp:ExactlyOne>
</wsp:All>
<Assertion X />
<Assertion Y />
</wsp:ExactlyOne>
</wsp:Policy>
Only one of assertions A, B, C, X or Y must be in effect.
<wsp:Policy name=Example2 ...>
<wsp:ExactlyOne>
<Assertion A/>
<Assertion B/>
<Assertion C/>
</wsp:ExactlyOne>
</wsp:Policy>
e-Macao-16-5-401
Different Policy Assertions
Discipline-specific - policy assertions selected, configured and combined into
a policy document, such as:
1) security policy assertions,
2) reliability policy assertions,
3) etc.
Generic assertions - four standard policy assertions defined by WS-Policy in
a separate specification called WS-PolicyAssertions
e-Macao-16-5-402
Generic Policy Assertions
Four generic policy assertions:
1) text encoding - declares which character set is used for text that appears
in web service messages
2) language assertion - declares the human language expected in
messages
3) spec assertion - declares which version of a particular technical
specification a web service is compliant with
4) message predicate - declares the exact content of a message going into
or coming out of a web service. The contents are defined using the
XPath language.
e-Macao-16-5-403
Message Predicate Example
This policy requires:
1) exactly one wsse:Security header element, and
2) exactly one child element within the soap:Body element
<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
<wsp:MessagePredicate wsp:Usage="wsp:Required">
count(wsp:GetHeader(.)/wsse:Security) = 1
</wsp:MessagePredicate>
<wsp:MessagePredicate wsp:Usage="wsp:Required">
count(wsp:GetBody(.)/*) = 1
</wsp:MessagePredicate>
...
</wsp:Policy>
e-Macao-16-5-404
Task 57: Policy
Objective: Write a policy MyPolicy specifying that messages must be sent
using UTF-8 encoding, SOAP 1.2, and optionally a digital signature.
1) cd \demos\WSDL\Example1
2) create MyPolicy.xml for the specified requirements, using the following
namespaces:
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext
e-Macao-16-5-405
Policy Attachments
A policy can be attached to a policy subject, such as WSDL portType,
WSDL message, UDDI elements or others.
A policy can be attached to a policy subject in two ways:
1) as part of the subjects definition
2) external to the subjects definition
e-Macao-16-5-406
Policy Attachment Example 1
Suppose we want to declare that the language expected for a web service
can be English, Chinese or Spanish:
<wsp:Policy name = WeatherLanguages
TargetNamespace = http://www.example.com/policies >
<wsp:OneOrMore>
<wsp:Language Language=en />
<wsp:Language Language=cn />
<wsp:Language Language=es />
</wsp:OneOrMore>
</wsp:Policy>
e-Macao-16-5-407
Policy Attachment Example 2
The policy can be referenced from within the AskData service declaration,
using the PolicyRefs attribute:
<service name=AskData
wsp:PolicyRefs=pol:WeatherLanguages
xmlns:wsp=http://schemas.xmloap.org/ws/2002/12/policy
xmlns:pol=http://www.examples.com/policies>
<port name=AskData binding=AskDataSOAPBinding>
<soap:address
location=http://www.example.com/WeatherService />
</port>
</service>
</definitions>
The policyRefs attribute takes a list of QNames allowing to associate a
collection of policies to any policy subject.
The policyURIs attribute provides the same functionality allowing to
associate a collection of policies identified by URI with any policy subject.
e-Macao-16-5-408
Task 58: Policy Attachment
Objective: Attach MyPolicy to the Error Mail Service.
1) cd \demos\WSDL\Example1
2) edit MyExample.wsdl and below the service definition, add the reference
to the policy
3) save the file
e-Macao-16-5-409
Effective Policy
A policy attached to a WSDL element can be inherited by its child elements.
For instance, a policy attached to a portType would be inherited by its
input, output and fault child elements.
Effective policy is the policy associated with a WSDL element. It can be an
inherited policy or a policy directly attached to the element.
e-Macao-16-5-410
Policy Inheritance in WSDL 1
similar to input
portType/operation/fault
similar to input
portType/operation/output
policy associated with input, merged with the
effective policy of the inputs operation parent
and with the effective policy of the message
associated with the input element
portType/operation/input
policy associated with operation, merged with the
effective policy of the operations portType
parent
portType/operation
policy associated with portType
portType
policy associated with part, merged with the
effective policy of the parts message parent
message/part
policy associated with message
message
Effective Policy WSDL Element
e-Macao-16-5-411
Policy Inheritance in WSDL 2
policy associated with the port merged with the
effective policy of the ports service parent
service/port
policy associated with the service
service
similar to input
portType/operation/fault
similar to input
binding/operation/output
policy associated with the input merged with the
effective policy of the inputs operation parent
and merged with the effective policy of the
corresponding portType/operation/input
binding/operation/input
policy associated with the operation merged with
the effective policy of the operations binding
parent and merged with the effective policy of the
portType operation
binding/operation
policy associated with the binding merged with the
effective policy of the associated portType
binding
Effective Policy WSDL Element
e-Macao-16-5-412
External Policy Attachment 1
Allows policies to be associated with a policy subject independent of that
subject's definition and/or representation through the use of a
PolicyAttachment element.
The PolicyAttachment element has three components:
1) the policy scope of the attachment
2) the policy expressions being bound
3) security information (optional)
e-Macao-16-5-413
External Policy Attachment Example
<wsp:PolicyAttachment ... >
<wsp:AppliesTo>
<x:DomainExpression/> +
</wsp:AppliesTo>
( <wsp:Policy>...</wsp:Policy> |
<wsp:PolicyReference>...</wsp:PolicyReference> ) +
<wsse:Security>...</wsse:Security> ?
...
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference
xmlns:ad="http://www.example.com/WeatherService" >
<wsa:Address>http://www.example.com/WeatherService/askData
</wsa:Address>
<wsa:PortType>ad:askDataPortType</wsa:PortType>
<wsa:ServiceName>ad:AskData</wsa:ServiceName>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:PolicyReference URI="http://www.example.com/policies#ASKDATAPOL"/>
</wsp:PolicyAttachment>
policy scope
policy expressions
security information
e-Macao-16-5-414
WSDL: Outline
1) Introduction
2) The Language
a) structure
b) definitions
c) types
d) message
e) part
f) port type
g) operation
h) binding
i) port
j) service
k) documentation
l) import
3) Transmission Primitives
a) one way
b) request-response
c) notification
d) solicit-response
4) WSDL Extensions
a) functional extensions
b) non-functional extensions
5) WSDL and Java
6) Summary
e-Macao-16-5-415
WSDL Mapping to Java
Many tools maps WSDL to Java, both sides:
1) service requestor
2) service provider.
For instance: the Axis WSDL2Java tool.
Some conventions are defined for mapping:
1) portTypes
2) operations
3) messages
4) bindings
e-Macao-16-5-416
portType to Java
1) the portType naturally maps into a Java Interface
2) the name of the interface typically takes the name of the portType
3) the file is declared in a package named from the targetNamespace URI
of the WSDL definitions element containing the portType
e-Macao-16-5-417
portType to Java Example
The WeatherService.wsdl where the portType AskData was defined,
include:
<?xml version=1.0?>
<definitions name=WeatherServices
targetNamespace=http://www.example.com/WeatherService
Thus a piece of the Java Interface for the AskData PortType is:
Package com.example.www.WeatherService.AskData;
Public interface AskDataPortType extends java.rmi.Remote {
e-Macao-16-5-418
Operation to Java
1) for each of the portTypes operations, a public method is declared as
part of the interface
2) the signature of the method is built from:
a) the name of the operation
b) the input and output values defined in the operation
c) any fault element associated with the operation are included as
exceptions thrown by the method.
e-Macao-16-5-419
The method signature generated from the askData operation defined in
askDataPortType is:
public com.example.www.WeatherService.cityDateWeatherData
askData (com.example.www.WeatherService.userID uid,
com.example.www.WeatherService.dataRequest uRequestData)
throws java.rmi.RemoteException;
Operation to Java Example
e-Macao-16-5-420
Message to Java
1) for those messages that are referenced by input and output
elements, a class is generated for complexTypes referenced by the
parts of those messages
2) a class is generated for those messages referenced in fault elements.
3) the name of the class is taken from the name of the type or element
4) the package from the class is taken from the targetNamespace URI of
the XML schema that defines the type or element.
These type-based classes are used as part of the mechanism to serialize
and deserialize XML to and from Java.
e-Macao-16-5-421
Message to Java Example
Input element:
<input>
<soap:header message=tns:askDataRequest part=userIdent
use=literal >
<soap:headerfault message=tns:HeaderErrorMessage
part=errorString use=literal />
</soap:header>
<soap:body parts=userRequestData use=encoded
namespace=http://www.example.com/WeatherService
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ />
</input>
Classes in Java:
1) userId
2) dataRequest
3) fault
defined in package: com.example.www.WeatherService
e-Macao-16-5-422
Binding to Java
1) each binding is generated as a stub class
2) the name of the class is the name of the binding
3) the targetNamespace of the definitions element is used to define
the name of the package
4) this class implements the interface defined by portType
This class is a proxy to the service encapsulates the implementation
details associated with how a given portType is made concrete by the
binding.
e-Macao-16-5-423
Binding to Java Example
<binding name=AskDataSOAPBinding
type=tns:askDataPortType>
<soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http />
<operation name=askData>
. . .
A class called AskDataSOAPBindingImpl is defined.
Implements the interface defined by the portType askDataPortType.
e-Macao-16-5-424
Service to Java
The WSDL service also generates an interface and class.
They encapsulate details of invoking the service from the client application.
e-Macao-16-5-425
WSDL Outline
1) Introduction
2) The Language
a) structure
b) definitions
c) types
d) message
e) part
f) port type
g) operation
h) binding
i) port
j) service
k) documentation
l) import
3) Transmission Primitives
a) one way
b) request-response
c) notification
d) solicit-response
4) WSDL Extensions
a) functional extensions
b) non-functional extensions
5) WSDL and Java
6) Summary
e-Macao-16-5-426
WSDL Summary 1
WSDL is an XML-based language for describing and accessing web
services.
WSDL describes four pieces of critical data:
1) data type declarations for all requests and response messages
2) interfaces describing available functions
3) binding information about the transport protocol
4) address information for locating the service
e-Macao-16-5-427
WSDL Summary 2
The service description is an XML document where the root element called
definitions may include the following elements:
1) types - user-defined types and elements used in messages
2) message - composed of parts, describes data exchanged
3) portType - collection of related operations describing a WS
interface
4) binding - specification of how to format messages in a protocol-
specific manner
5) service - a collection of ports specifying network addresses of the
end-points hosting the web service
6) documentation - human-readable information about the WS
7) import - including other WSDL documents or XML Schemas
documents
e-Macao-16-5-428
WSDL Summary 3
Conventional use of WSDL includes:
1) Service interface definition:
a) types
b) message
c) portType
d) binding
2) Service implementation definition:
a) service and port
e-Macao-16-5-429
WSDL Summary 4
WSDL supports four patterns of operation called transmission primitives:
1) one way - only an input message
2) request-Response - input-output messages and optional faults
3) notification - only an output message
4) solicit-Response - output-input messages and optional faults
e-Macao-16-5-430
WSDL Summary 5
WSDL provides functional extensions for:
1) SOAP
2) HTTP GET/POST operations
3) MIME attachments
e-Macao-16-5-431
WSDL Summary 6
Non-functional aspects of a web service can be specified using WS-Policy
and related specifications:
1) A policy assertion describes certain aspects of a service quality: reliability,
security, etc.
2) Policy assertions are grouped to form a policy.
3) WS-Policy also specifies how policies can be referenced by other
components.
4) A policy can be attached to a subject, such as: WSDL portType and
message, UDDI elements, or others in two ways:
a) as part of the subject definition
b) external to the subject definition using WS-PolicyAttachments
AXIS
e-Macao-16-5-433
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-434
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-435
Axis Overview
Axis is a SOAP engine.
Axis consists of several subsystems working together for processing
messages.
The Axis engine invokes in sequence a series of handlers to process
messages.
The order in which handlers are invoked is determined by:
1) deployment configuration
2) whether the engine is a client or a server
e-Macao-16-5-436
Axis History
IBM contributed with an early implementation of the SOAP protocol to Apache
in 1999, known as Apache SOAP.
This implementation was based on SOAP4J and was written in a monolithic
style.
Apache Community decided to make re-engineering of this code, and Apache
SOAP 2.1 emerged.
The development team started a major refactoring and redesign of the
codebase and it was supposed to be called Apache SOAP 3.0.
Axis (Apache eXtensible Interaction System) was chosen instead of Apache
SOAP 3.0.
e-Macao-16-5-437
Axis Architecture
A chain of message-processing components that can be developed
separately and assembled at deployment time.
These components are called handlers.
Axis replaced the Apache SOAPs DOM-based XML processing used in
predecessors, to faster SAX system.
e-Macao-16-5-438
Axis Handlers
Axis handlers tell the engine how to deal with messages that need to be
processed.
Handlers can be:
1) built-in the engine
2) included in a module defined by the user
Handlers may:
1) send a request and receive a response
2) process a request and produce a response - called pivot point of
the sequence of messages
e-Macao-16-5-439
Handlers Implementations
Handlers are Java classes based around a simple abstract class:
apache.axis.handlers.BasicHandler
A handler implementation, overrides the following method:
void invoke (MessageContext context) throws AxisFault;
When a handler is invoked, it may execute different functions:
1) reading and writing pieces of SOAP message,
2) logging information to a database,
3) checking users identification credentials,
4) . . .
e-Macao-16-5-440
Different Types of Handlers
Handlers are:
1) transport-specific
2) service-specific
3) global
e-Macao-16-5-441
Handlers and Chains
Handlers can be combined into chains.
A chain is a pre-defined ordered collection of handlers.
The overall sequence of handlers comprises three chains:
1) transport
2) global
3) service
e-Macao-16-5-442
Chains
The Axis engine processes chains in the same way as handlers.
A chain class groups handlers together.
The chain class also implements the Handler interface.
When a chains invoke method is called, it calls the invoke method on
each of its constituent handlers, which themselves might be chains.
Axis uses two types of chains:
1) simple chains
2) targeted chains
e-Macao-16-5-443
Simple Chains
A simple chain is a list of handlers that should be invoked in order.
Handler 1 Handler 2 Handler 3
e-Macao-16-5-444
A targeted chain has exactly three handlers:
1) request hander: does the pre-processing work
2) pivot handler: the place where real work is done
3) response handler: does the post-processing work
Deployed services in Axis are invoked by targeted chains. The pivot handler
calls the Java class that is exposed as a web service.
Targeted Chains
Request Handler
Response Handler
Pivot
Handler
Java class
e-Macao-16-5-445
Message Context
The object passed to each handler is called MessageContext.
MessageContext is a structure which contains:
1) a request message
2) a response message
3) several properties
4) other fields
Axis processing framework passes the MessageContext through the set of
handlers that are configured in the engine.
e-Macao-16-5-446
Message Path on the Server
handlers
chain
[courtesy Apache-Axis]
e-Macao-16-5-447
A message arrives at a transport listener - any software that can take input
messages and handle them to Axis.
A transport listener:
implements a particular SOAP binding
1) packages protocol-specific data into a Message object and puts it into a
MessageContext
2) sets some properties in the MessageContext:
a) http.SOAPAction - with the value defined in the HTTP header
b) transportName - http
c) other general properties such as reception-time, etc.
3) hands the MessageContext to the AxisEngine
A built-in HTTP listener:
org.apache.axis.transport.http.AxisServlet
Server Side Listener Request
e-Macao-16-5-448
The AxisEngine:
a) looks for a transport chain whose name matches the
transportName in the MessageContext
b) if a transport chain exists, the engine invokes the request handler of
this chain passing it the MessageContext
This allows the server to implement transport-specific processing.
Transport-specific processing consists of any work that closely relates to the
transport over which the message was received.
Example: any process dealing with HTTP headers for an HTTP transport,
for instance HTTP authentication.
Server Side Transport Level
e-Macao-16-5-449
After the transport-specific request processing completes without error, the
server passes the MessageContext to the global request chain.
This chain contains handlers that process all incoming messages,
regardless the transport.
The global chain may be used to implement common features to all
messages, such as: security or logging.
Server Side Global Level
e-Macao-16-5-450
Server Side Service Level
After the global chain is finished, the server calls the service handler.
The service handler is a special kind of wrapper called a SOAPService.
The SOAPService class is a targeted chain, including:
1) request chain allows to insert pre-processing handlers specific for
the service invoked
2) provider handler is the pivot handler that calls the service class
3) response chain allows to insert post-processing handlers specific
for the service that is invoked
e-Macao-16-5-451
Server Side Listener Response
After the Axis engine processes the message, the control is passed again to
the listener.
The listener:
1) takes the message out from the MessageContext
2) sends it back to the client as an HTTP response
e-Macao-16-5-452
Deploying Global Handlers Example
Deployment descriptor to deploy a global handler :
<deployment xmlns=...
<globalConfiguration>
<requestFlow>
<handler type="requestHandler"/>
</requestFlow>
<responseFlow>
<handler type="responseHandler"/>
</responseFlow>
</globalConfiguration>
<handler name="requestHandler" type="java:MyRequestHandler">
...
</handler>
<handler name="responseHandler type="java:MyResponseHandler">
...
</handler>
</deployment>
e-Macao-16-5-453
Task 59: Handlers Development
Objective: deploy two global handlers on the server side - request and
response handlers. Both handlers write the envelope of the messages they
process to a file.
1) cd \demos\Axis\Handlers
2) dir
deployService.bat
FileTransferRequest.class
MyHandlers.wsdd
MyRequestHandler.class
MyResponseHandler.class
Analyze the deployment file:
3) edit MyHandlers.wsdd
e-Macao-16-5-454
Task 60: Deploy Global Handlers
Deploy the handlers:
4) copy MyRequestHandler.class MyResponseHandler.class
to Tomcat 4.1\webapps\axis\WEB-INF\classes
5) deployService.bat
6) browse: http://localhost:8080/axis --> View
7) Why they do not appear?
Test the handlers:
8) java cp \demos\Axis\Handlers
FileTransferRequest \WebServices\MacaoNews.txt Macao.txt
8) cd Tomcat 4.1\bin
9) dir
10) edit SOAPRequest.log SOAPResponse.log
e-Macao-16-5-455
Message Path on the Client
[courtesy Apache-Axis]
e-Macao-16-5-456
Client Side Message Processing
The AxisClient is the class handling the message flow through the various
components on the client side.
The Call object (org.apache.axis.client.Call) is the main client-side
entry point to Axis.
Inside the AxisClient, the message flows in a reverse order than in the
server.
The last chain, is the transport-specific chain.
The transport chain has a pivot handler called the sender.
The sender is responsible for taking the request message out of the
MessageContext and sending it across the wire in a protocol-specific
way.
e-Macao-16-5-457
Sequence of Handlers
pivot
transport
global
service
pivot
server client
e-Macao-16-5-458
JAX-RPC Overview
JAX-RPC: Java API for XML-based RPC.
The fundamental purpose of JAX-RPC is to make communications
between Java and non-Java platforms easier:
1) using Web services technologies like XML, SOAP and WSDL
2) providing a simple object-oriented API that Java developers can
use to communicate with other technologies
It is possible to use JAX-RPC to:
1) access web services that run in non-Java environments
2) host Java web services, so that non-java applications can access
them
e-Macao-16-5-459
JAX-RPC
1) JAX-RPC is designed as a Java API for web services.
2) incorporates XML-based RPC functionality according to the SOAP 1.1
specification
3) requires support for:
a) SOAP and WSDL
b) RPC encoded messaging
c) SOAP with Attachments
e-Macao-16-5-460
WS and JAX-RPC
A Web service endpoint is deployed on either the Web container or EJB
container based on the corresponding component model.
These endpoints are described using a WSDL document.
A client uses this WSDL document and invokes the Web service endpoint.
JAX-RPC requires SOAP over
HTTP for interoperability.
e-Macao-16-5-461
JAX-RPC and SOAP
JAX-RPC provides support for SOAP message processing model through
the SOAP message handler functionality.
JAX-RPC uses SAAJ API (SOAP with Attachments API for Java).
SAAJ provides a standard Java API for constructing and manipulating SOAP
messages with attachments.
e-Macao-16-5-462
JAX-RPC Extensions
1) Message Handlers: they allow to manipulate SOAP header blocks as
they flow in and out of JAX-RPC endpoint and the client applications.
2) Mappings from WSDL and XML to Java describing how:
a) Java endpoint interfaces used by JAX-RPC web services are
converted into WSDL
b) WSDL documents are converted into JAX-RPC generated stubs
and dynamic proxies
c) method calls to JAX-RPC client APIs are converted into SOAP
messages
d) SOAP messages are mapped to JAX-RPC service endpoint
methods
e-Macao-16-5-463
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-464
Message Context Class
MessageContext is the Axis implementation of the SOAPMessageContext
class.
Is the core class for processing messages in handlers and other parts of the
system.
This class also contains constants for accessing some well-known properties.
Some methods include:
getResponseMessage()
getRequestMessage()
getSOAPActionURI() getService()
getOperation() getMessage()
getProperty() getAllPropertyNames()
e-Macao-16-5-465
Message Type
Asking the MessageContext for the request or response message will return
a message of type org.apache.axis.Message.
The Message class extends SOAPMessage.
The message contains:
1) a SOAPPart
2) zero or more AttachmentsParts
Messages conforming to the simple SOAP HTTP binding will have only a
SOAPPart and no attachments.
e-Macao-16-5-466
SOAPPart
The SOAPPart allows to get the SOAPEnvelope.
A client can access the SOAPPart object of a SOAPMessage object like:
void invoke(MessageContext context) ...
SOAPMessage message = context.getMessage();
SOAPPart soapPart = message.getSOAPPart();
SOAPPart object contains a SOAPEnvelope object, which in turn contains a
SOAPBody object and a SOAPHeader object.
The SOAPPart method getEnvelope can be used to retrieve the
SOAPEnvelope object.
SOAPEnvelope env = soapPart.getEnvelope();
e-Macao-16-5-467
Accesing the Envelope Elements
Some important classes involving the SOAP envelope:
MessageElement
SOAPEnvelope
SOAPHeader
SOAPHeaderElement
SOAPBody
SOAPBodyElement
SOAPFault
extends
contains
MessageElement is the base type of nodes of the SOAP message parse tree.
e-Macao-16-5-468
Accesing to Envelope Elements
Once, obtained the object SOAPEnvelope (env), it is possible to access
SOAPHeader and SOAPBody objects:
void invoke(MessageContext context) ...
SOAPMessage message = context.getMessage();
SOAPPart soapPart = message.getSOAPPart();
SOAPEnvelope env = soapPart.getEnvelope();
SOAPHeader sh = env.getHeaders();
SOAPBody sb = env.getBody();
e-Macao-16-5-469
Envelope Elements Example
Count the headers on a SOAP Envelope:
void invoke(MessageContext mc) ...
/* Get the SOAP Envelope from the request message */
Message requestMsg = mc.getRequestMessage();
SOAPEnvelope env = requestMsg.getSOAPEnvelope();
/* Obtain the headers */
Vector headers = env.getHeaders();
e-Macao-16-5-470
Looking for a Fault Example
Analyze if the content of the body is a fault:
void invoke(MessageContext mc) ...
/* Get the SOAP Envelope from the response message */
Message responseMsg = mc.getResponseMessage();
env = responseMsg.getSOAPEnvelope();
SOAPBodyElement body = env.getFirstBody();
/* controls whether the body contains a fault */
if (body instanceof SOAPFault) {
System.out.println (First body element is a fault code,
code = + ((SOAPFault)body).getFaultCode().toString() );
e-Macao-16-5-471
Task 61: Envelope
Objective: Write the EnvelopeManager Java class which provides the invoke method.
This method receives as argument an object of type MessageContext. The
method provides the following functionality:
1) prints a message specifying how many headers has the request message
2) prints a message specifying if the body element of the response message
contains a fault and what is the code of the fault
The EnvelopeManager class is used by:
1) envelopeExample1: the same example as FileTransferRequest
2) envelopeExample2: the same example as FileTransferSenderFault
These classes include the following code:
MessageContext mc = call.getMessageContext();
EnvelopeManager em = new EnvelopeManager();
em.invoke(mc);
e-Macao-16-5-472
Task 62: Envelope
1) cd demos\axis\envelope
2) dir
EnvelopeExample1.class
EnvelopeExample2.class
EnvelopeManagerTemplate.java
3) edit the class using: EnvelopeManagerTemplate.java
4) add the lines of code to get the headers of the envelope
5) add the lines of code to get the envelope
6) save the file as EnvelopeManager,java
e-Macao-16-5-473
Task 63: Envelope
Compile the class:
7) javac EnvelopeManager.java
Execute the examples:
8) java cp \demos\Axis\Envelope envelopeExample1
c:\WebServices\MacaoNews.txt macao.txt
9) java cp \demos\Axis\Envelope envelopeExample2
c:\WebServices\MacaoNews.txt macao.txt
e-Macao-16-5-474
Replacing the Envelope Elements
It is possible to change the body or header of a SOAPEnvelope object by
retrieving the current one, deleting it, and then adding a new body or
header.
The javax.xml.soap.Node method detachNode detaches the XML element
(node) on which it is called.
For example, to create a new header:
env.getHeader().detachNode();
SOAPHeader sh = env.addHeader();
e-Macao-16-5-475
Type Mapping
Axis has the ability to map XML to Java and vice versa.
A type mapping consists of:
1) an XML type (a QName)
2) a Java type (a class)
3) a serializer (to write Java to XML)
4) a deserializer (to write Java from XML)
To map types on the client side, use:
call.registerTypeMapping (Class javaType,
QName xmlType,
Class serializerFactoryClass,
Class deserializerFactoryClass)
e-Macao-16-5-476
Type Mapping Example
Recall the example that downloads the attributes of the file.
The code on the client, looks like:
QName qn = new QName("urn:FileAttribute","FileAttribute");
call.registerTypeMapping(FileAttribute.class, qn,
new org.apache.axis.encoding.ser.BeanSerializerFactory(
FileAttribute.class, qn),
new org.apache.axis.encoding.ser.BeanDeserializerFactory(
FileAttribute.class, qn));
e-Macao-16-5-477
Task 64: Accessing Documentation
1) cd axis-1_2RC2\docs
2) open index.html
3) access API Documentation
e-Macao-16-5-478
Axis Client APIs
The client APIs can divided in two categories:
1) dynamic invocation: only pre-existing Java classes are used to do
the work
2) stub generation: a tool generates code from the WSDL description
In order to invoke a web service, the client needs to use the Dynamic
Invocation Interface (DII).
e-Macao-16-5-479
Service Object
The Service object acts as a factory for Call objects and it also stores meta-
data about the service:
1) is the object representing the AxisClient instance that processes the
client invocations
2) is where the type-mappings XML-Java are stored
The Service object can generate many Call objects.
Each Call object represents a single invocation of a service.
Since all these Call objects will talk to the same Web service, all the meta-
data related to it is stored in the Service object.
e-Macao-16-5-480
Service Object and WSDL
A Service may or may not be associated with a WSDL description.
If it is related, it is possible to request:
1) a generic Call object,
2) a Call object that has been preconfigured with all the meta-data
from the WSDL
The Service API as defined by JAX-RPC has no direct means to access
WSDL documents for dynamic invocation.
The Service object has two constructors that allows the association with a
WSDL document.
e-Macao-16-5-481
Service Object: WSDL Association
Two constructors for building a Service object with meta-data initialized from
the WSDL:
1) Service(URL wsdlLocation, QName serviceName): the
WSDL is located at the specified URL.
2) Service(String wsdlLocation, QName serviceName): the
WSDLocation is a String that may be a URL or may also be a
filename on the local filesystem, relative to the current directory.
The Axis Service object also has a no-argument constructor for use without
a WSDL:
3) Service()
e-Macao-16-5-482
Call Object
Call objects are generated with the createCall() method of the Service
object.
import org.apache.axis.client.Service;
import javax.xml.rpc.Call;
Service service = new Service();
Call call = service.createCall();
The no-arguments service constructor creates a blank service.
The createCall() factory method without arguments, creates a generic
JAX-RPC Call object.
e-Macao-16-5-483
Setting Properties on the Call
The Call class has a setProperty() API:
void setProperty(String name, Object value)
This method allows to set properties on the Call object.
All the properties that are set on the Call will be available to every
MessageContext that is created as a result of using the Call.
It is possible to use a Call object to make multiple invocations to a given
service. Each time a new MessageContext will be created.
e-Macao-16-5-484
Generic Calls for WS
The development of the Web service client includes:
1) creating objects to manage the call and the service
2) defining the endpoint URL of the web service
3) defining the operation name of the web service
4) invoking the desired service passing the corresponding parameters
e-Macao-16-5-485
Creating Objects: Call and Service
Lets have a look at one of our Web Service client: FileTransferRequest:
public class FileTransferRequest {
public static void main(String [] args) {
. . .
Service service = new Service();
Call call = (Call) service.createCall();
Two objects are created: Service and Call.
e-Macao-16-5-486
Defining the Endpoint
A variable endpoint is defined and initialized with the URL address of the
desired web service.
String endpoint =
"http://localhost:8080/axis/services/FileDownloadService";
This address containing the final destination of the SOAP message is
passed to the newly created Call object:
call.setTargetEndpointAddress( new java.net.URL(endpoint) );
Axis also provides two constructors that allow to create a Call, pointing to a
particular Web service endpoint:
1) Call (String endpoint)
2) Call(URL endpoint)
e-Macao-16-5-487
Defining the Operation Name
The name of the operation that the Call object is invoking is defined as:
call.setOperationName(new QName("http://soapinterop.org/",
"downloadFile")
e-Macao-16-5-488
Invoking the Desired Service
The invoke() method allows to invoke a web service. It has several different
forms.
The data for any given invocation is generally handed to the invoke method
as an array of Java objects:
1) for RPC-Style services, these objects are parameters for a remote
method call and each one maps to an XML element
2) for document-style services is generally a single object in the array
and maps to the entire SOAP body for the operation
In our example, we have:
byte[] ret = (byte[])call.invoke( new Object[] { args[0] } );
args[0] is the name of the file to download, that is sent as a parameter
e-Macao-16-5-489
Invoke Method: Different Forms
invoke(SOAPEnvelope env)
Invokes the service with a custom SOAPEnvelope.
invoke(RPCElement body)
Invokes an RPC service with a pre-constructed RPCElement.
invoke (QName operationName, java.lang.Object[] params)
Invokes a specific operation using a synchronous request-response interaction
mode.
invoke (java.lang.Object[] params)
Invokes the operation associated with this Call object using the passed in
parameters as the arguments to the method.
invoke(Message msg)
Invokes the service with a custom Message.
invoke()
Invokes this Call with its established MessageContext
and more
e-Macao-16-5-490
Task 65: Invoking the WS
Objective: Write the FileTransferClient Java class invoking the method
downloadfile of the FileDownloadService. Use the FileTransferTemplate.java.
1) cd demos\Axis\Client
2) dir
FileTransferTemplate.java
3) edit FileTransferTemplate.java to generate
FileTransferClient.java adding the corresponding lines of code
4) javac FileTransferClient.java
5) java cp \demos\Axis\Client FileTransferClient
c:\WebServices\MacaoNews.txt Macao.txt
6) dir
e-Macao-16-5-491
Naming Parameters
Axis automatically names the XML-encoded arguments in the SOAP
message as arg0, arg1, etc.
For changing these names, we need to add the call addParameter for each
parameter, and setReturnType for the return, before the invoke:
call.addParameter (testParam,
org.apache.axis.Constants.XSD_String,
javax.xnl.rpc.ParameterMode.IN);
call.setReturnType (org.apache.axis.Constants.XSD_String);
The testParam will be the first parameter on the invoke call. It also defines
the type of the parameter and whether it is an input, output or inout
parameter.
If names are added to the parameters, it is needed to add the type of the
result.
e-Macao-16-5-492
Defining SOAP Version
It is possible to define the SOAP version in the Call object:
import org.apache.axis.soap.SOAPConstants;
. . .
. . .
call.setSOAPVersion(SOAPConstants.SOAP12_CONSTANTS);
The default version of SOAP is 1.1.
e-Macao-16-5-493
Task 66: Parameters and Version
Objective: Add to the FileTransferClient the name fileName to the
argument of the method. The name of the result should be: outputFile.
Generate a SOAP 1.2 envelope.
1) cd demos\Axis\ParametersVersion
2) copy: \demos\Axis\Client\FileTransferClient.java
to : \demos\Axis\ParametersVersion
e-Macao-16-5-494
Task 67: Parameters and Version
3) edit FileTransferClient.java, adding:
import org.apache.axis.soap.SOAPConstants;
/* Naming Parameters and Result */
call.addParameter(fileName",
org.apache.axis.Constanst.XSD_STRING,
javax.xml.rpc.ParameterMode.IN);
call.setReturnType (org.apache.axis.Constants.XSD_BASE64);
/* Defining SOAP Version */
call.setSOAPVersion(SOAPConstants.SOAP12_CONSTANTS);
4) javac FileTransferClient.java
5) java cp \demos\Axis\ParametersVersion
FileTransferClient
c:\WebServices\MacaoNews.txt Macao.txt
e-Macao-16-5-495
Inserting a Header Example
Let us remember the header of our example:
<soapenv:Header>
<ns1:authentication
soapenv:actor=http://manager
soapenv:mustUnderstand=0
xmlns:n1=http://localhost:8080/axis/services/FileDownloadService>
<ns1:username>admin</ns1:username>
<ns1:password>admin</ns1:password>
</ns1:authentication>
</soapenv:Header>
1) one header: authentication
2) two attributes: actor and mustUnderstand
3) two sub-elements: username and password
e-Macao-16-5-496
Implementing Headers 1
1) define a SOAP Header Element with the name of the header:
String nameSpace =
"http://localhost:8080/axis/services/FileDownloadService";
SOAPHeaderElement she = new
SOAPHeaderElement(XMLUtils.StringToElement(nameSpace,
"authentication", ""));
2) define the attributes:
she.setRole("http://manager");
she.setMustUnderstand(false);
e-Macao-16-5-497
Implementing Headers 2
3) define the sub-elements and its contents:
String nameSpace =
http://localhost:8080/axis/services/FileDownloadService;
MessageElement username = new
MessageElement(nameSpace,"username");
username.addTextNode("admin");
MessageElement password = new
MessageElement(nameSpace,"password");
password.addTextNode("admin");
4) add the childs to the header element:
she.addChild(username);
she.addChild(password);
5) create the header:
call.addHeader(she);
e-Macao-16-5-498
Task 68: Inserting a Header
Objective: add a header to the request message.
1) cd demos\Axis\Headers
2) copy: \demos\Axis\ParametersVersion\FileTransferClient.java
to : \demos\Axis\Headers
3) edit FileTransferClient and add the lines of code to generate the
header
4) javac FileTransferClient.java
5) java cp \demos\Axis\ParametersVersion
FileTransferClient
c:\WebServices\MacaoNews.txt Macao.txt
e-Macao-16-5-499
Dynamic Binding
Using one of the WSDL-aware Service() constructors, Axis extracts the
meta-data (endpoint, parameters and return types) from the WSDL file and
prepares the Call.
The only missing information is the port and the operation. Some possible
formats include:
service.createCall (QName portName, String operation)
The same as the previous format, but it accepts the unqualified operation name.
service.createCall (QName portName, QName operation)
Returns a Call that has been initialized with the endpoint address and also with all
the parameters and return types.
service.createCall (QName portName)
Returns a Call that has been initialized with the endpoint address referred to by the
named port.
e-Macao-16-5-500
Dynamic Binding Example 1
Using the following constructor:
Service (java.lang.String wsdlLocation, QName serviceName)
The example looks like:
String wsdlLocation =
"http://localhost:8080/axis/services/FileDownloadService?wsdl";
String nameSpace =
"http://localhost:8080/axis/services/FileDownloadService";
QName serviceName = new QName(nameSpace, "FileDownloadService");
Service service = new Service(wsdlLocation, serviceName);
e-Macao-16-5-501
Dynamic Binding Example 2
Using the following method:
createCall (QName portName, java.lang.String operationName)
The example looks like:
QName portName = new QName(nameSpace, "FileDownloadService");
String operationName = "downloadFile";
Call call = (Call)service.createCall( portName, operationName);
e-Macao-16-5-502
Task 69: Dynamic Binding
Objective: Develop the FileTransferClient using a WSDL-aware Service()
constructor. Use FileTransferTemplate.java
1) cd demos\Axis\Dynamic
2) dir
FileTransferTemplate.java
3) edit FileTransferTemplate.java and save it as
FileTransferClient.java
e-Macao-16-5-503
Task 70: Dynamic Binding
4) add the following instructions:
String wsdlLocation =
"http://localhost:8080/axis/services/FileDownloadService?wsdl";
String nameSpace =
"http://localhost:8080/axis/services/FileDownloadService";
QName serviceName = new QName(nameSpace, "FileDownloadService");
Service service = new Service(wsdlLocation, serviceName);
QName portName = new QName(nameSpace, "FileDownloadService");
String operationName = "downloadFile";
Call call = (Call)service.createCall( portName, operationName);
5) javac FileTransferClient.java
6) java cp \demos\Axis\Dynamic FileTransferClient
c:\WebServices\MacaoNews.txt Macao.txt
e-Macao-16-5-504
Using Sessions
In some cases, it is useful if the server is able to remember data related to
various invocations of the same client.
Some kind of session is needed to associate some data with a given client.
Axis has some simple APIs for session support.
e-Macao-16-5-505
Session Implementations
Axis provides two built-in ways to maintain sessions across web services
connections, using:
1) standard HTTP session mechanisms
2) SOAP headers
3) WS-Resource Framework
e-Macao-16-5-506
Sessions with HTTP
Uses HTTP cookies to store session state:
1) the server transmits to the client some kind of cookie
2) the server accepts the same cookie from the client on subsequent
requests
3) the server realizes that the new requests are associated with the
same client
The actual session data is kept by the servlet framework.
It is needed:
1) to use HTTP
2) to call setMaintainSession(true) on either the Call or the
Service object
e-Macao-16-5-507
Sessions with SOAP Headers
To use this approach, the SimpleSessionHandler must be deployed.
The handler org.apache.axis.handlers.SimpleSessionHandler is
included with Axis.
In order to work, this handler must be deployed in the global request and
response flows of the client in order to work.
e-Macao-16-5-508
Sessions with WS-Resource
WS-Resource Framework consists of five specifications:
1) WS-ResourceProperties
2) WS-ResourceLifetime
3) WS-ServiceGroup
4) WS-RenewableReferences
5) WS-BaseFaults
and an approach to modeling statefull resource using web services.
The WS-Resource Framework was developed by Computer Associates,
Fujitsu, Globus, Hewlett-Packard and IBM.
It was submitted to OASIS.
e-Macao-16-5-509
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-510
Axis Tools
Axis comes with the following tools:
1) WSDL2Java: based on WSDL descriptions generates Java code for
the client and server side
2) Java2WSDL: is a command-line tool for taking Java interfaces and
generating WSDL
3) generation of WSDL: at runtime, the Axis engine automatically
generates WSDL for the deployed services
e-Macao-16-5-511
WSDL2Java
WSDL2Java automatically builds stubs.
A Stub is a Java class with a Java-friendly API that closely matches the Web
service interface defined in a given WSDL document.
The tool is executed from the command line:
java org.apache.axis.wsdl.WSDL2Java WSDL_Document_URL
For instance:
java org.apache.axis.wsdl.WSDL2Java
http://localhost:8080/axis/services/FileDownloadService?wsdl
e-Macao-16-5-512
WSDL2Java Example 1
Executing WSDL2Java for our example, the following Java classes are
generated:
1) FileDownload.java: this is the service interface . In JAX-RPC is known as
Service Endpoint Interface (SEI).
/**
* FileDownload.java
*
* This file was auto-generated from WSDL
* by the Apache Axis 1.2RC2 Nov 16, 2004 (12:19:44 EST)
WSDL2Java emitter.
*/
package localhost.axis.services.FileDownloadService;
public interface FileDownload extends java.rmi.Remote {
public byte[] downloadFile(java.lang.String in0) throws
java.rmi.RemoteException;
}
e-Macao-16-5-513
WSDL2Java Example 2
2) FileDownloadService: this interface allows type-safe access to the SEI
from the locator class. Includes two methods:
a) getFileDownloadService(): gets an implementation of the
FileDownload interface that will call the endpoint specified in the
WSDL
b) getFileDownloadService(URL url): gets a FileDownload
stub that uses the same WSDL interface but points at a different
endpoint
3) FileDownloadServiceLocator.java: this class implements the
FileDownloadService interface and acts as the factory for stub instances
4) FileDownloadServiceSOAPBindingStub.java: the class that implements
the FileDownload interface the core of the client
e-Macao-16-5-514
Task 71: Execute WSDL2Java
Objective: execute WSDL2Java for the FileDownloadService
1) cd demos\Axis\WSDL2Java
2) java org.apache.axis.wsdl.WSDL2Java
http://localhost:8080/axis/services/FileDownloadService?wsdl
3) cd localhost\axis\services\FileDownloadService
4) dir
FileDownload.java
FileDownloadService.java
FileDownloadServiceLocator.java
FileDownloadServiceSOAPBindingStub.java
5) notepad FileDownload*.java
e-Macao-16-5-515
Tools for Invoking a Service
Two ways for invoking a service from the client:
1) using a generic stub: instantiating a service and a call object
2) using a specific stub: invoking the interfaces generated by WSDL2Java
based on the WSDL file
e-Macao-16-5-516
Task 72: Using a Specific Stub
Objective: testing the service with a client that uses the interfaces generated by
WSDL2Java.
1) cd \demos\Axis\TestStubs
2) dir
FileTransferTestTemplate.java
3) generate the stubs:
java org.apache.axis.wsdl.WSDL2Java
http://localhost:8080/axis/services/FileDownloadService?wsdl
4) compile the generated classes:
cd localhost\axis\services\FileDownloadService
javac *.java
e-Macao-16-5-517
Task 73: Using a Specific Stub
5) cd \demos\Axis\TestStubs
6) edit FileTransferTestTemplate.java, adding:
import localhost.axis.services.FileDownloadService.*;
/* Get the stub from the locator object */
FileDownloadServiceLocator locator = new
ileDownloadServiceLocator();
FileDownload stub = locator.getFileDownloadService();
/* Call the web service
byte[] ret = stub.downloadFile(fileName);
save it as FileTransferTest.java
e-Macao-16-5-518
Task 74: Using a Specific Stub
Compile:
7) javac classpath \demos\Axis\TestStubs
FileTransferTest.java
Execute:
8) java cp \demos\Axis\TestStubs FileTransferTest
c:\WebServices\MacaoNews.txt Macao.txt
9) dir
e-Macao-16-5-519
Using WSDL2Java for Services 1
It is possible to take a WSDL description of a Web Service and create a
skeleton implementation of the service described by the WSDL.
Specifying the option s to WSDL2Java, in addition to the client and data
classes, will generate for the FileDownloadService:
1) FileDownloadServiceSOAPBindingImpl.java: the framework
implementation of the service
2) deploy.wsdd: a pre-built deployment file for use with the
AdminClient
3) undeploy.wsdd: a pre-built undeployment file
e-Macao-16-5-520
Using WSDL2Java for Services 2
The FileDownloadServiceSOAPBindingImpl.java looks like:
/**
* FileDownloadServiceSoapBindingImpl.java
*
* This file was auto-generated from WSDL
* by the Apache Axis 1.2RC2 Nov 16, 2004 (12:19:44 EST)... */
package localhost.axis.services.FileDownloadService;
public class FileDownloadServiceSoapBindingImpl implements
localhost.axis.services.FileDownloadService.FileDownload{
public byte[] downloadFile(java.lang.String in0) throws
java.rmi.RemoteException {
return null;
}
}
e-Macao-16-5-521
Task 75: Using WSDL2Java More
Objective: execute WSDL2Java for the FileDownloadService with s option
1) cd demos\Axis\WSDL2JavaWS
2) java org.apache.axis.wsdl.WSDL2Java -s
http://localhost:8080/axis/services/FileDownloadService?wsdl
3) cd localhost\axis\services\FileDownloadService
4) dir
deploy.wsdd
FileDownload.java
FileDownloadService.java
FileDownloadServiceLocator.java
FileDownloadServiceSOAPBindingImpl.java
FileDownloadServiceSOAPBindingStub.java
undeploy.wsdd
5) notepad deploy.wsdd, undeploy.wsdd,
FileDownloadServiceSOAPBindingImpl.java
e-Macao-16-5-522
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-523
WSDD Overview
WSDD is an XML format that Axis uses to store its configuration and
deployment information.
The Axis server keeps its configuration in a file: server-config.wsdd.
The Axis client has an equivalent file: client-config.wsdd.
These files have default versions stored in axis.jar
e-Macao-16-5-524
WSDD Structure
In order to deploy web services the root element of WSDD is deployment.
Inside the root element is a <globalConfiguration> element which
contains options for the Axis engine plus definitions for the global request and
response chains.
<globalConfiguration>
<parameter name=defaultSOAPVersion value=1.2 />
<requestFlow>
<handler type="requestHandler"/>
</requestFlow>
<responseFlow>
<handler type="responseHandler"/>
</responseFlow>
</globalConfiguration>
e-Macao-16-5-525
Global Configuration
The parameter declarations inside the globalConfiguration set
options on the AxisEngine. For instance: SOAP version.
The <requestFlow> and <responseFlow> elements define the request
and response global chains. They can contain either <handler> elements
or <chain> elements.
The components inside <requestFlow> and <responseFlow> are
invoked in exactly the same order as they are declared in the XML file.
e-Macao-16-5-526
Handler Declarations
Handler declarations tell Axis that a given Java class is a handler, allowing:
1) configure it with a set of options
2) name the configuraion, so it is possible to refer to it
<handler [name=name] type=type>
<parameter name=name value=value />
</handler>
For example:
<handler name="requestHandler" type="java:MyRequestHandler">
<parameter name="filename" value="SOAPRequest.log"/>
</handler>
This handler can be referenced:
<handler type="requestHandler"/>
e-Macao-16-5-527
Chain Definitions
It is possible to group a series of handlers into a chain.
<chain [name=name] >
<handler type=type>
<parameter name=name value=value />
</handler>
</chain>
For instance:
<chain name=logAndNotify >
<handler type=java:LogHandler />
<handler type=java:NotifyHandler />
</chain>
This chain can be referenced as:
<requestFlow>
<handler type=logAndNotify />
</requestFlow>
e-Macao-16-5-528
Transport Declarations
Transport declarations define a
named, targeted chain, which has:
1) a requestFlow,
2) a responseFlow,
3) a pivot handler (only on the
client)
On the client, the pivot handler is the
sender of the message.
On the server there is no need for a
pivot handler.
Server Side
Client Side
e-Macao-16-5-529
Transport Handler: Client Example
Example from the client-config.wsdd:
<transport name=http
pivot=java:org.apache.axis.transport.http.HTTPSender />
A pivot handler is defined using the pivot attribute.
e-Macao-16-5-530
Transport Handler: Server Example
Example from the server-config.wsdd:
<transport name="http">
<requestFlow>
<handler type="URLMapper"/>
<handler
type="java:org.apache.axis.handlers.http.HTTPAuthHandler"/>
</requestFlow>
. . .
This transport is named http and contains two-transport specific handlers:
1) URLMapper: sets the Axis service name in the MessageContext
based on the HTTP URL
2) HTTPAuthHandler: takes the username and password out of the
HTTP Basic authentication header and puts them in the
MessageContext
e-Macao-16-5-531
Type Mapping
Type mappings control the mapping between Java classes and XML
structures.
It is possible to tell the engine to map a particular Java class to a particular
XML type, and even customize the serializer and deserializer classes.
<typeMapping qname=typeQName
type=java:classname
serializer=Serializer
deserializer=DeserializerFactory
encodingStyle=uri />
e-Macao-16-5-532
Bean Mapping
The <beanMapping> tag is a shorthand for a <typeMapping>, which uses
BeanSerializer, and BeanDeserializer classes to do the Axiss default data-
mapping algorithms.
<beanMapping qname=typeQName
languageSpecificType=java:classname
encodingStyle =url/>
For instance, this mapping was used in the example of SOAP encoding,
where the web service was returning the attributes of the file as an object:
<beanMapping qname="ns:FileAttribute"
xmlns:ns="urn:FileAttribute"
languageSpecificType="java:FileAttribute"/>
e-Macao-16-5-533
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-534
WSDD for Services
The entire configuration of the Axis server is contained in: server-config.wsdd
Each deployed service in the server, has a <service> element in the WSDD
file with the following syntax:
<service name=name
[style=rpc | wrapped | document | message]
[use=literal | encoded]
[provider=provider] >
<operation>*
<typeMapping>* | <beanMapping>*
<namespace>uri</namespace>*
<wsdlFile>absolute-filename</wsdlFile>
<endpointURL>uri</endpointURL>
<handlerInfoChain>
<parameter name=name value=value />
</service>
* means that the element may appear zero or more times.
e-Macao-16-5-535
Attributes 1
The name attribute contains the name of the service.
The style attribute specifies one of several different ways that Axis can
map SOAP messages to and from Java method calls: rpc, document,
wrapped or messsage.
If a style is specified, there is no need to specify the use or provider
attribute, since they will have a default value based on the style chosen.
The use attribute specifies encoded or literal use. The default value is based
on the style attribute.
e-Macao-16-5-536
Attributes 2
The provider attribute allows to specify a QName representing the
particular provider:
1) Java:RPC: used for rpc, document, and wrapped styles
a) this provider is automatically selected if the style is rpc,
document or wrapped
b) using RPC provider, the class name and the methods allowed
must be specified:
<parameter name=className value=class_name/>
<parameter name=allowedMethods value=m1 m2 />
2) Java:MSG: used for message style
a) the message provider will dispatch raw XML to the service
3) Java:EJB: allows to use an Enterprise JavaBean as a web service
4) Handler: lets specify a user-defined handler for a particular service
e-Macao-16-5-537
Some Elements
If <typeMapping> or <beanMapping> are defined inside a service
deployment, those XML/Java mappings will hold only for the service.
If the <namespace> element is present, the first one is the default
namespace for the service.
The <wsdlFile> element allows to specify a custom WSDL file that the
engine will return when asked about the WSDL for the service.
e-Macao-16-5-538
JAX-RPC Handlers Element
The <handlerInfoChain> element is used to enable deploying JAX-RPC
style handlers:
<handlerInfoChain>
<handlerInfo class=className >
<parameter name=name value=value/>
<header qname=qname />*
<role SOAPActorName=uri />
</handlerInfo>*
</handlerInfoChain>
JAX-RPC handlers specified in this chain will run after the global chain, but
before the request flow of the service.
JAX-RPC handlers have two methods: handleRequest() and
handleResponse(), while Axis handlers only have invoke().
Each <handlerInfo> defines a single JAX-RPC handler.
e-Macao-16-5-539
Operation Element 1
A service can contain zero or more <operation> elements.
The <operation> element is used when more fine-grained control of the
options of a particular operation is desirable.
It handles the mapping from arbitrary XML QNames in the SOAP body to
arbitrary Java methods, controlling:
1) how parameters to those methods map to XML elements
2) how the exceptions thrown by the Java methods are map to and
from SOAP faults
e-Macao-16-5-540
Operation Element 2
<operation name=name [qname=qname] [returnQName=qname]
[returnType=qname] [returnHeader=true | false]>
<parameter [qname=qname | name=name]
[mode=in | out | inout]
type=qname
inHeader=true | false outHeader=true | false />*
<fault name=name qname=qname
class=classname type=qname />*
</operation>
The operation name is the name of the Java method this web service operation
will invoke.
The qname is the QName of the XML element that will map to this operation.
e-Macao-16-5-541
Operation Element 3
Inside the operation element are zero or more parameter elements, each
represents a parameter of the operation.
If the inheader or outheader attribute is specified for the parameter, then
the serialization of the parameter will be in the SOAP header or in the
SOAP body respectively.
The data related to the faults thrown by the service and specified in the
fault element, will be serialized inside a fault class as a <detail>
element with the specified QName and XML type.
e-Macao-16-5-542
Deploying Services
Two ways:
1) directly edit the server-config.wsdd
2) use the AdminClient tool
e-Macao-16-5-543
Admin Client
> java org.apache.axis.client.AdminClient
[-u {username}] [-w {password}]
[-p {port}] [-l {service-url}] {wsdd-file}
Executing this from the command line:
1) reads the WSDD file
2) attempts to deploy the service to the Axis engine
If authentication is required the username and password arguments are
used.
If the WSDD has <deployment> as the root element, all the components in
the WSDD are deployed.
All the classes referred in the WSDD must be available on the servers
classpath before doing the deployment.
e-Macao-16-5-544
Undeploying Web Services
If the WSDD document has <undeployment> as its root element, all the
referenced components will be removed from the running server.
For undeploying services, only the name of the components to undeploy are
specified.
<undeployment xmlns=http://xml.apache.org/axis/wsdd/>
<handler name=MyHandler>
<service name=MyService>
</undeployment>
e-Macao-16-5-545
Task 76: Undeploying a Service
Objective: undeploy the FileUploadService service.
1) Make a copy of the file server-config.wsdd:
copy: \Tomcat 4.1\webapps\axis\WEB-INF\server-config.wsdd
to: server-configbup.wsdd
2) Undeploy the service:
a) cd \demos\Axis\Undeploy
b) write the undeploy.wsdd file to undeploy the service:
<undeployment xmlns="http://xml.apache.org/axis/wsdd/">
<service name="FileUploadService" />
</undeployment>
c) java org.apache.axis.client.AdminClient
undeploy.wsdd
d) browse: http://localhost:8080/Axis --> View
e-Macao-16-5-546
Task 77: Return to Previous State
Objective: return to the previous state (including the FileUploadService).
1) cd \Tomcat 4.1\webapps\axis\WEB-INF
2) java org.apache.axis.client.AdminClient
3) server-configbup.wsdd
4) browse: http://localhost:8080/Axis --> View
e-Macao-16-5-547
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-548
Service Lifecycle and Scope
Some questions that should be answered during design include:
1) how is the web service object created?
2) how many web service objects will exist?
3) can the objects be shared across multiple threads at once?
These issues can be specified when deploying a web service, using the
scope option.
<service name=service_name>
. . .
<parameter name=scope
value = [application | request | session] />
</service>
e-Macao-16-5-549
Scope
The valid values for the scope option are:
1) application:
a) only a single instance of the service class for the entire Axis engine
b) all methods must be thread-safe many active requests in parallel
for the same code
c) any state of the service object will be shared across all invocations
2) request:
a) a new service will be created for every SOAP request
b) constructors should not have expensive initialization code
c) default value
3) session:
a) Are created once per client session
b) data fields hold state on a per-session basis
e-Macao-16-5-550
Creation and Destruction
JAX-RPC provides an interface called: javax.xml.rpc.server.ServiceLifecycle
This interface contains two methods:
1) void init (Object context) throws ServiceException;
2) void destroy();
When a service is created or destroyed by the Axis runtime, the engine checks
to see if the objects implements one of these interfaces.
Implementing these methods, initialization or cleanup may be done.
When a new service object is created, init is called with a context object
allowing the service to access the MessageContext.
e-Macao-16-5-551
Sessions on the Server Side
Axis provides an abstraction to manage sessions in the server side in the
org.apache.axis.session package.
A given interaction can optionally be associated with a session.
The MessageContext has a slot in it for the currently active session.
A Session object lets you to store values in a library indexed by String
keys like a map or hash-table.
Data stored in a Session during one interaction will be available again on
the next interaction of the same client.
e-Macao-16-5-552
Accessing Sessions
There are two built-in ways for accessing sessions on the Axis server:
1) using the servlet HTTPSession: the servlet engine will handle time out
2) using SimpleSession: the SimpleSessionHandler will periodically read
expired sessions
It is possible to set the timeout on a session with:
session.setTimeout(int)
The session implementations included in Axis are not persistent data will be
lost in case of a server crash or restart.
e-Macao-16-5-553
AXIS Outline
1) Overview
2) Service Invocation
a) data structures
b) static binding
c) dynamic binding
d) sessions
3) AXIS Tools
4) AXIS Configuration
5) Service Deployment
6) Service Lifecycle
7) Summary
e-Macao-16-5-554
AXIS Summary 1
1) Axis is an engine for processing SOAP messages
2) the Axis engine invokes a series of handlers to process messages
3) handlers are built-in the engine or can be included in a module defined by
the user
4) handlers may:
1) receive a request and send a response
2) process a request and produce a response pivot handlers
5) handlers are grouped in chains.
e-Macao-16-5-555
AXIS Summary 2
1) Axis defines different processing levels:
a) on the server: transport global service
b) on the client: service global transport
2) the object passed through the different handles in all these levels is the
MessageContext
3) the MessageContext structure includes:
a) the request message
b) the response message
c) several properties
d) other fields
e-Macao-16-5-556
AXIS Summary 3
1) JAX-RPC is Java API for XML-based RPC
2) JAX-RPC facilitates communication between Java and non-Java
platforms
3) JAX-RPC is designed as a Java API for web services
4) JAX-RPC supports:
a) SOAP and WSDL
b) RPC encoded messaging
c) SOAP with Attachments
e-Macao-16-5-557
AXIS Summary 4
1) Axis provides APIs for implementing SOAP classes.
2) it is possible to access, add and delete SOAP Envelope elements
3) the client APIs can be divided in:
a) dynamic invocation: using pre-existing Java classes
b) stub generation: using code generated by WSDL2Java tool
4) dynamic invocation: uses a Service and a Call object, where the endpoint
address and the operation name of the service are defined
5) the endpoint address and the operation name can be:
a) directly hard-coded in the Java program
b) extracted automatically by Axis from the WSDL file, using WSDL-
aware service constructors
e-Macao-16-5-558
AXIS Summary 5
1) It is possible to manage sessions on web services, by:
a) standard HTTP session mechanisms
b) SOAP headers
c) WS-Resource Framework
2) Axis provides several tools:
a) WSDL2Java: generates Java code for the client and the server
based on WSDL
b) Java2WSDL: generates WSDL based on Java interfaces
c) generation of WSDL: at runtime when deploying services
e-Macao-16-5-559
AXIS Summary 6
1) Axis uses an XML file called deployment descriptor to:
a) deploy services
b) undeploy services
c) customize the engine
2) the scope parameter when deploying the service allows to define its
lifecycle:
a) application
b) request
c) session
3) JAX-RPC provides two methods that can be invoked when the service
object is created or destroyed
4) Axis engine looks if these methods are implemented by the service, and
invoke them accordingly.
e-Macao-16-5-560
Axis Summary 7
Accessing the envelope:
Example:
demos\SourceFiles\Axis\Envelope
e-Macao-16-5-561
Axis Summary 8
Adding a Header:
Example: demos\SourceFiles\Axis\Header
e-Macao-16-5-562
Axis Summary 9
Invoking a Service without referencing to the WSDL document:
Example: \demos\SourceFiles\Axis\Client
e-Macao-16-5-563
Axis Summary 10
Invoking a Service referencing to the WSDL document:
Example: \demos\SourceFiles\Axis\Dynamic
e-Macao-16-5-564
Axis Summary 11
Invoking a Service using a generated stub:
Example: \demos\SourceFiles\Axis\TestStubs
e-Macao-16-5-565
Axis Summary 12
Developing a Handler:
Example: \demos\SourceFiles\Axis\Handlers
UDDI
e-Macao-16-5-567
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-568
UDDI Outline
1) Introduction
2) Concepts
3) Data Types
a) businessEntity
b) businessService
c) bindingTemplate
d) tModel
e) publisherAssertion
f) identifierBag
g) categoryBag
4) UDDI Registry
a) registry implementations
b) publishing a service
c) finding a service
5) Summary
e-Macao-16-5-569
UDDI Motivation
Once services have been properly described, these descriptions should be
made available to those interested in using them.
Service discovery is a process for locating service providers and retrieving
service description documents that have been published in a service registry.
Two types of service discovery:
1) static: occurs at application design time and is done by a human
designer
2) dynamic: occurs at runtime and is done by the application
For doing so, it is needed to standardize the web service registry.
Such standardization is done by UDDI project.
e-Macao-16-5-570
UDDI Project
UDDI project is an industry initiative attempting to create a platform-
independent, open framework for:
1) describing,
2) discovering
3) integrating
business services.
UDDI specifications define a registry service for:
1) web services
2) other electronic and non-electronic services.
e-Macao-16-5-571
UDDI Registry Service
A UDDI registry service is a web service.
The UDDI registry service manages information about:
1) service providers
2) service implementations
3) and service metadata
e-Macao-16-5-572
UDDI Usage
UDDI is used by:
1) providers - use UDDI to advertise their services
2) consumers - use UDDI to:
a) discover services that suit their requirements
b) obtain the service metadata needed to consume them
e-Macao-16-5-573
UDDI Process
1) software companies
populate the registry with
descriptions of technical
models
2) businesses populate the
registry with descriptions of
their services
Business
registries
Service
registries
UDDI Registry
3) UDDI assigns a unique
identifier to each registry
and stores them in an
Internet registry
4) search engines and
business applications
query the registry to
discover services
5) businesses use this
data to facilitate business
integration
e-Macao-16-5-574
UDDI Goals
Primary goal of UDDI:
the specification of a framework for describing and discovering web
services.
Two main goals for UDDI registry specifications:
1) support developers in finding information about services
2) enable dynamic binding
e-Macao-16-5-575
UDDI Data Structures and APIs
UDDI defines data structures and APIs for:
1) publishing service descriptions in the registry
2) querying the registry to look for published descriptions
e-Macao-16-5-576
UDDI History
The initiative was announced on 6
th
September 2000.
The first three UDDI versions were developed by uddi.org.
After completion of UDDI version 3.0, uddi.org submitted the specifications
to the Organization for the Advancement of Structured Information
Standards (OASIS).
In April 2003, the UDDI version 2.0 specifications were approved as a formal
OASIS standard.
UDDI version 3.0.2 has been published as a Committee Draft in October
2004.
The specifications are available at:
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm
e-Macao-16-5-577
UDDI Services
UDDI defines a number of lookup services allowing clients to look up and
retrieve information to access a web service.
Four services are provided to clients:
1) white pages to look up a web service by business identification
2) yellow pages to look up a web service by topic
3) green pages for searches through web services features
A service for providers:
4) UDDI business registry to publish/request information about web
services
e-Macao-16-5-578
UDDI Members
UDDI members are companies that are committed to the:
1) enhancement,
2) evolution
3) world-wide acceptance
of the UDDI registry.
For instance, some UDDI members:
a) Cisco Systems
b) IBM
c) Intel
d) Microsoft
e) NEC Corporation
f) Oracle
g) SAP
h) Sun Microsystems
i) ...
e-Macao-16-5-579
UDDI Operators
A UDDI operator is an organization that hosts an implementation of the
UDDI Business Registry (UBR).
Currently, there are four operators:
a) IBM UBR node: http://uddi.ibm.com/
b) Microsoft UBR node: http://uddi.microsoft.com/
c) SAP UBR node: http://uddi.sap.com/
d) NTT UBR node: http://www.ntt.com/uddi/
e-Macao-16-5-580
Different Operators One Registry
A company needs to register its information with only one operator, called
the custodian.
UBR is based on: register once, publish everywhere.
The information contained in one registry is replicated in the other
registries, not instantaneously, but at least every 12 hours.
A company can update its information only through its custodian.
e-Macao-16-5-581
UDDI Specifications
The UDDI specifications define:
1) SOAP APIs that applications use to query and to publish information
to a UDDI registry
2) XML Schema of the registry data model and the SOAP message
formats
3) WSDL definitions of the SOAP APIs
4) UDDI registry definitions of various identifier/category systems that
may be used to identify and categorize UDDI registrations
e-Macao-16-5-582
UDDI Outline
1) Introduction
2) Concepts
3) Data Types
a) businessEntity
b) businessService
c) bindingTemplate
d) tModel
e) publisherAssertion
f) identifierBag
g) categoryBag
4) UDDI Registry
a) registry implementations
b) publishing a service
c) finding a service
5) Summary
e-Macao-16-5-583
UDDI - UUID
A service registry maintains information about
1) businesses
2) services
3) technical information
4) specification of services
Instances of these data structures are kept separate and are identified by a
Universally Unique Identifier (UUID).
UUIDs are assigned when the data structure is first inserted in the registry.
UUIDs are hexadecimal strings whose structure and generation algorithm is
defined by the ISO/IEC 11578:1996 standard.
e-Macao-16-5-584
UDDI Other Identifiers
UDDI allows to define additional international identifiers.
These identifiers are assigned to business and technical information in order
to retrieve data according to them.
Two identifier types have been adopted and made core part of the UDDI
operator registries:
1) D-U-N-S
2) Thomas Register
e-Macao-16-5-585
D-U-N-S Identifier
D-U-N-S number is a unique nine-digit identification sequence which
provides unique identifiers of single business entities.
D-U-N-S is provided by Dun & Bradstreet.
Dun & Bradstreet is a company providing global business information, tools,
and insights.
Reference: http://www.dnb.com
e-Macao-16-5-586
Thomas Register Identifier
Thomas Register identifiers are used in Thomas Global Register.
The Thomas Global Register is a directory of manufacturers and distributors
from 28 countries.
The registry is classified by products and services categories.
Reference: http://www.thomasregister.com
e-Macao-16-5-587
UDDI Core Identifier Systems
uuid:B1B1BAF5-2329-43E6-AE13-BA8E97195039
Thomas
Registry
uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823 D-U-N-S
UUID Name
In order to take advantage of these identification systems, businesses
need to provide the relevant codes when publishing information.
This information is provided using the identifierBag element.
The UDDI - UUIDs for these identifier systems are:
e-Macao-16-5-588
Categorization and Classification
In order to improve the search procedure UDDI provides a method to
perform intelligent searches through categorization and classification.
Categorization: is the process of creating categories.
Classification: is the process of assigning objects to these predefined
categories.
UDDI defines a set of built-in classification schemes (or taxonomies):
classifies geographic
locations
ISO 3166
http://www.iso.org/iso/en/prods-services/iso3166ma
classifies products
and services
United Nations Standard Products and Services Code
(UNSPSC) http://www.unspsc.org/
classifies businesses
by industry
North American Industry Classification System (NAICS)
http://www.census.gov/epcd/www/naics.html
e-Macao-16-5-589
Classification Codes: UNSPSC
Examples of UNSPSC classification codes:
e-Macao-16-5-590
Classification Codes: NAICS
Examples of NAICS classification codes for public administration:
e-Macao-16-5-591
UDDI Classification Schemes
uuid:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88 geographic ISO 3166
uuid:CD153257-086A-4237-B336-6BDCBDCC6634
product and
services
UNSPSC
uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2 business NAICS
UUID Type Name
In order to take advantage of these classification schemes businesses
need to provide the relevant classification information as they publish their
entries.
This is done using the categoryBag element.
The UDDI - UUIDs for the classification schemes are:
e-Macao-16-5-592
UDDI Core tModels
UDDI registries store tModels.
tModels represent technical specifications.
UDDI describes the classification schemes NAICS, UNSPSC and ISO 3166
as tModels.
e-Macao-16-5-593
UDDI Type Taxonomy
UDDI type taxonomy has been established to assist in general
categorization of tModels.
UDDI type taxonomy is described as a tModel:
tModel name= uddi-org:types
tModel description = UDDI Type Taxonomy
tModel UUID: uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4
The categorization information for each tModel is added in the categoryBag
element to indicate the type of tModel.
e-Macao-16-5-594
uddi-org:types: Values 1
Some of the values defined in uddi-org:types taxonomy include:
1) namespace: represents a scoping constraint or domain for a set of
information. Similar to the namespace functionality used for XML
2) specification: is used for tModels that define interactions with
a web service
3) xmlSpec: is used to indicate that the interaction with the service is
via XML
4) soapSpec: is used to indicate that the interaction with the service is
via SOAP
e-Macao-16-5-595
uddi-org:types: Values 2
5) wsdlSpec: is used to indicate that the web service is described
using WSDL
6) protocol: is used for a tModel describing a protocol of any sort
7) transport: is used for a tModel specifying specific types of
protocols: HTTP, FTP, and SMTP
e-Macao-16-5-596
UDDI Outline
1) Introduction
2) Concepts
3) Data Types
a) businessEntity
b) businessService
c) bindingTemplate
d) tModel
e) publisherAssertion
f) identifierBag
g) categoryBag
4) UDDI Registry
a) registry implementations
b) publishing a service
c) finding a service
5) Summary
e-Macao-16-5-597
UDDI Data Types
UDDI version 2.0 is modeled using five data types:
1) businessEntity: describes an organization that provides web
services
2) businessService: describes a group of related web services offered
by a businessEntity
3) bindingTemplate: describes the technical information necessary to
use a particular web service
4) tModel: (technical model) is a generic container for any kind of
specification
5) publisherAssertion: is used to define a relationship between two or
more businessEntity elements
e-Macao-16-5-598
BusinessEntity
discoveryURLs
name
description
contacts
identifiers
categories
UDDI Data Model
businessService
service key
name
description
categories
bindingTemplate
binding key
description
accessPoint
detailed info
references to tModels
tModel
key
name
description
overviewDoc
identifiers
categories
tModel
key
name
description
overviewDoc
identifiers
categories
specs stored
at the providers
site
e-Macao-16-5-599
BusinessEntity
The structure is used to represent all known information about a business or
entity that publishes descriptive information about the entity as well as the
services that it offers.
The structure includes:
1) attributes:
a) businessKey
b) operator
c) authorizedName
2) elements:
a) discoveryURLs
b) name
c) description
d) contacts
e) businessServices
f) identifierBag
g) categoryBag
BusinessEntity
discoveryURLs
name
description
contacts
identifiers
categories
businessService
e-Macao-16-5-600
BusinessEntity Attributes
1) businessKey: UUID for a given instance of the businessEntity
structure
2) operator: is the certified name of the UDDI registry site operator that
manages the master copy of the businessEntity data
3) authorizedName: is the recorded name of the individual that published
the businessEntity data.
<?xml version="1.0" encoding="utf-8" ?>
<businessEntity businessKey="5774466b-089d-4fa8-b8cb-fa2ead5329c5
operator="Microsoft Corporation"
authorizedName=NiceWeather UDDI Publisher
. . .
e-Macao-16-5-601
BusinessEntity Elements 1
1) discoveryURLs: (optional) is used to hold pointers to alternate, file
based service discovery mechanisms.
<discoveryURLs>
<discoveryURL
useType="businessEntity">http://uddi.microsoft.com/discovery?
businessKey=5774466b-089d-4fa8-b8cb-fa2ead5329c5
</discoveryURL>
</discoveryURLs>
2) name: (repeating element) are the human readable names recorded for
the businessEntity, adorned with a unique xml:lang value
<name xml:lang=en>NiceWeather</name>
<name xml:lang=es>BuenTiempo</name>
e-Macao-16-5-602
BusinessEntity Elements 2
3) description: (optional repeating element) one or more short business
descriptions. One description is allowed per language code supplied.
<description xml:lang=en>UDDI businessEntity for NiceWeather.
</description>
<description xml:lang=es>UDDI businessEntity para BuenTiempo.
</description>
e-Macao-16-5-603
BusinessEntity Elements 3
4) contacts: (optional) list of contact information including:
a) useType: attribute describing the type of contact in freeform text
b) description: (optional) descriptions in more than one language
of the reasons for using the contact
c) personName: is the name of the person or the name of the job role
d) phone: (optional)
e) email: (optional)
f) address: (optional repeating element) this structure represents the
printable lines suitable for addressing an envelope
<contact useType=Technical Information>
<description>Contact for technical information</description>
<personName>Susan Carroll</personName>
<phone useType=Main Office>853.782.923</phone>
<email useType=CTO>susancarroll@niceweather.com</email>
<address useType=Main Office sortCode=10001>
<addressLine>2001 Kuong Building</addressLine>
<addressLine>Macao</addressLine>
</address>
</contact>
e-Macao-16-5-604
BusinessEntity Elements 4
5) businessServices: (optional) list of one or more logical business
service descriptions
6) identifierBag: (optional) list of name-value pairs that can be used
to record identifiers for a businessEntity
7) categoryBag: (optional) list of name-value pairs that are used to tag
a businessEntity with specific taxonomy information. For instance:
industry, product or geographic codes
e-Macao-16-5-605
BusinessEntity Example
<businessEntity businessKey=5441234-763E-11D5-B565-000782FD9C23>
<name xml:lang=en>NiceWeather</name>
<description xml:lang=en>UDDI businessEntity for NiceWeather.
</description>
<contacts>
<contact useType=Technical Information>
<description>Contact for technical information</description>
<personName>Susan Carroll</personName>
<phone useType=Main Office>853.782.923</phone>
<email useType=CTO>susancarroll@niceweather.com</email>
<email useType=General Information>info@niceweather.com</email>
<address useType=Main Office sortCode=10001>
<addressLine>2001 Kuong Building</addressLine>
<addressLine>Macao</addressLine>
</address>
</contact>
<contact> ... </contact>
</contacts>
<businessServices> . . . </businessServices>
<identifierBag> . . . </identifierBag>
<categoryBag> . . . </categoryBag>
</businessEntity>
e-Macao-16-5-606
BusinessService
The businessService element is the root element for describing a
logical business service.
The structure includes:
1) attributes:
a) serviceKey
b) businessKey
2) elements:
a) name
b) description
c) bindingTemplates
d) categoryBag
businessService
service key
businessKey
name
description
categories
bindingTemplate
e-Macao-16-5-607
BusinessService Attributes
1) serviceKey: UUID for identifying a given businessService.
2) businessKey: is a direct reference to the businessEntity that is
associated with it.
<businessService serviceKey=1T264170-2E3E-TE97-M9A8-F11111JE9WBH
businessKey=5441234-763E-11D5-B565-000782FD9C2 >
reference to
businessEntity
e-Macao-16-5-608
BusinessService Elements
1) name: (optional repeating element) are the human readable names
recorded for the businessService, adorned with a unique xml:lang
value
2) description: (optional) descriptions in more than one language of the
logical service family
3) bindingTemplates: this structure holds the technical service
description information related to a given business service family
4) categoryBag: (optional) list of name-value pairs that are used to tag a
businessService with specific taxonomy information. For instance:
industry, product or geographic codes.
e-Macao-16-5-609
BusinessService Example
<businessServices>
<businessService serviceKey=1T264170-2E3E-TE97-M9A8-F11111JE9WBH
businessKey=5441234-763E-11D5-B565-000782FD9C2 >
<name>ask Data Submission</name>
<description>NiceWeather ask data submission service.</description>
<bindingTemplates>
. . .
</bindingTemplates>
<categoryBag>
. . .
</categoryBag>
</businessServices>
e-Macao-16-5-610
BindingTemplate
The bindingTemplate element contains the technical information
necessary to invoke a specific web service.
The same logical service may have more than one type of binding (SOAP-
HTTP, HTTP browser-based binding, etc.), each of them is described in a
separate bindingTemplate element.
The structure includes:
1) attributes:
a) bindingKey
b) serviceKey
2) elements:
a) description
b) accessPoint
c) hostingRedirector
d) tModelInstanceDetails
bindingTemplate
binding key
serviceKey
description
accessPoint
references to tModels
e-Macao-16-5-611
BindingTemplate Attributes
1) bindingKey: UUID for identifying a given bindingTemplate
2) serviceKey: is a direct reference to the businessSevice that is
associated with it.
<bindingTemplate bindingKey=2T5FDS12-04T4-GTT6-08GF-Y67E454357T89
serviceKey= 1T264170-2E3E-TE97-M9A8-F11111JE9WBH>
reference to
businessService
e-Macao-16-5-612
BindingTemplate Elements 1
1) description: (optional) descriptions in more than one language of the
technical service entry point
2) accessPoint: is an attribute-qualified element that is used to convey
the entry point address suitable for calling a particular web service. A
single attribute named URLType is provided with the following values:
3) hostingRedirector: used to designate that a bindingTemplate
entry is a pointer to a different bindingTemplate entry. Is a required
element if accessPoint is not provided. Is adorned with a
bindingKey attribute, giving the redirected reference to a different
bindingTemplate
a) mailto
b) http
c) https
d) ftp
e) fax
f) phone
g) other
e-Macao-16-5-613
3) tModelInstanceDetails: list of zero or more tModelInstanceInfo
elements.
The tModelInstanceInfo is a distinct fingerprint used to identify
services including one attribute (tModelKey) and two elements:
a) tModelKey: is a unique key reference to a tModel describing
the implementation details of the service
b) description: (optional) descriptions in more than one
language describing what role a tModel reference plays in the
overall service description
c) instanceDetails: (optional) is a structure providing
additional information required to understand the details relative
to the tModelKey reference, or to provide further parameters
and settings support
BindingTemplate Elements 2
e-Macao-16-5-614
BindingTemplate Example
<bindingTemplate bindingKey=2T5FDS12-04T4-GTT6-08GF-Y67E454357T89
serviceKey= 1T264170-2E3E-TE97-M9A8-F11111JE9WBH>
<description>SOAP based ask data submission service.</description>
<accessPoint URLtype=http:>
http://www.example.com/WeatherService/askData
</accessPoint>
<tModelsInstanceDetails>
<tModelsInstanceInfo
tModelKey=uuid:67DF6F55-SG56-976F-9U77-570425RFD68J>
<description>HTTP address</description>
</tModelsInstanceInfo>
</tModelsInstanceDetails>
</bindingTemplate>
e-Macao-16-5-615
BindingTemplate - instanceDetails
The instanceDetails element is added to the tModelInstanceInfo
to specify additional service implementation details. It has the following
structure :
a) description: (optional) descriptions in more than one
language describing the purpose and/or the use of the particular
instanceDetails entry
b) overviewDoc: (optional) is a structure referencing to remote
descriptive information or instructions related to proper use of
the bindingTemplate technical sub-element. The structure
contains:
- description
- overviewURL
c) instanceParms: (optional) used to contain setting parameters
or a URL reference to a file containing setting or parameters
required to use a specific facet of a bindingTemplate
description
e-Macao-16-5-616
instanceDetails Example
<tModelsInstanceDetails>
<tModelsInstanceInfo
tModelKey=uuid: 9OC7WMI1-0998-0375-NE00-0702IBA09049>
<description>Reference to tModel with Web Service interface
definition
</description>
<instanceDetails>
<overviewDoc>
<description>
Reference to additional semantic specification of the
web service.
</description>
<overviewURL>
http://www.example.com/WeatherService/additionalFeatures.xml
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelsInstanceDetails>
. . .
e-Macao-16-5-617
tModel Structure
The primary role that a tModel plays is to represent a technical
specification.
The structure includes:
1) attributes:
a) tModelKey
b) operator
c) authorizedName
2) elements:
a) name
b) description
c) overviewDoc
d) identifierBag
e) categoryBag
tModel
key
name
description
overviewDoc
identifiers
categories
e-Macao-16-5-618
tModel Attributes
1) tModelKey: is a unique key for a given tModel structure
2) operator: is the certified name of the UDDI registry site operator that
manages the master copy of the tModel data
3) authorizedName: is the recorded name of the individual that published
the tModel data
e-Macao-16-5-619
tModel Elements
1) name: the name recorded for the tModel
2) description: (optional repeating element) one description is allowed
per national language code supplied
3) overviewDoc: is a structure referencing to remote descriptive
information or instructions related to proper use of the tModel. The
structure contains:
- description
- overviewURL
4) identifierBag: (optional) is an optional list of name-value pairs that
can be used to record identification numbers for a tModel
5) categoryBag: (optional) is a list of name-value pairs that are used to
tag a tModel with specific taxonomy information
e-Macao-16-5-620
tModel Example 1
<tModel tModelKey=uuid:67DF6F55-SG56-976F-9U77-570425RFD68J>
<name>Ask Weather Data Service</name>
<description xml:lang=en> Service interface definition for ask
weather data submission service.</description>
<overviewDoc>
<description xml:lang=en>Reference to the WSDL document that
contains the service interface definition for the ask data
submission service.</description>
<overviewURL>
http://www.example.com/WeatherService/askData.wsdl
</overviewURL>
</overviewDoc>
reference to the web
service description
e-Macao-16-5-621
tModel Example 2
<identifierBag>
<keyedReference keyName=DUNS
keyValue=00-111-1111
tModelKey=uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823 />
</identifierBag>
<categoryBag>
<keyedReference keyName=uddi-org:types
keyValue=soapSpec
tModelKey=uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4 />
<keyedReference keyName=uddi-org:types
keyValue=wsdlSpec
tModelKey=uuid:C1ACF26D-9672-4404-9D70-39B756E62AB />
<keyedReference keyName=Weather
keyValue=84902934
tModelKey=uuid:J6LIJ84T-3874-8301-Y9JY-2JS76GFD60J8 />
</categoryBag>
</tModel>
reference to UDDI type
taxonomy tModel
reference to
DUNS tModel
e-Macao-16-5-622
publisherAssertion 1
The publisherAssertion is a declaration done by two
businessEntitys in order to establish a relationship between them.
The relation becomes visible when both businessEntitys published the
same information.
The structure includes:
a) fromKey: UUID referencing the first businessEntity
b) toKey: UUID referencing the second businessEntity
c) keyedReference: designates the relationship between the
business entities by three attributes:
- tModelKey: reference the relationship type system
- keyName
- keyValue
are used to indicate the specific
type of relationship
e-Macao-16-5-623
publisherAssertion 2
According to the relationship type system defined in the UDDI specification:
Values for the keyValue attribute are:
1) parent-child: the business referenced by the fromKey is the
parent of the business referenced by the toKey
2) peer-peer: both businesses referenced are partners or affiliates
3) identity: both businesses referenced are the same. Is typically
used to assert different divisions, units and departments of the same
organization
Providing, publisher-assertion capabilities, UDDI allows large corporations to
describe aspects of their businesses - such as: divisions, partners, and
subsidiaries - to users of the UBR.
e-Macao-16-5-624
publisherAssertion Example
<publisherAssertion>
<fromKey>5441234-763E-11D5-B565-000782FD9C23</fromKey>
<toKey>U7O0J86-JU77-MN88-G86G-096YY8EV9JK1</toKey>
<keyedReference
keyName=subsidiary
keyValue=parent-child
tModelKey=uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03 />
</publisherAssertion>
This declaration models the relationship between the company
NiceWeather (fromKey) and its subsidiary in Hong Kong (toKey).
For this example, the keyValue attribute defines that NiceWeather is the
parent-company of NiceWeather Hong Kong.
reference to UDDI
relationships tModel
e-Macao-16-5-625
identifierBag
UDDI defines the notion of attaching identifiers to data using the
identifierBag
Two of the core data types support attaching identifiers to data:
1) businessEntity
2) tModel
An identifierBag is an element that holds zero or more instances of
something called keyedReference.
e-Macao-16-5-626
identifierBag Example
<identifierBag>
<keyedReference keyName=DUNS
keyValue=00-111-1111
tModelKey=uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823 />
</identifierBag>
Is a general-purpose structure for a name-value pair with one additional
attribute referencing a tModel structure
The reference to a tModel structure makes the identifier scheme
extensible, allowing tModels to be used as a conceptual namespace
qualifiers.
reference to
DUNS tModel
e-Macao-16-5-627
categoryBag
The categoryBag is the container that describes relevant classification
information that businesses provide when publishing their services.
<categoryBag>
<keyedReference keyName=uddi-org:types
keyValue=soapSpec
tModelKey=uuid:T6TGU76T-9876-3234-4J90-34J997T78TG5 />
</categoryBag>
Three of the core data types support attaching identifiers to data:
1) businessEntity
2) businessService
3) tModel
e-Macao-16-5-628
categoryBag Example
<categoryBag>
<keyedReference keyName=Weather Station
keyValue=41114410
tModelKey=CD153257-086A-4237-B336-6BDCBDCC6634/>
<keyedReference keyName=Macao
keyValue=MO
tModelKey=4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88/>
</categoryBag>
This categoryBag corresponds to the businessEntity of NiceWeather.
We are defining that the business belongs to the 41114410 category that
corresponds to weather stations according to UNSPSC codes, and we are
locating the company in Macao according to ISO-3166.
reference to UNSPSC tModel
reference to ISO 3166 tModel
e-Macao-16-5-629
UDDI Outline
1) Introduction
2) Concepts
3) Data Types
a) businessEntity
b) businessService
c) bindingTemplate
d) tModel
e) publisherAssertion
f) identifierBag
g) categoryBag
4) UDDI Registry
a) registry implementations
b) publishing a service
c) finding a service
5) Summary
e-Macao-16-5-630
Using a UDDI Registry
A UDDI is itself an instance of a web service.
Entries in the registry can be published and queried using SOAP-based
service interface.
The WSDL service interface definitions for a UDDI registry can be found at:
http://uddi.org/wsdl/uddi_api_v3_binding.wsdl
UDDI Bindings
API v 3.0
http://uddi.org/wsdl/uddi_api_v3_portType.wsdl
UDDI portTypes
API v3.0
http://uddi.org/wsdl/publish_v2.wsdl
UDDI Publication
API v2.0
http://uddi.org/wsdl/inquire_v2.wsdl
UDDI Inquiry
API v2.0
e-Macao-16-5-631
UDDI Business Registry 1
Four organization hosts nodes in the UDDI Business Registry.
Most of them also host a test registry.
Three URLs are provided for each:
https://uddi.ibm.com/testregistry/publishapi Publish
http://www-3.ibm.com/services/uddi/testregistry/inquiryapi
Inquiry
http://uddi.ibm.com/testregistry/registry.html Web IBM Test Registry
http://uddi.ibm.com/ubr/publishapi Publish
http://uddi.ibm.com/ubr/inquiryapi Inquiry
http://uddi.ibm.com Web
IBM Business
Registry
URL Access
Type
Host Organization
e-Macao-16-5-632
UDDI Business Registry 2
http://uddi.sap.com Web SAP Business
Registry
http://uddi.sap.com/uddi/api/inquiry Inquiry
https://uddi.sap.com/uddi/api/publish Publish
http://udditest.sap.com Web SAP Test
Registry
http://udditest.sap.com/UDDI/api/inquiry Inquiry
https://udditest.sap.com/UDDI/api/publish Publish
https://test.uddi.microsoft.com/publish Publish
http://test.uddi.microsoft.com/inquire Inquiry
http://test.uddi.microsoft.com Web Microsoft Test
Registry
https://uddi.microsoft.com/publish Publish
http://uddi.microsoft.com/inquire Inquiry
http://uddi.microsoft.com Web
Microsoft Business
Registry
URL Access Type Host Organization
e-Macao-16-5-633
UDDI Business Registry 3
https://www.uddi.ne.jp/ubr/publishapi Publish
http://www.uddi.ne.jp/ubr/inquiryapi Inquiry
http://www.ntt.com/uddi Web
NTT Business
Registry
URL Access Type Host Organization
e-Macao-16-5-634
Task 78: UDDI Registry
1) access the UDDI v2 IBM Business Registry: http://uddi.ibm.com
2) select option Search UDDI Business Registry
3) search for Business starting with: Public Administration
4) select Administration Division
5) access the file in the DiscoveryURL
6) save this file in your PC
e-Macao-16-5-635
Task 79: Test UDDI Registry
7) open the file:
a) where is the master copy of the businessEntity data?
b) who registered the information for this businessEntity?
c) access the business contact on the web page containing the
businessEntity information
d) what is the information described for the contact? check the address
details with the information on the XML file
e) how many services related does the business have?
f) what is the information provided for this service and how can you
access this service?
e-Macao-16-5-636
Task 80: Test UDDI Registry
8) go back to the page where the results of step 3 where shown
9) select services for the Administration Division
10) what is the information shown in the page?
11) what links are provided?
12) select home page
13) what information is provided?
e-Macao-16-5-637
Publishing Service Descriptions 1
Most UDDI operators require the user to register before publishing any
UDDI entries.
The registration process provides a publisher account consisting on a user-
id and a password.
Entries in the registry are owned by the publisher who created them, and
only the owner can update or delete a registry entry.
The UDDI publication APIs provide support for creating, updating, and
deleting the following entries:
1) businessEntity
2) businessService
3) bindingTemplate
4) tModel
5) publisherAssertions
e-Macao-16-5-638
Authentication Token
Before using a publication API, an authentication token must be obtained,
using the get_authToken API call.
Authentication tokens are required for all publication APIs. They represent
an active session with the registry.
Authentication tokens are valid for a period of time defined by the registry.
The discard_authToken message is used to indicate the registry that
the token can be discarded.
e-Macao-16-5-639
APIs for Publishing
APIs for publishing the four primary data types:
The get_registeredInfo API call is used to obtain a complete list of
businessEntity and tModel entries owned by the publisher.
delete_tModel save_tModel tModel
delete_service save_service serviceBusiness
delete_business save_business businessEntity
delete_binding save_binding bindingTemplate
Delete API Save API Datatype
e-Macao-16-5-640
Publishing Publisher-Assertions
Five APIs are used to process publisher assertions:
1) add_publisherAssertions
2) delete_publisherAssertions
3) get_publisherAssertions: gets the full list of publisher
assertions associated with a publishers assertion collection
4) get_assertionsStatusReport: determines the status of current
assertions
5) set_publisherAssertions: adds new assertions or updates
existing assertions
e-Macao-16-5-641
WSDL and UDDI
UDDI provides a method for publishing and finding businesses and services
information.
UDDI provides support for many different types of service descriptions:
1) WSDL
2) plain ASCII text
3) RDF
4) others
The service description information defined in WSDL is complementary to
the information found in a UDDI registry.
e-Macao-16-5-642
Mapping from WSDL to UDDI 1
Service Interface Definition
types
portType
message
binding
Service Implementation Definition
import
service
port
represents the reusable part
of a service description
UDDI registry
tModel
business
Service
a reference is published in
describes an instance of a
service
a service element maps to
e-Macao-16-5-643
Mapping from WSDL to UDDI 2
Service Interface Definition
types
portType
message
binding
Service Implementation Definition
import
service
port
tModel
overviewDoc
overviewURL
businessService
bindingTemplate
accessPoint
tModelInstanceDetails
tModelsInstanceInfo
instanceDetails
overviewDoc
overviewURL
Not covered in
best practices
document
WSDL UDDI
e-Macao-16-5-644
Mapping Co-Relations
1) Service Interface Definition - UDDI-tModel:
a) the overviewDoc field in each new tModel will point to the
corresponding WSDL document
2) Service Implementation Definition UDDI-businessService:
a) a bindingTemplate is created for each access endpoint. The
network address of the access point is the accessPoint
element
b) one tModelInstanceInfo is created in the
bindingTemplate for each wsdlSpec tModel that defines
interfaces and bindings supported by the service
e-Macao-16-5-645
Procedure for Publishing Services
1) the WSDL service interface definition is created
2) the WSDL service interface definition is registered as UDDI tModels.
Such models are called wsdlSpec tModels
3) programmers will build services conforming to the service definitions
4) the new service must be deployed and registered in the UDDI registry. A
UDDI businessService data structure is created and registered
e-Macao-16-5-646
Publishing a Service Example 1
1) the WSDL service interface definition is created
2) the WSDL service interface definition is registered as UDDI tModel.
<tModel authorizedName= operator=
tModelKey=9OC7WMI1-0998-0375-NE00-0702IBA09049>
<name>Ask Weather Data Service</name>
<description xml:lang=en>
WSDL description of a standard ask data about weather service.
</description>
<overviewDoc>
<description xml:lang=en>WSDL source document.</description>
<overviewURL> http://www.example.com/WeatherService/askData.wsdl
</overviewURL>
<overviewDoc>
<categoryBag>
<keyedReference
tModelKey=uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4
keyName=uddi-org:types
keyValue=wsdlSpec />
</categoryBag>
</tModel>
reference WSDL binding element
tModel is categorized as a WSDL specification
e-Macao-16-5-647
Publishing a Service Example 2
3) after the service is deployed, is registered as a businessService:
<businessService serviceKey=1T264170-2E3E-TE97-M9A8-F11111JE9WBH
businessKey=5441234-763E-11D5-B565-000782FD9C23>
<name>Ask Data Service</name>
<description>Ask data submission service.</description>
<bindingTemplates>
<bindingTemplate bindingKey=2T5FDS12-04T4-GTT6-08GF-Y67E454357T89
serviceKey= 1T264170-2E3E-TE97-M9A8-F11111JE9WBH>
<description>SOAP based ask data submission service.</description>
<accessPoint URLType=http:>
http://www.example.com/WeatherService/askData
</accessPoint>
<tModelsInstanceDetails>
<tModelsInstanceInfo
tModelKey=uuid: 9OC7WMI1-0998-0375-NE00-0702IBA09049>
<description>Reference to tModel with Web Service interface
definition
</description>
URL where the WS can be invoked
reference to tModel (wsdlSpec)
e-Macao-16-5-648
Publishing a Service Example 3
<instanceDetails>
<overviewDoc>
<description>
Reference to WSDL service implementation document.
</description>
<overviewURL>
http://www.example.com/WeatherService/askDataImplementation.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelsInstanceDetails>
</bindingTemplate>
</bindingTemplates>
. . .
</busienessService>
reference to service implementation definition
(not defined in best practices)
e-Macao-16-5-649
Service with Multiple Bindings 1
The WSDL service interface definition contains multiple bindings:
<portType name=CancelUserPortType>
. . .
</portType>
<portType name=AskDataPortType>
. . .
</portType>
<binding name=CancelUserSoapBinding>
. . .
</binding>
<binding name=AskDataSoapBinding>
. . .
</binding>
e-Macao-16-5-650
Service with Multiple Bindings 2
Create a tModel for each binding definition using an XPointer in the
overviewURL element
. . .
<overviewDoc>
<description>
Reference to WSDL service implementation document.
</description>
<overviewURL>
http://www.example.com/WeatherService/MultipleBindings.wsdl
xmlns(wsdl=http://schemas.xmlsoap.org/wsdl/)
xpointer (//wsdl:binding[@name=AskDataSoapBinding])
</overviewURL>
</overviewDoc>
. . .
e-Macao-16-5-651
Finding Service Description 1
When finding service descriptions, two types of inquiry APIs are available:
1) find APIs:
a) find_binding: returns the contents of a bindingTemplate
b) all others (business, service, tModel): retrieve a list of references
(UDDI keys) to UDDI data entries matching the specified search
criteria
2) get APIs: return the actual contents of a data entry
e-Macao-16-5-652
Finding Service Description 2
APIs for inquiring the four primary data types:
get_tModelDetail find_tModel tModel
get_serviceDetail find_service serviceBusiness
get_businessDetail find_business businessEntity
get_bindingDetail find_binding bindingTemplate
Get API Find API Datatype
e-Macao-16-5-653
Task 81: Find Business
Objective: find businesses in the IBM test UUDI registry. The name must
match Business, case sensitive match, 100 instances.
1) cd demos\UDDI\FindBusiness
2) dir
FindBusinessExample.class
FindBusinessExample.java
1) notepad FindBusinessExample.java
2) java cp demos\UDDI\FindBusiness FindBusinessExample
e-Macao-16-5-654
Task 82: Find Service
Objective: find a service in the IBM test UUDI registry. The tModel key is:
AFFC30D0-D83E-11D5-8055-0004AC49CC1E.
1) cd demos\UDDI\FindService
2) dir
FindServiceExample.class
FindServiceExample.java
1) notepad FindServiceExample.java
2) java classpath demos\UDDI\FindService
FindServiceExample
e-Macao-16-5-655
UDDI Outline
1) Introduction
2) Concepts
3) Data Types
a) businessEntity
b) businessService
c) bindingTemplate
d) tModel
e) publisherAssertion
f) identifierBag
g) categoryBag
4) UDDI Registry
a) registry implementations
b) publishing a service
c) finding a service
5) Summary
e-Macao-16-5-656
UDDI Summary 1
UDDI is a platform independent, open framework for describing, discovering
and integrating business services
Two types of service discovery:
1) static
2) dynamic
e-Macao-16-5-657
UDDI Summary 2
How it works:
a) service providers publish information about businesses and
services
b) UDDI assigns unique identifiers to the information provided
c) service requestors query the registry
d) data returned is used to invoke web services
e-Macao-16-5-658
UDDI Summary 3
Four services provided:
a) white pages to look up a web service by the business
b) yellow pages to look up a web service by topic
c) green pages to look up a service through web services features
d) publish information
e-Macao-16-5-659
Global registry hosted by UDDI operators: IBM, Microsoft, SAP, NTT
UDDI principle: register once publish everywhere
UDDI provides two core systems for identifying businesses and services:
1) D-U-N-S
2) Thomas Register
UDDI provides three classification schemes:
1) NAICS
2) UNSPSC
3) ISO-3199
UDDI Summary 4
e-Macao-16-5-660
UDDI is modeled using five data types:
1)businessEntity
2)businessService
3)bindingTemplate
4)tModel
5)publisherAssertion
UDDI Summary 5
e-Macao-16-5-661
1) businessEntity: represents all the information about a business
2) businessService: describes a logical business service
3) bindingTemplates: contains the technical information needed to
invoke a web service
4) tModel: represents a technical model specification
5) publisherAssertion: establishes a relation between two
businessEntitys
UDDI Summary 6
e-Macao-16-5-662
1) identifierBag and categoryBag can be defined for
businessEntity and tModels.
2) categoryBag can also be defined for businessService
3) UDDI provides the UDDI type taxonomy for assisting in general
categorization of the tModels themselves
UDDI Summary 7
e-Macao-16-5-663
1) APIs are provided for publishing the four core data types:
a) save_business
b) save_service
c) save_binding
d) save-tModel
2) four APIs are also provided to delete the information related to these
core data types.
3) five APIs are used to process publisher assertions:
add / delete / get_publisherAssertions,
get_assertionsStatusReport and
set_publisherAssertions
4) for retreving information, two types of APIS are available:
1) find_business - find_(service/binding/tModel)
2) get_businessDetail -
get_(service/binding/tModel)Detail
UDDI Summary 8
e-Macao-16-5-664
The WSDL service interface definition of a web service is created and
published as a tModel.
The overviewURL of the tModel points to the WSDL document.
After the service implementation is built and deployed, it is published as a
businessService.
A bindingTemplate is created for each access endpoint.
The accessPoint contains the network address of the service
Implementation.
If the WSDL service interface definition contains multiple bindings, a tModel
is created for each binding definition using an XPointer in the overviewURL
element.
UDDI Summary 9
Security
e-Macao-16-5-666
Course Outline
1) Introduction
2) SOAP
a) introduction
b) messaging
c) data structures
d) protocol binding
e) binary data
3) WSDL
a) introduction
b) the language
c) transmission primitives
d) WSDL extensions
e) WSDL and Java
4) AXIS
a) concepts
b) service invocation
c) tools and configuration
d) service deployment
e) service lifecycle
5) UDDI
a) introduction
b) concepts
c) data types
d) UDDI registry
6) Security
a) security basics
b) web service security
c) digital signatures
e-Macao-16-5-667
Security Outline
1) Security Basics
2) Web Service Security
3) Digital Signatures
e-Macao-16-5-668
Security Context
e-Business as well as e-Government relies on the exchange of information
between partners over insecure networks.
Sending messages over insecure networks implies risks.
Messages could be:
a) stolen
b) lost
c) modified
e-Macao-16-5-669
Security Requirements
Four security requirements must be addressed to ensure the safety of
information exchanged among partners:
a) confidentiality
b) integrity
c) authentication
d) non-repudiation
One security requirement to assure resources:
1) authorization
protect messages
protects resources
e-Macao-16-5-670
Confidentiality
Guarantees that exchanged information is protected against
eavesdroppers.
For example:
a) licenses information should not be exposed to outsiders
b) credit card information should not be wiretapped by third
parties
e-Macao-16-5-671
Integrity
Assures that a message is not accidentally or deliberately modified in
transit.
For example:
a) social security benefitss information should not be modified as it
moves between citizens and government
e-Macao-16-5-672
Authentication
Guarantees that access to e-applications and data is restricted to those who
can provide appropriate proof of identity.
For example:
a) in order to track the status of a license application, subscribers are
required to provide an ID and password as proof of their identity
e-Macao-16-5-673
Non-Repudiation
Guarantees that the messages sender cannot deny having send it.
For example:
a) with non-repudiation, once an application license is submitted, the
business cannot repudiate it
e-Macao-16-5-674
Decides whether an entity with a given identity can access a particular
resource
For example:
a) a particular citizen can only view the information related to him
Authorization
e-Macao-16-5-675
Cryptography
Cryptography technologies provide a basis for protecting messages
exchanged between partners.
A process based on algorithms transforming a clear text message
plaintext, in encrypted data - ciphertext.
hello &(5%y
encrypt decrypt
hello
plaintext ciphertext plaintext
e-Macao-16-5-676
Cryptography Algorithms
Most of the algorithms use a key to encrypt and decrypt.
According to the keys used, encrypting algorithms can be classified in:
1) symmetric
2) asymmetric
RSA-SHA1
HMAC-SHA1
HMAC-MD5
Digital signature
RSA15 3DES AES RC4 Encryption
Asymmetric key Symmetric key
Different
technologies
e-Macao-16-5-677
Symmetric Encryption
Requires the use of the same key for encryption and decryption.
plaintext
sender
plaintext
receiver
ciphertext
same key
e-Macao-16-5-678
DES Algorithm
DES Data Encryption Standard: developed by IBM and approved by the
National Bureau of Standards (NBS).
short key parity plaintext
algorithm
ciphertext
64 bits
64 bits 56 bits 8 bits
16 times
e-Macao-16-5-679
Asymmetric Encryption
Uses two keys: public and private key
plaintext
sender
plaintext
receiver
ciphertext
receivers public key receivers private key
e-Macao-16-5-680
Asymmetric Encryption Process

receivers
public key
plaintext
ciphertext ciphertext
plaintext
public domain
private domain
receivers
private key
Sender: Receiver:
e-Macao-16-5-681
Symmetric Digital Signature
Symmetric digital signature technology is called Message Authentication
Code (MAC) technology.
MAC relies on mathematical algorithms known as hashing functions to
ensure data integrity.
A hashing function takes data as input and produces smaller data called
digest.
In MAC, the digest is created with a key in addition to the input data.
hashing
function
digest
e-Macao-16-5-682
Symmetric Digital Signature
MAC
generates
MAC
verifies
MAC
sender sender receiver
Keyed-Hashing for Message Authentication Code (HMAC) is an example
of MAC.
HMAC is combined with hashing functions such as MD5 and SHA-1.
Therefore, the algorithm names: HMAC-SHA1 and HMAC-MD5.
e-Macao-16-5-683
Digital Signature
The asymmetric digital signature technology is called digital signature.
The sender signs the plaintext with his private key.
Signing means creating a signature value that is sent with the original plaintext.
Like MAC algorithms, digital signature algorithms are also combined with
hashing functions such as SHA-1 (SHA: Secure Hash Algorithm).
e-Macao-16-5-684
Digital Signature Process

public
domain
sender
plaintext
hashing
algorithm
hash value
8e:6511
:vr:
digital signature
senders
public key
plaintext
8e:6511
8e:6511
compare
private
domain
senders
private key
hashing
algorithm
hash value
hash value
:vr:
ok
fail
receiver
e-Macao-16-5-685
Use of Digital Signature
The digital signature technology ensures:
a) non-repudiation: the receiver can assure the message is signed
by the sender because he is using the senders public key to
decrypt the message
b) integrity: the receiver can assure that the message was not
changed during the transmission
e-Macao-16-5-686
Public Key Infrastructure
How can the receiver know that Person A is the holder of the public key?
Public Key Infrastructure (PKI) provides a solution.
In PKI an authority issues digital certificates.
Digital certificates are used to bind a party to a public key.
e-Macao-16-5-687
Different Solutions
Different solutions may be applied to assure security:
1) password authentication
2) HTTP Basic Authentication
3) digital signature authentication
4) secure protocols SSL
e-Macao-16-5-688
Password Authentication
Password authentication is the most commonly used authentication method
on the Internet:
1) a client shows its ID or username and password
2) the server checks the ID and password in a user registry
Password authentication to access Web servers over HTTP is called HTTP
Basic Authentication (BASIC-AUTH) and its defined in RFC 2617
e-Macao-16-5-689
HTTP Basic Authentication
Is an interaction protocol between a Web browser and a Web server.
1:GET/protected/index.html/HTTP/1.0
2:HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic real=Basic
Authentication Area
3:GET/protected/index.html HTTP/1.0
Authorization:Basic dGTiyahsduUTgfasg
4:HTTP/1.0 200 OK
Web Browser
Web Server
e-Macao-16-5-690
Digital Signature Authentication
Digital signatures can also be used for authentication.
Is more convenient than password authentication since a certificate
authority manages certificates.
Use of certificates:
1) client certificates are not widely used - not easy for users to install
certificates.
2) server certificates are commonly used - when web browsers need to
authenticate servers.
e-Macao-16-5-691
Security Protocols - SSL
Security protocols allows to share symmetric keys between partners in a
secure manner.
SSL Secure Socket Layer defined by Netscape for Web browsers is the
most widely used protocol on the Internet:
1) enables to share symmetric keys
2) performs authentication
e-Macao-16-5-692
SSL Protocol
Client:
1) accesses the server
3) prepares a random number
(a seed for generating a symmetric
key)
4) encrypts the seed number with a
public key contained in the server
certificate
5) sends the encrypted data to the
server
7) generates a symmetric key
based on the seed number
Server:
2) returns its certificate
6) decrypts the received data to
extract the seed number
7) generates a symmetric key based
on the seed number
e-Macao-16-5-693
SSL authentication is based on encryption.
After the negotiation has been completed, the client and the server can
authenticate themselves:
1) the client authenticating the server:
a) client sends application data encrypted with the symmetric key
b) server sends response encrypted with the symmetric key
c) client can authenticate the server
2) the server authenticating the client two ways:
1) HTTP Basic Authentication
2) the client is required to decrypt a random number encrypted with its
public key
SSL Authentication
e-Macao-16-5-694
To solve the difficulties of combining security technologies properly, security
infrastructures have been developed and are use in real systems.
A security infrastructure is a basis on which applications can interact with
each other securely.
Security Infrastructure
security infrastructure
Application
Application
communication
protect protect protect
e-Macao-16-5-695
Different Security Infrastructures
Each security infrastructure has different design requirements and vary in
terms of their design and architecture.
Three security infrastructures will be presented:
a) user registries
b) Public Key Infrastructure
c) Kerberos
e-Macao-16-5-696
User Registries
The most basic security infrastructure used for authentication.
User registries manages users identification and password.
An authentication module is placed in front of applications checking each
ID/password with the user registry.
user
registry
Application
A
u
t
h
e
n
t
i
c
a
t
i
o
n
Requester message
with ID/Password
e-Macao-16-5-697
User Registries Usage
The advantage is its simplicity.
The disadvantage is that they may be cracked. Once a password is stolen,
the attacker can easily access a system.
Operating systems, Data Base Management Systems (DBMS) and HTTP
servers incorporate user registries.
The cost for development and management of user registries is cheaper
than other mechanisms.
e-Macao-16-5-698
Public Key Infrastructure
Public Key Infrastructure provides a basis to certify holders of public keys.
The key constructs of PKI are:
1) certificate: a proof of identity
2) certificate authority: an entity that issues certificates.
e-Macao-16-5-699
Use of Certificates
1) X registers its public key in CA
2) CA issues a certificate to X
3) X signs a message with the
private key and sends it to B,
attaching the certificate
4) Y verifies the signature using
a public key included in the
certificate
5) Y verifies if the certificate is
signed by CA
CA
X
1
3
4
Y
2
e-Macao-16-5-700
Certificate Example
certificate
e-Macao-16-5-701
Valid Signed Message Example
e-Macao-16-5-702
Invalid Signed Message Example 1
e-Macao-16-5-703
Invalid Signed Message Example 2
e-Macao-16-5-704
Kerberos
Kerberos was initially developed for workstation users who wanted to
access a network.
Key requirements:
1) Single Sign ON (SSO): a user provides an ID and a password only
once to access various applications within a certain interval
2) no use of public key cryptography
e-Macao-16-5-705
Use of Kerberos
1) X logins in KDC (Key
Distribution Center) using
password authentication and
requests a Ticket-Granting
Ticket
2) X receives TGT from KDC
3) X requests and receives a
service ticket (ST) for Y,
showing the TGT to the KDC
4) X can now access Y by
including the ST in a request
message
KDC
X
Y
TGT
login
TGT
ST
encrypted message
ST
e-Macao-16-5-706
Ticket-Granting Ticket
The TGT contains:
1) users ID
2) session key
3) TGT expiration time
As long as the TGT is valid, X can get various STs without giving its ID and
password. Therefore, single sign on is achieved.
When issuing the ST, KDC encrypts Xs information with Ys information.
Thus, only Y can decrypt Xs ID in the ST.
ST contains a session key between X and Y, so they can securely exchange
messages with encryption and digital signatures.
e-Macao-16-5-707
Security Domains
Each security infrastructure has a scope.
The scope determines the participants and resources managed by the
security infrastructure.
User registries and Kerberos have explicit databases defining their scope.
CA implicitly prescribes a set of participants in PKI.
The scope of the security infrastructure is called security domain.
e-Macao-16-5-708
Multiple Security Domains
Multiple security domains exist in the real world.
Is out of question considering a single security infrastructure to integrate
them.
Web services security addresses how to integrate security domains based
on different security infrastructure.
e-Macao-16-5-709
Security Outline
1) Security Basics
2) Web Service Security
3) Digital Signatures
e-Macao-16-5-710
Web Services Security
Each business has its own security infrastructure.
Web services need to interoperate over different security domains.
The security model for web services defines:
1) concepts
2) architecture
e-Macao-16-5-711
WS Security Model Concepts
Some concepts used in the WS security model include:
1) security token
2) subject
3) claim
4) web service endpoint policy
5) security token service
e-Macao-16-5-712
Security Token
A security token is a piece of information related to security.
For instance a security token can be:
1) a X.509 certificate,
2) Kerberos ticket,
3) username,
4) mobile device security token from a SIM card,
5) etc.
e-Macao-16-5-713
Subject
A subject is an entity about which the claims expressed in the security
token apply.
For instance:
1) a person
2) an application
3) business
e-Macao-16-5-714
Claim
A claim is a statement about a subject.
A claim can be done by:
1) the subject itself
2) a third party that associates a subject with a claim
For instance, claims:
1) may be about keys that may be used to sign or encrypt messages
2) may be statements of the security token itself
3) may be used to assert the users identity or an authorized role
e-Macao-16-5-715
Web Service Endpoint Policy
A Web service endpoint policy are the claims and related information that
web services require in order to process messages.
Endpoint policies may be expressed in XML.
Endpoint policies can be used to indicate requirements related to:
1) authentication proof of user
2) authorization proof of execution capabilities
3) other requirements
e-Macao-16-5-716
Security Token Service (STS)
A security token service is a third party issuing security tokens.
For instance:
1) the certificate authority in PKI
2) Key Distribution Center in Kerberos
A security token service is a web service.
e-Macao-16-5-717
WS Security Architecture
The web services security architecture defines an abstract model for
managing security based on three parties:
a) requestor
b) web service
c) security token service
e-Macao-16-5-718
Security Model for WS
Requester
Security
Token
Policy
Claims
Security
Token
Service
Policy
Security
Token
Claims
Web
Service
Policy
Security
Token
Claims
Each party has its own claims, security token and policy.
e-Macao-16-5-719
Scenario for the Security Model
1) One end - the requestor:
a) wants to invoke a web service
b) has claims, such as identity and privileges
2) other end - the web service:
a) has a policy requires encryption of messages and
authentication of requestors
e-Macao-16-5-720
Sending Security Claims
How security claims can be represented in messages?
WS security model suggest that all security claims should be included in the
security token that is attached to the request message.
For instance:
1) identification via password
2) X.509 certificate
are security claims, therefore they are represented as security tokens
attached to the message.
e-Macao-16-5-721
WS Security Specifications
On April 2004 OASIS officially announced Web Services Security v1.0,
composed of:
1) Web Services Security: SOAP Message Security 1.0 (WS-Security
2004)
2) Web Services Security Username Token Profile 1.0
3) Web Services Security X.509 Certificate Token Profile
4) two XML schema documents:
a) secext.xsd
b) utility.xsd
Reference: http://www.oasis-open.org/committees/wss/
e-Macao-16-5-722
WSS - SOAP Message Security 1
Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)
specification proposes a standard set of SOAP (1.1 and 1.2) extensions.
It can be used when building secure web services to implement message
content integrity and confidentiality.
Provides support for:
1) multiple security token formats
2) multiple trust domains
3) multiple signature formats
4) multiple encryption technologies
e-Macao-16-5-723
WSS - SOAP Message Security 2
The specification provides three main mechanisms:
1) ability to send security tokens as part of a message
2) message integrity
3) message confidentiality
They do not provide a complete security solution for WS.
This specification is a building block that can be used in conjunction with
other WS extensions.
e-Macao-16-5-724
SOAP Security Namespaces
The XML namespaces URI that must be used by implementations are:
wsse: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
wsu: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
The XML namespaces URI for digital signature and encryption are:
ds: http://www.w3.org/2000/09/xmldsig#
xenc: http://www.w3.org/2001/04/xmlenc#
e-Macao-16-5-725
SOAP Message Security Model
The specification uses security tokens combined with digital signatures to
protect and authenticate messages.
Security tokens:
1) state claims
2) can be used to declare the binding between authentication keys and
security identities
Signatures are used to verify the message origin and integrity:
1) bind the identity of the sender with the message
2) confirm the claims in a security token
e-Macao-16-5-726
Message Protection
The specification provides a means to protect a message by encrypting
and/or digitally signing a body, a header, or any combination of them.
Message integrity is provided by XML Signature [XMLSIG] in combination
with security tokens to ensure that modifications to messages are detected.
Message confidentiality leverages XML Encryption [XMLENC] in conjunction
with security tokens to keep portions of a SOAP message confidential.
The specification defines syntax and semantics of signatures within
<wsse:Security> element.
e-Macao-16-5-727
Rules for Invalid Messages
A message recipient should reject messages:
a) containing invalid signatures
b) messages missing necessary claims
c) messages whose claims have unacceptable values
These are unauthorized or malformed messages.
e-Macao-16-5-728
SOAP Security Example 1
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..."
xmlns:ds="...">
<S11:Header>
<wsse:Security xmlns:wsse="...">
<xxx:CustomToken wsu:Id="MyID"
xmlns:xxx="http://www.example.com/token">FHUIORv...
</xxx:CustomToken>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<ds:Reference URI="#MsgBody">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
1) what is being signed
2) type of canonicalization being used
e-Macao-16-5-729
SOAP Security Example 2
<ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#MyID"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S11:Header>
<S11:Body wsu:Id="MsgBody">
<tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">QQQ
</tru:StockSymbol>
</S11:Body>
</S11:Envelope>
e-Macao-16-5-730
Id Attribute
There are many situations where elements within SOAP messages need to
be referenced.
The specification introduces wsu:ID attribute to reference elements.
Example:

<ds:Reference URI="#MsgBody">
...
<S11:Body wsu:Id="MsgBody">
e-Macao-16-5-731
Security Header
The <wsse:Security> header block provides a mechanism for attaching
security-related information targeted at a specific recipient.
<S11:Envelope>
<S11:Header>
. . .
<wsse:Security soap:role= soap:mustaunderstand=.. >
. . .
</wsse:Security>
. . .
</S11:Header>
. . .
</S11:Envelope>
This header is extensible by design -it supports many types of security
information.
e-Macao-16-5-732
Security Headers Rules 1
A message may have multiple <wsse:Security> headers if they are
targeted for separate recipients.
Only one <wsse:Security> header may omit the role attribute (actor
in SOAP 1.1).
Two <wsse:Security> headers must not have the same value for the
role attributes (actor in SOAP 1.1).
e-Macao-16-5-733
Security Headers: Rules 2
Message security information targeted for different recipients must appear
in different <wsse:Security> header blocks.
The <wsse:Security> header block without a specified role (or actor)
may be processed by anyone, but must not be removed prior to the final
destination or endpoint.
e-Macao-16-5-734
Security Tokens
The extensibility of the <wsse:Security> header allows to insert security
tokens based on XML into the header.
The security token may be:
a) user name token
b) binary security token
c) XML token
e-Macao-16-5-735
User Name Token
The <wsse:UsernameToken> element is introduced as a way of providing
a username.
This element is optionally included in the <wsse:Security> header.
It contains a mandatory UserName and an optional Password sub-
elements.
It is used for password authentication, such as HTTP Basic Authorization.
Disadvantage - the plaintext representation is extremely insecure.
e-Macao-16-5-736
User Name Token Example
<S11:Envelope xmlns:S11=... xmlns:wsse=... >
<S11:Header>
<wsse:Security>
<wsse:UsernameToken wsu:ID= >
<wsse:Username>Mary</wsse:Username>
</wsse:UsernameToken>
</wsse:Security>
. . .
</S11:Header>
. . .
</S11:Envelope>
e-Macao-16-5-737
Binary Security Token
Binary security tokens, such as: X.509 certificates or Kerberos tickets, or
other non-XML formats require a special encoding format for inclusion.
The <wsse:BinarySecurityToken> element defines two attributes:
1) <ValueType>: indicates what is the security token:
2) <EncodingType>: specifies how the security token is encoded,
using a URI
Kerberos service ticket Kerberos5ST
Kerberos ticket-granting ticket Kerberos5TGT
X.509 v3 digital certificate X509v3
e-Macao-16-5-738
Binary Security Token Example
<wsse:BinarySecurityToken wsu:ID=Kerberosv5ST
ValueType=Kerberosv5ST
EncodingType=wsse:Base64Binary />
e-Macao-16-5-739
XML Token
The specification also defines multiple mechanisms for identifying and
referencing security tokens using:
1) wsu:ID attribute
2) wsse:SecurityTokenReference element
e-Macao-16-5-740
Security Token Reference
A security token conveys a set of claims.
Sometimes these claims reside somewhere else and need to be retrieved by
the receiving application.
The <wsse:SecurityTokenReference> element provides an extensible
mechanism for referencing security tokens.
<wsse:SecurityTokenReference wsu:ID=...>
. . .
</wsse:SecurityTokenReference>
e-Macao-16-5-741
Use of Security Token Reference
The <wsse:SecurityTokenReference> element can be used as a direct
child element of <ds:KeyInfo> to indicate a hint to retrieve the key
information from a security token placed somewhere else.
It is recommended to use it when applying XML Signature and XML
Encoding to reference the security token used for the signature or
encryption.
<wsse:SecurityTokenReference>
<wsse:Reference URI="#MyID"/>
</wsse:SecurityTokenReference>
e-Macao-16-5-742
Security Outline
1) Security Basics
2) Web Service Security
3) Digital Signatures
e-Macao-16-5-743
Signatures
Signatures are used to:
1) enable message recipients to determine whether the message was
altered in transit
2) verify that the claims in a particular security token apply to the
producer of the message
The specification allows multiple signatures and signature formats to be
attached to a message.
Each signature may refer to different or overlapping parts of a message.
e-Macao-16-5-744
Signature Algorithms
The specification builds on XML Digital Signature Specification.
XML Digital Signature specification (XML Signature) defines how to sign part
of an XML document in a flexible manner, using two canonicalization
algorithms:
1) XML Canonicalization (Inclusive Canonicalization)
2) Exclusive XML Canonicalization
Neither one solves all possible problems that can arise.
e-Macao-16-5-745
Signature Algorithms: Problems
Two problems:
1) XML allows different documents to be considered equivalent. For
instance: duplicate namespace declaration can be removed or
created
2) if the signature covers something like nms:abc, its meaning may
change if nms is redefined
Related to the second problem:
a) it could be solved by expanding all the values
b) mechanisms like XPATH considers nms1=http://example.com to be
different from nms2=http://example.com
e-Macao-16-5-746
Canonicalization Example
Document 1:
<?xml version =1.0 encoding=us-ascii ?>
<example
a=a
b=b
></example>
Document 2:
<?xml version =1.0 encoding=us-ascii ?>
<example a=a b=b />
These two documents appear quite different, although with canonicalization
are translated both to:
<?xml version =1.0 encoding=us-ascii ?>
<example a=a b=b></example>
e-Macao-16-5-747
Inclusive Canonicalization
The fundamental difference between Inclusive and Exclusive
Canonicalization is the namespace declarations.
Inclusive Canonicalization copies all the declarations that are currently in
force, even if they are defined outside the scope of the signature.
Problem: if the file is moved into another XML document which has other
declarations, the signature will be invalid.
XML-C14N specifies inclusive canonicalization.
e-Macao-16-5-748
Exclusive Canonicalization
Exclusive Canonicalization copies only the namespaces that are visibly
used, those that are part of the XML syntax.
It does not look into attributes values or element content, so the namespaces
declarations required to process these are not copied.
It allows you to create a list of the namespaces that must be declared.
Exclusive canonicalization is useful when you have a signed XML document
that you wish to insert into other XML documents.
EXC-C14N specifies exclusive canonicalization.
The specification strongly recommends the use of exclusive
canonicalization.
e-Macao-16-5-749
Signing Messages
The <wsse:Security> header block may be used to carry a signature
compliant with XML Signature specification within a SOAP envelope.
Multiple signature entries may be added within one <wsse:Security>
header block.
To add a signature, a <ds:Signature> element must be inserted at the
top of the existing content of the <wsse:Security> header block.
e-Macao-16-5-750
XML Signature
In XML Signature, an element Signature is defined with its descendants
under the namespace http://www.w3.org/2000/09/xmldsig#
The WS-Security defines how to embed the Signature element in SOAP
messages as a header entry.
e-Macao-16-5-751
Signature Example
<S11:Header>
<wsse:Security xmlns:wsse="...">
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<ds:Reference URI="#MsgBody">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
</ds:Signature>
</wsse:Security>
</S11:Header>
e-Macao-16-5-752
Signing Messages 1
The part signed is specified by Reference and is transformed by the
method specified in CanonicalizationMethod.
The digest value is calculated with an algorithm specified by the
DigestMethod element.
The value is inserted in the DigestValue element represented in Base64.
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<ds:Reference URI="#MsgBody">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
e-Macao-16-5-753
Signing Messages 2
The value of the part is not signed directly. The SignedInfo element is
signed.
The SignedInfo element is canonicalized and signed with the algorithm
specified in the SignatureMethod element.
The calculated value is inserted in SignatureValue element with Base64
format.
<ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
e-Macao-16-5-754
Security Summary 1
Security requirements include:
1) confidentiality: protect messages against eavesdroppers
2) integrity: protect messages against deliberate or accidental
modifications
3) authentication: guarantees access to those who provide proof of
identity
4) non-repudiation: guarantees that the sender not deny the message
5) authorization: decides whether an entity can access a particular
resource
e-Macao-16-5-755
Security Summary 2
Cryptography technologies provide a basis for protecting messaged
exchanged between partners.
Cryptography algorithms are classified in: symmetric and asymmetric.
Symmetric algorithms require the use of the same key for encryption and
decryption.
Asymmetric algorithms uses a public and a private key.
Digital signatures assures integrity and non-repudiation of messages.
e-Macao-16-5-756
Security Summary 3
Different technologies can be applied:
1) Password authentication
2) HTTP Basic Authentication
3) Digital Signature Authentication
4) Security protocols SSL
To solve the difficulties of combining these technologies security
infrastructure have been developed.
e-Macao-16-5-757
Security Summary 4
Some security infrastructure:
1) User registries managing user identifications and passwords
2) Public Key Infrastructure certificate authority providing certificates
3) Kerberos a key distribution center provides tickets based on a
single sign on
e-Macao-16-5-758
Security Summary 5
To manage different security infrastructures, web services define a security
model based on three parties:
1) requester
2) web service
3) security token service
Each of them posses:
1) policy
2) security token
3) claims
e-Macao-16-5-759
Security Summary 6
On April 2004 OASIS announced Web Services Security v1.0 composed by
a set of specifications.
WS Security SOAP Message Security 1.0 propose a set of SOAP
extensions to assure integrity and confidentiality of the message contents.
Security headers may include:
1) security tokens:
a) user name token
b) binary security token
c) XML token
2) digital signatures
e-Macao-16-5-760
Acknowledgements
I would like to thank to:
1) Tomasz Janowski and Adegboyega Ojo - for their valuable comments
2) Gabriel Oteniya - for his help in developing the examples
3) Audience - for your presence and valuable comments
e-Macao-16-5-761
Web Services and e-Government
1) promotes the development of seamless services grouping services
provided by different agencies
2) do not require expensive technologies
3) based on open-source standards
4) facilitates the integration of legacy systems
e-Macao-16-5-762
Many Thanks!