SOA & WEB SERVICES PRIMER

Introduction

Expectations & Objectives

 Agenda

SOA
Web Services
Web Service design methodology (on a very high level)
 Bottom up method
 Top down method
SOAP
The structure of SOAP messages: Envelope, Header and Body
WSDL
Structure of a WSDL and How to read a WSDL
The Message styles: RPC/Encoded, RPC/Literal, Document/Literal,
Wrapped and Bare
Comparison of the SOAP Engines Axis, Axis2, Metro and CXF
Key Terms

SOA

SOAP

WSDL

JBI

ESB
 Service Oriented Architecture

SOA is a technical pattern for implementing cohesive

and loosely coupled (business and technical) functions
with well-defined interfaces.

Such services are consumed with the help of the details

specified in the interface without any knowledge of
the implementation.
 Service Oriented Architecture

 A service-oriented architecture is essentially a

collection of services.

 These services communicate with each other.

 Service Oriented Architecture

 A service is a function that is well-defined, self-

contained, and does not depend on the context or
state of other services Services

Connections

 The technology of web services is the most likely

connection technology of service-oriented
architectures.
 Advantages of SOA

They offer business services across the platforms

They provide location independence
Services need not be at a particular system or particular
network
Completely loosely coupled approach
Authentication and authorization support at every level
The search and connectivity to other services is dynamic
 Short-term benefits

Enhances reliability
Reduces hardware acquisition costs
Leverages existing development skills
Accelerates movement towards application
consolidation
Provides a data bridge between incompatible
technologies
 Long-term benefits

Provides the ability to build composite applications

Creates a self-healing infrastructure that reduces
management costs
Provides truly real-time decision-making applications
Enables the compilation of a unified taxonomy of
information across an enterprise and its customer and
partners
Benefits from Business perspective

Ability to more quickly meet customer demands

Lower costs associated with the acquisition and
maintenance of technology
Management of business functionality closer to the
business units
Leverages existing investments in technology
Reduces reliance on expensive custom development
Web Services
 What is Web Service

Web Services can convert your application into a Web-

application, which can publish its function or message
to the rest of the world.
Why Web Service
 Services Provider, Service
Consumer, Registry

The figure above illustrates a basic service

 Request
 Response
The request and subsequent response connections are
defined in some way that is understandable to both the
service consumer and service provider.
A service provider can also be a service consumer.
 Types of Web Service

The three most common styles of use are RPC, SOA and
REST.
 RPC

RPC Web services present a distributed function (or

method) call interface that is familiar with many
developers. Typically, the basic unit of RPC Web
services is the WSDL operation
 SOA

Web services can also be used to implement an

architecture according to Service-oriented
architecture (SOA) concepts, where the basic unit of
communication is a message, rather than an
operation. This is often referred to as “message-
oriented” services
 REST

(REST) attempts to describe architectures which use

HTTP or similar protocols by constraining the
interface to a set of well-known, standard operations
(like GET, POST, PUT, DELETE for HTTP). Here, the
focus is on interacting with stateful resources, rather
than messages or operations.
 Web service design methodology

Web services can be written in two ways:

 bottom up method
 top down method
Web service design methodology

A developer using the "bottom up method" first writes the

implementing class in a programming language, and then
uses a WSDL generating tool to expose its methods as a web
service. This is often the simpler approach.
Web service design methodology

A developer using the "top down method" first writes

the WSDL document and then uses a code generating
tool to produce the class skeleton, which he later
completes.
 <This way is generally considered more difficult but can produce cleaner designs. >
SOAP

Simple Object Access Protocol

SOAP Structure
 SOAP Structure

A SOAP message is encoded as an XML document, consisting of an

<Envelope> element, which contains an optional <Header> element,
and a mandatory <Body> element. The <Fault> element, contained
within the <Body>, is used for reporting errors.
 The SOAP envelope The SOAP <Envelope> is the root element in every SOAP
message, and contains two child elements, an optional <Header> and a
mandatory <Body>.
 The SOAP header The SOAP <Header> is an optional sub-element of the SOAP
envelope, and is used to pass application-related information that is to be
processed by SOAP nodes along the message path.
 The SOAP body The SOAP <Body> is a mandatory sub-element of the SOAP
envelope, which contains information intended for the ultimate recipient of
the message.
 The SOAP fault The SOAP <Fault> is a sub-element of the SOAP body, which is
used for reporting errors.
WSDL
 Web Service Descriptor Language

WSDL is an XML-based language for describing Web

