SOAP, WSDL, UDDI

Service Broker Basic SOAP Message Exchange Service Consumer Service Provider http transport SOAP message WSDL describing service SOAP message http transport client service registry find publish DESCRIBE INVOKE SOAP SenderSOAP Receiver SOAP Sender SOAP Receiver

SOAP Body SOAP Message SOAP header SOAP envelope Header block Header data Header data Header data Body child element

SOAP Building Blocks A SOAP message is an XML document with the following elements –A required envelope Identifies XML document as a SOAP message –An optional header Contains header information –A required body element with call and response information –An optional fault element Information about errors that could occur

Sample SOAP Message T14:00:00-05:00 Pick up Mary at school at 2pm

SOAP Envelope Element Required field – tells that this XML document is a SOAP message Encoding style attribute – used to define data types used in the document <soap:Envelope xmlns:soap=" soap:encodingStyle=" Message information goes here...

SOAP Header Contains application specific information (e.g. authentication, payment, etc.) Optional field, but if present, must be the first child of the envelope element <soap:Envelope xmlns:soap=" soap:encodingStyle=" <m:Trans xmlns:m= soap:mustUnderstand="1">

SOAP Header – Contd. The previous example contains –A Trans element, which is an actor –mustUnderstand attribute of 1 –A value of 234, which denotes an encoding style Actor attribute –Message may pass multiple nodes – we need to denote who needs to act on it mustUnderstand – whether a header entry is madatory or optional for the recipient to process

SOAP Body Actual message <soap:Envelope xmlns:soap=" soap:encodingStyle=" Apples

Response <soap:Envelope xmlns:soap=" soap:encodingStyle=" 1.90

SOAP Fault Element Error message from a SOAP message is carried inside a fault element Must appear as a child element of the body element Has the following subelements: –Faultcode - identifies the fault –Faultstring – human readable explanation of the fault –Fault-factor – what caused the fault –Details -- application specific information

A More Involved Example buyer seller message broker RFQ QuoteResponse Award

Conversational SOAP Message Exchange: A Request – – – SanDisk – SecureDigital memory – 1GB – – 100 –

Conversational Exchange: A Response – env:mustUnderstand=“true”> – – KingMax – SecureDigital memory – 1GB – 9000KB/s – Memories Unlimited – KM-SD1000 – 100 –

Conversational Exchange: Completion KM-SD

Remote Procedure Calls To invoke RPC –Address of target SOAP node –Method name –Identities and values of arguments –Separation of arguments identifying target of RPC versus data Plus values of properties for binding (e.g. GET, POST) –Optional header data

RPC Invocation g

RPC Result 5 <s:shipOrderResponse env:encodingStyle=“ encoding” encoding xmlns:rpc=“ xmlns:s=“ s:status confirmed $20.00

SOAP Faults Place faults inside env:Body elements In single env:Fault env:Node identifies node which generated fault Absence indicates “ultimate recipient” env:Code env:Value env:Subcode env:Reason env:Text env:Detail Application specific

SOAP Fault Example env:Sender rpc:BadArguments Processing error Chyba zpracování Unknown destination 999

SOAP Processing Model SOAP messages are sent from one sender node passing through zero or more intermediaries Three roles –next: each SOAP intermediary or end destination must act in this role –none: SOAP nodes must not act in this role –ultimateReceiver: destination acts in this role Header blocks targeted to specific roles using Role attribute If mustUnderstand=“true” SOAP receiver must understand or generate SOAP fault Header blocks processed by intermediaries are generally removed before forwarding –Override with relay attribute –Allows targeting of headers to specific intermediaries (but mustUnderstand would then generally be turned off)

SOAP Processing: Header Blocks, MustUnderstand and Relay

SOAP Remoting Architecture Server object implementation application level Client application code Server skeleton XML unmarshaller Client stub XML marshaller TCP/IP socket remoting architecture level wire protocol level http protocol http server http server body envelope header

Web Services Description Language Provides a model and an XML format for the “contract” of a web service Separates abstract service description from both concrete network protocol and message format Describes data types used in messages Messages are defined as aggregation of typed parts Operations are message exchange patterns supported by the web service PortTypes are named collections of operations

WSDL Specification types message operation porttype operation binding service port

WSDL: More Basics Define services as collections of network endpoints or ports Messages are abstract descriptions of data being exchanged Port types are abstraction collection of operations Concrete protocol and data format specification for a particular porttype constitutes a binding

WSDL Components Types– a container for data type definitions using some type system Message– an abstract, typed definition of the data being communicated. Operation– an abstract description of an action supported by the service. Port Type–an abstract set of operations supported by one or more endpoints. Binding– a concrete protocol and data format specification for a particular port type Port– a single endpoint defined as a combination of a binding and a network address. Service– a collection of related endpoints.

An Example - WSDL Types

WSDL Operations

WSDL Bindings, Services, Ports My first service

More on Messages Messages consist of one or more logical parts Each part is associated with a type * *

More on Messages Multiple part elements are used if the message has multiple logical units Abstract vs. Concrete messages –Message definitions are abstract –Message binding describes how the abstract content is mapped to a concrete format –Bindings may provide very limited information is they are close

Operations * *

Port Types A port type is a named set of abstract operations and abstract messages

WSDL Binding maps the abstract service functionality to a specific network protocol and message format defines: –the communication protocol to use –how service interactions are accomplished using this protocol –the address to communicate with Three bindings are defined in the WSDL spec: –SOAP binding – HTTP binding – SMTP binding

WSDL Binding Example: One-way Over SMTP – – – – – –

Request-Response RPC Over HTTP – – – > My first service

UDDI:Why Do We Need a Web Services Registry Web services are valuable because of standardized payloads and transport definitions –The value is creating a web service that is used by many clients Can’t happen unless the services are advertised to multiple consumers

What Does UDDI Contain? Businesses and other service providers Services they expose Bindings (locations) of those services Interfaces supported by those services

UDDI Entities businessEntity – provider of service businessService – collection of related services bindingTemplate - information necessary to use tModel - “reusable concept” such as –Interface –Protocol used by web services –Category publisherAssertion - relationship that business entity has with another businessEntity Subscription – request to be informed of particular changes

Core UDDI Entities businessService Interface tModel bindingTemplate businessEntity bindingTemplate Interface tModel