Topic6 Basic Web Services Technology

Basic Web Services Technology

Sanjoy Sanyal (Tech for NonGeek)

Basic Technology Components

XML

SOAP

WSDL

UDDI


SOAP


Application Object(client)

SOAP-based

middleware

Service requestor

Application Object

(service provider)

SOAP-based

middleware

Service provider

SOAP messages exchanged on top of HTTP, SMTP or other transport protocol

Converts procedure calls to/from XML messages sent through HTTP or other protocols

Clients can invoke Web Services by exchanging SOAP messages

Services can exchange messages by means of standardized conventions to turn a service invocation into an XML message, to exchange the message and to turn the XML message back into an actual service invocation

WSDL



SOAP-based

middleware

Service requestor

WSDL of service provider

WSDL compiler (client side)

WSDL compiler (server side)

Application Object

(service provider)

SOAP-based middleware

Service provider

stub skeleton

The programming interface of a Web service can be specified using WSDL. The interface is specified in terms of methods supported by the Web service, and the corresponding input and output messages

WSDL specifications can be compiled into stubs and skeletons, analogous to IDL in conventional middleware. Dashed lines denote steps performed at development time, solid line to those performed at run-time

SOAP messages

UDDI



SOAP-based

middleware

Service requestorApplication

Object(service provider)


stub skeleton

SOAP messages (to look for services)

Service provider


Service descriptions

SOAP messages

SOAP messages (to publish service descriptions)

UDDI standardizes the Web services registry

Providers advertise their services in a UDDI registry. Clients (at development or run-time) look for services in the registry, thereby statically or dynamically binding to a service. Then clients can invoke the service

SOAP


SOAP specifications

A message format for one-way communication, describing how information can be packaged into XML

Conventions to implement RPC interaction pattern, defining how remote services can be invoked

Set of rules that any entity that processes a SOAP message must follow

Description of how a SOAP message should be transported on top of HTTP and SMTP


SOAP message


SOAP envelope

SOAP header

header block

SOAP body

body block

Applications enclose information in a SOAP envelope

Each envelope has a header and a body. Both can have multiple sub-parts in the form of blocks.

The header is not mandatory

The core of the information that is to be transmitted to the receiver is in the body

Any additional information for intermediate processing or value added services (transactional interaction, security) goes into the header

SOAP messages: interaction styles


SOAP body

PurchaseOrderDocument-product item-quantity

SOAP envelope

SOAP body

Acknowldgedocument-orderid

SOAP envelope Document style interaction The two interacting applications agree upon the structure of the documents to be exchanged

SOAP body

MethodnameOrderGoods

SOAP envelope

Input parameter 1Product item

Input parameter 1Quantity

SOAP body

Method return

SOAP envelope

Return valueOrder id

RPC style interaction The two interacting applications agree upon the RPC method signature The body of the requesting message includes the name of the procedure being invoked and the input parameters. The body of the response message contains the output parameters

SOAP messages: encoding rules

SOAP does not impose any specific form of encoding SOAP 1.2 does specify SOAP encoding which

defines how data structures can be serialized into XML

Applications are free to agree on other encoding (literal encoding)


SOAP message processing

Every message has: A sender, An ultimate receiver and a number of intermediary nodes that process and route

Nodes are typically the middleware architecture:They process the header of the SOAP message

A Header block can be assigned to following roles: None: will not be processed by a node (can be read)UltimateReceiver: block is solely meant for the

ultimate receiverNext: every node can process the message

Header block can have a mustUnderstand flag:A node playing that role must process the block and

if it cannot raise a fault


SOAP: Binding to a Transport protocol

SOAP does not impose any transport protocol Typically associated with HTTP or SMTP The specification of which protocol to use is

called a bindingFunctions of the binding:

Defines how the message has to be treated using the primitives of the transport protocol (GET/POST etc. for HTTP)

Addressing (since the identification of the ultimate receiver is not part of a SOAP message)

Routing (since there is no mechanism to describe a SOAP path as a part of a SOAP message)


Simple SOAP implementation


Client implementatio

n

SOAP engine

Service requestor

Client stub

HTTP Engine

Invokes the service as a local call

Invokes SOAP engine to prepare SOAP message

Packages SOAP into HTTP and passes it to an HTTP client that sends it to provider

Service implementation

SOAP router

Service requestor

server stub

HTTP server

Invokes the local procedure of the service implementation