services and how to access them.
WSDL is used to describe Web services
WSDL is also used to locate Web services
WSDL is a W3C recommendation
WSDL Structure
 Abstract and Concrete

An abstract WSDL document describes what the web service

does, but not how it does it or how to contact it. An
abstract WSDL document defines:
 the operations provided by the web service.
 the input, output and fault messages used by each operation to
communicate with the web service, and their format.
A concrete WSDL document adds the information about
how the web service communicates and where you can
reach it. A concrete WSDL document contains the abstract
WSDL definitions, and also defines:
 the communication protocols and data encodings used by the web
service.
 the port address that must be used to contact the web service.
 The WSDL Document Structure

A typical WSDL document consists of the following

elements
Element Defines
<definition> Root WSDL element
<types> What datatypes will be transmitted
<message> What message will be transmitted
<portType> What operations (functions) will be supported
<binding> The communication protocols used by the web service
<service> Where is the service located.
<documentation> Used to provide human-readable documentation
<import> To import other WSDL documents or XML Schemas
 How to read a WSDL

The root element of a WSDL is definitions. So we start

the WSDL tree with a definition node as root
 How to read a WSDL (Definition)

The definition element specifies that this document is

the HelloService. It also specifies the numerous
namespaces that will be used throughout the
document.
The use of namespaces is important for differentiating
elements, and it enables the document reference
multiple external specification.
 WSDL specification
 SOAP specification and
 XML schema specification
 How to read a WSDL (Definition)

The definition element also specifies a targetNamespace

attribute. The targetNamespace is a convention of XML
schema that enables the WSDL document to refer to
itself.
In this example we specifed a targetNamespace of
http://www.ecerami.com/wsdl/HelloService.wsdl
Note: the namespace specification does not require that the
doucment actually exist at this location; the important
point is that you specify a value that is unique, different
from all other namespaces that are defined.
 How to read a WSDL (Definition)

The definition element specifies a default namespace:

xmlns=http://schemas.xmlsoap.org/wsdl/ .
All the elements without a namespace prefic, such as
message or porttype, are therefore assumed to be
part of the default WSDL namespace.
 How to read a WSDL (Service)

To analyze a WSDL document it is recommended to read it

from the bottom upwards.

At the bottom of the WSDL we find a child element named

service
 How to read a WSDL (Service)

A Service may have one or more ports. Each port

describes a way to access the service.
 How to read a WSDL (Service)

Its child element address has a different XML prefix than

the other elements. (soap, soap12, http, etc.,)
 How to read a WSDL (Binding)

To move on, we have to look at the binding attribute of

the port.
 How to read a WSDL (Binding)

A binding provides details about a specific transport.

 How to read a WSDL (Binding)

