Basic Web Services Technology

Transcription

1 Web Services Basic Web Services Technology Copyright 2010 Srdjan Komazec 1

2 Where are we? # Title 1 Distributed Information Systems 2 Middleware 3 Web Technologies 4 Web Services 5 Basic Web Service Technologies 6 Web 2.0 Services 7 Web Service Security 2

3 Outline Motivation Technical solution A Minimalist Infrastructure for Web Services Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) Universal Description Discovery and Integration (UDDI) brief overview Related Standards Possible extensions Summary Resources 3

4 Motivation 4

5 Motivation Web Services architectures today are based on three components: service requester, service provider, and service registry. They are following closely basic client/server model with an explicit name and directory service. Infrastructure supporting this model needs to enable: a way to communicate (SOAP), a way to describe services (WSDL), and a name and directory service (UDDI). Specifications covering other aspects are typically designed on top of SOAP, WSDL, UDDI. This approach closely follows the way conventional middleware platforms are built with interaction protocols, IDLs, and name and directory services. 5

6 Technical Solution A Minimalist Infrastructure for Web Services 6

7 A Minimalist Infrastructure for Web Services Which problems are under consideration when trying to invoke a service across the Internet? Common syntax for all specifications is needed. In the Web Services domain it is XML. A mechanism to allow remote sites to interact with each other is needed. Common data format for the messages being exchanged. Convention for supporting specific forms of interaction (e.g., messaging or RPC). A set of bindings to map messages into a transport protocol (plain TCP/IP, HTTP, SMTP). Mechanism must be general enough to support all protocols. Loosely coupling of applications is a must messages are the basic unit of communication. RPC-style interactions should also be supported because of the legacy applications. Simple Object Access Protocol (SOAP) is the solution. A way to describe services in a standardized manner is needed. The role of IDL is played by Web Services Description Language (WSDL). Used to generate and compile stubs and intermediate layers, thus hiding Web services behind some interfaces A standard way to publish and locate services is needed. Registry standardized through Universal Description, Discovery and Integration (UDDI). 7

8 A Minimalist Infrastructure for Web Services 8

9 Technical Solution Simple Object Access Protocol (SOAP) 9

10 SOAP Overview Simple Object Access Protocol Version 1.0 (1999) - Entirely based on HTTP. Version 1.1 (2000) Lifted to be more generic so to support various transport protocols Version 1.2 (2003) Adds additional semantics in term of protocol bindings and XML encoding. Current version: W3C SOAP targets the following goals Message structure How information can be packaged in XML? Which conventions to use when implementing RPC interaction pattern over SOAP messages? Processing model Which are the rules that any entity processing SOAP must follow? Which XML elements should be read and understood, and actions taken in case of misunderstanding? Protocol bindings How SOAP messages are transported on top of HTTP or SMTP? 10

11 SOAP Overview SOAP is in nature stateless and one-way. SOAP is not bound to any particular underlying protocol. SOAP ignores the semantics of the messages being exchanged. More complex interactions between the two sites have to be encoded within SOAP message Communication patterns have to implemented by the underlying systems. What is needed to support RPC over SOAP? For describing document types SOAP 1.2 uses XML Schema Schema definition language for defining the structure of XML documents. 11

12 SOAP Message structure XML Envelope Contains whatever information needs to be sent. Contains a header and a body part. Header Optional part. Can have multiple sub-parts header blocks. Contains metadata, processing instructions. May be marked as mandatory. Possibly targeted at intermediaries (processing and routing message on the way to receiver). Body Mandatory part. Can have multiple sub-parts body blocks. Contains application payload. May also contain faults. 12

