Web Services - PowerPoint PPT Presentation

About This Presentation
Title:

Web Services

Description:

Web Services Chapter 28 Web Basics Internet Collection of physically interconnected computers. Messages decomposed into packets. Packets transmitted from source to ... – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 177
Provided by: www3CsSto8
Category:
Tags: services | servlets | web

less

Transcript and Presenter's Notes

Title: Web Services


1
Web Services
  • Chapter 28

2
Web Basics
3
Internet
  • Collection of physically interconnected
    computers.
  • Messages decomposed into packets.
  • Packets transmitted from source to destination
    using a store-and-forward technique.
  • Routing algorithm directs packets to destination

4
Connection-Oriented Protocol
  • Prior to transmission connection is established
    between source and destination. Each maintains
    state information
  • Sequence numbers, acknowledgements provide
    reliability
  • guarantee that packet loss or duplication will be
    detected
  • packets arrive in the order they were sent
  • Buffers, flow control algorithm guarantee
    transmission rate appropriate to both sender and
    receiver
  • Destination address
  • Characteristics of connection (e.g., out-of-band
    messages)
  • Transmission Control Protocol (TCP) is
    connection-oriented.
  • Problem Overhead of setting up taking down
    connection.

5
Hypertext Transfer Protocol (HTTP)
  • A high level protocol built on top of a TCP
    connection for exchanging messages (with
    arbitrary content)
  • Each (request) message from client to server is
    followed by a (response) message from server to
    client.
  • Facilitates remote invocation of methods on the
    server.
  • Web A set of client and server processes on the
    Internet that communicate via HTTP.

6
Protocol Stack
HTTP
TCP
Added features to support client interactions
(reliability flow control, ..)
Network Level Protocol
End-to-end protocol
Link Level Protocol
Protocol for tranmitting packets between
neighboring nodes
7
Clients and Servers
  • Client browser capable of displaying HTML pages.
  • Web Server stores pages for distribution to
    clients.
  • Pages identified by Uniform Resource Locator
    (URL).
  • ltprotocolgt protocol to be used to communicate
    with host.
  • Example - http, ftp
  • lthost_namegt Directory server translates this
    into the hosts internet address
  • Example www.cs.sunysb.edu becomes
    155.233.123.532
  • ltfile_namegt name of file on host.

ltprotocolgt//lthost_namegt/ltfile_namegt
8
HTTP Request Format
Start line ltmethodgt ltURLgt
ltprotocol_versiongt CrLf Followed by
ltheadergt Followed by CrLf Followed by
ltdatagt ltmethodgt GET HEAD POST PUT
. ltprotocol_versiongt HTTP/1.1 .
there can be several header lines
9
Request Methods
  • GET response body contains data identified by
    argument URL
  • HEAD response header describes data identified
    by argument URL (no response body)
  • Use has page changed since last fetched?
  • PUT request body contains page to be stored at
    argument URL

10
Request Methods
  • DELETE delete data at argument URL
  • POST request body contains a new object to be
    placed subordinate to object at argument URL
  • Use adding file to directory named by URL
  • Use information entered by user on displayed
    form
  • Others .

11
HTTP Request Format
ltheadergt ltfield_namegt ltvaluegt
CrLf ltfield_namegt From --
senders e-mail address Accept --
acceptable response formats User-Agent
-- identifies requestors program SOAPAction
-- identifies SOAP processor to
receive message (if data is a SOAP message)
If-Modified-Since -- send document only if
modified since ltvaluegt (used with
GET) Content-Type -- type of data
(application/soapxml
for SOAP) Host
-- destination host ltdatagt ASCII text
(default)
12
Simple Client / Server Interaction I
  • 1. User supplies URL (clicks on link)
  • http//yourbusiness.com/items/printers.h
    tml
  • 2. Browser translates lthost_namegt
    (yourbusiness.com)
  • to host_internet_address (using name server)
  • 3. Browser assumes a port number of 80 for http
    (if no
  • port is explicitly provided as part of
    lthost_namegt )
  • Program at port 80 interprets http headers

13
Simple Client / Server Interaction I
  • 4. Browser sets up TCP connection to
  • yourbusiness.com at
  • (host internet address, 80)
  • 5. Browser sends http message
  • GET items/printers.html HTTP/1.0
  • over connection

14
HTTP Response
Status line ltHTTP_versiongt ltstatus_codegt
ltreason_linegt CrLf Followed by lt header
gt Followed by ltdatagt
15
HTTP Response
ltstatus_codegt 3 digits Ex 2xx -- success
4xx -- bad request from client 5xx
-- server failed to fulfill valid
request ltreason_linegt explanation for human
reader ltheadergt ltfield_namegt ltvaluegt
CrLf ltfield_namegt Allowed -- methods
supported by URL Date -- creation date
for response Expires -- expiration date
for data Last-Modified -- creation date
for object Content-Length Content-Type
.
16
Simple Client/Server Interaction I
  • 6. Server sends response message with requested
    html page to browser
  • 7. Server releases TCP connection (stateless)
  • 8. Browser receives page and displays it

HTTP/1.0 200 Document follows Date
ltdategt Content-Type text/html Content-Length
integer Expires date html document
items/printers.html goes here
17
Simple Client/Server Interaction II
  • 1. Page displayed by browser is a form with tag
  • ltFORM ACTIONhttp//yourbusiness.com/servlets/pl
    aceorder
  • METHODgt
  • 2. Client fills input boxes
  • 3. If METHODGET, client sets up connection to
    yourbusiness.com and sends http request
  • Values in input boxes encoded as suffix.
    Since ACTION
  • designates a servlet, server invokes
    placeorder

GET /servlets/placeorder?name1value1name2value2
HTTP/1.0

18
Simple Client / Server Interaction II
  • 4. If METHODPOST, client sends http request
  • invoking POST to yourbusiness.com data
  • contains values in input boxes.

