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, selfcontained, 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 Webapplication, 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 “messageoriented” 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 <definition> <types> <message> <portType> <binding> <service> <import> Defines Root WSDL element What datatypes will be transmitted What message will be transmitted What operations (functions) will be supported The communication protocols used by the web service Where is the service located. To import other WSDL documents or XML Schemas

<documentation> Used to provide human-readable documentation

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 serviceoriented 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

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.