Router parses the message, identifies the appropriate stub and delivers the parsed message

Passes the content of the HTTP message to the router

SOAP supports asynchronous interaction of loosely coupled interactions

Any further complications such as two-way synchronous messaging or transactions requires SOAP to be associated with an underlying protocol or middleware that has additional properties

WSDL

Web Services Description Language


WSDL Goals

Specifications as XML documents that describe Web services and service interfaces

Role and purpose similar to IDLs with differences:Also needs to define the protocols to access

the servicesAlso needs to define the locations at which

the service is availableAlso needs to handle the cope with the

complexity of several asynchronous messages used in Web Services


WSDL Interface Structure


abstract part

types

WSDL specification

messages

operations

port types

concrete part

bindings

Services & ports

Each port type is a logical collection of related operations

Each operation defines an exchange of messages

The type system allows the data that is being exchanged to be correctly interpreted. By default WSDL uses the same type system as XML Schemas, although a different type system can be specified in necessary

InterfaceBindings specifies the message encoding and protocol bindings (for example: -interaction style: (RPC style operation/document style) -transport bindings (SOAP/SOAP is typical but not mandatory, HTTP/SMTP given SOAP,) -encoding rules) (SOAP encoding/literal encoding)

Ports: also called EndPoints combine the InterfaceBinding information to a network address (specified by a URI)

Services : logical grouping of Ports

Defining a WSDL Interface: Steps


Step 1: Identify and Define all the data structures that will be exchanged as parts of messages between applications

Step 2: Define messages that build on data structures. In WSDL each message is divided into parts

Step 3: Define operations (also called transmission primitives or interactions).

Four basic operations: one-way, request-response, solicit-response, notification

One-way and notification operations require a single message . Asynchronous interactions are defined using one-way and notification operations

Request-Response and Solicit-Response requires two messages. The former is initiated outside the service and the latter by the service. Synchronous interactions are defined using these operations.

Step 4: Group operations into port types

Step 5: Define a concrete service by specifying concrete binding, encoding, locations ….

WSDL Implications

Solicit-response operation: A service can proactively initiate the interaction

Separation of abstract and concrete:Different services could combine different

interfaces using different bindings and make them available at different addresses

Both SOAP with WSDL are generic standardsSOAP is a generic envelope to wrap invocations

that the applications may make using other tools WSDL is a generic service description for services

built using other languages


Using WSDL



SOAP-based

middleware

Service requestor

WSDL of service provider

WSDL compiler (client side)

WSDL compiler (server side)

Application Object

(service provider)


Service provider

stub skeleton

WSDL documents can be automatically generated thru APIs

Dashed lines indicate compile-time activities First, WSDL is generated. Next, stubs and skeletons are generated.

SOAP messages

WSDL generator

1

2

UDDI: Universal Description Discovery Integration


UDDI Goals

Specifies a framework for describing and discovering Web services Business registry : sophisticated naming and

directory service Defines data structures and APIs for

publishing service descriptions in the registry and for querying the registry

Universal Business Registry:Worldwide directory for services was the

original goal


Information in a UDDI registry

White pages:Listing of organizations, their contact information

and the services they provide To find Web services provided by a given business

Yellow pages:Classification of both organizations and Web

services To find Web services according to a category

Green pages:Describes how a given Web service can be invoked Points to description documents stored outside the

registry


UDDI Data

Type of Data Description

businessEntity Describes an organization that provides Web services

businessService

Describes a group of related Web services offered by a businessEntity,. businessService may correspond to one type of service but provided at multiple addresses, versions, technologies (protocols, bindings)

bindingTemplate

Describes the technical information necessary to use a particular Web service

tModel Stands for “technical model”-generic container for any kind of specification. (for e.g.: WSDL service interface, interaction model…)


UDDI Data


businessEntitynamecontacts description identifierscategories

businessServiceservice keyname description categories

bindingTemplatebinding keydescriptionaddressdetailed inforeferences to tModels

tModelkeynamedescriptionoverviewDocidentifierscategories

tModelkeynamedescriptionoverviewDocidentifierscategories

Specs stored at the provider’s site

One businessEntity can include

One businessService can include

Multiple businessServices

Multiple bindingTemplates

tModel Structure

The actual content (Service Description)Resides within an overviewDoc to which the

tModel points but which is stored outside the registry

overviewDoc can be in any structure and written in any language

A tModel once published is assigned a unique key


UDDI Registry API

UDDI API Description

