Web Services Core Technologies • SOA and Web Services • Web Services Standards • The XML! • SOAP • WSDL • UDDI 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. What does this entail? • Every step of the process needs to be machine processable • Service description • Data description • Metadata description • Service discovery • Service invocation SOA Triad of Operations Web Service Protocols • Web Services Protocols based on XML • Messaging Service Registry • SOAP • Service Description • WSDL • Service Discovery Find (UDDI) • UDDI Describe (WSDL) • Many Others • BPEL, WSRF, WSAddressing, WS-Security, • WS-Notification • SOAP, WSDL are de-facto standards • UDDI less ubiquitous – but a good example of simple publish/find. Publish (UDDI) Service Consumer Bind (SOAP) Service Provider 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… SOAP Document • SOAP Envelope (Required) • SOAP Header (Optional) Extension Information e.g. routing, security SOAP Body (Required) • Application Data • e.g. request, response error Envelope • Top-level wrapper Header (optional) • Security and authentication information (WS-Security) • Routing information (WSAddressing) • Resource information (WSRF) • … Body • XML encoded application data Attachments (optional and used less now) • Additional non XML-data (binary, unencoded text, etc.) SOAP Request (HTTP) POST /InStock HTTP/1.1 Host: www.stock.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... (optional header information) </soap:Header> <soap:Body xmlns:m="http://www.stock.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope> This envelope is dependent on HTTP HTTP Header SOAP Envelope SOAP Header SOAP Body SOAP Response (HTTP) HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle ="http://www.w3.org/2001/12/soapencoding"> <soap:Header> ... (optional header information) </soap:Header> <soap:Body xmlns:m ="http://www.stock.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope> SOAP Faults • SOAP fault sent instead of normal response if something goes wrong <Body xmlns=http://www.w3.org/2001/12/soap-envelope> <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 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. WS-Addressing Simple EndpointReference: <wsa:EndpointReference> <wsa:Address>http://example.com/service</wsa:Address> </wsa:EndpointReference> Gets mapped to SOAP Header: <soap:Header> <wsa:MessageID>urn:uuid:2</wsa:MessageID> <wsa:To>http://example.com/service</wsa:To> </soap:Header> EPR Can contain other info, e.g.: ReferenceParameters – application specific keys Service description location – WSDL file EndpointReference to SOAP Headers EndpointReference Address http://server.com SOAP Envelope Header To http://server.com ReferenceParameters Element Element … … Element Element Body CM0356/CMT606 Spring 2008 SOAP Request (HTTP & WS-Addressing) POST /StockMarketService HTTP/1.1 Host: www.stock.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope xmlns:wsa="http://www.w3.org/2005/08/addressing" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <wsa:MessageID>urn:uuid:1</wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://example.com/business/client</wsa:Address> </wsa:ReplyTo> <wsa:To>http://www.stock.org/StockMarketService</wsa:To> <wsa:Action>http://www.stock.org/GetStockMarket</wsa:Action> </soap:Header> <soap:Body xmlns:m="http://www.stock.org/stock"> <m:GetStockMarket> <m:MarketName>DOW</m:MarketName> </m:GetStockMarket> </soap:Body> </soap:Envelope> HTTP Header SOAP Envelope SOAP Header SOAP Body SOAP Response (HTTP & WS-Addressing) HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <soap:Envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope xmlns:wsa="http://www.w3.org/2005/08/addressing" soap:encodingStyle ="http://www.w3.org/2001/12/soapencoding"> <soap:Header> <wsa:MessageID>urn:uuid:2</wsa:MessageID> <wsa:RelatesTo>urn:uuid:1</wsa:RelatesTo> <wsa:To>http://example.com/business/client</wsa:To> <wsa:Action> http://www.stock.org/GetStockMarketResponse</wsa:Action> </soap:Header> <soap:Body xmlns:m ="http://www.stock.org/stock"> <m:GetStockMarketResponse> <wsa:EndpointReference> <wsa:Address>http://www.dow-service.com</wsa:Address> </wsa:EndpointReference> </m:GetStockMarketResponse> </soap:Body> </soap:Envelope> 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 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. http://bouscat.cs.cf.ac.uk/someService?WSDL • Location of WSDL relative to Web Service not specified • Like CORBA Interface Definition Language (IDL) but more flexible WSDL Documents (1) Types Messages Port Types Bindings Service • 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? WSDL Documents (2) • Service can have multiple ports • A port is an endpoint to which messages are sent Service • e.g. http://cs.cf.ac.uk/service Port (http://host/) Port Binding (e.g. SOAP) Binding • Each port is bound to: • A message protocol • e.g. SOAP Port Type Abstract Definition (in) Message Operation(s) (out) Message • A port type • via the binding element • Port types specify: • Operation name • Input message type • Output message type • Types defined using XML Schemas WSDL Documents (3) <message name="getBookRequest"> <part name="param" element="isbn"/> </message> <message name="getBookResponse"> <part name="resp" element="book"/> </message> <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 WSDL Documents (4) <binding type="bookPortType" name="bookBind"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <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="http://localhost/bookservice"/> </port> </service> 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 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) UDDI Data Model (1) <businessEntity businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> 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) • 93141800 = Employment • 83111603 = Cellular telephone services • A business may provide multiple services UDDI Data Model (2) <businessEntity businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> <businessService serviceKey=“EFGH” businessKey=“ABCD”> <name>News</name> </businessService> <businessService serviceKey=“IJKL” businessKey=“ABCD”> <name>Weather</name> </businessService> 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 • • • • E-mail FTP CORBA Telephone • A service may have multiple bindings (e.g. a Web Service binding, a telephone binding) UDDI Data Model (3) <businessEntity businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> <businessService serviceKey=“EFGH” businessKey=“ABCD”> <name>News</name> </businessService> <bindingTemplate> bindingKey=“MNOP” serviceKey=“EFGH”> <description> Web Service </description> <accessPoint> http://bbc.co.uk/news </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey=”QRST”/> </tModelInstanceDetails> </bindingTemplate> <bindingTemplate> bindingKey=“IJKL” serviceKey=“EFGH”> <description> Web Page </description> <accessPoint> http://news.bbc.co.uk </accessPoint> </bindingTemplate> 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 UDDI Data Model (4) <businessEntity businessKey=“ABCD”> <name>BBC</name> <description> ... </description> </businessEntity> <businessService serviceKey=“EFGH” businessKey=“ABCD”> <name>News</name> </businessService> <bindingTemplate> bindingKey=“MNOP” serviceKey=“EFGH”> <description> Web Service </description> <accessPoint> http://bbc.co.uk/news </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey=”QRST”/> </tModelInstanceDetails> </businessTemplate> <tModel tModelKey=”QRST”> <overviewDoc> <overviewURL> http://bbc.co.uk/news?wsdl </overviewURL> </overviewDoc> </tModel> UDDI Query <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 Putting It All Together Service Registry <find_service> <findQualifiers> <findQualifier> exactMatch </findQualifier> </findQualifiers> <name> Book Service </name> </find_service> Find (UDDI) Service Consumer <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> http://cs.cf.ac.uk/bookservice?wsdl </overviewURL> </overviewDoc> </tModel> </businessService> </businessEntity> Service Publish (UDDI) Describe (WSDL) Bind (SOAP) Provider http://cs.cf.ac.uk/bookservice Putting It All Together Find (UDDI) <message name="getBookRequest"> <part name="param“ element="isbn"/> </message> <message name="getBookResponse"> <part name="resp" element="book"/> </message> <portType name="bookPortType"> Service <operation name="getBook"> Registry <input message="getBookRequest"/> <output message="getBookResponse"/> </operation> </portType> <binding type="bookPortType" name="bookBind"> <soap:binding style="document" transport=http://schemas.xmlsoap.org/soap/http <operation> <soap:operation soapAction="getBook"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> Service <service name="Hello_Service"> <port binding="bookBind" name="bookPort"> Provider <soap:address location="http://cs.cf.ac.uk/bookservice"/> </port> http://cs.cf.ac.uk/bookservice </service> Publish (UDDI) Describe (WSDL) Service Consumer Bind (SOAP) Putting It All Together Service Registry Find (UDDI) Publish (UDDI) Describe (WSDL) Service <soap:Envelope Consumer <soap:Body> <getBookRequest> <isbn>0004702670</isbn> </getBookRequest> </soap:Body> </soap:Envelope> Bind (SOAP) <soap:Envelope <soap:Body> Service <getBookResponse> Provider <book> <title>Harry Potter</title> <author>J.K. Rowling</author> http://cs.cf.ac.uk/bookservice <date>2005-10-05</date> </book> </getBookResponse> </soap:Body> </soap:Envelope> 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. 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. 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 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