POST /servlets/placeorder HTTP/1.0 Content-Type
text/. Content-Length 54321 PrinterHP660
NameArtBernstein
19
HyperText Transfer Protocol (HTTP 1.1)
  • 1. Client sets up TCP connection to server named
    in URL
  • 2. Client sends a request
  • 3. Client receives a response
  • 4. If (server has not disconnected) goto 2 else
    goto 1
  • - Only actively used connections are maintained

20
SOAP
  • Version 1.2

21
What is SOAP?
  • The de facto standard for Web Service
    communication that provides support for
  • Remote procedure call (RPC) to invoke methods on
    servers
  • Messaging to exchange documents
  • Extensibility
  • Error handling
  • Flexible data encoding
  • Binding to a variety of transports (e.g., SOAP,
    SMTP)
  • We will discuss Version 1.2

22
HTTP Binding
  • A SOAP message must be carried by some transport
    protocol
  • HTTP is frequently used for this purpose
  • Message is the data part of a request invoking
    POST

POST /fareService/getFareOp HTTP/1.1 Host
www.SlowHawk.com Content-Type
application/soapxml Content-Length
xxx SOAPAction yyy lt! the SOAP message goes
here ?
23
SOAP and XML
  • Since XML is language and platform independent,
    it is the lingua franca for the exchange of
    information in a heterogeneous distributed
    system.
  • SOAP supports the transmission of arbitrary XML
    documents
  • For RPC, SOAP provides a message format for
    invoking a procedure and returning results in XML

24
SOAP Message
SOAP Envelope
SOAP Header
Header Block
optional
Header Block
SOAP Body
Message Body
required
25
SOAP Envelope
ltsEnvelope xmlnsshttp//www.w3.org/2003/05/soa
p-envelopegt ltsHeadergt lt!-- header
blocks go here --gt lt/sHeadergt ltsBodygt
lt!-- an XML document goes here --gt
lt/sBodygt lt/sEnvelopegt
http//www.w3.org/2003/05/soap-envelope
identifies a name space that defines the
structure of a SOAP message
26
Using SOAP
  • For document exchange, the XML document being
    exchanged is nested directly in SOAP envelope.
  • Referred to as document-style SOAP
  • Conversational mode of message exchange
  • For RPC, SOAP defines the format of the body of
    messages to be used for invocation and response.
  • Referred to as RPC-style SOAP
  • Uses a request-response pattern
  • Parameters are passed by value/result

27
RPC Request Message
Client invocation of procedure public Float
getQuoteOp(String symbol) generates SOAP request
message
ltsEnvelope xmlnsshttp//www.w3.org/2003/05/soa
p-envelope xmlnsxsdhttp//www.w3.org/20
01/XMLSchema xmlnsxsihttp//www.w3.org/
2001/XMLSchema-instancegt ltsBodygt ltngetQuot
eOp xmlnsnhttp//www.shearson.com/quoteService
gt ltnsymbol xsitypexsdstringgt IBM lt/n
symbolgt lt/ngetQuoteOpgt lt/sBodygt lt/sEnvelope
gt
28
RPC Response Message
ltsEnvelope xmlnsshttp//www.w3.org/2003/05/soa
p-envelope xmlnsxsdhttp//www.w3.org/20
01/XMLSchema xmlnsxsihttp//www.w3.org/
2001/XMLSchema-instancegt ltsBodygt ltngetQuo
teOpResponse xmlnsnhttp//www.shears
on.com/quoteServicegt ltnvalue
xsitypexsdfloatgt 30.45 lt/nvaluegt lt/ng
etQuoteOpResponsegt lt/sBodygt lt/sEnvelopegt
29
RPC Request/Response Messages
  • Conventions
  • Name of the request structure is same as method
    name.
  • Name of response structure is same as method name
    concatenated with Response
  • Name and order of in and in/out parameters in
    request structure same as name and order in
    signature
  • Value of method (if returned) is first child
    element of response structure out and in/out
    parameters follow, their name and order same as
    name and order in signature

30
Data Encoding
  • Problem SOAP provides a language/platform
    independent mechanism for invoking remote
    procedures
  • Argument values are carried in an XML document
  • Caller and callee may use different
    representations of the same types (e.g., Java, C)
  • A mechanism is needed for mapping from callers
    format to XML syntax and from XML syntax to
    callees format (referred to as
    serialization/deserialization)
  • Example mapping a Java array to XML syntax

31
Serialization
  • Serialization is simple for simple types
    (integer, string, float,) since they correspond
    to XML Schema types.
  • Translate from binary to ASCII using XML schema
    specified format
  • Serialization not so simple for complex types
  • Ex What tags will be used for an array? Will it
    be stored by rows or by columns? How will a
    sparse array be sent?

32
Encoding Style
  • encodingStyle attribute used to identify the
    serialization rules to encode the data contents
    of an element
  • An arbitrary set of rules can be used
  • SOAP defines its own set of rules
  • Message is referred to as RPC/encoded
  • RPC refers to the format of the message as a
    whole
  • Encoded refers to the fact that argument values
    have been represented using the rule set
    specified in the encoding style attribute

33
SOAP Encoding Style
  • SOAP defines its own graphical data model for
    describing complex types and rules for
    transforming instances of the model into
    serialized ASCII strings
  • Vendors provide serializers (and deserializers)
    which maps each local type to an instance of the
    model and then transforms the local
    representation to the encoded data using the SOAP
    rules

34
Data Encoding
ltsEnvelope xmlnsshttp//www.w3.org/2003/05/soa
p-envelope xmlnsxsdhttp//www.w3.org/20
01/XMLSchema xmlnsxsihttp//www.w3.org/
2001/XMLSchema-instancegt ltsBodygt ltngetQuot
eOp xmlnsnhttp//www.shearson.com/quoteService
sencodingStylehttp//www.w3.org/2003/05/soap
-encodinggt ltnsymbol xsitypexsdstringgt
IBM lt/nsymbolgt lt/ngetQuoteOpgt
lt/sBodygt lt/sEnvelopegt
35
SOAP Extensibility
  • A SOAP message goes from client to server to
    advance some application related cause.
  • It is often the case that some orthogonal issues
    related to the message must be handled
  • Security encryption, authentication,
    authorization
  • Transaction management
  • Tracing
  • Logging

