Post on 21-Jan-2016
Basic Standards for Web Services
SOAPWSDLUDDI
Chapter 2 2Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Highlights eXtensible Markup Language (XML) Simple Object Access Protocol
(SOAP) Web Services Description
Language (WSDL) Directory Services Universal Description, Discovery,
and Integration (UDDI)
Chapter 2 3Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Basic Profile (BP 1.0)
The Web Services Interoperability Organization (WS-I) has specified the following Basic Profile version 1.0: SOAP 1.1 HTTP 1.1 XML 1.0 XML Schema Parts 1 and 2 UDDI Version 2 WSDL 1.1
Chapter 2 4Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Standards for Web Services
BPEL4WSOWL-S Service
Model
ebXMLCPA
Process and workflow orchestrations
QoS: Service descriptions and bindings
Contracts andagreements
XLANG
WSCL
WSDLebXML
CPP
ebXMLBPSS
XML, DTD, and XML Schema
HTTP, FTP, SMTP, SIP, etc.
SOAPebXML
messaging
OWL
UDDIebXML
Registries
WSCLWSCI
WS-Coordination
WS-AtomicTransaction and WS-BusinessActivity
OWL-S Service Grounding
OWL-S Service Profile
BTP
BPML
Discovery (not selection)
Messaging
Transport
QoS: Conversations
QoS: Choreography
QoS: Transactions
Encoding
WS-Policy
WS-Security
WS-Reliable Messaging
PSL
RDF
SOAP SOAP is acronym for Simple Object Access Protocol SOAP is a communication protocol SOAP is designed to communicate via Internet SOAP can extend HTTP for XML messaging SOAP provides data transport for Web services SOAP can exchange complete documents or call a
remote procedure SOAP can be used for broadcasting a message SOAP is platform and language independent SOAP is the XML way of defining what information
gets sent and how
Chapter 2 5Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Chapter 2 6Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
SOAP (Simple Object Access Protocol)
Used to exchange messages via HTTP, SMTP, and SIP (Session Initiation Protocol for Internet telephony)
Originally designed for remote-procedure calls (RPC)
Works through firewalls on port 80 Character-based, so easy to encrypt/decrypt
and thus easy to secure Inefficient due to character, not binary, data
and large headers Does not describe bidirectional or n-party
interaction
Chapter 2 10Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Web Services: Basic Architecture
ServiceBroker
ServiceProvider
ServiceRequesto
r
Bind or invoke(SOAP)
Find or discover(UDDI)
Publish or announce(WSDL)
Registry; well-known
Not well-known
Chapter 2 11Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Describing a Service
Namee.g., GetTemperature
Types of Input Parameterse.g., (String, String)
Types of Output Parameterse.g., Integer
SOAP architecture
An Envelope element that identifies the XML document as a SOAP message (mandatory)
A Header element that contains header information (optional)
A Body element that contains call and response information (mandatory)
A Fault element containing errors and status information (optional)
Chapter 2 12Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
SOAP Envelope (1) The SOAP envelope indicates the start and the end of the
message.
The SOAP envelope solves the problem of knowing when you're done receiving a message and are ready to process it.
Every SOAP message has a root Envelope element.
Envelope element is mandatory part of SOAP Message.
Every Envelope element must contain exactly one Body element.
If an Envelope contains a Header element, it must contain no more than one, and it must appear as the first child of the Envelope, before the Body.
13
SOAP Envelope (2) The envelope changes when SOAP versions change.
The SOAP envelope is specified using the ENV namespace prefix and the Envelope element.
The optional SOAP encoding is also specified using a namespace name and the optional encodingStyle element, which could also point to an encoding style other than the SOAP one.
A v1.1-compliant SOAP processor will generate a fault when receiving a message containing the v1.2 envelope namespace.
A v1.2- compliant SOAP processor generates a VersionMismatch fault if it receives a message that does not include the v1.2 envelope namespace.
Chapter 2 14Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
... Message information goes here ...
</SOAP-ENV:Envelope>
Chapter 2 15Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Chapter 2 16Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Ex. SOAP Request
POST /temp HTTP/1.1Host: www.socweather.comContent-Type: text/xml; charset="utf-8"Content-Length: xxxSOAPAction: "http://www.socweather.com/temp"
<!-- Above: HTTP headers and a blank line. --><!—These comments below: an XML document --><?xml version=“1.0”?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <env:Body> <m:GetTemp xmlns:m="http://www.socweather.com/temp.xsd"> <m:City>Honolulu</m:City> <m:When>now</m:When> </m:GetTemp> </env:Body></env:Envelope>
Chapter 2 17Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Ex. SOAP Response
HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: xxxSOAPAction: "http://www.socweather.com/temp"
<?xml version="1.0"?><env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<env:Body> <m:GetTempResponse
xmlns:m="http://www.socweather.com/temp.xsd"> <m:DegreesCelsius>30</m:DegreesCelsius> </m:GetTempResponse> </env:Body></env:Envelope>
SOAP Fault The SOAP fault mechanism returns specific information about the
error, including a predefined code, a description, the address of the SOAP processor that generated
A SOAP Message can carry only one fault block Fault element is an optional part of SOAP Message For the HTTP binding, a successful response is linked to the 200 to 299
range of status codes; SOAP fault is linked to the 500 to 599 range of status codes.
Chapter 2 18Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Fault example<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body>
<SOAP-ENV:Fault> <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode> <faultstring xsi:type="xsd:string">
Failed to locate method (ValidateCreditCard) in class (examplesCreditCard) at /usr/local/ActivePerl-5.6/lib/ site_perl/5.6.0/SOAP/Lite.pm line 1555.
</faultstring> </SOAP-ENV:Fault>
</SOAP-ENV:Body> </SOAP-ENV:Envelope>
Chapter 2 20Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
WSDL: Web Services Description Language
Describes a programmatic interface to a Web service, including Definitions of data types Input and output message formats The operations provided by the service Network addresses Protocol bindings
WSDL structure<definitions>
<types> definition of types........</types>
<message> definition of a message....</message>
<portType> definition of a port.......</portType>
<binding> definition of a binding....</binding>
</definitions>
Chapter 2 21Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
A WSDL document describes a web service using these major elements:
Element Defines
<types> The data types used by the web service
<message> The messages used by the web service
<portType> The operations performed by the web service
<binding> The communication protocols used by the web service
Chapter 2 22Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
WSDL Ports The <portType> element is the most important WSDL element.
It describes a web service, the operations that can be performed, and the messages that are involved.
The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language.
WSDL Messages The <message> element defines the data elements of an operation. Each message can consist of one or more parts. The parts can be compared to the
parameters of a function call in a traditional programming language. WSDL Types
The <types> element defines the data types that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
WSDL Bindings
The <binding> element defines the message format and protocol details for each port.
Chapter 2 23Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
WSDL example
<message name="getTermRequest"> <part name="term" type="xs:string"/></message>
<message name="getTermResponse"> <part name="value" type="xs:string"/></message>
<portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType>
Chapter 2 24Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
portType Operations
Type DefinitionOne-way The operation can receive a message but will
not return a responseRequest-response The operation can receive a request and will
return a responseSolicit-response The operation can send a request and will wait
for a responseNotification The operation can send a message but will not
wait for a response
Chapter 2 25Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
<?xml version="1.0"?><!-- the root element, wsdl:definitions, defines a set of --><!-- related services --><wsdl:definitions name="Temperature" targetNamespace="http://www.socweather.com/schema" xmlns:ts="http://www.socweather.com/TempSvc.wsdl" xmlns:tsxsd="http://schemas.socweather.com/TempSvc.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<!-- wsdl:types encapsulates schema definitions of --><!-- communication types; here using xsd -->
<wsdl:types><!-- all type declarations are expressed in xsd --> <xsd:schema targetNamespace="http://namespaces.socweather.com" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<!-- xsd def: GetTemp [City string, When string] --> <xsd:element name="GetTemp"> <xsd:complexType> <xsd:sequence> <xsd:element name="City" type="string"/> <xsd:element name="When" type="string"/> </xsd:sequence> </xsd:complexType> </xsd:element>
<!-- xsd def: GetTempResponse [DegreesCelsius integer] --> <xsd:element name="GetTempResponse"> <!-- XML Schema entry as above --> </xsd:element>
<!-- xsd def: GetTempFault [errorMessage string] --> <xsd:element name="GetTempFault"> <!-- XML Schema entry as above --> </xsd:element> </xsd:schema> </wsdl:types>
<!-- wsdl:message elements describe potential transactions --><!-- Most messages, as here, have only one part. Multiple --><!-- parts provide a way to aggregate complex messages -->
<!-- request GetTempRequest is of type GetTemp --> <wsdl:message name="GetTempRequest"> <wsdl:part name="body" element="tsxsd:GetTemp"/> </wsdl:message>
<!-- response GetTempResponse is of type GetTempResponse --> <wsdl:message name="GetTempResponse"> <wsdl:part name="body" element="tsxsd:GetTempResponse"/> </wsdl:message>
<!-- wsdl:portType describes messages in an operation --> <wsdl:portType name="GetTempPortType">
<!-- wsdl:operation describes the entire protocol from --><!-- input to output or fault --> <wsdl:operation name="GetTemp"><!-- The order input preceding output indicates the --><!-- request-response operation type --> <wsdl:input message="ts:GetTempRequest"/> <wsdl:output message="ts:GetTempResponse"/> <wsdl:fault message="ts:GetTempFault"/> </wsdl:operation> </wsdl:portType>
<!-- wsdl:binding specifies a serialization protocol --> <wsdl:binding name="TempSvcSoapBinding" type="ts:GetTempPortType">
<!-- leverage off soap:binding document style --> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- semi-opaque container of network transport details --> <!-- classed by soap:binding above @@@ --> <wsdl:operation name="GetTemp"> <soap:operation soapAction="http://www.socweather.com/TempSvc"/><!-- further specify that the messages in the --><!-- wsdl:operation "GetTemp" use SOAP? @@@ --> <wsdl:input> <soap:body use="literal" namespace="http://schemas.socweather.com/TempSvc.xsd"/> </wsdl:input>
<!-- As above for wsdl:output and wsdl:fault -->
</wsdl:operation> </wsdl:binding>
<!-- wsdl:service names a new service "TemperatureService" --> <wsdl:service name="TemperatureService"> <wsdl:documentation>socweather.com temperature service </wsdl:documentation>
<!-- connect it to the binding "TempSvcSoapBinding" above --> <wsdl:port name="GetTempPort" binding="ts:TempSvcSoapBinding">
<!-- give the binding a network address --> <soap:address location="http://www.socweather.com/TempSvc"/> </wsdl:port> </wsdl:service></wsdl:definitions>
Chapter 2 32Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
WSDL Data Model
definitions targetNamespace=thisNamespace xmins:tns=thisNamespace
types message name=in message name=out
portType name=foo operation input message=tns:in output message=tns:out
binding name=foobar type=tns:foo [binding information]
service name=foobar Service
Port name=foobarPort binding=tns:foobar [endpoint information]
Types contains data type definitionsMessages consist of one or more parts
A portType describes an abstract setof operations
A binding describes a concrete set offormats and protocols for the fooportTypes
A port describes an implementationof the foobar binding
Chapter 2 33Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Directory Services Support discovery: enable applications,
agents, Web service providers, Web service requestors, people, objects, and procedures to locate each other White pages – entries found by name Yellow pages – entries found by characteristics
and capabilities A basic directory might be a simple
database (passive) or a broker/facilitator (active, that provides alerts and recruits participants)
UDDI – both white pages and yellow pages, but passive
Chapter 2 34Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
UDDI: Universal Description, Discovery, and Integration
UDDI is a Web service that is based on SOAP and XML
UDDI registers tModels: technical descriptions of a
service’s behavior businessEntities: describes the
specifications of multiple tModels
Chapter 2 35Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Yellow, Green, and White Pages in UDDI
-businessKey : string(idl)-name : string(idl)-description : string(idl)-URL : string(idl)-contacts : contact-businessServices : businessService-identifierBag : keyedReference-categoryBag : keyedReference
businessEntity
1
*
-tModelKey : string(idl)-keyName : string(idl)-keyValue : string(idl)
keyedReference
-serviceKey : string(idl)-tModelKey : string(idl)-name : string(idl)-description : string(idl)-bindingTemplates
businessService
-phone : string(idl)-address : string(idl)
contact
businessEntity: Information about theparty who publishes information about
a service
businessService: Descriptiveinformation about a particular family of
technical services
bindingTemplate: Technicalinformation about a service entry point
and implementation specs
tModel: Descriptions of specificationsfor services or value sets. Basis for
technical fingerprints
businessEntities containbusinessServices
businessServices containbindingTemplates
bindingTemplates contain referencesto tModels. These references
designate the interface specificationsfor a service
Chapter 2 36Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Data Model for UDDI
businessEntity data structure:<businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40" operator="http://www.ibm.com"
authorizedName="John Doe"> <name>Acme Company</name> <description>
We create cool Web services </description> <contacts>
<contact useType="general info"> <description>General Information</description> <personName>John Doe</personName> <phone>(123) 123-1234</phone>
<email>jdoe@acme.com</email> </contact> </contacts> <businessServices> ... </businessServices>
37
<identifierBag> <keyedReference tModelKey="UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823" name="D-U-N-S" value="123456789" /> </identifierBag> <categoryBag>
<keyedReference tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" name="NAICS" value="111336" /> </categoryBag>
</businessEntity>
Chapter 2 38Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
businessService data structure
<businessService serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <name>Hello World Web Service</name> <description>A friendly Web service</description>
<bindingTemplates> ... </bindingTemplates>
</businessService>
Chapter 2 39Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
bindingTemplate
Chapter 2 40Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Chapter 2 41Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
WSDL UDDI
<import>
<port>
<port>
BusinessEntity
BusinessService
BindingTemplate
BindingTemplate
Service Implementation
UDDI
<service>
Service Interface
<types>
<message>
<portType>
<binding>
tModel
WSDL
Chapter 2 42Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Chapter 2 Summary
The main triad of Web services standards Bring together well-known ideas
SOAP: object access and messaging WSDL: based on CORBA IDL UDDI: based on directories
Provide necessary functionality for interoperation
Are complicated in their details Meant for tool vendors rather than
programmers Increasingly hidden by tools