The (wsdl:binding> element of the WSDL contains a pair

of parameters that influence the form of the resulting
SOAP messages :
Binding style (RPC or document) and
Use (encoded or literal)
 How to read a WSDL (Binding)

The “Style” Attribute – This choice corresponds to how the

SOAP payload – i.e., how the contents of the <soap:body>
element – can be structured.
 Document – The SOAP message is sent as one “document” in the
<soap:Body> element without additional formatting rules having
to be considered. The Document style is the default choice.
 RPC – The structure of an RPC style <soap:Body> element needs
to comly with the rules specified in detail in section 7 of the SOAP
1.1 specification. According to these rules, <soap:Body> may
contain only one element that is named after the operation, and
all parameters myst be represented as sub-elements of this
wrapper elements.
 How to read a WSDL (Binding)

SOAP has its roots in synchronous remote procedure

calls over HTTP and the appearance of the document
accordingly followed these conventions. Later, it was
seen as a simplification to use arbitary XML in the
SOAP body without adhering to conventions.

The choice of one or the other is mainly a question of

personal taste since most SOAP clients today accept
both versions.
 How to read a WSDL (Binding)

The “Use” Attribute – This attribute specifies the encoding rules

of the SOAP message. It refers to the serialization rules
followed by the SOAP client and SOAP server to interpret the
contents of the <body> element of the SOAP payload.

 Literal – Means that the type definitions literally follow an XML schema
definition.
 Encoded – refers to the representation of application data in XML,
usually according to the SOAP encoding rules of the SOAP 1.1
specification. The rules to encode and interpret a SOAP body are in a
URL specified by the encodingStyle attribute.

Encoded is the appropriate choice where non-treelike structures are

concerned, because all others can be perfectly described in XML
schema.
 How to read a WSDL (Binding)

The combination of the style and use attributes leads to

four possible style/use pairs:
1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal
 How to read a WSDL (Binding)

In the binding you can find the transport option for the
operation.
Inside the operation element there is a soap:operation
element defining details for the SOAP protocol and its
transport. The soapAction is a reminiscent from the
past and is used with a fixed value of an empty string.
 How to read a WSDL (Binding)
Because Web Services set the focus on message not parameters,
information about the transport of these messages can be found in the
wsdl:input and wsdl:output element.

A service may specify one or more faults as an alternative for the output.
 How to read a WSDL (Binding)

The soap:body and soap:header elements can describe a

message further.
 How to read a WSDL (PortType)
Time to move up in the WSDL. Now we follow the value of the type attribute of the
binding. It points to a portType with the same name further up in the document.

Now we have crossed the border from the concrete details about the transport and
location of a service to its pure abstract description of its interface.
 How to read a WSDL (PortType)

PortType is in WSDL 1.1 similar to the interface of the

Web Service.
In WSDL 2.0 the term portType is substituted with the
term interface.
 How to read a WSDL (PortType)
An interface can have several operations.

An operation corresponds to a function in procedural programming.

 How to read a WSDL (PortType)
Inside a portType we find operation element as in the
binding.

But this time the input and output describe the structure of
the message not transport specific options
 How to read a WSDL (Message)
The message attribute of the input refers again up in the
WSDL document.

Further up in the document we find a corresponding

message with this name
 How to read a WSDL (Message)
The message element has one part element as child.

A WSDL specialist will recognize the value of the attribute name,

“parameters” indicates the wrapper sub-style
 How to read a WSDL (Types)

The next child of the definitions element is types

 How to read a WSDL (Types)

The types element can have multiple XML schema as

children.
 How to read a WSDL (Types)
In a schema we can find the definition of :
 Complex Types
 Simple Types
and the declaration of:
 Elements

In a document/literal style all the parts point to elements

 How to read a WSDL (Types)

A complex type with a sequence as content

 How to read a WSDL (Types)

A sequence consists of several elements that describe

the order of elements in a SOAP message.
 WSDL operations
WSDL supports four basic patterns of operation:
 One – Way
The service receives a message. The operation there has a single input
element.
 Request-response
The service receives a message and sends a response. The operation
therefore has one input element and one output element. To
encapsulate errors, an optional fault element can be specified.
 Solicit-response
The service sends a message and receives a response. The operation
therefore has one output element, followed by one input element. To
encapsulate errors, an optional fault element can also be specified.
 Notification
The service sends a message. The operation therefore has a single
output element.
WSDL operations
ESB
 Enterprise Service Bus

A Standard based middleware architecture which allows

pluggable components to communicate with each
other via a messaging system
 Enterprise Service Bus

Use of an ESB certainly implies adherence to a particular

architecture

The term “Enterprise Service Bus" almost always

denotes the software infrastructure that enables such
an architecture.
 Enterprise Service Bus

In essence, the ESB is considered a platform to realize a

service-oriented architecture.
 Enterprise Service Bus

An Enterprise Service Bus (ESB) brings flow-related

concepts such as
 Transformation and
 Routing
to a Service-Oriented Architecture.
 Enterprise Service Bus

Routing — In a large enterprise with numerous applications and channels to connect them, a message may have to go
through several channels to reach its final destination. The route a message must follow may be so complex that the
original sender does not know what channel will get the message to the final receiver. Instead, the original sender
sends the message to a Message Router, an application component and filter in the pipes-and-filters architecture,
which will determine how to navigate the channel topology and direct the message to the final receiver, or at least to
the next router.

Transformation — Various applications may not agree on the format for the same conceptual data; the sender formats
the message one way, yet the receiver expects it to be formatted another way. To reconcile this, the message must
go through an intermediate filter, a Message Translator, that converts the message from one format to another.

Endpoints — An application does not have some built-in capability to interface with a messaging system. Rather, it must
contain a layer of code that knows both how the application works and how the messaging system works, bridging
the two so that they work together. This bridge code is a set of coordinated Message Endpoints that enable the
application to send and receive messages.
 Enterprise Service Bus

An ESB can also provide an Abstraction for Endpoints.

This promotes flexibility in the Transportation Layer and
enables loose coupling and easy connection between
services
JBI
 Java Business Integration

Java Business Integration is a Java-based standard

addressing the EAI and B2B issues based on the
paradigms and principles advocated by service-
oriented architecture.
The current version (1.0) is finalized through the JSR
(Java Specification Request) 208 in August 2005. Both
commercial and open source worlds have already
started embracing JBI as an integration standard in
their ESB products
Thank you