36
Intermediaries
intermediary
intermediary
client
server
  • To support scalability and decentralization,
    these issues need not be handled by the server.
  • Intermediaries between client and server are used
  • Intermediaries perform orthogonal services as the
    message passes along a route

37
Example
purchasing server
Proxy/ gateway
client
accounting server
inventory server
Message addressed to Proxy. Contains target dept
(purchasing), client name, password, and
request body. Proxy performs authentication.
Message addressed to target dept. Contains
authenticated Id and request body. Target
department services the request.
38
Requirements
  • Information directed to each intermediary and to
    final destination kept separate
  • Intermediaries can be easily added/deleted, route
    changed
  • SOAP does not specify how routing is to be done
  • It is up to each node along the chain to know
    where to send the message next
  • Information carried in the message may direct
    routing

39
Header
  • SOAP envelope defines an optional header
    containing an arbitrary number of header blocks.
    Each block
  • Has an optional role and should be processed by
    an intermediary that can perform that role
  • Can have its own namespace declaration
  • Eliminates the possibility of interference
    between groups that independently design headers.

40
Example Message Sent by Client
POST /purchasing/retailSale HTTP/1.1
-- method invoked at final destination Host
proxy.yourcompany.com
-- initial destination intermediary
. ltsEnvelope xmlnss.gt
ltsHeadergt lttdtargetdept xmlnstd.
srolecompany-proxy.com -- identifies
intermediary smustUnderstandtruegt
-- this header better be processed purchas
ing -- identifies next
node lt/tdtargetdeptgt ltauthauthinfo.
srolecompany-proxy.com -- identifies
intermediary smustUnderstandtrue gt
-- this header better be processed ltauthn
amegt madonna lt/authnamegt ltauthpasswdgt xxxxxx
lt/authpasswdgt lt/authauthinfogt lt/Headergt
ltsBodygt lt/sBodygt lt/sEnvelopegt
41
Processing Model
  • An intermediary has an assigned set of roles
  • On receiving a message, it identifies the blocks
    whose role attribute matches an element of its
    set (or has value next)
  • A block without a role attribute is targeted for
    final destination
  • The intermediary
  • can modify/delete its block
  • can insert new blocks
  • should retarget the message to the next
    destination
  • can do anything (frowned upon)

42
Must Understand
  • An intermediary can choose to ignore a block
    directed to it
  • If mustUnderstand attribute has value true
    intermediary must process the block or else abort
    the message and return a fault message

43
Example Message Sent by Proxy
POST /purchasing/retailSale HTTP/1.1
-- method invoked at destination Host
purchasing.yourcompany.com
-- initial intermediary . ltsEnvelope
xmlnss.gt ltsHeadergt ltccClientCredentials
xmlnscc. smustUnderstandtrue gt
-- this block better be processed by
-- destination (no role
specified) ltccclientIdgt 122334
lt/ccclientIdgt lt/ ccClientCredentials gt
lt/Headergt ltsBodygt lt/sBodygt
-- same body lt/sEnvelopegt
44
Example Message Sent by Proxy
  • Proxy has deleted the two headers
  • Verified that user is valid using ltnamegt and
    ltpasswdgt and determined Id
  • Retargeted message to final destination using
    lttargetdeptgt
  • Proxy has inserted a new header containing Id
  • Final destination uses Id to determine
    authorization

45
WS-Addressing
  • Problem As described up to this point
    destination address (including target SOAP
    processor) is not included in SOAP message
  • This information is contained in transport header
    (e.g., SOAPAction header in HTTP)
  • Information has to be supplied separately to the
    transport and the mechanism for doing this is
    different for different transports
  • SOAP is not transport-neutral

46
WS-Addressing
  • Solution Include the information in SOAP header
    blocks.
  • WS-Addressing is defined for this purpose
  • ltwsaTogt - destination URL
  • ltwsaActiongt - message intent (analogous to
    SOAPAction)
  • ltwsaMessageIDgt - unique Id
  • ltwsaReplyTogt - address for reply
  • ltwsaRelatesTogt - Id of another message
  • .

47
WS-Addressing
  • The type EndpointReferenceType is defined to
    carry references to endpoints (e.g., value of
    ReplyTo)
  • Contains destination address as well as
    additional information that might be needed to
    send a message to that address
  • Identity of WSDL elements describing destination
    (port type, service,..)
  • Policy information (e.g., should message be
    encrypted)

48
SOAP Faults
  • SOAP provides a message format for communicating
    information about errors containing the following
    information
  • Fault category identifies error (not meant for
    human consumption)
  • VersionMismatch
  • MustUnderstand related to headers
  • Sender problem with message content
  • Receiver error had nothing to do with the
    message
  • human readable explanation
  • node at which error occurred (related to
    intermediaries)
  • application specific information about Client
    error

49
Embedding SOAP in HTTP POST
  • For document-style SOAP, the envelope is the body
    of an HTTP POST.
  • The HTTP response message simply acknowledges
    receipt of HTTP request messsage
  • For RPC-style SOAP, the envelope containing the
    SOAP request is the body of an HTTP POST the
    envelope containing the SOAP response (or fault)
    is the body of the corresponding HTTP response.

