Presentation is loading. Please wait.

Presentation is loading. Please wait.

Web Services. Need for web services JEE provides a component based approach to development of n-tier applications Limitations Primarily designed for Java.

Similar presentations


Presentation on theme: "Web Services. Need for web services JEE provides a component based approach to development of n-tier applications Limitations Primarily designed for Java."— Presentation transcript:

1 Web Services

2 Need for web services JEE provides a component based approach to development of n-tier applications Limitations Primarily designed for Java Does not directly address inter-language integration Not web centric distribution Uses Java specific mechanisms for inter-component integration Not supported by all major vendors (i.e. Microsoft) 2

3 Web Services Two approaches ‘SOAP’ Web Services: The original and most often meant by term Web Services In this module, web services = ‘SOAP’ web services ‘RESTful’ Web Services: Increasing popular due to simplicity of approach REST versus SOAP is a subject of a continuing ‘religious war’ Caution: Need to check terminology being used when referring to Web Services 3

4 4 Web Services: Definitions W3C: “A software system designed to support interoperable machine-to-machine interaction over a network.” While W3C does refer to both SOAP and REST based web services, most of their definitions relate to SOAP based web services SOAP Web Service definitions A Web service is a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web Service standards form a platform-independent, open framework for describing services, discovering businesses, and integrating business services.

5 Web Services in 1 slide A distributed architecture Does not include component model Platform neutral Access through platform specific development kits Based on internet standards XML, http etc 5

6 6 eXtensible Markup Language A common data format derived from SGML Language independent, hierarchical and self-describing Uses tag-based structure similar to HTML to define XML documents John Smith 1 Grafton Street Dublin 2, Ireland Supports arbitrarily complex data formats Schema (defined in xsd files) can be used to define document formats Fragment defining a BankAccount as a type of financial record

7 7 eXtensible Markup Language Independent of IT infrastructure Separates the what from the how Many industry based schema standards have been developed For example, Financial Services: ISO15022 (SWIFT, FIX, FpML) XBRL (business reporting) Any XML based infrastructure can handle multiple and evolving schema standards without excessive cost Due to changes in business relationships Due to regulatory changes (e.g. Basil II) Due to evolution of the schemas themselves

8 8 The Web Services architecture UDDI Registry 2. Request contract information 3. Retrieve WSDL definition 4. Exchange SOAP messages WSDL 1. Register contract information Service Consumer Service Provider WSDL Web Services define Service provider: “server” supporting the interface Service consumer: “client” making requests Web Services is based on three standards Simple Object Access Protocol (SOAP) defines the communication mechanism Universal Directory Discovery Interface (UDDI) defines the registry of interface definitions Web Service Definition Language (WSDL) defines the actual interfaces

9 Client code 9 Web Services Model Stub Server-Side code Consumer-SideNetworkProvider Side invokes return results connect to remote service invoke return results return results Stub is auto-generated from the WSDL during development The server side received the call (invocation) through the SOAP runtime library SOAP runtime library

10 10 SOAP- Simple Object Access Protocol XML based protocol for exchange of information Encoding rules for datatype instances Convention for representing RPC invocations Used with XML Schema Normally HTTP-based Uses Request/Response Two different modes RPC Document SOAP with Attachments allow arbitrary data to be packaged. SOAP1.1 Message Structure SOAP Envelope Header Entries Header Body Fault Element

11 11 SOAP Example: Request Sample SOAP Message embedded in an HTTP Request POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: 1024 SOAPAction: "http://example.org/2001/06/quotes" <m:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes"> IBM

12 12 SOAP Example: Response SOAP message sent by the StockQuote service in the corresponding HTTP response to the request HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 512 <m:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes"> 97.5

13 13 UDDI Universal Description, Discovery and Integration Platform-independent, open framework for describing services, discovering businesses, and integrating business services. A DNS-like model implementation of the directory Originally intended to support global registries Created during the.com bubble. Includes White, Green and Yellow Pages for search purposes Now primarily inside organisations if at all

