www.sti-innsbruck.at © copyright 2009 sti innsbruck 1 web services technologies jacek kopecký

www.sti-innsbruck.at

1

www.sti-innsbruck.at © Copyright 2009 STI INNSBRUCK www.sti-innsbruck.at

Web Services Technologies

Jacek Kopecký

sti-innsbruck.at 2

Overview

• Introduction to Web Service technologies• SOAP• WSDL• Further selected specfications

sti-innsbruck.at 3

About Me

• If I seem dry, now you'll know why

• Worked at Web Services Platform company• Got involved in W3C

– SOAP 1.2– WSDL 2.0

• Moved to STI Innsbruck– Working on connecting the lower layers to semantics

sti-innsbruck.at 4

SOA Recap (in my words)

• Service-oriented architecture– For large-scale distributed computing

• Coarse-grained service interfaces• Evolvability, manageability• Interoperability within and among

enterprises– Inspired by the goals of CORBA and such

sti-innsbruck.at 5

Web Services: Main Points

• Technology for SOA• Client-server messaging approach

– With predefined Message exchange patterns– Independent of network protocols

• Application-specific interfaces– Similar to Remote Procedure Calls – RPC– Contrasted to REST and the Web

• Most data in XML– Descriptions in XML Schema

sti-innsbruck.at 6

RPC vs. Web Services

• RPC aims to hide the network– Distributed system looks like a local system– Some calls happen to go over the network

• But network is important– Latency, bandwidth– Reliability – connection, nodes

• RPC is harmful• Web Services keep the network in mind

sti-innsbruck.at 7

Web Services Basics

registry

client service(provider)

publish descriptions

discoverservices

invoke

sti-innsbruck.at 8

Web Services Basics

• SOAP– An XML messaging protocol

• WSDL + XML Schema– An XML interface definition language

• UDDI– A business-oriented service registry

sti-innsbruck.at 9

More WS Specifications

• Modular approach to adding features:– Attachments– Addressing, Policy– … many others

• W3C, OASIS, WS-I• Plus ad-hoc industry alliances

sti-innsbruck.at 10

SOAP

sti-innsbruck.at 11

SOAP in Detail: Overview

• née Simple Object Access Protocol– In fact, simple messaging protocol

• Current version: 1.2 @ W3C

• Message structure• Processing model• Protocol bindings

sti-innsbruck.at 12

SOAP Messages

• XML Envelope • Body

– Application payload– Faults

• Headers– Metadata, processing instructions– Possibly mandatory (mustUnderstand)– Possibly targeted at intermediaries

sti-innsbruck.at 13

SOAP Message Example

<soap:Envelope> <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>

sti-innsbruck.at 14

Body

SOAP Message Envelope

Header

sti-innsbruck.at 15

SOAP Processing Model

• Processing a message

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

3. Processing everything in some order

sti-innsbruck.at 16

SOAP MustUnderstand

• Mandatory headers– The receiver must understand them– Implies agreement to act in accordance

• Non-mandatory headers can be ignored

• 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

sti-innsbruck.at 17

SOAP Protocol Bindings

• Transporting the message over a network• Addressing

– What an endpoint address looks like

• Serialization– How to put the XML message in on-the-wire

bits and bytes

• Connection– How to send the bits to the endpoint

sti-innsbruck.at 18

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

sti-innsbruck.at 19

SOAP MEPs

• Message Exchange Patterns

• Request-Response– Input message followed by output or fault

• SOAP-Response– Request without SOAP (e.g. HTTP GET)– SOAP output or fault

sti-innsbruck.at 20

SOAP Summary

• Still pretty simple even if the name doesn’t say so any more

• Extremely extensible• HTTP binding for easy communication

• The value of SOAP:XML and Processing Model

sti-innsbruck.at 21

Attachments

• XML is nice, but… not binary• XOP: XML-binary Optimized Packaging

– Binary data in XML logically in the tree– On serialization, it is outside, raw, efficient

• MIME multipart message

• MTOM: XOP for SOAP– Message Transfer Optimization Mechanism– Extends SOAP HTTP binding

sti-innsbruck.at 22

WS-Addressing

• Simple routing protocol• Endpoint References for addressing

– With parameters or metadata

• Message headers for routing & correlation

sti-innsbruck.at 23

WSA Msg Info Headers

• To – let the middleware deliver the message• From, ReplyTo, FaultTo – channels back• MessageID, RelatesTo – simple correlation• Action – semantics implied by the message

<S:Header><wsa:MessageID> unique ID </wsa:MessageID>

<wsa:ReplyTo> endpoint </wsa:ReplyTo> <wsa:To> address </wsa:To> <wsa:Action> URI </wsa:Action></S:Header>

sti-innsbruck.at 24

Web Service Description LanguageWSDL

sti-innsbruck.at 25

WSDL in Detail: Overview

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