50
Embedding RPC-style SOAP in HTTP
POST /StockQuote HTTP/1.1 Content-Type
text/xml Content-Length .. ltsEnvelope
xmlnsshttp//www.w3.org/2003/05/soap-envelope
xmlnsxsdhttp//www.w3.org/2001/XMLSchema
xmlnsxsihttp//www.w3.org/2001/XMLSche
ma-instancegt ltsBodygt ltngetQuoteOp
xmlnsnhttp//www.shearson.com/quoteService
sencodingStylehttp//www.w3.org/2001/06/soa
p-encodinggt ltnstockSymbol xsitypexsdstring
gt IBM lt/nstockSymbolgt lt/ngetQuoteOpgt
lt/sBodygt lt/sEnvelopegt
51
Embedding Soap in HTTP GET
  • In some situations the client simply wants to
    retrieve an XML document
  • An HTTP GET request message is sent with no data
    (no SOAP content)
  • Document (actually a SOAP envelope) is returned
    as the data in the HTTP response

52
Web Services Description Language (WSDL)
  • Version 1.1

53
Goals of WSDL
  • Describes the formats and protocols of a Web
    Service in a standard way
  • The operations the service supports
  • The message(s) needed to invoke the operations
  • The binding of the messages to a communication
    protocol
  • The address to which messages should be sent

54
WSDL Description
  • A Web Service is described at both the abstract
    and concrete levels
  • Abstract Level (corresponds to portType
    Description Language)
  • What are the operations that are supported?
  • What messages are needed to invoke the
    operations?
  • Concrete Level
  • How are the messages bound to a transport
    protocol?
  • What is the Web address to which the messages
    should be sent?

55
WSDL Abstract Level
  • At the abstract level, obtaining a service is
    like executing a method of an object
  • WSDL defines the following elements
  • An portType is like an object it consists of a
    set of operations
  • An operation is like a method it is invoked by
    messages
  • A message is composed of parts
  • A part is like a parameter and has an associated
    type

56
Example
  • ltportType name GetQuotePTgt
  • ltoperation name getQuoteOpgt
  • ltinput message gsgetQuoteOpReq/gt
  • ltoutput message gsgetQuoteOpResp
    /gt
  • ltfault name invalidSymbolFault
  • message
    gsinvalidSymbolFaultMsg/gt
  • lt/operationgt
  • lt!-- other operations go here --gt
  • lt/portTypegt

gs is the target namespace of the document
containing this declaration and the message
declarations
57
Patterns
  • The messages exchanged when an operation is
    invoked conform to a pattern
  • WSDL 1.1 has defined two patterns
  • Request/response
  • Input sent by requestor, output produced by
    service
  • Requestor might wait for response (e.g., RPC) or
    might not
  • Choice is a function of how operation is used and
    would be specified at a higher level
  • One-way
  • Input sent by requestor, no response expected

58
Faults
ltoutput message gsgetQuoteOpResp/gt ltfault
name invalidSymbolFault
message gsinvalidSymbolFaultMsg/gt
  • Request/response pattern allows a fault message
    to replace the output message if server detects a
    fault
  • One-way pattern does not allow fault message

59
Example Message Definitions
  • ltmessage name getQuoteOpReqgt
  • ltpart name stockSymbol type
    xsdstring/gt
  • lt/messagegt
  • ltmessage name getQuoteOpRespgt
  • ltpart name stockSymbol type
    xsdstring/gt
  • ltpart name QuoteValue type
    xsdfloat/gt
  • lt/messagegt
  • ltmessage name invalidSymbolFaultMsggt
  • ltpart name faultInfo type
    gsfaultType/gt
  • lt/messagegt

60
Parts of a Message
  • A message can have many parts
  • Each part can be bound to a different position
    within the physical message sent by the transport
  • With SOAP parts can be distributed over body and
    header blocks
  • Each part can have a simple or complex type
    defined in an XML schema

61
Example
  • ltschemagt
  • ltcomplexType name faultTypegt
  • ltsequencegt
  • ltelement name faultCode type
    string/gt
  • ltelement name faultDetail type
    string
  • minOccurs 0 maxOccurs 1/gt
  • lt/sequencegt
  • lt/complexTypegt
  • lt/schemagt

62
Concrete Level
  • The concrete level defines how portTypes and
    operations are bound to transports and addresses
  • A given portType can be bound to several
    different transports and addresses
  • A Web Service might support a portType using
    several different transports
  • For example, the operations can be invoked using
    SOAP over either HTTP or SMTP
  • The same portType might be supported by several
    different Web Services using the same or
    different transports
  • In all of these cases, semantically identical
    service should be provided at each address

63
Concrete Level
  • At the concrete level, WSDL defines the following
    elements
  • A binding describes how the messages of a
    portType are mapped to the messages of a
    particular transport
  • An port maps a binding to a Web address
  • A service is a collection of ports that host
    related portTypes

64
Example Service and port
identifies binding
  • ltservice name GetQuoteServicegt
  • ltport name GetQuoteRPC
    bindinggqGetQuoteSOAPBindinggt
  • ltsoapaddress location
    http//www.shearson.com/quoteservice/gt
  • lt/portgt
  • lt!Other ports go here --gt
  • lt/servicegt

65
WSDL Extensibility
  • A binding maps a portType to a particular
    transport
  • It must be capable of targeting a variety of
    transports
  • Each transport has its own idiosynchrosies
  • WSDL is extended by introducing a different
    namespace for each transport

ltdefinitions xmlnshttp//schemas.xmlsoap.o
rg/wsdl/ xmlnsxsdhttp//www.w3.org/2001/
XMLSchema xmlnssoaphttp//schemas.xmlsoap
.org/wsdl/soap/ targetNamespacehttp//www.s
hearson.com/quoteservicegt lt!-- WSDL
declarations go here --gt lt/definitionsgt
introduce SOAP namespace
66
Example RPC/encoded SOAP Binding
identifies portType
  • ltbinding name GetQuoteSOAPBinding type
    tnsGetQuotePTgt
  • ltsoapbinding style rpc
  • transport http//schemas.xmlsoap.
    org/soap/http//gt
  • ltoperation name getQuoteOpgt
  • ltinputgt
  • ltsoapbody
  • use encoded
  • namespace
    http//www.shearson.com/quoteservice
  • encodingStyle
    http//schemas.xmlsoap.org/soap/encoding/gt
  • lt/inputgt
  • Continued on next slide

