Basic Web Services Technology - STI Innsbruck · – a way to communicate (SOAP), – a way to...

1© Copyright 2010 Srdjan Komazec

Web Services

Basic Web Services Technology

2

Where are we?

# Title1 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

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

4

Motivation

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.

6

Technical SolutionA Minimalist Infrastructure for Web Services

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).

8

A Minimalist Infrastructure for Web Services

9

Technical SolutionSimple Object Access Protocol (SOAP)

10

SOAPOverview

• 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: 1.2 @ 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?

11

• 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.

SOAPOverview

12

SOAPMessage 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.

13

• 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.


14


15


16

SOAPMessage 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>

17

SOAPMessage Envelope

Body

Header

18

SOAPProcessing 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

19

SOAPMandatory 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

20

SOAPProtocol 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?

21

SOAPHTTP Binding

• Addressing: URIs• Serialization: HTTP message body

– Media type application/soap+xml

• Connection: TCP• Possibly Web-friendly

– SOAP 1.1 only used HTTP POST

22

SOAPHTTP Binding

23

Technical SolutionWeb Services Description Language (WSDL)

24

WSDLOverview

• Web Service Description Language– Interface Definition Language (IDL) for Web Services.

• Current version: 2.0 @ 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

25

WSDLComponent Structure

serviceserviceservice

26



endpointendpoint

27



endpointendpoint

interfaceinterfaceinterface

28



endpointendpoint


faultfault

operationoperationoperation

fault

29



endpointendpoint


faultfault


faultinterfaceinterfacebinding

30



endpointendpoint


faultfault


faultinterfaceinterfacebinding

faultfault


fault

31


interface

faultfault


fault

32


interface

faultfault


fault

msg refmsg refmessage ref

msg refmsg reffault ref

33


interface

faultfault


fault



types

34


interface

faultfault


fault



types

faultfault

operationoperationelement declaration

type definition

35


interface

faultfault


fault



types

faultfault

operationoperationelement declaration

type definition

36

WSDLInterface

• 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

37

WSDLInterface Example

<interface name=“Banking”><operation name=“transfer”

pattern=“http://www.w3.org/2004/08/wsdl/in-out”><input element=“Transfer”/><output element=“Balance”/><outfault ref=“InvalidBankAccount”/><outfault ref=“InsufficientFunds”/>

</operation><operation name=“balance” safe=“true”

pattern=“http://www.w3.org/2004/08/wsdl/in-out”><input element=“BalanceRequest”/><output element=“Balance”/><outfault ref=“InvalidBankAccount”/>

</operation><fault name=“InvalidBankAccount”

element=“InvalidAccountInfo” /><fault name=“InsufficientFunds”

element=“InsufficentFundsInfo” /></interface>

38

WSDLPredefined MEPs

Invocation:

In-onlyIn-out

Out-onlyOut-in

Messaging:

Robust in-only

In-optional-outRobust out-onlyOut-optional-in

core

additional, not formal standard

39

WSDLPredefined 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

40

WSDLBindings

• 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.

41

WSDLService

• 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

42

WSDLService Example

<service name=“HypoTirol” interface=“Banking”>

<endpoint name=“visible”binding=“HTTP”address=“http://ht.at/bankingSvc” />

<endpoint name=“tls”binding=“SecureHTTP”address=“https://ht.at/bankingSvc” />

</service>

43

WSDLOverall Example (WSDL v1.1)

In WSDL 2.0 portType is called

interface.

44

Technical SolutionUniversal Description Discovery and Integration (UDDI)

45

UDDIOverview

• 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.

46

Technical SolutionRelated Standards

47

Related StandardsWS-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.

48

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="..." xmlns:fabrikam="... ">

<S:Header>...<wsa:To>http://www.fabrikam123.example/acct</wsa:To> <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey> <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>...

</S:Header><S:Body>

...</S:Body>

</S:Envelope>

Related StandardsWS-Addressing

Example taken from http://www.w3.org/Submission/ws-addressing

49

Related StandardsWS-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

50

Related StandardsWS-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.

51

Related StandardsWS-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>

52

Related StandardsWeb 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 2001.– 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.

53

Possible Extensions

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 2007.

• 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 2009.– http://www.w3.org/Submission/wadl/

• Unified Service Description Language (USDL)– Describing business and technical services.– Not exclusively designed for targeting automated services only.– More information can be found at http://www.internet-of-services.com/index.php?id=24

55

Summary

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.

57

References

58

References

• Mandatory reading– Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Web Services -

Concepts, Architectures and Applications. Springer-Verlag, 2004. 6th Chapter

• Wiki and Web reference– SOAP http://en.wikipedia.org/wiki/SOAP– WSDL http://en.wikipedia.org/wiki/Web_Services_Description_Language– UDDI http://en.wikipedia.org/wiki/UDDI– W3C http://en.wikipedia.org/wiki/W3C– XML Schema http://en.wikipedia.org/wiki/XML_Schema_(W3C)– RPC http://en.wikipedia.org/wiki/Remote_procedure_call– MEP http://en.wikipedia.org/wiki/Message_Exchange_Pattern– WS-Addressing http://en.wikipedia.org/wiki/WS-Addressing– WS-Policy http://en.wikipedia.org/wiki/WS-Policy– WSIF http://ws.apache.org/wsif– SAWSDL http://www.w3.org/2002/ws/sawsdl– WADL http://en.wikipedia.org/wiki/Web_Application_Description_Language

59

Next Lecture

# Title1 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

60

Questions?

Basic Web Services Technology - STI Innsbruck · – a way to communicate (SOAP), – a way to...

Documents

Transcript of Basic Web Services Technology - STI Innsbruck · – a way to communicate (SOAP), – a way to...