13 SOAP Message structure No further structure is required within the content placed in header and body. But there are some common ways to construct header and body Two aspects influence the construction Interaction style Document style two parties are agreeing upon the structure of exchanged documents. SOAP is used just for transportation purposes. RPC style SOAP messages are encapsulating request/response where the body of the request message contains the actual call (procedure name, input parameters) while the body of the response message contains results and output parameters. The parties need to agree upon RPC method signature. Encoding rules How a particular entity or data structure is represented in XML. SOAP 1.2 defined SOAP encoding defines XML serialization mechanisms. Literal encoding applications are agreeing upon an XML Schema representation of a data structure as the serialization format for the data structure. 13

14 SOAP Message structure 14

15 SOAP Message structure 15

16 SOAP Message Example <soap:envelope namespaces > <soap:header> <wsa:messageid> unique ID </wsa:messageid> <wsa:replyto> endpoint </wsa:replyto> </soap:header> <soap:body> <bank:balancerequest> data </bank:balancerequest> </soap:body> </soap:envelope> 16

17 SOAP Message Envelope Body Header 17

18 SOAP Processing Model Processing a message Different nodes along the message path can be dedicated to message processing. Nodes can play one of more roles: none, next, ultimatereceiver. Header blocks have the associated node role. Nodes can remove headers, perform some actions, extend the header, adding headers, etc. 1. Selecting headers targeted at me The current intermediary or ultimate receiver. 2. Checking for understanding Do I understand all that is targeted at me and marked as mandatory? 3. Processing everything in some order 18

19 SOAP Mandatory Headers mustunderstand="true" The recipient must understand (i.e. process) the header. Implies agreement to act in accordance to the spec. Non-mandatory headers can be ignored. In case of failure further processing stops and fault is generated. This mechanism enables gracious evolution If a new feature can be ignored, its introduction won't harm older nodes If a new feature must be understood, its introduction will be discovered early by older nodes, without unexpected behavior 19

20 SOAP Protocol Bindings Transporting the message over a network Specification of a particular protocol is called binding. How a message is wrapped within a transport protocol. Addressing What an endpoint address looks like? Where to send the message? Serialization How to put the XML message in on-the-wire bits and bytes? Connection How to send the bits to the endpoint? 20

21 SOAP HTTP Binding Addressing: URIs Serialization: HTTP message body Media type application/soap+xml Connection: TCP Possibly Web-friendly SOAP 1.1 only used HTTP POST 21

22 SOAP HTTP Binding 22

23 Technical Solution Web Services Description Language (WSDL) 23

24 WSDL Overview Web Service Description Language Interface Definition Language (IDL) for Web Services. Current version: W3C Version 1.1 still in widespread use. As opposed to conventional middleware IDLs, WSDL needs to address also Explicit definition of access protocols. Definition of service location (centralized platform doesn t exist). Asynchronous interactions (different interaction paradigms must be supported). WSDL specification is modular Interface (former Port Type) reusable, abstract Operations with Message Exchange Patterns (MEPs). Binding reusable, concrete Service implements an interface Endpoints use bindings 24

25 WSDL Component Structure service service 25

26 WSDL Component Structure service service endpoint 26

27 WSDL Component Structure interface interface service service endpoint 27

28 WSDL Component Structure interface interface operation operation fault fault service service endpoint 28

29 WSDL Component Structure interface interface operation operation fault fault interface binding service service endpoint 29

30 WSDL Component Structure interface interface operation operation service service endpoint fault fault interface binding operation operation fault fault 30

31 WSDL Component Structure interface operation operation fault fault 31

32 WSDL Component Structure interface operation operation message msg msg ref ref ref fault msg ref msg ref ref fault fault 32

33 WSDL Component Structure interface operation operation message msg msg ref ref ref types fault msg ref msg ref ref fault fault 33

34 WSDL Component Structure interface operation operation message msg msg ref ref ref fault msg ref msg ref ref types element operation declaration type definition fault fault fault 34

35 WSDL Component Structure interface operation operation message msg msg ref ref ref fault msg ref msg ref ref types element operation declaration type definition fault fault fault 35

