Download presentation
Presentation is loading. Please wait.
1
Web Services Core Technologies
SOA and Web Services Web Services Standards The XML! SOAP WSDL UDDI
2
Service Oriented Architecture (SOA)
SOA is an example of a the composite computing model: “an architecture that uses distributed, discovery-based execution to expose and manage a collection of service-oriented software assets” In this model: capabilities (i.e. software assets) should be dynamically discoverable should be a clear separation of the software's capabilities and its implementation should be possible to quickly assemble impromptu computing communities with minimal coordinated planning efforts, installation technicalities or human intervention.
3
What does this entail? Every step of the process needs to be machine processable Service description Data description Metadata description Service discovery Service invocation
5
SOA Triad of Operations
6
Web Service Protocols Web Services Protocols based on XML Messaging
SOAP Service Description WSDL Service Discovery UDDI Many Others BPEL, WSRF, WS-Addressing, WS-Security, WS-Notification SOAP, WSDL are de-facto standards UDDI less ubiquitous – but a good example of simple publish/find. Service Registry Find (UDDI) Publish (UDDI) Describe (WSDL) Service Consumer Service Provider Bind (SOAP)
7
SOAP Simple Object Access Protocol (SOAP) Now just SOAP
Has its roots in RPC as you can tell by the name Envelope for exchanging XML messages Doesn’t define message exchange pattern Not restricted to request/response Doesn’t specify transport protocol Normally tunnelled through HTTP POST, but can be any protocol that can carry a SOAP envelope Structurally very similar to an (X)HTML document…
8
Extension Information
SOAP Document Envelope Top-level wrapper Header (optional) Security and authentication information (WS-Security) Routing information (WS-Addressing) Resource information (WSRF) … Body XML encoded application data Attachments (optional and used less now) Additional non XML-data (binary, unencoded text, etc.) SOAP Envelope (Required) SOAP Header (Optional) Extension Information e.g. routing, security SOAP Body (Required) Application Data e.g. request, response error
9
SOAP Request (HTTP) This envelope is dependent on HTTP HTTP Header
POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap=" soap:encodingStyle=" <soap:Header> ... (optional header information) </soap:Header> <soap:Body xmlns:m=" <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope> HTTP Header SOAP Envelope SOAP Header SOAP Body This envelope is dependent on HTTP
10
SOAP Response (HTTP) HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <soap:Envelope xmlns:soap=" soap:encodingStyle =" <soap:Header> ... (optional header information) </soap:Header> <soap:Body xmlns:m =" <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope> This is still transfer protocol dependent. There is no address in the envelope so I can’t cut and paste this into an for example, and send it to someone. Where ever it goes, it will rely on the transfer protocol to set the address.
11
SOAP Faults SOAP fault sent instead of normal response if something goes wrong <Body xmlns= <Fault> <faultcode>Client</faultcode> <faultstring>Something went wrong</faultstring> <detail>Application specific error information</detail> </Fault> </Body> Fault Code Client – Message incorrectly formed by client Server – Problem on server so message could not proceed VersionMismatch – Invalid namespace for SOAP envelope MustUnderstand – Header element not understood
12
WS-Addressing The previous example was dependent on HTTP to have an address WS-Addressing overcomes this Allows addressing information to be embedded in the SOAP header E.g. To, From, FaultTo These values can also be transferred in a SOAP body using an EndpointReference xml structure WS-Addressing specifies how an EndpointReference can be mapped to a bunch of SOAP headers.
13
WS-Addressing Simple EndpointReference: Gets mapped to SOAP Header:
<wsa:EndpointReference> <wsa:Address> </wsa:EndpointReference> Gets mapped to SOAP Header: <soap:Header> <wsa:MessageID>urn:uuid:2</wsa:MessageID> <wsa:To> </soap:Header> EPR Can contain other info, e.g.: ReferenceParameters – application specific keys Service description location – WSDL file
14
EndpointReference to SOAP Headers
SOAP Envelope Address Header To ReferenceParameters Element Element … … Element Element Body CM0356/CMT606 Spring 2008
15
SOAP Request (HTTP & WS-Addressing)
POST /StockMarketService HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap= xmlns:wsa=" soap:encodingStyle=" <soap:Header> <wsa:MessageID>urn:uuid:1</wsa:MessageID> <wsa:ReplyTo> <wsa:Address> </wsa:ReplyTo> <wsa:To> <wsa:Action> </soap:Header> <soap:Body xmlns:m=" <m:GetStockMarket> <m:MarketName>DOW</m:MarketName> </m:GetStockMarket> </soap:Body> </soap:Envelope> HTTP Header SOAP Envelope SOAP Header SOAP Body
16
SOAP Response (HTTP & WS-Addressing)
HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <soap:Envelope xmlns:soap= xmlns:wsa=" soap:encodingStyle =" <soap:Header> <wsa:MessageID>urn:uuid:2</wsa:MessageID> <wsa:RelatesTo>urn:uuid:1</wsa:RelatesTo> <wsa:To> <wsa:Action> </soap:Header> <soap:Body xmlns:m =" <m:GetStockMarketResponse> <wsa:EndpointReference> <wsa:Address> </wsa:EndpointReference> </m:GetStockMarketResponse> </soap:Body> </soap:Envelope> This is still transfer protocol dependent. There is no address in the envelope so I can’t cut and paste this into an for example, and send it to someone. Where ever it goes, it will rely on the transfer protocol to set the address.
17
SOAP XML based Simple and Lightweight
Compared to CORBA, RMI, DCOM etc. Language and OS Independent Unlike RMI (Java) or DCOM (Windows) Transport Protocol Independent Transfer Protocol Independent with WS-Addressing Extensible Additional features can be included in header Vendor Support IBM, Microsoft, Apache, HP, Sun, etc
18
WSDL Web Service Definition Language (WSDL) WSDL documents describe:
Where the service resides, and How to invoke the service Generally available as web pages e.g. Location of WSDL relative to Web Service not specified Like CORBA Interface Definition Language (IDL) but more flexible
19
WSDL Documents (1) Types What data types will be transmitted Messages
What messages will be transmitted Port Types What operations (functions) will be supported Bindings How will the messages be transmitted on the wire? What message protocol (e.g. SOAP) specific details are there? Service Where is the service located? Types Messages Port Types Bindings Service
20
WSDL Documents (2) Service can have multiple ports
A port is an endpoint to which messages are sent e.g. Each port is bound to: A message protocol e.g. SOAP A port type via the binding element Port types specify: Operation name Input message type Output message type Types defined using XML Schemas Service Port ( Port Binding (e.g. SOAP) Binding Abstract Definition Port Type (in) Message Operation(s) (out) Message
21
WSDL Documents (3) <message name="getBookRequest">
<part name="param" element="isbn"/> </message> <message name="getBookResponse"> <part name="resp" element="book"/> <portType name="bookPortType"> <operation name="getBook"> <input message="getBookRequest"/> <output message="getBookResponse"/> </operation> </portType> point to xml in the types section Abstract Definition of Service
22
WSDL Documents (4) <binding type="bookPortType" name="bookBind">
<soap:binding style="document" transport=" <operation name=“getBook”> <soap:operation soapAction="getBook"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="Hello_Service"> <port binding="bookBind" name="bookPort"> <soap:address location=" </port> </service>
23
UDDI Universal Description, Discovery and Integration (UDDI) Protocol
Originally Microsoft, IBM and Ariba Registry for business services Like a phone book for Web Services, although not actually restricted to Web Services XML-based UDDI directory contains three components White Pages - Businesses Yellow Pages – Services provided by the businesses Green Pages – How these services can be accessed
24
UDDI – White Pages Information about businesses Name
Description of the business Potentially multiple languages Contact information Address Phone number etc. Other information Dun & Bradstreet Universal Numbering System number (D.U.N.S)
25
UDDI Data Model (1) <businessEntity businessKey=“ABCD”>
<name>BBC</name> <description> ... </description> </businessEntity>
26
UDDI – Yellow Pages Classification of services/businesses based on standard taxonomies Standard Industrial Classification (SIC) 7361 = Services - Employment Agencies 7385 = Services - Telephone Interconnect Systems United Nations Standard Products and Services Code (UNSPSC) = Employment = Cellular telephone services A business may provide multiple services
27
UDDI Data Model (2) <businessService serviceKey=“EFGH”
businessKey=“ABCD”> <name>News</name> </businessService> <businessEntity businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> <businessService serviceKey=“IJKL” businessKey=“ABCD”> <name>Weather</name> </businessService>
28
UDDI – Green Pages Information and service bindings, i.e. how a service can be accessed Web Service related Web Service address Parameters Non-Web Service related FTP CORBA Telephone A service may have multiple bindings (e.g. a Web Service binding, a telephone binding)
29
UDDI Data Model (3) <bindingTemplate> <businessEntity
bindingKey=“MNOP” serviceKey=“EFGH”> <description> Web Service </description> <accessPoint> </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey=”QRST”/> </tModelInstanceDetails> </bindingTemplate> <businessEntity businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> <businessService serviceKey=“EFGH” businessKey=“ABCD”> <name>News</name> </businessService> <bindingTemplate> bindingKey=“IJKL” serviceKey=“EFGH”> <description> Web Page </description> <accessPoint> </accessPoint> </bindingTemplate>
30
UDDI - tModels No explicit link between UDDI and WSDL
Binding template contains access point (i.e. where to contact the service) But no information on how to interface with the access point (such as expected data types) tModel (Technical Model) associates an interface description with a binding e.g. WSDL Multiple bindings may refer to the same interface (tModel) e.g. The airline industry may define a standard ticket booking interface, multiple airlines may implement this interface
31
UDDI Data Model (4) <businessEntity <bindingTemplate>
businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> <bindingTemplate> bindingKey=“MNOP” serviceKey=“EFGH”> <description> Web Service </description> <accessPoint> </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey=”QRST”/> </tModelInstanceDetails> </businessTemplate> <businessService serviceKey=“EFGH” businessKey=“ABCD”> <name>News</name> </businessService> <tModel tModelKey=”QRST”> <overviewDoc> <overviewURL> </overviewURL> </overviewDoc> </tModel>
32
UDDI Query Also find_service, find_binding, find_tModel
<find_business> <findQualifiers> <findQualifier> uddi:uddi.org:findQualifier:exactMatch </findQualifier> </findQualifiers> <name> BBC </name> </find_business> Also find_service, find_binding, find_tModel NOTE: This search is lexical
33
Putting It All Together
<businessEntity> <name>Book Club</name> <businessService> <name>Book Service</name> <bindingTemplate> <description>Web Service</description> <tModelInstanceDetails> <tModelInstanceInfo tModelKey=”QRST”/> </tModelInstanceDetails> </bindingTemplate> <tModel tModelKey=”QRST”> <overviewDoc> <overviewURL> </overviewURL> </overviewDoc> </tModel> </businessService> </businessEntity> Service Registry <find_service> <findQualifiers> <findQualifier> exactMatch </findQualifier> </findQualifiers> <name> Book Service </name> </find_service> Find (UDDI) Publish (UDDI) Describe (WSDL) Service Consumer Service Provider Bind (SOAP)
34
Putting It All Together
<message name="getBookRequest"> <part name="param“ element="isbn"/> </message> <message name="getBookResponse"> <part name="resp" element="book"/> <portType name="bookPortType"> <operation name="getBook"> <input message="getBookRequest"/> <output message="getBookResponse"/> </operation> </portType> <binding type="bookPortType" name="bookBind"> <soap:binding style="document" transport= <operation> <soap:operation soapAction="getBook"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </binding> <service name="Hello_Service"> <port binding="bookBind" name="bookPort"> <soap:address location=" </port> </service> Service Registry Find (UDDI) Publish (UDDI) Describe (WSDL) Service Consumer Service Provider Bind (SOAP)
35
Putting It All Together
Service Registry Find (UDDI) Publish (UDDI) Describe (WSDL) Service Consumer Service Provider <soap:Envelope <soap:Body> <getBookResponse> <book> <title>Harry Potter</title> <author>J.K. Rowling</author> <date> </date> </book> </getBookResponse> </soap:Body> </soap:Envelope> <soap:Envelope <soap:Body> <getBookRequest> <isbn> </isbn> </getBookRequest> </soap:Body> </soap:Envelope> Bind (SOAP)
36
Discussion What have we seen here? A lot of XML!
What about Service Orientation? How do the technologies support his? SOAP as a simple, transport/transfer independent envelope is useful. Applications can put everything they need in it to make messages self describing Supports transactions/security/adressing etc.
37
And What About WSDL? The abstractions defined by WSDL are Object Oriented and encourage RPC style interactions. Operations = methods Input type/Output types = method parameters Ports - collections of related operations = a Class/Interface PortBinding - Instance of the Port = Object This is not very service oriented! It often results in RPC interactions simply wrapped in complex XML.
38
And UDDI? The idea of UDDI is good But it’s very complicated
Wants to cover everything But searching is limited to lexical queries It never really took off The two main public UDDI repositories run by MS and IBM have shut down Why? Perhaps because of complexity Perhaps because companies do not want to share their commodities in this way They want more control over how their services are published and accessed. Hence UDDI still works, but mainly behind the corporate firewall - NOT on an internat scale
39
Conclusion SOA What is it, what are its benefits?
How do core Web Service technologies support SOA? SOAP Simple protocol for exchanging XML messages Extensible via header WSDL Language for defining web services Operations Inputs/Outputs Object Oriented in spirit UDDI Registry for business services Not tied to Web Services Complex data structures Only supports lexical matching without extensions
Similar presentations
