Download - 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
WSDL Component Structure
service
endpointendpoint
sti-innsbruck.at 28
serviceservice
WSDL Component Structure
service
endpointendpoint
interfaceinterfaceinterface
sti-innsbruck.at 29
serviceservice
WSDL Component Structure
service
endpointendpoint
interfaceinterfaceinterface
faultfault
operationoperationoperation
fault
sti-innsbruck.at 30
serviceservice
WSDL Component Structure
service
endpointendpoint
interfaceinterfaceinterface
faultfault
operationoperationoperation
fault
interfaceinterfacebinding
sti-innsbruck.at 31
serviceservice
WSDL Component Structure
service
endpointendpoint
interfaceinterfaceinterface
faultfault
operationoperationoperation
fault
interfaceinterfacebinding
faultfault
operationoperationoperation
fault
sti-innsbruck.at 32
WSDL Component Structure
interface
faultfault
operationoperationoperation
fault
sti-innsbruck.at 33
WSDL Component Structure
interface
faultfault
operationoperationoperation
fault
msg refmsg refmessage ref
msg refmsg reffault ref
sti-innsbruck.at 34
WSDL Component Structure
interface
faultfault
operationoperationoperation
fault
msg refmsg refmessage ref
msg refmsg reffault ref
types
sti-innsbruck.at 35
WSDL Component Structure
interface
faultfault
operationoperationoperation
fault
msg refmsg refmessage ref
msg refmsg reffault ref
types
faultfault
operationoperationelement declaration
type definition
sti-innsbruck.at 36
WSDL Component Structure
interface
faultfault
operationoperationoperation
fault
msg refmsg refmessage ref
msg refmsg reffault ref
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