rpc style msg
for tags used in messsage
SOAP extensions
encode parameters
encoding rules
67
Binding Example - Continued
  • ltoutputgt
  • ltsoapbody
  • use encoded
  • namespace
    http//www.shearson.com/quoteservice
  • encodingStyle
    http//schemas.xmlsoap.org/soap/encoding//gt
  • lt/outputgt
  • lt/operationgt
  • lt!-- other operations go here
    --gt
  • lt/bindinggt

68
RPC/encoded Message
ltsEnvelope xmlnsshttp//www.w3.org/2003/05/soa
p-envelope xmlnsxsdhttp//www.w3.org/20
01/XMLSchema xmlnsxsihttp//www.w3.org/
2001/XMLSchema-instancegt ltsBodygt ltngetQuot
eOp xmlnsnhttp//www.shearson.com/quoteService
gt ltnstockSymbol xsitypexsdstringgt IBM
lt/nstockSymbolgt lt/ngetQuoteOpgt
lt/sBodygt lt/sEnvelopegt
69
Encoding
  • Problem Serializer serializes arguments (parts)
    in accordance with rules specified by
    encodingStyle attribute
  • Receiver can deserialize arguments since style is
    specified in the message
  • But message has a declared type
  • How can we be sure that the rules produce an
    instance of the type?
  • In fact they might not!

70
Example Encoding Style
  • Suppose there are n arguments of the same type.
  • Serializer might produce a message containing n
    instances of the type.
  • But suppose in a particular invocation all
    arguments have same value.
  • Serializer might produce a message containing n
    pointers to a single instance of the value.
  • Then the value of each argument (a pointer) is
    not an instance of the type!

71
Encoded Vs. Literal
  • If useencoded, arguments are encoded in
    accordance with the specified encoding style
  • If useliteral, arguments are instances of part
    types specified in the message declaration
  • Yields two distinct styles for invoking a remote
    procedure
  • rpc/encoded
  • rpc/literal

72
Example RPC/literal SOAP Binding
identifies portType
  • ltbinding name GetQuoteSOAPBinding type
    tnsGetQuotePTgt
  • ltsoapbinding style rpc
  • transport http//schemas.xmlsoap.
    org/soap/http//gt
  • ltoperation name getQuoteOpgt
  • ltinputgt
  • ltsoapbody
  • use literal
  • namespace
    http//www.shearson.com/quoteservice/gt
  • lt/inputgt
  • ltoutputgt . lt/outputgt
  • lt/operationgt
  • lt/bindinggt

rpc style msg
dont encode parameters
73
RPC/literal SOAP Binding
lttypesgt ltschemagt ltcomplexType
namecomptypgt lt/complexTypegt
ltschemagt lt/typesgt ltmessage namemsggt ltpart
namepart1 typecomptyp /gt lt/messagegt ltsoap
Envelopegt ltsoapBodygt ltnmyProc
xmlnsngt ltnpart1gt
instance of comptyp lt/npart1gt
lt/nmyProcgt lt/soapBodygt lt/soapEnvelopegt
74
RPC/encoded and RPC/literal
  • RPC style specified for both bindings
  • There is no schema describing the (entire)
    message body
  • Child of body element uses name of procedure
  • Each grandchild corresponds to a parameter and
    uses parameter name
  • Might be a grandchild for result returned
  • Hence, validation is not possible

75
Sending Documents
  • Increasingly, Web communication is
  • Asynchronous
  • Web Services are loosely coupled (as opposed to
    tightly coupled, object-oriented systems that are
    developed in a more integrated fashion and are
    more oriented towards rpc)
  • More appropriate for delay prone/failure prone
    environments
  • Messages contain XML documents (instead of
    procedure arguments)
  • A wide variety of communication patterns (as
    opposed to simply request/response) are useful

76
Example - Document Style Messaging
ltmessage name sendInvoiceMsggt ltpart name
invoice type invinvoiceType/gt lt/messagegt
ltportType name invoicePTgt ltoperation name
sendInvoiceOpgt ltinput message
invsendInvoiceMsg/gt lt/operationgt lt/portTypegt
one-way pattern
77
Example (cont)
SOAP body contains XML documents
ltbinding name sendInvBinding type
inginvoicePTgt ltsoapbinding style
document transport
http//schemas.xmlsoap.org/soap/http/gt
ltoperation name invsendInvoiceOpgt
ltinputgt ltsoapbody use
literal namespace
http//www.invoicesource.com/invoice/gt
lt/inputgt lt/operationgt lt/bindinggt
body is an instance of part type
78
Document/literal SOAP Binding
Alternative 1 one part specified by a type
lttypesgt ltschemagt ltcomplexType
namecomptypgt lt/complexTypegt
ltschemagt lt/typesgt ltmessage namemsggt ltpart
namepart1 typencomptyp /gt lt/messagegt ltsoa
pEnvelopegt ltsoapBodygt instance of
comptyp lt/soapBodygt lt/soapEnvelopegt
n is target namespace of this document
message can have only one part in this case since
the schema of the body can have only one type
specification
79
Document/literal SOAP Binding
Alternative 2 part specified by an element
lttypesgt ltschemagt ltelement nameelem
typencomptyp /gt ltcomplexType
namecomptypgt lt/complexTypegt
ltschemagt lt/typesgt ltmessage namemsggt ltpart
namepart1 elementnelem /gt lt/messagegt ltsoa
pEnvelopegt ltsoapBodygt ltnelem
xmlns target ns of WSDL doc gt
instance of comptyp
lt/nelemgt lt/soapBodygt lt/soapEnvelopegt
Part is identified as an element. An instance
of element is a child of body, named with
elements name, typed with elements type
80
Sending Multiple Documents
ltelement namefirstInvoice typeinvinvoiceTyp
e /gt ltelement namesecondInvoice
typeinvinvoiceType /gt ltcomplexType
nameinvoiceTypegt lt!-- the complex type
definition goes here --gt lt/complexTypegt ltmessage
name sendInvoiceMsggt ltpart name
invoice1 element invfirstInvoice /gt
ltpart name invoice2 element
invsecondInvoice /gt lt/messagegt
element specification must be used since message
has multiple parts
ltsoapBodygt ltinvfirstInvoicegt lt!--
instance of invoiceType goes here --gt
lt/invfirstInvoicegt ltinvsecondInvoicegt
lt!-- instance of invoiceType goes here --gt
lt/invsecondInvoicegt lt/soapBodygt
81
Sending Messages By Email Simple Mail Transfer
Prototol
  • ltservice name GetQuoteSMTPServicegt
  • ltport name GetQuoteSMTP
  • bindinggqGetQuoteSMTPBin
    ding/gt
  • ltsoapaddress
  • location
    mailtostockquote_at_shearson.com/gt
  • lt/portgt
  • lt/servicegt