• Current version: 2.0 @ W3C– Version 1.1 still in widespread use

• Interface – reusable, abstract– Operations with MEPs

• Binding – reusable, concrete• Service implements an interface

– Endpoints use bindings

sti-innsbruck.at 26

serviceservice

WSDL Component Structure

service

sti-innsbruck.at 27

serviceservice


service

endpointendpoint

sti-innsbruck.at 28

serviceservice


service

endpointendpoint

interfaceinterfaceinterface

sti-innsbruck.at 29

serviceservice


service

endpointendpoint


faultfault

operationoperationoperation

fault

sti-innsbruck.at 30

serviceservice


service

endpointendpoint


faultfault


fault

interfaceinterfacebinding

sti-innsbruck.at 31

serviceservice


service

endpointendpoint


faultfault


fault

interfaceinterfacebinding

faultfault


fault

sti-innsbruck.at 32


interface

faultfault


fault

sti-innsbruck.at 33


interface

faultfault


fault

msg refmsg refmessage ref

msg refmsg reffault ref

sti-innsbruck.at 34


interface

faultfault


fault



types

sti-innsbruck.at 35


interface

faultfault


fault



types

faultfault

operationoperationelement declaration

type definition

sti-innsbruck.at 36


interface

faultfault


fault



types

faultfault

operationoperationelement declaration

type definition

sti-innsbruck.at 37

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

sti-innsbruck.at 38

WSDL Interface 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>

sti-innsbruck.at 39

WSDL Predefined MEPs

Invocation:

In-onlyIn-out

Out-onlyOut-in

Messaging:

Robust in-only

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

core

additional, not formal standard

sti-innsbruck.at 40

WSDL 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

sti-innsbruck.at 41

WSDL 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

sti-innsbruck.at 42

WSDL Binding

• Networking details necessary for accessing the service

• Copies interface structure• SOAP and HTTP bindings provided

sti-innsbruck.at 43

WSDL Bindings

• 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

sti-innsbruck.at 44

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

sti-innsbruck.at 45

WSDL Service 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>

sti-innsbruck.at 46

WSDL Summary

• Concrete service• Abstract and reusable Interface• Network binding

• WSDL does not imply implementation– CORBA IDL requires objects

• Exchange of XML business documents• Extensible in many ways

sti-innsbruck.at 47

And More…

sti-innsbruck.at 48

UDDI

• Universal Description, Discovery and Integration

• A Web service registry API specification– Business-oriented service publication,

discovery (initially limited search capabilities)– Itself has Web service interface– Useful for intranet registries

• A failed public service

sti-innsbruck.at 49

UDDI Structure

• Business entity– Organization information, contact

• Business Service– A group of related services

• Binding Template– Information on how to access the service

• tModel (technical model)– Any kind of specification, e.g. WSDL– Also for classification, categorization

sti-innsbruck.at 50

WS Policy

• Non-functional metadata– Security, Quality of service, Privacy,

Transactionality policies

• Policy a set of alternatives (OR)– Auth tokens: Kerberos OR X509

• Alternative a set of assertions (AND)– Auth token AND secure channel

• Assertions come from 3rd parties

sti-innsbruck.at 51

WS Policy Example

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

sti-innsbruck.at 52

The Rest of the Specs

• Security: authentication, encryption• Reliable messaging

– “Get the message there or tell me”

• Transactions: ACID, Compensating• BPEL4WS: Scripting Web Services• Interoperability: WS-I Basic Profile• … and still more

sti-innsbruck.at 53

Deploying Web Services

• Power in the tools and middleware• The developer need not deal with XML

– SOAP serialization in infrastructure– WSDL generated from code– Code generated from WSDL– Features (security, transactions) added

through configuration• Apache Axis, Microsoft .NET,

IBM WebSphere, WSO2 AppServer etc.

sti-innsbruck.at 54

Web Services Summary

• Core: protocol + IDL (SOAP + WSDL)• Many extension specifications• Messaging paradigm

– Sometimes RPC

• Biggest benefit: XML– Vendor-neutral, platform-independent– Interoperable– Easy to begin and play with– But hidden in the frameworks

• Unless you're a developer of the framework

sti-innsbruck.at 55

Hands-on with Axis2

• We'll develop a service– Travel reservation

• We'll deploy it on a server– My laptop

• We'll develop a client– And run it on your laptops

• All with Apache Axis2

sti-innsbruck.at 56

Travel Reservation Service

• getConnections(from, to, when) list of itinerariesItinerary = id + list of trains

• reserveTickets(itinerary ID , class, (&passengersNumber)

list of ticket IDs

sti-innsbruck.at 57

Building with Axis2

• Make sure to set AXIS2_HOME to where you unpacked Axis 2

www.sti-innsbruck.at © copyright 2009 sti innsbruck 1 web services technologies jacek kopecký

Documents