Web Services Core Technologies SOA and Web Services
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 • 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) Describe (WSDL) 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 /In. Stock 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. w 3. org/2001/12/soap-envelope" soap: encoding. Style="http: //www. w 3. org/2001/12/soap-encoding"> <soap: Header>. . . (optional header information) </soap: Header> <soap: Body xmlns: m="http: //www. stock. org/stock"> <m: Get. Stock. Price> <m: Stock. Name>IBM</m: Stock. Name> </m: Get. Stock. Price> </soap: Body> </soap: Envelope> This envelope is dependent on 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. w 3. org/2001/12/soap-envelope" soap: encoding. Style ="http: //www. w 3. org/2001/12/soapencoding"> <soap: Header>. . . (optional header information) </soap: Header> <soap: Body xmlns: m ="http: //www. stock. org/stock"> <m: Get. Stock. Price. Response> <m: Price>34. 5</m: Price> </m: Get. Stock. Price. Response> </soap: Body> </soap: Envelope>
SOAP Faults • SOAP fault sent instead of normal response if something goes wrong <Body xmlns=http: //www. w 3. 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 • Version. Mismatch – Invalid namespace for SOAP envelope • Must. Understand – 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, Fault. To • These values can also be transferred in a SOAP body using an Endpoint. Reference xml structure • WS-Addressing specifies how an Endpoint. Reference can be mapped to a bunch of SOAP headers.
WS-Addressing Simple Endpoint. Reference: <wsa: Endpoint. Reference> <wsa: Address>http: //example. com/service</wsa: Address> </wsa: Endpoint. Reference> Gets mapped to SOAP Header: <soap: Header> <wsa: Message. ID>urn: uuid: 2</wsa: Message. ID> <wsa: To>http: //example. com/service</wsa: To> </soap: Header> EPR Can contain other info, e. g. : Reference. Parameters – application specific keys Service description location – WSDL file
Endpoint. Reference to SOAP Headers Endpoint. Reference Address http: //server. com SOAP Envelope Header To http: //server. com Reference. Parameters Element … … Element Body CM 0356/CMT 606 Spring 2008
SOAP Request (HTTP & WS-Addressing) POST /Stock. Market. Service 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. w 3. org/2001/12/soap-envelope xmlns: wsa="http: //www. w 3. org/2005/08/addressing" soap: encoding. Style="http: //www. w 3. org/2001/12/soap-encoding"> <soap: Header> <wsa: Message. ID>urn: uuid: 1</wsa: Message. ID> <wsa: Reply. To> <wsa: Address>http: //example. com/business/client</wsa: Address> </wsa: Reply. To> <wsa: To>http: //www. stock. org/Stock. Market. Service</wsa: To> <wsa: Action>http: //www. stock. org/Get. Stock. Market</wsa: Action> </soap: Header> <soap: Body xmlns: m="http: //www. stock. org/stock"> <m: Get. Stock. Market> <m: Market. Name>DOW</m: Market. Name> </m: Get. Stock. Market> </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. w 3. org/2001/12/soap-envelope xmlns: wsa="http: //www. w 3. org/2005/08/addressing" soap: encoding. Style ="http: //www. w 3. org/2001/12/soapencoding"> <soap: Header> <wsa: Message. ID>urn: uuid: 2</wsa: Message. ID> <wsa: Relates. To>urn: uuid: 1</wsa: Relates. To> <wsa: To>http: //example. com/business/client</wsa: To> <wsa: Action> http: //www. stock. org/Get. Stock. Market. Response</wsa: Action> </soap: Header> <soap: Body xmlns: m ="http: //www. stock. org/stock"> <m: Get. Stock. Market. Response> <wsa: Endpoint. Reference> <wsa: Address>http: //www. dow-service. com</wsa: Address> </wsa: Endpoint. Reference> </m: Get. Stock. Market. Response> </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/some. Service? 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 Port (http: //host/) Port Binding (e. g. SOAP) Binding • e. g. http: //cs. cf. ac. uk/service • 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="get. Book. Request"> <part name="param" element="isbn"/> </message> <message name="get. Book. Response"> <part name="resp" element="book"/> </message> <port. Type name="book. Port. Type"> <operation name="get. Book"> <input message="get. Book. Request"/> <output message="get. Book. Response"/> </operation> </port. Type> point to xml in the types section Abstract Definition of Service
WSDL Documents (4) <binding type="book. Port. Type" name="book. Bind"> <soap: binding style="document" transport="http: //schemas. xmlsoap. org/soap/http"/> <operation name=“get. Book”> <soap: operation soap. Action="get. Book"/> <input> <soap: body use="literal"/> </input> <output> <soap: body use="literal"/> </output> </operation> </binding> <service name="Hello_Service"> <port binding="book. Bind" name="book. Port"> <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) <business. Entity business. Key=“ABCD”> <name>BBC</name> <description>. . . </description> </business. Entity>
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) <business. Entity business. Key=“ABCD”> <name>BBC</name> <description>. . . </description> </business. Entity> <business. Service service. Key=“EFGH” business. Key=“ABCD”> <name>News</name> </business. Service> <business. Service service. Key=“IJKL” business. Key=“ABCD”> <name>Weather</name> </business. Service>
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) <business. Entity business. Key=“ABCD”> <name>BBC</name> <description>. . . </description> </business. Entity> <business. Service service. Key=“EFGH” business. Key=“ABCD”> <name>News</name> </business. Service> <binding. Template> binding. Key=“MNOP” service. Key=“EFGH”> <description> Web Service </description> <access. Point> http: //bbc. co. uk/news </access. Point> <t. Model. Instance. Details> <t. Model. Instance. Info t. Model. Key=”QRST”/> </t. Model. Instance. Details> </binding. Template> <binding. Template> binding. Key=“IJKL” service. Key=“EFGH”> <description> Web Page </description> <access. Point> http: //news. bbc. co. uk </access. Point> </binding. Template>
UDDI - t. Models • 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) • t. Model (Technical Model) associates an interface description with a binding • e. g. WSDL • Multiple bindings may refer to the same interface (t. Model) • e. g. The airline industry may define a standard ticket booking interface, multiple airlines may implement this interface
UDDI Data Model (4) <business. Entity business. Key=“ABCD”> <name>BBC</name> <description>. . . </description> </business. Entity> <business. Service service. Key=“EFGH” business. Key=“ABCD”> <name>News</name> </business. Service> <binding. Template> binding. Key=“MNOP” service. Key=“EFGH”> <description> Web Service </description> <access. Point> http: //bbc. co. uk/news </access. Point> <t. Model. Instance. Details> <t. Model. Instance. Info t. Model. Key=”QRST”/> </t. Model. Instance. Details> </business. Template> <t. Model. Key=”QRST”> <overview. Doc> <overview. URL> http: //bbc. co. uk/news? wsdl </overview. URL> </overview. Doc> </t. Model>
UDDI Query <find_business> <find. Qualifier> uddi: uddi. org: find. Qualifier: exact. Match </find. Qualifier> </find. Qualifiers> <name> BBC </name> </find_business> • Also find_service, find_binding, find_t. Model • NOTE: This search is lexical
Putting It All Together Service Registry <find_service> <find. Qualifiers> <find. Qualifier> exact. Match </find. Qualifier> </find. Qualifiers> <name> Book Service </name> </find_service> Find (UDDI) Service Consumer <business. Entity> <name>Book Club</name> <business. Service> <name>Book Service</name> <binding. Template> <description>Web Service</description> <t. Model. Instance. Details> <t. Model. Instance. Info t. Model. Key=”QRST”/> </t. Model. Instance. Details> </binding. Template> <t. Model. Key=”QRST”> <overview. Doc> <overview. URL> http: //cs. cf. ac. uk/bookservice? wsdl </overview. URL> </overview. Doc> </t. Model> </business. Service> </business. Entity> Service Publish (UDDI) Describe (WSDL) Bind (SOAP) Provider http: //cs. cf. ac. uk/bookservice
Putting It All Together Find (UDDI) <message name="get. Book. Request"> <part name="param“ element="isbn"/> </message> <message name="get. Book. Response"> <part name="resp" element="book"/> </message> <port. Type name="book. Port. Type"> Service <operation name="get. Book"> Registry <input message="get. Book. Request"/> <output message="get. Book. Response"/> </operation> </port. Type> <binding type="book. Port. Type" name="book. Bind"> <soap: binding style="document" transport=http: //schemas. xmlsoap. org/soap/http <operation> <soap: operation soap. Action="get. Book"/> <input> <soap: body use="literal"/> </input> <output> <soap: body use="literal"/> </output> </operation> </binding> Service <service name="Hello_Service"> <port binding="book. Bind" name="book. Port"> 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> <get. Book. Request> <isbn>0004702670</isbn> </get. Book. Request> </soap: Body> </soap: Envelope> Bind (SOAP) <soap: Envelope <soap: Body> Service <get. Book. Response> Provider <book> <title>Harry Potter</title> <author>J. K. Rowling</author> http: //cs. cf. ac. uk/bookservice <date>2005 -10 -05</date> </book> </get. Book. Response> </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 • Port. Binding - 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
- Slides: 39