36 WSDL Interface Design of application interface Possibly extending other interfaces Operations Message exchange pattern (MEP) Input/output messages, faults Referencing XML elements defined in types Faults Used and reused by operations 36

37 WSDL Interface Example <interface name= Banking > <operation name= transfer pattern= > <input element= Transfer /> <output element= Balance /> <outfault ref= InvalidBankAccount /> <outfault ref= InsufficientFunds /> </operation> <operation name= balance safe= true pattern= > <input element= BalanceRequest /> <output element= Balance /> <outfault ref= InvalidBankAccount /> </operation> <fault name= InvalidBankAccount element= InvalidAccountInfo /> <fault name= InsufficientFunds element= InsufficentFundsInfo /> </interface> 37

38 WSDL Predefined MEPs Invocation: Messaging: core In-only In-out Out-only Out-in Robust in-only In-optional-out Robust out-only Out-optional-in additional, not formal standard 38

39 WSDL Predefined MEPs Invocation MEPs In-only: a single input message No faults In-out: a single input message, a single output message A fault may replace output message Out-only and Out-in mirror images of the above Messaging MEPs Robust in-only: a single input message May trigger a fault In-optional-out: a single input message, possibly an output message Either message may trigger a fault Robust out-only, Out-optional-in mirrored 39

40 WSDL Bindings Networking details necessary for accessing the service Message encoding and protocol binding for all operations and messages in the interface, encoding rules that should be used in serializing the parts of a message in XML. It follows the interface structure. SOAP and HTTP bindings provided SOAP binding: XML message in SOAP envelope. Transport using a SOAP protocol binding (HTTP) HTTP binding: Web-friendly. XML message in payload, or as parameters in the URI. 40

41 WSDL Service A logical node of the application One interface Multiple alternate endpoints Endpoints may have different bindings E.g. SOAP over HTTP for a public endpoint, and SOAP over JMS for the intranet 41

42 WSDL Service Example <service <endpoint <endpoint </service> name= HypoTirol interface= Banking > name= visible binding= HTTP address= /> name= tls binding= SecureHTTP address= /> 42

43 WSDL Overall Example (WSDL v1.1) In WSDL 2.0 porttype is called interface. 43

44 Technical Solution Universal Description Discovery and Integration (UDDI) 44

45 UDDI Overview Current version is 3.0 (OASIS Standard, February 2005) Specifies framework to describe and discover Web services The core is in the Business Registry advanced naming and directory service. Defines data structures and APIs for publishing service descriptions and querying the registry. UDDI APIs are also specified through SOAP grounded WSDL. As of 2006 major UDDI service providers (IBM, Microsoft, SAP) have discontinued the support for their public UDDI registries. 45

46 Technical Solution Related Standards 46

47 Related Standards WS-Addressing SOAP relies on transparent bindings to indicate the receiver address. WS-Addressing defines a way to specify endpoint reference inside SOAP messages. It s a protocol-neutral mechanism. The reference consists of URI + set of properties. Properties can be various A client identifier specifying which particular client has invoked the service, A service instance object identifier meant to handle the request (e.g. session tracking). WS-Addressing relies on the header blocks. 47

48 Related Standards WS-Addressing <S:Envelope xmlns:s=" xmlns:wsa="..." xmlns:fabrikam="... "> <S:Header>... <wsa:to> <fabrikam:customerkey> </fabrikam:customerkey> <fabrikam:shoppingcart>abcdefg</fabrikam:shoppingcart>... </S:Header> <S:Body>... </S:Body> </S:Envelope> Example taken from 48

49 Related Standards WS-Policy - Overview None of the previous solutions is addressing the non-functional aspects in the context of Web Services e.g., a Web Service can be accessed only if a particular security constraint (such as secure channel communication) holds. WS-Policy is an XML-based set of specifications to advertise and specify service-related non-functional metadata Security, Quality of service, Privacy, Transactional policies WS-Policy main specifications WS-Policy Framework Provides model and syntax to describe and communicate policies WS-Policy Assertions Defines a common set of policy assertions for Web services WS-Policy Attachments General-purpose mechanisms for associating such policies with the subjects to which they apply Capability vs. Requirement policy 49