UDDI Inquiry API

To find registry entries (find_business,find_binding,find_tModel)To get details about a specific entity (get_businessDetail,get_serviceDetail, get_bindingDetail,get_tModelDetail)

UDDI Publishers API

Add, Modify, delete entries in the registry (save_business,save_ service,save_binding,save_tModel,delete_business,delete_service….)

UDDI Security API

Get and discard authentication tokens (get_authToken, discard_authToken)

UDDI Subscription API

Monitors changes in a registry by subscribing to track new, modified and deleted entries (delete_subscription,get_subscriptionResults,get_subscriptions, save_subscriptions)

UDDI Replication API

Supports replication of information between registries, so that different registries can be kept synchronized.


UDDI registries have three main types of users: service providers, service requestors, other registries that need to exchange information

UDDI Access Points & APIs


Service Requestor Service Provider

Web service interface


Web service interface


Subscription, Replication and Custody transfer APIs

SOAP/HTTP SOAP/HTTPS

Inquiry API Publishers API

UDDI registers maintain different access points (URIs) for requestors, publishers and other registries to separate inquiries that do not require authentication from those they do.

Registries interact to transfer the custody of an entity and replicate information. Each entity is owned by a single registry

UDDI & WSDL

WSDL interface definitions (specifically port types and protocol bindings) are registered as tModels: whose overviewDoc will point to the corresponding

WSDL document


businessEntity

businessService

bindingTemplate tModelWSDL


Service provider

Public and Private Registries

Registry Description

Public Provides Open and public access to registry data

Private Internal registry isolated behind a firewallUsed by organizations to support integration of internal applications

Shared/Semi-private

Deployed within a controlled environment and shared with trusted partners


Web Services at Work


Service implementation

SOAP router

Service provider

server stub

HTTP Engine

WSDL generator

WSDL service descriptions

WSDL compiler

UDDI publisher

1

2

3

businessEntity

businessServicebindingTemplate tModel

UDDI publisher

Inquiry API

Publishers API

Exposing an internal service as a Web Service

Step 1: Generation of WSDL

Step 2: Generation of servlet and registration with SOAP router

Step 3: Registration in UDDI registry

Web Services @ work - Steps


Exposing an internal service as a Web Service

Step 1: The interface of the procedure is translated into a description of the Web service by mapping the information into the corresponding WSDL structure

Step 2: The generated WSDL is stored at the providers site. A WSDL compiler can then create a server stub (in the form of a servlet in the Java world) and register the servlet with the SOAP router so that the router knows it has to invoke the servlet whenever a certain URI is invoked.

Step 3: A tModel is published that refers to the generated WSDL in a UDDI registry accessible to clients. Next, new businessService and a bindingTemplate entities are published providing the address at which the service is available and referencing the tModel.

Scenario: WSDL specification has been provided and the service provider wants to offer a service compliant with the standardised interface

Step 1: WSDL is retrieved from the UDDI registry, following the pointer in the tModel

Step 2: The WSDL compiler generates the code required on the server side. The servlet (in the Java world) is registered with the SOAP router

Step 3: Publication of the UDDI registry as above. This time there is no need to register the tModel sine it has already been regsitered.

Related Standards


Standard Description

WS – Addressing

Proposes a protocol-neutral mechanism for specifying endpoint references of services within SOAP messagesImplementation Example: Creating one stateful persistent object for each new client, which manages all the interactions with the client.

WS – Routing

Allows a way of specifying which intermediaries should be visited by a SOAP message

WS - Security

Extension to SOAP that defines a SOAP header block (called Security) which is where security information can be included

WS - Policy Framework thru which clients and services can express their policies (requirements, capabilities, preferences)

WSIF Web Services Invocation Framework – a pluggable framework that allows providers to be added to an existing Web Services infrastructure. This allows a service to be invoked thru a WSDL binding

Summary


SOAP Interactions in Web Services happens thru SOAP Provides standardized way to encode interaction mechanisms into

XML documents Defines transport bindings

WSDL Defines interface to a Web Service The interface is specified in terms of methods supported by the

Web service, and the corresponding input and output messages UDDI

Defines data structures and APIs for publishing service descriptions in the registry and for querying the registry

(the material in this topic is based on Web Services: Concepts, Architectures and Applications by Alonso, Casati, Kuno, Machiraju)

Topic6 Basic Web Services Technology

Technology

Transcript of Topic6 Basic Web Services Technology