Topic6 Basic Web Services Technology
-
Upload
sanjoysanyal -
Category
Business
-
view
1.543 -
download
0
Transcript of Topic6 Basic Web Services Technology
Basic Web Services Technology
Sanjoy Sanyal (Tech for NonGeek)
Basic Technology Components
XML
SOAP
WSDL
UDDI
Sanjoy Sanyal (Tech for NonGeek)
SOAP
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
Application Object(client)
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
Sanjoy Sanyal (Tech for NonGeek)
Application Object(client)
SOAP-based
middleware
Service requestorApplication
Object(service provider)
SOAP-based middleware
stub skeleton
SOAP messages (to look for services)
Service provider
SOAP-based middleware
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
SOAP message
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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)
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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)
Sanjoy Sanyal (Tech for NonGeek)
Simple SOAP implementation
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
WSDL Interface Structure
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
Using WSDL
Sanjoy Sanyal (Tech for NonGeek)
Application Object(client)
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
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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…)
Sanjoy Sanyal (Tech for NonGeek)
UDDI Data
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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.
Sanjoy Sanyal (Tech for NonGeek)
UDDI registries have three main types of users: service providers, service requestors, other registries that need to exchange information
UDDI Access Points & APIs
Sanjoy Sanyal (Tech for NonGeek)
Service Requestor Service Provider
Web service interface
Service descriptions
Web service interface
Service descriptions
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
Sanjoy Sanyal (Tech for NonGeek)
businessEntity
businessService
bindingTemplate tModelWSDL
Service descriptions
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
Sanjoy Sanyal (Tech for NonGeek)
Web Services at Work
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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
Sanjoy Sanyal (Tech for NonGeek)
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)