82
Mail Example (continued)
  • ltbinding name GetQuoteSMTPBinding
  • type tnsGetQuotePTgt
  • ltsoapbinding style document
  • transporthttp//schemas.xmlsoap
    .org/soap/smtp /gt
  • ltoperation name getQuoteOpgt
  • ltinputgt
  • ltsoapbody useliteral/gt
  • lt/inputgt
  • ltoutputgt
  • ltsoapbody useliteral/gt
  • lt/outputgt
  • lt/operationgt
  • lt/bindinggt

83
Complete WSDL Document
ltdefinitions targetNamespace. xmlns
other namespaces gt lttypesgt lt!
specification of XML Schema types used in this
document --gt lt/typesgt ltmesssagegt
lt/messsagegt lt! specification of other
messages goes here--gt ltportTypegt
lt/portTypegt lt! specification of other
portTypes goes here--gt ltbindinggt
lt/bindinggt lt! specification of other
bindings goes here--gt ltservicegt
ltportgt lt/portgt lt! specification of
other ports goes here--gt lt/servicegt
lt!-- specification of other services goes here
--gt lt/definitionsgt
84
What WSDL Cannot Do
  • WSDL describes how each operation can be invoked
  • E.g., getQuoteOp
  • Many services require a sequence of operations
  • Send this message, receive that message, if this
    happens send this other message to another port,
    etc
  • The sequence cannot be described in WSDL
  • BPEL describes the logic of a Web Service
  • How it is impemented
  • How it communicates with other busienss processes
  • Sometimes called an orchestration language

85
Business Process Execution Language for Web
Services (BPEL4WS)
Version 1.1
86
BPEL vs. WSDL
  • WSDL supports a stateless model which describes
    operations supported by web servers
  • One or two messages needed for client/server
    communication
  • No mechanism for describing state between
    operations
  • A business process (BP) typically characterized
    by long-running, statefull sequence of operations
    with one or more web services (business partners).

87
Simple Example Ordering Stationery
  • cobegin
  • invoke Staples.StationeryQuote(staples-quot
    e)
  • invoke Office-Max.StationeryQuote
    Service(max-quote)
  • coend
  • if staples-quote lt max-quote
  • invoke Staples.StationeryPurchase
  • else
  • invoke Office-Max.StationeryPurchase

state
88
New Issues
  • A language for business processes
  • Must be able to communicate with other Web
    Services
  • Must be able to access and modify data received
    in messages
  • Use XPath to extract information from messages
  • Must have control constructs
  • sequence, switch (if), flow (concurrency), while,
    link (synchronize concurrent processes), invoke,
    etc
  • Must be able to handle faults

89
Example (BPEL)
  • ltsequencegt
  • ltflowgt
  • ltinvoke partnerLinkStaples
    portTypestaplesPurchasePt
  • operationrequestQuote
    inputVariablestationeryReq
  • outputVariablestaplesStati
    oneryQuotegt
  • lt/invokegt
  • ltinvoke partnerLinkOfficeMax
    portTypeofficeMQuotePT
  • operationrequestQuote
    inputVariablestationeryReq
  • outputvariableofficeMStati
    oneryQuotegt
  • lt/invokegt
  • lt/flowgt
  • .. Continued
    on next slide ..

90
Example (BPEL)
  • ltswitchgt
  • ltcase conditionbpwsgetVariableProperty(sta
    plesStationeryQuote, quote)
  • lt
    bpwsgetVariableProperty(officeMStationeryQuote,
    quote) /gt
  • ltinvoke partnerLinkStaples
    portTypestaplesQuotePt
  • operationpurchStation
    ery inputVariablestationeryPurch
  • outputVariablestation
    eryRespgt
  • lt/invokegt
  • lt/case
  • ltotherwisegt
  • ltinvoke partnerLinkOffice Max
    portTypeofficeMQuotePT
  • operationpurchStation
    ery inputVariablestationeryPurch
  • outputVariablestation
    eryRespgt
  • lt/invokegt
  • lt/otherwisegt
  • lt/switchgt
  • lt/sequencegt

91
Business Process (BP)
  • A BP consists of both internal computations and
    invocations of operations exported by Web service
    partners
  • The operations it exports constitute its
    interface to its partners
  • The sequence of invocations it executes is
    referred to as a protocol and
  • is data dependent
  • responds to exceptional conditions

92
Abstract Vs. Executable BPs
  • Executable BP complete description of BP
    (including all computations)
  • Abstract BP contains only externally visible
    (communication related) behavior of BP
  • Not executable
  • Intention Internal decision making algorithm and
    data manipulation not described (although this is
    not enforced)
  • Languages for describing abstract and executable
    BPs share a common core, but differ primarily in
    data handling capabilities
  • BPEL4WS is used to specify both abstract and
    executable BPs