14 14 Web Service Description Language (WSDL) Interface definition language in XML Conceptually, no different from Enterprise Java Bean or Common Gateway Interface Based on XML Schema Can appear to be very verbose An interface description is a contract between the server developers and the client developers WSDL describes the web service Similar to Java method signatures

15 15 Interoperability Challenges Interoperability remains the chief challenge of web services Complex and imprecise standard Tools generating SOAP, WSDL, UDDI, etc. need to be interoperable Web Services Interoperability (WS-I) focus on creating to Interoperability WS-I Basic Profile 1.0 defines an interoperable web services platform Current version is WS-I v2.0

16 16 Web Services: Another approach to distributed computing Transport Messaging Description Discovery Quality Of Service Builds on the legacy of CORBA, J2EE etc It is not a new component model, programming model or programming language. UDDI/WSDL/SOAP provide another distributed computing technology Standards developing for the Quality of Services functionality E.g. WS-Security, WS-ReliableMessaging etc

17 17 Web Services Strengths versus JEE Interoperability Based on open standards, utilizes existing infrastructure Can be accessed from any programming language/model Ubiquity Communicates through XML/HTTP – Any system that supports these standards, supports Web Services Support from all major software vendors (IBM and Microsoft) Low barrier to entry Concepts easy to understand, easy to implement Toolkits allow COM, JEE, and CORBA components to be exposed as Web Services

18 RESTful Web Services REpresentational State Transfer Architecture inherent in all web based system since 1994, not explicitly described as an architecture until later An architecture - not a set of standard Web Services is both an architecture and a set of standards Goal: To leverage web based standards to allow inter-application communication as simply as possible Matches the ‘standard’ web interaction model 18

19 The standard Web architecture Web Server HTTP POST URL 3 PO (HTML) HTTP GET request URL 1 HTTP response URL to submitted PO Parts List Part Data PO HTTP response Response (HTML doc) HTTP response Response (HTML doc) HTTP GET request URL 2 Copyright © [2005]. Roger L. Costello, Timothy D. Kehoe.

20 The RESTful architecture Web Server HTTP POST URL 3 PO (XML) HTTP GET request URL 1 HTTP response URL to submitted PO Parts List Part Data PO HTTP response Response (XML doc) HTTP response Response (XML doc) HTTP GET request URL 2 Copyright © [2005]. Roger L. Costello, Timothy D. Kehoe.

21 REST architecture Uses HTTP operations: GET = "give me some info" (Retrieve) POST = "here's some update info" (Update) PUT = "here's some new info" (Create) DELETE = "delete some info" (Delete) Typically exchanges XML documents But supports a wide range of other internet media types Example of client side REST request: GET /shoppingcart/5873 Server must be able to correctly interpret the client request as there is no explicitly defined equivalent to an interface definition 21

22 22 REST Architecture Servers are stateless and messages can be interpreted without examining history Messages are self-contained There is no such thing as a “service”. There are just resources which are accessed through URI URI = generalisation of URL Clients navigate through a series of steps towards a goal by following hypertext links (GET) and submitting representations (POST).

23 REST – strong versus weak Pure REST should use ‘pure’ URI only E.g. GET /shoppingcart/5873 Many REST implementations also allow parameter passing E.g. GET /shoppingcart/5873?sessionID=123 Allowing parameter passing makes REST a lot more usable but blurs the architectural principle of statelessness 23

24 REST versus web services REST Strengths No toolkit or infrastructure Independent of programming language, platform or component model Easy to learn Easy to get simple systems working quickly REST weaknesses No standardisation on use of URI No standardisation response document format Yahoo uses XML, Google uses JSON (JavaScript) Less structured approach makes it harder to build complex interactions 24


Download ppt "Web Services. Need for web services JEE provides a component based approach to development of n-tier applications Limitations Primarily designed for Java."

Similar presentations


Ads by Google