marco piccioni what s a web service
play

Marco Piccioni Whats a web service? A software system designed to - PowerPoint PPT Presentation

Chair of Software Engineering Languages in Depth Series: Java Programming Prof. Dr. Bertrand Meyer Web Services Marco Piccioni Whats a web service? A software system designed to support interoperable machine to machine interaction over


  1. Chair of Software Engineering Languages in Depth Series: Java Programming Prof. Dr. Bertrand Meyer Web Services Marco Piccioni

  2. What’s a web service?  “A software system designed to support interoperable machine to machine interaction over a network” (W3C)  A self-contained, self-describing client-server system that enforces communication via XML messages  A web API accessible over a network, and executed on a remote system hosting the requested service Languages in Depth series: Java Programming 2

  3. The Web services protocol stack A collection of protocols that are used to define, locate, implement, and make web services interact with each other Description protocol layer: WSDL  Discovery protocol layer: UDDI  XML messaging protocol layer: SOAP, …  Transport protocol layer: HTTP(S), SMTP, FTP, RSS,  XMPP Languages in Depth series: Java Programming 3

  4. A high- level view 1 2 Endpoint Endpoint 3 Picture from http://en.wikipedia.org/wiki/Web_services Languages in Depth series: Java Programming 4

  5. The WSDL protocol Web Services Description Language XML-based, platform independent  2.0 is endorsed by W3C  Describes A web service public interface  Protocol bindings details  Configuration  Used For generating client and server code  By Microsoft for .NET  Languages in Depth series: Java Programming 5

  6. The WSDL protocol (2) Web services are described as collections of network endpoints, or ports A port type is defined: As an abstract collection of supported operations  By associating a network address with a reusable binding  Languages in Depth series: Java Programming 6

  7. The WSDL protocol (3) A reusable binding is a concrete protocol and data format  specification for a specific port type Through the binding, operations and messages are bound  to a concrete network protocol and message format A message is an abstract description of the exchanged  data Ports and messages abstract definition is separated from  their implementation, allowing reuse Languages in Depth series: Java Programming 7

  8. The UDDI protocol Universal Description, Discovery and Integration XML-based, platform independent  A registry for businesses to list themselves on the www Each business publishes a list of services  Each UDDI business registration consists of: White pages: address, contact and known identifiers  Yellow pages: industrial categorizations  Green pages: technical info about exposed services  Languages in Depth series: Java Programming 8

  9. The UDDI protocol (2) Written in Y2K, enforces a vision in which consumers link  to providers through a public brokerage system By the end of 2005, 70% of Fortune 500 companies were  planning to use it In January 2006, IBM, Microsoft and SAP announced they  were closing their public UDDI nodes Languages in Depth series: Java Programming 9

  10. The UDDI protocol (3) “ The idea was that companies could publish how they wanted to interact, and other companies could find that information and use it to establish a relationship. Needless to say, this isn't how companies do business. There's always a human element to establishing a relationship.” Jason Bloomberg, senior analyst at ZapThink Languages in Depth series: Java Programming 10

  11. The UDDI protocol (3) Anyway, according to Microsoft and IBM The interoperability and robustness of the UDDI was  proven What now? Mostly used from within-the firewall (intranet)  Used as metadata management standard for SOA (more  on this later) Languages in Depth series: Java Programming 11

  12. The SOAP protocol Service Oriented Architecture Protocol (former Simple Object Access Protocol) Simple and extensible XML-based communication  protocol Platform and language independent  Basic message-wrapping framework  Has bindings to underlying protocols like HTTP, HTTPS,  SMTP, FTP, RSS, XMPP Languages in Depth series: Java Programming 12

  13. Remote Procedure Call The most used SOAP messaging pattern  Enables remote calls to be treated as local calls from the  programmer In object-oriented terms: Remote Method Invocation  Microsoft DCOM, .NET remoting, OMG‘s CORBA and  Java RMI API all use RPC Languages in Depth series: Java Programming 13

  14. Remote Procedure Call (2) Implements the classical client-server model of distributed  computing An RPC is initiated by a client (network node) sending a  request to a server (another network node) The server immediately responds, while the client is  blocked Remote calls can fail due to unpredictable network issues  Languages in Depth series: Java Programming 14

  15. Java RPC-style implementation  JAX-RPC (Java API for XML-based Remote Procedure Calls) provides a standard way for accessing and exposing RPC-style SOAP web services  JAX-RPC 2.0 has been renamed to JAX-WS 2.0 (Java API for XML Web Services)  Apache Axis, fully JAX-RPC compliant, is the most popular JAX-RPC flavor Languages in Depth series: Java Programming 15

  16. High-level view of Java JAX  A Java program invokes a method on a stub (local object representing the remote service)  The stub invokes routines in the JAX-WS Runtime  JAX-WS converts the RMI into a SOAP message  JAX-WS transmits the message as an HTTP request  Therefore the web service can be implemented on the server side as a servlet or EJB container Languages in Depth series: Java Programming 16

  17. A general framework: SOA Service Oriented Architecture  A message is the basic unit of communication  Focus is on WSDL contract, specifying  Header (name, version, owner, responsible, type…)  Functional (functionality accomplished, service operations, invocation details)  Non-functional (security constraints, allowed failure rate, transactional, service level agreement, semantics) Languages in Depth series: Java Programming 17

  18. One more style of use: RESTful REpresentational State Transfer is a collection of network architecture principles  Application state and functionality are divided into resources  Every resource is uniquely addressable using a universal syntax for use in hypermedia links  All resources share a uniform interface for the transfer of state between client and resource  A constrained set of well-defined operations  A constrained set of content types  A client-server, stateless, cacheable and layered protocol  Does non use SOAP Languages in Depth series: Java Programming 18

  19. Quiz What could be an example of RESTful design? Languages in Depth series: Java Programming 19

  20. Quiz solution What could be an example of RESTful design? Yes, the World Wide Web, using URIs, MIME types, HTTP, HTML, DNS, … Languages in Depth series: Java Programming 20

  21. RESTful vs. RPC  RESTful resources  Commands are defined in simple terms of resources to be retrieved, stored, get, set  Difficult to do many joins  RPC commands  Commands are defined in methods with varying complexity depending on “standard”  RESTful nouns exchange resources and concepts  RPC verbs exchange methods Languages in Depth series: Java Programming 21

  22. Spring Web Services support Spring Web Services is a separate Spring subproject  1.5.1 released on 04/05/2008  Document-driven, contract-first development  Loose coupling between contract and implementation  Standard JAXP API support (DOM, SAX,…)  Mappings from incoming XML requests to any object  Flexible XML marshalling (using JAXB, Castor, …)  Support for security (sign, encrypt, decrypt and authenticate against SOAP messages) Languages in Depth series: Java Programming 22

  23. Contract-first and contract-last WS  Contract-First approach  Write contract (WSDL) first, and use the language (Java) to implement that contract  Contract-Last approach  Write (Java) code first (interfaces), and let the Web Service contract (WSDL) be generated from that Languages in Depth series: Java Programming 23

  24. Issues with contract-last development  Object/XML impedance mismatch  Fragility  Performance  Reusability  Versioning Languages in Depth series: Java Programming 24

  25. Object-XML impedance mismatch XML (and XSD) are hierarchical, OO languages are modeled by graphs XSD extensions are not like inheritance  A XSD restriction that uses a regular expression is lost Unportable types  e.g. java.util.TreeMap, time and dates Cyclic graphs  A refers to B that refers to A Languages in Depth series: Java Programming 25

  26. Fragility and performance  Not all SOAP stacks generate the same web service contract from a Java contract  By automatically transforming Java into XML, there is no guarantee on what is sent over the wire (dependencies can be very deep and unwanted)  Using contract-first you can choose what information has to be sent Languages in Depth series: Java Programming 26

  27. Reusability and versioning  Defining your schema in a separate file you can reuse it in different scenarios  Starting from Java, when a contract evolves you have no choice but to assign a different name to your interface. The old contract must be kept around for clients that need the older version  Starting from contracts, you can implement the old and the new version of the contract in one class using XSLT for conversions Languages in Depth series: Java Programming 27

Recommend


More recommend