93
Executable BPs
  • BPEL is sufficient for describing a complete
    (executable) BP that
  • Relies on Web services and XML data
  • Is portable (platform independent)
  • Executable BP is a complete specification of the
    Web service
  • Actual implementation, however, might not use
    BPEL,
  • Abstract BP specifies external interface and can
    be exported for use by business partners

94
Abstract BP
  • Unfolding of protocol related portion of BP
  • depends on properties - a subset of the data
    contained in messages
  • Ex. Message invoking getQuoteRequest might have
    parts instrumentType (with value stock or bond)
    and symbol (which identifies a particular
    instrument of that type)
  • instrumentType will be a property if it affects
    the course of the protocol
  • symbol will not if it does not affect the course
    of the protocol
  • Only properties are visible to abstract BP

95
Abstract Vs Executable BP
  • Internal computation of executable BP not
    included in abstract BP
  • If assignment is to a variable that is not a
    property, it is eliminated from abstract process
  • Ex. Address data might not affect the protocol
  • If assignment is to a variable that is a
    property, it (generally) affects the protocol
  • Ex. Value of bidPrice might affect protocol
  • if (bidPricegt1000) invoke webService1 else invoke
    webService2
  • bidPrice will be a property, but its value is
    computed by an internal algorithm
  • The computation that produces the new value is
    generally not relevant to the protocol

96
Abstract BP Non-determinism
  • Description of abstract BP allows assignment of
    non-deterministic values to properties to model
    this
  • Abstract and executable BPs differ in data
    handling ability
  • Executable can explicitly manipulate all data
  • Abstract can access only properties and can
    assign non-deterministic values to them
  • Executable cannot assign non-deterministic values
    to anything

97
Abstract BP Non-determinism
computation that assigns a value to part x
non-deterministic assignment to property
x? (alias of x)
switch(x)
switch(x? )
Abstract BP
Executable BP
98
Communication Client Side
  • Invoking an operation of a portType (specified in
    WSDL) exported by server
  • Client assigns message to operations input
    variable
  • Client executes invoke on operation
  • Asynchronous (one-way WSDL pattern)
  • Client resumes execution immediately
  • Synchronous (request/response WSDL pattern)
  • Client waits for response and then resumes
    execution
  • Synchronization imposed by BPEL
  • Client can access response message in operations
    output variable

99
Communication Client Side
  • Receiving an invocation of an operation exported
    by client
  • Client executes receive on operation
  • Client waits for message
  • Client can access message in variable associated
    with operation and resume execution
  • Ex an asynchronous response to a prior
    invocation on a callback portType

100
Communication Client Side
client
server invoke invoke invoke receive
(synchronous invoke)

client waits
(asynchronous invoke)
server exports portType

client continues

(asynchronous invoke)
problem how do you associate request
with response?


(asynchronous invoke)
client exports (callback) operation
101
Communication Server Side
  • Accepting an operation invocation on an
    (exported) portType (specified in WSDL)
  • Server executes receive on operation and waits
  • Responding to a synchronous operation invocation
  • Server executes reply on operation (rpc)
  • Invoking a clients exported (callback) operation
  • Server executes invoke on operation

102
Communication Server Side
client
server invoke
(synchronous invoke)
receive

reply
(asynchronous invoke)
receive
server exports portType
invoke

(asynchronous invoke)
receive
invoke



(asynchronous invoke)
receive
invoke
client exports (callback) portType
103
Example Purchase Order (PO) Service
receive purchase order
concurrency
sequencing
initiate price calculation
decide on shipper
initiate production scheduling
complete price calculation
arrange logistics
complete production scheduling
synchronization
invoice processing, reply
104
PO Service
PO Service
receive
synchronous invocation
POMsg
Body of PO Service
customer
operation sendPurchOr on portType purchOrPT
InvMsg
reply
105
PO Service Interface (WSDL)
ltdefinitions targetNamespace.
xmlnshttp//schemas.smlsoap.org/wsdl/ gt
ltmessage namePOMsggt ltpart namecustInfo
typesnscustInfo/gt ltpart namepurchOr
typesnspurchOr/gt lt/messagegt ltmessage
nameInvMsggt ltpart nameIVC
typesnsInvoice/gt lt/messagegt .. ltportType
namepurchOrPTgt ltoperation
namesendPurchOrgt ltinput
messageposPOMsg/gt -- arguments supplied
ltouput messageposInvMsg/gt -- response
lt/operationgt lt/portTypegt ..
portType exported by PO Service
prefix for target namespace in this document
lt/definitionsgt
106
Variables (BPEL)
  • Variables maintain the state of a BP
  • Used to store messages that have been sent or
    received or for local storage (no message
    involved)
  • Has an associated type
  • Can be a message type
  • Can be an XML simple type
  • Can be an XML schema element (which might have a
    complex type)
  • Has an associated scope

ltvariable namePO messageTypelnsPOMsg/gt
lns is prefix in BPEL document for the WSDL
document
107
Partner Link Type (WSDL)
ltpartnerLinkTypegt describes the way two BPs
interact - names a portType that must be
declared in each - associates ltrolegt with
each end of the interaction
Not a process (allows actual partner to be
specified dynamically)
WSDL extension for BPEL
ltplnkpartnerLinkType namepurchLTgt
ltplnkrole namepurchServicegt
ltplnkportType namepospurchOrPT/gt
lt/plnkrolegt lt/plnkpartnerLinkTypegt
partnerLinkType is a unit of collaboration
Only one role (in this case) since only POService
needs to provide an portType
108
Partner Link Type (WSDL)
ltplnkpartnerLinkType nameinvoicingLTgt
ltplnkrole nameinvoiceServicegt
ltplnkportType nameposcomputePricePT/gt
lt/plnkrolegt ltplnkrole nameinvoiceRequester
gt ltplnkportType nameposinvoiceCallbackPT
/gt lt/plnkpartnerLinkTypegt
description of a possible relationship between
two BPs
BP playing role of invoice requester
BP playing role of invoice service
invoiceCallbackPT
computePricePT
109
Partner Link (BPEL)
Connection to another BP described by a
partner link ltpartnerLinkgt construct in BPEL
names a process and associates it with a
role in that link.
partner specification in PO service

