Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to Web Services

3,862 views

Published on

What is Service?, How Web Services differ from other services? Web Services Standard

Introduction to Web Services

  1. 1. Topic 2 Introduction to Web Service Dr.Thanachart Numnonda Sun Microsystems (Thailand) Asst.Prof.Thanisa Kruawaisayawan KMITL
  2. 2. Agenda  What is Service?  What/Why Web Services?  Web Services Specifications:  Web Services Demo 2
  3. 3. What is Service? 3
  4. 4. What is Service?  Primary goal of a service is to represent a “natural” step of business functionality  Technically, a service is a software component  a service is an interface for (multiple) messages that return information and/or change the state of an associate entity (backend)  The operations defines in the interface carry out business functions  Service is available across a network. 4
  5. 5. Services in SOA • SOA is focused on business process • Services can be implemented by any technology on any platform (NOT only web services) • In fact, SOA has been around for quite a while • Other service components – EJB (Enterprise Java Bean), COM+, .NET Enterprise services, CCM (CORBA Component Models) 5
  6. 6. Characteristics of Service 6
  7. 7. Characteristics of Service (cont.) 7
  8. 8. Types of Services • Entity Service – Represent one or more business entity – Features CRUD operations • Functional Service – Is a technology oriented service – Perform a given function; eg: sending mail, deposit • Process Service – Represents a series of related tasks – Can be represented as an orchestration invoked by ESB; eg: loan process 8
  9. 9. What/Why Web Service? 9
  10. 10. What is Web Service?  A Web service is a software module that has a URL or an Internet address so they can be called upon to perform a operation via the Internet.  One Web service makes a request of another Web service to perform its task or tasks and pass back an answer creating a highly distributed system.  using XML based messages via internet-based protocols  Web Services are latest distributed technology 10
  11. 11. Web Services Conceptual Model 11
  12. 12. Web Services Conceptual Model (cont.) 12
  13. 13. Web Services Conceptual Model (cont.) 13
  14. 14. Web Services Conceptual Model (cont.) 14
  15. 15. Characteristics of Web Services  XML based everywhere  Message-based  Programming language independent  Could be dynamically located  Could be dynamically assembled or aggregated  Accessed over the internet  Loosely coupled  Based on industry standards 15
  16. 16. How Web Services differ from Others? • Supported by all major software vendors; so fulfills the promose of universal interoperability • Operations of Web Services are based on the exchanged of XML format • Web Services utilize standard Internet protocols such as HTTP, SMTP, FTP 16
  17. 17. Distributed Computing Evolution Servers Servers Clients PDA Cell Internet Phone Client-Server(C/S) silos Clients Workstation Server Web-based computing Kiosk Laptop Web Services/Peer-to-Peer 17
  18. 18. Traditional C/S vs. Web Services Traditional C/S Web Service  Within enterprise  Between enterprises  Tied to a set of  Program language programming languages independent  Procedural  Message-driven  Usually bound to a  Easily bound to different particular transport transports  Tightly-coupled  Loosely-coupled  Efficient processing  Relatively not efficient (space/time) processing
  19. 19. Web Application vs. Web Services Web Application Web Service  User-to-program  Program-to-program interaction interaction  Static integration of  Possibility of dynamic components integration of  Monolithic service components (in the future)  Possibility of service aggregation (in the future)
  20. 20. Why Web Services? Web Services:  Are platform neutral  Are accessible in a standard way  Are accessible in an interoperable way  Use simple and ubiquitous plumbing  Are relatively cheap  Simplify enterprise integration 20
  21. 21. Why Web Services are a Hot Topic:  Interoperable – Connect across heterogeneous networks using ubiquitous web-based standards  Economical – Recycle components, no installation and tight integration of software  Automatic – No human intervention required even for highly complex transactions  Accessible – Legacy assets & internal apps are exposed and accessible on the web  Available – Services on any device, anywhere, anytime  Scalable – No limits on scope of applications and amount of heterogeneous applications
  22. 22. Web Services Usage Example Distributor XML XML Manufacturing Supplier Internet Facility XML XML Logistics “Growing need for a standard lightweight infrastructure for data exchange in e-business applications.” 22
  23. 23. Myth: Web Services is a New Concept  Web services is distributed computing all over again – only now it is based on the web Distributed Computing via Concept CORBA /Java Basic Web Services Interface Description CORBA IDL, Java interface WSDL RPC support ORBs, Idl2java compilers, rmic SOAP Service Registry CORBA naming service, JNDI UDDI Messaging support CORBA Event/Notification service, JMS WS-Reliable Messaging? Transaction support CORBA Transaction service, JTS WS-AtomicTransaction ? Secuity support CORBA Security service, Java security WS-Security ?
  24. 24. Other Popular Myths Surrounding Web Services  Web services require only SOAP, WSDL, UDDI: − We need more high-level semantics  Web services are based on the RPC paradigm: − Document-driven model would be more popular communication model  Web services must be based on HTTP: − Other transports such as SMTP can be also used 24
  25. 25. Myths about Web Services  Web Services cure cancer: Not for a very very long time!  Web Services are something completely new: Not True!  You have to write Web Services from scratch: Not True!  Java Platform does not support web services: Not True! 25
  26. 26. State of Web Services  Technology/Standards are still evolving − SOAP, WSDL, UDDI are not enough  Business web services is the next big thing, but more works are needed in − Quality of Service, management − Security, transaction, state and user context − Work flow, Identity management, − Provisioning, Accounting  Will be adopted in phases 26
  27. 27. Web Services Adoption Phases  1st phase (in the past)  Concerted deployment internally within an organization mainly for interoperability  SOAP over HTTP/S  2nd phase (current state)  Selective and non-aggregate deployment with trusted outside business partners  Private registry deployment  3rd phase (1 to 2 years)  Wider, more dynamic and aggregate deployment with outside business partners  Public registry deployment
  28. 28. Web Services Adoption Phases (cont.)  1st Phase – Simple Web Services (Past)  Consumer-focused, stateless, SOAP over HTTP/S  2nd Phase – EAI Web Services (Now)  Deployed within organization boundaries to enable internal integration  3rd Phase – Business Web Services (1-2 Year)  Deployed on extranets to enable business transactions with trading partners, suppliers, and customers, ebXML & UBL
  29. 29. Trends Towards Service Orientation  Evolution of EAI to web service standards  XML RPC => Asynchronous XML Messaging  Towards de-centralization  Componentized services − Composable and composite services − Data encapsulated within component − Data ownership follows component ownership  Brokered web services  Flexible relationships => Adaptive businesses 29
  30. 30. Web Service Specifications? 30
  31. 31. Web Services : Fundamental Specifiations  Service Invocation => SOAP  Service Description => WSDL  Service Registration (Publication) and Discovery => UDDI  SOAP, WSDL and UDDI are XML based
  32. 32. XML 32
  33. 33. XML Schema • XML is the lingua franca of SOA, used for message payloads • XML Schema provides data definition in XML format • XML Schemas are not object-oriented , are intended to capture a data model 33
  34. 34. Example: Book.xsd 34
  35. 35. SOAP 35
  36. 36. SOAP  Simple Object Access Protocol  Wire protocol similar to − IIOP for CORBA − JRMP for RMI  XML is used for data encoding − “text” based protocol vs. “binary” protocol  Supports XML-based RPC 36
  37. 37. What SOAP is Not  Not a component model − So it will not replace objects and components, i.e. EJB, JavaBeans  Not a programming language − So it will not replace Java  Not a solution for all − So it will not replace other distributed computing technologies such as RMI 37
  38. 38. What does SOAP Define?  Message Envelope  Encoding Rules  RPC Convention  Binding with underlying protocols 38
  39. 39. SOAP Message Format SOAP Message SOAP Envelope SOAP Header Primary MIME part (text/xml) Header Entry Header Entry Attachment SOAP Body Attachment Body Entry Body Entry Attachment 39
  40. 40. SOAP Message Envelope  Encoding information  Header − Optional − Could contain context knowledge  Security  Transaction  Body − RPC methods and parameters − Contains application data 40
  41. 41. SOAP Encoding • Rules of expressing application-defined data types in XML • Based on W3C XML Schema • Simple values – Built-in types from XML Schema, Part 2 (simple types, enumerations, arrays of bytes) • Compound values – Structs, arrays, complex types 41
  42. 42. SOAP RPC Request Example <SOAP-ENV:Envelope xmlns:SOAP-ENV="…" SOAP-ENV:encodingStyle="…"> <SOAP-ENV:Header> <!-- Optional context information --> </SOAP-ENV:Header> <SOAP-ENV:Body>    <m:GetLastTradePrice xmlns:m=“some_URI">      <tickerSymbol>SUNW</tickerSymbol>    </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 42
  43. 43. SOAP RPC Response Example <SOAP-ENV:Envelope xmlns:SOAP-ENV="…" SOAP-ENV:encodingStyle="…"> <SOAP-ENV:Header> <!-- Optional context information --> </SOAP-ENV:Header> <SOAP-ENV:Body>   <m:GetLastTradePriceResponse xmlns:m=“some_URI">      <price>30.5</price>   </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 43
  44. 44. SOAP RPC  Information needed for a method call: − The URI of the target object <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=“http://stocks.com/StockQuotes"> <tickerSymbol>SUNW</tickerSymbol> </m:GetLastTradePrice> </SOAP-ENV:Body> 44
  45. 45. SOAP RPC (cont.)  Information needed for a method call: − The URI of the target object − Method name <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=“http://stocks.com/StockQuotes"> <tickerSymbol>SUNW</tickerSymbol> </m:GetLastTradePrice> </SOAP-ENV:Body> 45
  46. 46. SOAP RPC (cont.)  Information needed for a method call: − The URI of the target object − Method name − Parameters <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=“http://stocks.com/StockQuotes"> <tickerSymbol>SUNW</tickerSymbol> </m:GetLastTradePrice> </SOAP-ENV:Body> 46
  47. 47. WSDL 47
  48. 48. What is WSDL? • XML language for describing web services • Web service is described as – A set of communication endpoints (ports) • Endpoint is made of two parts – Abstract definitions of operations and messages – Concrete binding to networking protocol (and corresponding endpoint address) and message format • Why this separation? – Enhance reusability (as we will see in UDDI reference to WSDL document) 48
  49. 49. Why WSDL? • Enables automation of communication details between communicating partners – Machines can read WSDL – Machines can invoke a service defined in WSDL • Discoverable through registry • Arbitration – 3rd party can verify if communication conforms to WSDL 49
  50. 50. WSDL Document Example  Simple service providing stock quotes  A single operation called GetLastTradePrice  Deployed using SOAP 1.1 over HTTP  Request takes a ticker symbol of type string  Response returns price as a float 50
  51. 51. WSDL Elements  Types  Message  Operation  Port Type  Binding  Port  Service 51
  52. 52. WSDL Elements (cont.)  Types − Data type definitions − Used to describe exchanged messages − Uses W3C XML Schema as canonical type system 52
  53. 53. WSDL Example: Types <definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/”> <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name=”tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> 53
  54. 54. WSDL Elements  Messages − Abstract, typed definitions of data being exchanged  Operations − Abstract description of an action − Refers to an input and/or output messages  Port type − Collection of operations − Abstract definition of a service 54
  55. 55. Example: Messages, Operation, Port type <message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> <!-- More operations --> </portType> 55
  56. 56. WSDL Elements  Binding − Concrete protocol and data format for a particular Port type − Protocol example: SOAP 1.1 over HTTP or SOAP 1.1 over SMTP  Port − Defines a single communication endpoint − Endpoint address for binding − URL for HTTP, email address for SMTP  Service − Aggregate set of related ports 56
  57. 57. Example: Binding, Port, Service <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service> 57
  58. 58. UDDI 58
  59. 59. UDDI (Universal Description, Discovery and Integration)  “White pages” – address, contact, and known identifiers  “Yellow pages” – industrial categorizations  Industry: NAICS (Industry codes - US Govt.)  Product/Services: UN/SPSC (ECMA)  Location: Geographical taxonomy  “Green pages” – technical information about services 59
  60. 60. Additional WS Specifications • WS-Security: Address transport of security context • WS-Coordination: Framework for achieving coordination between partners • WS Transaction Specifications: Standard for creating distributed transaction involving multiple Web Services – WS-AtomicTransaction – WS-BusinessActivity • WS-Realiable Messaging: Standards for reliable delivery of messages between partners 60
  61. 61. Additional WS Specifications (cont.) • WS-Addressing: Defines end point communication • WS-Inspection: Specification uses for dynamic discovery of service documents • WS Policy: Specifics the policy of a web service provider • WS-Eventing: Defines event sources and consumers in the event model. 61
  62. 62. Web Services and Standards 62
  63. 63. RESTful Web Services • REST => REpresentational State Transfer • Resources (nouns) ->Identified by a URI, For example: • http://www.parts-depot.com/parts • Methods (verbs) to manipulate the nouns – Create, Read, Update, Delete • Representation is how you view the State – data and state transferred between client and server – XML, JSON... • Use verbs to exchange application state and representation 63
  64. 64. Characteristics of REST • RESTful services are stateless – Each request from client to server must contain all the information necessary to understand the request • RESTful services have a uniform interface – GET, POST, PUT, and DELETE. • REST-based architectures are built from resources (pieces of information) that are uniquely identified by URIs – In a RESTful purchasing system, each purchase order has a unique URI
  65. 65. REST vs “Traditional” Web Services • “Traditional” web service – Few URIs (nouns), many custom methods (verbs) • musicPort.getRecordings(“beatles”) – Uses HTTP as transport for SOAP messages • RESTful web service – Many resources (nouns), few fixed methods(verbs) • GET /music/artists/beatles/recordings – HTTP is the protocol
  66. 66. SOAP Service and REST Resource • SOAP based web services is about services SOA – Stock quote service quoteService.purchas e(“sunw”, 2000, 6.0f); • Resource-Oriented Architecture (ROA) – Stock quote resource – Resources are manipulated by exchanging representations – Eg. purchasing stock • Manipulate my portfolio resource • Handle a POST in a stock resource that I own • POST /mystocks/sunw From http://www.prescod.net/rest/mistakes/
  67. 67. Web Services : Demo 67
  68. 68. Public Web Services • Web Service X (http://www.webservicex.net) • StrikeIron.com • Xmethods.com • FedEx.com • Amazon Web Service • Google 68
  69. 69. soapUI • Open source tool for web service testing • Iinspecting, invoking, monitoring, simulating/mocking and functional/load /compliance/surveillance testing • REST/WADL and SOAP/WSDL-based Web Services over HTTP. • www.soupui.org 69
  70. 70. soapUI 70
  71. 71. Resources  Some contents are borrowed from the presentation slides of Sang Shin, Java™ Technology Evangelist, Sun Microsystems, Inc.  Business Process Execution Language for Web Services, Matjaz B. Juric  Java SOA Cookbook, Eben Hewitt  SOA in Practice, Nicolai M. Josuttis 71
  72. 72. Thank you thanachart.numnonda@sun.com twitter.com/thanachart www.facebook.com/thanachart 72

×