50 Related Standards WS-Policy - A Policy Policy is a collection of policy alternatives (OR) Auth tokens: Kerberos OR X509 Policy alternative is a collection of policy assertions (AND) Auth token AND secure channel Policy assertions specify Traditional policies that will ultimately manifest on the wire (authentication scheme, transport protocol selection), and Critical to proper service selection and usage (privacy policy, QoS characteristics). Two "operators" (XML tags) are used to make statements about policy combinations: wsp:exactlyone - asserts that only one child node must be satisfied. wsp:all - asserts that all child nodes must be satisfied. The intersection is a new policy that complies with both their requirements/capabilities. 50

51 Related Standards WS-Policy - An Example of the Security Policy <wsp:policy> <wsp:exactlyone> <wsse:securitytoken> <wsse:tokentype>wsse:kerberosv5tgt </wsse:tokentype> </wsse:securitytoken> <wsse:securitytoken> <wsse:tokentype>wsse:x509v3 </wsse:tokentype> </wsse:securitytoken> </wsp:exactlyone> </wsp:policy> 51

52 Related Standards Web Services Invocation Framework (WSIF) SOAP is a usual way to bind WSDL Tools are usually enabling quick generation of all necessary artifacts supporting SOAP-based messaging. Web Services Invocation Framework (WSIF) by IBM in WSDL specifications should be truly generic. Providers should be added to existing Web services infrastructure. Provider is an implementation of a WSDL binding allowing a service to be invoked. WSIF is hiding from a developer the type of binding used by a Web service. Developer should worry only about the abstract service descriptions. Web service infrastructure should take care of binding peculiarities. The port and binding to be used can be determined at deployment or configuration time by using the corresponding provider. 52

53 Possible Extensions 53

54 Possible Extensions Semantic extensions to WSDL Semantic Annotations for WSDL (SAWSDL) A set of extensions attributes for the Web Services Description Language. How semantic annotation is accomplished using references to semantic models? Introduces attributes modelreference, liftingschemamapping and loweringschemamapping W3C Recommendation since August Web Application Description Language (WADL) An attempt to provide a machine-readable description of HTTP-based web applications. The applications are typically REST Web Services. W3C Member Submission since August Unified Service Description Language (USDL) Describing business and technical services. Not exclusively designed for targeting automated services only. More information can be found at 54

55 Summary 55

56 Summary This lecture provides an insight into the fundamental Web services specifications and protocols Simple Object Access Protocol (SOAP) Defined message structure, processing model, and protocol bindings. SOAP Envelope = SOAP Header + SOAP Body. Two interaction styles: document and RPC. Web Services Description Language (WSDL) Represents Interface Definition Language for Web Services. Enables two levels of abstraction abstract and concrete descriptions. Service = Interface ( = Messages + Data Types) + Bindings. Message Exchange Patterns Related Standards WS-Addressing A way to specify endpoint reference inside SOAP messages WS-Policy An XML-based set of specifications to advertise and specify service-related non-functional metadata. WS Invocation Framework (WSIF) A way to shield developers from the peculiarities of a specific binding type. 56

57 References 57

58 References Mandatory reading Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Web Services - Concepts, Architectures and Applications. Springer-Verlag, th Chapter Wiki and Web reference SOAP WSDL UDDI W3C XML Schema RPC MEP WS-Addressing WS-Policy WSIF SAWSDL WADL 58

59 Next Lecture # Title 1 Distributed Information Systems 2 Middleware 3 Web Technologies 4 Web Services 5 Basic Web Service Technologies 6 Web 2.0 Services 7 Web Service Security 59

60 Questions? 60