name of partnerLink
prefix lns refers to WSDL document
ltpartnerLinksgt ltpartnerLink namepurchLink
partnerLinkTypelnspurchLT
myRolepurchService/gt lt!-- other
partnerLinks go here --gt lt/partnerLinksgt
hence PO service must provide purchOrPT
110
Partner (BPEL)
  • A BP might interact with another BP called a
    partner - through several partnerLinks
  • Need a mechanism that asserts that the same BP is
    at the other end of a set of partnerLinks
  • Ex BPs might support getFarePT and
    purchaseTicketPT an acceptable partner is one
    that supports both

ltpartnersgt ltpartner nameticketVendorgt
ltpartnerLink namexxxx/gt lt!-- supports
getFarePT --gt ltpartnerLink nameyyyy/gt
lt!-- supports purchaseTicketPT --gt
lt/partnergt lt/partnersgt
111
Process Name
  • Each BP is assigned a name in the ltprocessgt tag

ltprocess namecustomer
namespace declarations query
language (default XPath)
expression language (default XPath) gt
declarations and process body lt/processgt ltproce
ss namepurchOrProcess
similarly gt declarations and body of
PO service lt/processgt
112
Linkage Customerto PO Service
plnk prefix in WSDL doc refers to
WSDL extension pos target ns of WSDL doc lns
prefix in PO Service refers to WSDL
doc cns prefix in customer refers to
WSDL doc
ltplnkpartnerLinkType namepurchLTgt
ltplnkrole namepurchServicegt
ltplnkportType namepospurchOrPT/gt
lt/plnkrolegt lt/plnkpartnerLinkTypegt ltpartnerLink
namelinkToPurch
partnerLinkTypecnspurchLT
partnerRolepurchService/gt ltpartnerLink
namepurchLink partnerLinkTypeln
spurchLT myRolepurchService/gt
WSDL inter- face exported by PO Service
partner specification in customer process
partner specification in PO Service
113
Partners
In general - A partnerLinktype is not
specific to a particular BP it is a
global, bilateral (WSDL) description of the
interaction between two BPs. - A
partnerLink declaration (BPEL) describes how the
local BP interacts with other BPs
through a
partnerLinktype.

ltpartnerLinksgt ltpartnerLink nameinvoiceProvid
er partnerLinkTypelnsinvoice
LT myRoleinvoiceRequester
partnerRoleinvoiceServices/gt lt/
partnerLinksgt
114
PO Service (BPEL)
ltvariablesgt ltvariable namePO
messageTypelnsPOMsg/gt ltvariable
nameInvoice messageTypelnsInvMsg/gt lt/variab
lesgt ltsequencegt ltreceive partnerLinkpurchLi
nk portTypelnspurchOrPT
operationsendPurchOr variablePO/gt
lt/receivegt ltflowgt . concurrent body.
lt/flowgt ltreply partnerLinkpurchLink
portTypelnspurchOrPT
operationsendPurchOr variableInvoice/gt lt/se
quencegt
Both necessary since PO Service might
communicate with several BPs
through the same portType
115
Interaction with Shipping Provider
PO service
operation requestShipping on portType shippingPT
decide on shipper (invoke)
shipReqMsg
Shipping service
shipInfoMsg
scheduleMsg
arrange logisitics (receive)
operation sendSchedule on port shippingCallbackPT
role shippingService
role shippingRequester
116
Handling Shipping (WSDL)
ltportType nameshippingCallbackPTgt
ltoperation namesendSchedulegt ltinput
message/gt lt/operationgt lt/portTypegt ltportTy
pe nameshippingPTgt ltoperation
namerequestShippinggt ltinput
message/gt ltoutput message/gt
lt/operationgt lt/portTypegt
portType exported by PO Service
portType exported by shipping service
117
Handling Shipping
ltplnkpartnerLinkType nameshippingLTgt
ltplnkrole nameshippingServicegt
ltplnkportType nameposshippingPT/gt
lt/plnkrolegt ltplnkrole nameshippingRequester
gt ltplnkportType nameposshippingCallBack
PT/gt lt/plnkrolegt lt/plnkpartnerLinkTypegt ltpar
tnerLink nameshippingProvider
partnerLinkTypelnsshippingLT
myRoleshippingRequester
partnerRoleshippingService/gt
WSDL
BPEL (PO service)
118
Handling Shipping (BPEL)
contains input message
ltsequencegt ltassigngt ltcopygt
ltfrom variablePO partcustInfo /gt
ltto variableshippingReq
partcustInfo /gt lt/copygt
lt/assigngt ltinvoke partnerLinkshippingProv
ider portTypelnsshippingPT
operationrequestShipping
inputVariableshippingReq
outputVariableshippingInfo gt lt/invokegt
ltreceive
partnerLinkshippingProvider
portTypelnsshippingCallbackPT
operationsendSchedule variableshippingSch
edule/gt lt/sequencegt
119
Links (BPEL) Synchronizing Concurrent Activities
w/i a BP
  • Production scheduling cannot be completed until
    logistics have been arranged

Concurrent sequence activities in flow
data produced by arrange logistics is needed
by complete production scheduling data
communicated through globally shared variable
decide on shipper
initiate production scheduling
arrange logistics
complete production scheduling
link
source
target
120
Links
ltflowgt ltlinksgt ltlink nameship-sched/gt
lt/linksgt ltsequencegt

ltassigngt . lt/assigngt ltinvoke
partnerLink .gt lt/invokegt
ltreceive partnerLink .
variableshippingSchedgt ltsource
linkNameship-sched/gt lt/receivegt
lt/sequen
Write a Comment
User Comments (0)
About PowerShow.com