COMS E6125 Web-enHanced Information Management (WHIM) - PowerPoint PPT Presentation


Title: COMS E6125 Web-enHanced Information Management (WHIM)


1
COMS E6125 Web-enHanced Information Management
(WHIM)
  • Prof. Gail Kaiser
  • Spring 2012

2
Topics covered in this lecture
  • Introduction to Web Services
  • SOAP and WSDL
  • Web Services Component Model
  • WS- Specifications

3
What Are Web Services?
  • The Web infrastructure is increasingly used for
    application to application interaction (as
    opposed to human/browser to application
    interaction)
  • Any application that programmatically invokes
    computations via the Web infrastructure could be
    said to be using web services
  • But here the term is used to mean more explicit
    remote procedure (service) calls and messaging
  • Can vary in function from simple requests (e.g.,
    currency conversion or a weather report) to
    complex business systems that access and combine
    information from multiple sources

4
RPC vs. Messaging
  • Messaging has no notion of client and server -
    since a messaging framework concentrates on
    delivering a message, all nodes that accept and
    emit messages are considered equal in status and
    termed peers. RPC always has the concepts of
    client (caller) and server (callee).
  • Messaging is time-independent peers are not
    expected to accept the message in real time, the
    middleware takes care of delivering a message to
    the relevant peer when it is available. RPC,
    however, fails when one party goes down.
  • Messages can be duplicated and delivered to
    multiple peers quite easily. While RPC is
    essentially a one-with-one communication
    strategy, messaging is far more flexible and can
    deliver copies of the same message without any
    effort from the emitter.

5
Web Services Standards
  • Enable building Web-based applications using any
    platform, object model and programming language
  • Or add an Internet-capable interface to a legacy
    system
  • Allow any piece of software to communicate using
    a standardized XML messaging system (SOAP)
  • Once a Web Service is deployed with a machine
    readable interface (WSDL), other applications and
    Web Services can invoke that service

6
Example Web Service
  • http//www.webservicex.net/WS/WSDetails.aspx?WSID
    68CATID12

7
Steps to Creating and Using a Web Service
  1. Service provider creates a service or application
  2. Service provider defines a corresponding Web
    Service Description
  3. Service requester writes the code to access the
    Web Service, using the protocol and input/output
    parameters specified in its Web Service
    Description

8
Simple Object Access Protocol (SOAP)
  • Written in XML
  • Initially conceived as the minimal possible
    infrastructure necessary to perform RPC over the
    Web (predecessor XML-RPC)
  • Defines a mechanism to pass commands and
    parameters between clients and servers
  • Independent of the platform, object model and
    programming language
  • SOAP messages transported over HTTP are
    firewall-friendly and relatively easy to debug
    (XML text rather than binary stream)
  • But verbose and inefficient (i.e., slow) compared
    to alternative distributed computing
    infrastructures (e.g., CORBA IIOP, DCOM)

9
SOAP Message Structure
  • A message is seen as an envelope that contains
    the data to be sent ( control)
  • The envelope has two main parts, header
    (optional) and body (mandatory)
  • The header is for infrastructure level data and
    control
  • The body is for application level data

SOAP Envelope
SOAP Header
Header subelements
SOAP Body
Body subelements
10
SOAP Header
  • The header contains administrative and control
    information
  • Typical uses transaction identifiers, security
    certificates, processing instructions for
    intermediaries
  • Target of most WS- specifications

11
SOAP Body
  • The applications (sender and receiver) agree upon
    the method signatures
  • The body of the SOAP message contains the actual
    call the procedure name and the input parameters
  • The body of a response message contains the
    output parameters and optional result
    (analogous to return value)

12
SOAP Envelope Structure
  • ltenvEnvelope xmlnsenvhttp//schemas.xmlsoap.or
    g/soap/envelope/gt
  • ltenvHeadergt
  • lt!-- content of header goes here (optional)
    --gt
  • lt/envHeadergt
  • ltenvBodygt
  • lt!-- content of body goes here (mandatory)
    --gt
  • lt/envBodygt
  • lt/envEnvelopegt

XML namespace that defines SOAP tags
ltenvEnvelope xmlnsenvhttp//schemas.xmlsoap.or
g/soap/envelope/gt ltenvBodygt lteteTicket
xmlnsethttp//www.acme-travel.com/eticket/schem
agt ltetpassengerName firstJane
lastDoe/gt ltetflightInfo
airlineNameZZ
flightNumber9999
departureDate2011-09-21
departureTime1234/gt lt/eteTicketgt
lt/envBodygt lt/envEnvelopegt
The XML schema that defines the travel
application types
13
SOAP Request Example
POST /travelservice HTTP/1.1 Content-Type
application/soapxml charsetutf-8 Content-Leng
th nnnn ltenvEnvelope xmlnsenvhttp//schemas.
xmlsoap.org/soap/envelope/gt ltenvBodygt
ltmGetFlightInfo xmlnsmhttp//www.acme-travel.c
om/flightinfo envencodingStylehttp//sch
emas.xmlsoap.org/soap/encoding/
xmlnsxsdhttp//www.w3.org/2001/XMLSchema
xmlnsxsihttp//www.w3.org/2001/XMLSchema-insta
ncegt ltairlineName xsitypexsdstringgtZZlt
/airlineNamegt ltflightNumber
xsitypexsdintgt9999lt/flightNumbergt
lt/mGetFlightInfogt lt/envBodygt lt/envEnvelopegt
14
SOAP Response Example
HTTP/1.1 200 OK Content-Type application/soapxml
charsetutf-8 Content-Length
nnnn ltenvEnvelope xmlnsenvhttp//schemas.xmls
oap.org/soap/envelope/gt ltenvBodygt
ltmGetFlightInfoResponse xmlnsmhttp//www
.acme-travel.com/flightinfo
envencodingStylehttp//schemas.xmlsoap.org/soap
/encoding/ xmlnsxsdhttp//www.w3.org/200
1/XMLSchema xmlnsxsihttp//www.w3.org/20
01/XMLSchema-instancegt ltflightInfogt
ltgate xsitypexsdintgt1337lt/gategt
ltstatus xsitypexsdstringgtON TIMElt/statusgt
lt/flightInfogt lt/mGetFlightInfoResponsegt
lt/envBodygt lt/envEnvelopegt
15
SOAP Fault Message
  • In the case of failure, the contents of the SOAP
    response envelope will generally be a Fault
    message, along the lines of

ltenvBodygt ltenvFaultgt ltenvCodegt
ltenvValuegtenvSenderlt/envValuegt
ltenvSubcodegt ltenvValuegtrpcBadArgumentslt/envVal
uegt lt/envSubcodegt lt/envCodegt
ltenvReasongt ltenvText xmllang"en-US"gtPro
cessing errorlt/envTextgt lt/envReasongt
ltenvDetailgt lt/envDetailgt lt/envFaultgt
lt/envBodygt
16
Web Services Description Language (WSDL)
  • Written in XML
  • Used to define an individual Web service
  • The operations offered by the service (what)
  • The mechanisms to access the service (how)
  • The location at which the service is made
    available (where)
  • Analogous to interfaces
  • Often used to generate parts of the client
    (requester) and server (provider) code

17
WSDL Structure
  • Abstract part operations, messages sent and
    received as operation inputs and outputs, types
    of data to be exchanged
  • Concrete part binding to transport and wire
    format details that users must follow to access
    the service, endpoint network address

WSDL specification
abstract part
types
messages
port types operations
concrete part
bindings
ltdefinitions nameServiceNamegt lttypesgt data
types used... lt/typesgt ltmessagegt parameters
used... lt/messagegt ltportTypegt set of
operations performed... lt/portTypegt ltbindinggt
communication protocols and data formats used...
lt/bindinggt ltservicegt set of ports to service
provider endpoints lt/servicegt lt/definitionsgt
services ports
18
WSDL Types
  • lttypesgt element defines the data types that are
    used by the web service and exchanged in messages
  • Uses XML Schema syntax to define data types

lttypesgt ltcomplexType name"CompanyInfo"/gt
ltelement name"CompanyName" type"xsdstring"/gt
ltelement name"Address" type"xsdstring"/gt
lt/complexTypegt ltcomplexType name"ReimbursementR
equest"/gt ltelement name"amount"
type"xsdfloat"/gt ltelement name"date"
type"xsdstring"/gt lt/complexTypegt ... lt/typesgt
19
WSDL Messages
  • ltmessagegt element defines the operation signature
  • Each message can consist of one or more parts and
    zero or more attachments
  • Each part must have a name and a type
  • The parts and attachments are analogous to the
    parameters of a function call in a traditional
    programming language

lttypesgt ... lt/typesgt ltmessage name"Reimbursement
RequestInput"gt ltpart name"employeeId"
type"xsdstring"/gt ltpart name"info"
type"ReimbursementRequest"/gt ltattachment
name"hotelReceipt" uri"uri to image of hotel
receipt"/gt ltattachment name"carRentalReceipt"
uri"uri to image of rental car
receipt"/gt lt/messagegt
20
WSDL Port Types
  • ltportTypegt element defines the actual operations
    that can be performed and the messages
    (parameters) that are involved
  • Can be compared to a function library (or a
    module or a class) in a traditional programming
    language

ltportType nameanynamegt ltoperation
name"Reimburse"gt ltinput message"ReimbursementRe
questInput"/gt lt/operationgt ltoperationgt ...
lt/operationgt ltoperationgt ... lt/operationgt
ltoperationgt ... lt/operationgt ... lt/portTypegt
21
Types of Port Operations
  • Syntactically, an operation is a combination of
    input and output (and fault) messages indicating
    what role a message plays in the interaction
  • Each operation represents a message exchange
    pattern supported by the Web Service
  • A service requester's behavior in the transient
    period between two related messages defines the
    synchronous/asynchronous behavior in the client
    API.
  • In the synchronous case, invocation at the client
    API would block, and wait until the related
    message arrives at the destination.
  • In the asynchronous case, the client invocation
    continues without blocking, and when a related
    message arrives, it is correlated with earlier
    messages.

22
Message Exchange Patterns
  • One-way (in-only, fire and forget) The operation
    can receive a message but will not return a
    response (asynchronous)
  • Notification The operation can send a message
    but will not wait for a response (asynchronous)
  • Request-response (in-out, rpc) The operation can
    receive a request and will return a response
    (synchronous)
  • Solicit-response The operation can send a
    request and will wait for a response (synchronous)

23
WSDL Concrete Elements
  • Binding the interface to a transport protocol -
    What communication protocol to use to transport
    service requests and responses (e.g., SOAP over
    HTTP, HTTPS, SMTP, JMS)
  • The service as a collection of all bindings of
    the same interface - How to accomplish individual
    service interactions over this protocol (the
    interface in all its available implementations)
  • The endpoint or network address (port) of the
    binding - Where to terminate communication (i.e.,
    the network address of the service provider)

24
Example SOAP Binding
  • ltbinding nameAirportServiceSoapBinding
    typetnsAirportServicePortTypegt
  • ltsoapbinding transporthttp//schemas.xmlsoap.
    org/soap/http/gt
  • ltoperation nameGetFlightInfogt
  • ltsoapoperation stylerpc
    soapActionhttp//acme-travel/flightinfo/gt
  • ltinputgt
  • ltsoapbody useencoded namespacehttp//a
    cme-travel.com/flightinfo
    encodingStylehttp//schemas.xmlsoap.org/soap/enc
    oding//gt
  • lt/inputgt
  • ltoutputgt
  • ltsoapbody useencoded namespacehttp//a
    cme-travel.com/flightinfo
    encodingStylehttp//schemas.xmlsoap.org/soap/enc
    oding//gt
  • lt/outputgt
  • lt/operationgt
  • ltoperation nameCheckIngt
  • ltsoapoperation styledocument
    soapActionhttp//acme-travel.com/checkin/gt
  • ltinputgt
  • ltsoapbody useliteral/gt
  • lt/inputgt
  • lt/operationgt

ltservice nametravelservicegt ltport
nametravelservicePort bindingtnsAirportServi
ceSoapBindinggt ltsoapaddress
locationhttp//acmetravel.com/travelservice/gt
lt/portgt lt/servicegt
25
So Now We Have Web Services
  • Web Services distributed applications, services
    and components, described using XML-encoded WSDL
    interfaces, that process XML-encoded SOAP
    messages
  • XML, SOAP and WSDL constitute baseline
    specifications that provide a foundation for
    application integration

26
Example Web Service
  • http//www.webservicex.net/WS/WSDetails.aspx?WSID
    68CATID12

27
But
  • Additional standards beyond this baseline become
    necessary as WS applications become more complex,
    integrating multiple components across multiple
    organizations
  • Otherwise, WS developers are compelled to
    implement higher-level functionality in
    proprietary and often non-interoperable ways

28
Composable Services
  • Specialized Web Service specifications that are
    independent but can be combined
  • For example, it is possible to independently add
    transaction identifiers and reliable messaging
    sequence numbers
  • The two extensions do not conflict with each
    other and are compatible with pre-existing
    message structures
  • Developers and providers can integrate selected
    specifications that fulfill the requirements of
    their communicating processes

29
SOAP Inherently Supports Composition
  • SOAP uses a regular, multi-part message
    structure New message elements supporting new
    services may be added to message headers in a
    manner that does not alter the processing of
    existing functionality
  • SOAP body is for the ultimate recipient, SOAP
    header blocks may be targeted at any entity along
    the message path

30
(No Transcript)
31
Addressing
  • Messages and responses both go somewhere and come
    from somewhere (and errors also need to be
    reported somewhere)
  • By default, SOAP encodes the destination for a
    message with a URL placed in the HTTP transport
  • The destination for the response is determined by
    the HTTP return address
  • Builds on the basic browser-server model

32
Addressing
  • The source and destination information are not
    part of the message itself
  • But information can be lost if a transport
    connection terminates (e.g., if the response
    takes a long time and the connection times out)
  • Or if the message is forwarded by an
    intermediary, perhaps routed over multiple
    transports
  • Also does not allow for directing a response to a
    third party (e.g., request sent over HTTP but
    returned via SMTP)

33
WS-Addressing
  • Provides a mechanism to place the target, source
    and other addressing information directly within
    the message
  • Decouples address information from any specific
    transport model
  • Supports asynchronous communication patterns,
    both short and extended duration
  • Across multiple endpoint references
  • Does not match very well the request/response
    model over a single HTTP connection (see blog
    entry), more applicable to other transports
  • That is, messaging rather than RPC

34
Message Addressing Properties
  • To -- message destination
  • Action -- an action value indicating the
    semantics of the message, corresponds to WSDL
    porttype
  • From -- the endpoint of the service that
    dispatched this message
  • ReplyTo -- the endpoint to which reply messages
    should be dispatched
  • FaultTo -- the endpoint to which fault messages
    should be dispatched
  • Unique MessageId, required if there will be any
    response
  • RelatesTo previous messages (indicating previous
    From and MessageId)

35
(No Transcript)
36
Security Requirements
  • A sends a message to service B
  • B partially processes the message and forwards it
    to service C
  • HTTPS allows authentication, integrity and
    confidentiality between A-B and B-C
  • However, C and A cannot authenticate each other,
    or hide information from B
  • For A, B and C to use userid/password for
    authentication, they must share the same
    replicated user and password information
  • Instead need end to end security

37
WS-Security
  • Defines mechanisms for associating security
    related claims with a message
  • Signed, encrypted security tokens
  • Username/password (BASIC-Auth)
  • x509 certificates (public key infrastructure)
  • Kerberos tickets (secret key)
  • XrML eXtensible rights Markup Language (digital
    property rights)
  • SAML Security Assertion Markup Language (single
    sign-on)

38
WS-Security
  • A can generate a token that C can verify as
    having come from A, B cannot forge the token
  • A can sign selected elements or the entire
    message, this allows B and C to confirm that the
    message has not changed since A sent it
  • A can seal the message or selected elements, this
    ensures that only the intended service for those
    elements can use the information - prevents B
    from seeing information intended for C and vice
    versa

39
(No Transcript)
40
Reliable Messaging
  • In an Internet world, almost all communication
    channels are unreliable - messages disappear or
    are duplicated, connections break
  • Without a reliable messaging standard, WS
    application developers must build these functions
    into their applications
  • The basic approaches and techniques are well
    understood, e.g., many middleware systems ensure
    messages have unique identifiers, provide
    sequence numbers, and retransmit when messages
    are lost
  • If WS developers implement these models in their
    applications, they may make incompatible
    assumptions or design choices, resulting in
    little if any reliable messaging

41
WS-ReliableMessaging
  • Defines mechanisms that enable Web Services to
    ensure delivery of messages over unreliable
    communication networks
  • Supports bridging multiple different
    infrastructures into a single, logically
    complete, end-to-end model

42
WS-ReliableMessaging
  • The RM Source MUST assign each reliable message a
    sequence number beginning at 1 and increasing by
    exactly 1 for each subsequent reliable message
  • Every acknowledgement issued by the RM
    Destination MUST include within that
    acknowledgement the range or ranges of the
    sequence numbers of every message successfully
    received and MUST exclude sequence numbers of any
    messages not yet received

43
WS-ReliableMessaging
  • Delivery Assurances AtMostOnce, AtLeastOnce,
    ExactlyOnce, InOrder
  • Protocol Elements Sequence, Sequence
    Acknowledgement, Request Acknowledgement,
    Sequence Creation, Sequence Termination
  • Policy Assertions SequenceCreation,
    SequenceExpiration, InactivityTimeout,
    RetransmissionInterval, AcknowledgementInterval

44
(No Transcript)
45
Transactions
  • A complex business scenario may require multiple
    parties to exchange multiple sets of messages
  • The multiple messages exchanged between
    participants constitute a logical "task" or
    "objective"
  • The parties must be able to
  • Start new coordinated tasks.
  • Associate operations with their logical task -
    the parties may be performing multiple such tasks
    at the same time
  • Agree on the outcome of the computation

46
WS-Coordination
  • General mechanism for starting and agreeing on
    the outcome of multi-party, multi-message WS
    tasks
  • Coordination context is a message element that
    flows on all messages that Web Services exchange
    during the computation
  • The coordination context contains the
    WS-Addressing endpoint reference to the
    coordination service and the endpoint contains
    information to identify the specific task being
    coordinated

47
Coordination Service
  • Starts a coordinated task, terminates a
    coordinated task, allows a participant to
    register in a task, and produces a coordination
    context that is part of all messages within a
    group
  • Includes an interface that participating services
    use in order to be informed of the outcome of the
    coordinated task

48
(No Transcript)
49
WS-AtomicTransaction
  • Defines a specific set of protocols that plug
    into WS-Coordination to implement traditional
    atomic transactions
  • For activities that require the traditional
    atomic, consistent, isolated and durable (ACID)
    properties
  • Usually short-lived

50
Business Activities
  • May consume many resources over a long duration
  • May involve a significant number of atomic
    transactions
  • Individual tasks within a business activity can
    be seen prior to the completion of the business
    activity - their results may have an impact
    outside of the computer system
  • Responding to a request may take a very long time
    - human approval, assembly, manufacturing or
    delivery may have to take place before a response
    can be sent
  • In the case where a business exception requires
    an activity to be logically undone, transactional
    abort is typically impractical or impossible
  • Exception handling mechanisms may require
    business logic, e.g., in the form of a
    compensation task, to reverse the effects of a
    completed business task

51
WS-BusinessActivity
  • Another set of protocols that plug into
    WS-Coordination, to coordinate activities that
    apply business logic to handle business
    exceptions
  • Actions are applied immediately and are permanent
  • Compensating actions may be invoked in the event
    of an error
  • Enables existing business process and workflow
    systems to wrap their proprietary mechanisms and
    interoperate across trust boundaries and
    different vendor implementations

52
And many more
53
(No Transcript)
54
Summary
  • WS- specs add orthogonal features to SOAP
    headers
  • Implement a component model framework focused
    primarily on security, reliability and fault
    tolerance
  • Ease development of inter-organizational
    applications (as opposed to the
    intra-organizational applications targeted by
    most other component frameworks)

55
Contrast REST with Web Services
  • Web services based conceptually on
    service-oriented architecture (SOA), whose
    distributed objects predate the web (e.g., CORBA,
    DCOM)
  • SOA computation proceeds through connections
    between independent services communicating via
    rpc (e.g., SOAP over HTTP)
  • SOAs rich collection of methods (the services)
    with relatively limited parameter passing vs.
    RESTs small number of methods (HTTP) with rich
    parameter passing (web pages, form data)

56
Next Assignment Midterm Paper
  • Each paper must have a title, an author (with
    contact information), a brief abstract (about 100
    words), an introductory section, some number of
    body sections (3-5 is typical), a concluding
    section, and a bibliographic list of references
    most of which are cited somewhere in the paper
  • Do not simply survey some topic  Instead compare
    this to that, argue a position in favor or
    against something, evaluate something according
    to some meaningful criteria, etc. 
  • Pretend your reader will be another member of the
    class, who has heard all the same lectures you
    have/will, but may not know anything at all about
    the specifics of your particular topic

57
Midterm Paper Academic Honesty
  • All copied material must be short and must be
    explicitly quoted and cited
  • Non-copied material based conceptually on
    references must also be cited do not
    paraphrase, write in your own words
  • Example
  • If you dont like the Android phones on the
    market, just wait a minute. 1
  • 1 David Pogue, Android Phones Take a Power
    Trip,The New York Times, online edition, February
    8, 2012, http//www.nytimes.com/2012/02/09/technol
    ogy/personaltech/android-phones-go-on-a-power-trip
    -state-of-the-art.html

58
Midterm Paper Logistics
  • Due Tuesday February 28th by 10am
  • Approximately 15 pages (not including figures and
    reference list)
  • Submit by posting in Full Papers folder on
    CourseWorks
  • Must be in a format I can read, and the filename
    must adhere to the required naming convention
    (e.g., Full_Paper_Jane_Doe.pdf).

59
Upcoming Assignments
  • Full paper due Tuesday February 28th
  • Project proposal due Tuesday March 6th
  • Presentation proposal also due Tuesday March 6th

60
COMS E6125 Web-enHanced Information Management
(WHIM)
  • Prof. Gail Kaiser
  • Spring 2012
View by Category
About This Presentation
Title:

COMS E6125 Web-enHanced Information Management (WHIM)

Description:

COMS E6125 Web-enHanced Information Management (WHIM) ... Once a Web Service is deployed ... Example SOAP Fault Message Web Services Description Language ... – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 61
Provided by: GailK158
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: COMS E6125 Web-enHanced Information Management (WHIM)


1
COMS E6125 Web-enHanced Information Management
(WHIM)
  • Prof. Gail Kaiser
  • Spring 2012

2
Topics covered in this lecture
  • Introduction to Web Services
  • SOAP and WSDL
  • Web Services Component Model
  • WS- Specifications

3
What Are Web Services?
  • The Web infrastructure is increasingly used for
    application to application interaction (as
    opposed to human/browser to application
    interaction)
  • Any application that programmatically invokes
    computations via the Web infrastructure could be
    said to be using web services
  • But here the term is used to mean more explicit
    remote procedure (service) calls and messaging
  • Can vary in function from simple requests (e.g.,
    currency conversion or a weather report) to
    complex business systems that access and combine
    information from multiple sources

4
RPC vs. Messaging
  • Messaging has no notion of client and server -
    since a messaging framework concentrates on
    delivering a message, all nodes that accept and
    emit messages are considered equal in status and
    termed peers. RPC always has the concepts of
    client (caller) and server (callee).
  • Messaging is time-independent peers are not
    expected to accept the message in real time, the
    middleware takes care of delivering a message to
    the relevant peer when it is available. RPC,
    however, fails when one party goes down.
  • Messages can be duplicated and delivered to
    multiple peers quite easily. While RPC is
    essentially a one-with-one communication
    strategy, messaging is far more flexible and can
    deliver copies of the same message without any
    effort from the emitter.

5
Web Services Standards
  • Enable building Web-based applications using any
    platform, object model and programming language
  • Or add an Internet-capable interface to a legacy
    system
  • Allow any piece of software to communicate using
    a standardized XML messaging system (SOAP)
  • Once a Web Service is deployed with a machine
    readable interface (WSDL), other applications and
    Web Services can invoke that service

6
Example Web Service
  • http//www.webservicex.net/WS/WSDetails.aspx?WSID
    68CATID12

7
Steps to Creating and Using a Web Service
  1. Service provider creates a service or application
  2. Service provider defines a corresponding Web
    Service Description
  3. Service requester writes the code to access the
    Web Service, using the protocol and input/output
    parameters specified in its Web Service
    Description

8
Simple Object Access Protocol (SOAP)
  • Written in XML
  • Initially conceived as the minimal possible
    infrastructure necessary to perform RPC over the
    Web (predecessor XML-RPC)
  • Defines a mechanism to pass commands and
    parameters between clients and servers
  • Independent of the platform, object model and
    programming language
  • SOAP messages transported over HTTP are
    firewall-friendly and relatively easy to debug
    (XML text rather than binary stream)
  • But verbose and inefficient (i.e., slow) compared
    to alternative distributed computing
    infrastructures (e.g., CORBA IIOP, DCOM)

9
SOAP Message Structure
  • A message is seen as an envelope that contains
    the data to be sent ( control)
  • The envelope has two main parts, header
    (optional) and body (mandatory)
  • The header is for infrastructure level data and
    control
  • The body is for application level data

SOAP Envelope
SOAP Header
Header subelements
SOAP Body
Body subelements
10
SOAP Header
  • The header contains administrative and control
    information
  • Typical uses transaction identifiers, security
    certificates, processing instructions for
    intermediaries
  • Target of most WS- specifications

11
SOAP Body
  • The applications (sender and receiver) agree upon
    the method signatures
  • The body of the SOAP message contains the actual
    call the procedure name and the input parameters
  • The body of a response message contains the
    output parameters and optional result
    (analogous to return value)

12
SOAP Envelope Structure
  • ltenvEnvelope xmlnsenvhttp//schemas.xmlsoap.or
    g/soap/envelope/gt
  • ltenvHeadergt
  • lt!-- content of header goes here (optional)
    --gt
  • lt/envHeadergt
  • ltenvBodygt
  • lt!-- content of body goes here (mandatory)
    --gt
  • lt/envBodygt
  • lt/envEnvelopegt

XML namespace that defines SOAP tags
ltenvEnvelope xmlnsenvhttp//schemas.xmlsoap.or
g/soap/envelope/gt ltenvBodygt lteteTicket
xmlnsethttp//www.acme-travel.com/eticket/schem
agt ltetpassengerName firstJane
lastDoe/gt ltetflightInfo
airlineNameZZ
flightNumber9999
departureDate2011-09-21
departureTime1234/gt lt/eteTicketgt
lt/envBodygt lt/envEnvelopegt
The XML schema that defines the travel
application types
13
SOAP Request Example
POST /travelservice HTTP/1.1 Content-Type
application/soapxml charsetutf-8 Content-Leng
th nnnn ltenvEnvelope xmlnsenvhttp//schemas.
xmlsoap.org/soap/envelope/gt ltenvBodygt
ltmGetFlightInfo xmlnsmhttp//www.acme-travel.c
om/flightinfo envencodingStylehttp//sch
emas.xmlsoap.org/soap/encoding/
xmlnsxsdhttp//www.w3.org/2001/XMLSchema
xmlnsxsihttp//www.w3.org/2001/XMLSchema-insta
ncegt ltairlineName xsitypexsdstringgtZZlt
/airlineNamegt ltflightNumber
xsitypexsdintgt9999lt/flightNumbergt
lt/mGetFlightInfogt lt/envBodygt lt/envEnvelopegt
14
SOAP Response Example
HTTP/1.1 200 OK Content-Type application/soapxml
charsetutf-8 Content-Length
nnnn ltenvEnvelope xmlnsenvhttp//schemas.xmls
oap.org/soap/envelope/gt ltenvBodygt
ltmGetFlightInfoResponse xmlnsmhttp//www
.acme-travel.com/flightinfo
envencodingStylehttp//schemas.xmlsoap.org/soap
/encoding/ xmlnsxsdhttp//www.w3.org/200
1/XMLSchema xmlnsxsihttp//www.w3.org/20
01/XMLSchema-instancegt ltflightInfogt
ltgate xsitypexsdintgt1337lt/gategt
ltstatus xsitypexsdstringgtON TIMElt/statusgt
lt/flightInfogt lt/mGetFlightInfoResponsegt
lt/envBodygt lt/envEnvelopegt
15
SOAP Fault Message
  • In the case of failure, the contents of the SOAP
    response envelope will generally be a Fault
    message, along the lines of

ltenvBodygt ltenvFaultgt ltenvCodegt
ltenvValuegtenvSenderlt/envValuegt
ltenvSubcodegt ltenvValuegtrpcBadArgumentslt/envVal
uegt lt/envSubcodegt lt/envCodegt
ltenvReasongt ltenvText xmllang"en-US"gtPro
cessing errorlt/envTextgt lt/envReasongt
ltenvDetailgt lt/envDetailgt lt/envFaultgt
lt/envBodygt
16
Web Services Description Language (WSDL)
  • Written in XML
  • Used to define an individual Web service
  • The operations offered by the service (what)
  • The mechanisms to access the service (how)
  • The location at which the service is made
    available (where)
  • Analogous to interfaces
  • Often used to generate parts of the client
    (requester) and server (provider) code

17
WSDL Structure
  • Abstract part operations, messages sent and
    received as operation inputs and outputs, types
    of data to be exchanged
  • Concrete part binding to transport and wire
    format details that users must follow to access
    the service, endpoint network address

WSDL specification
abstract part
types
messages
port types operations
concrete part
bindings
ltdefinitions nameServiceNamegt lttypesgt data
types used... lt/typesgt ltmessagegt parameters
used... lt/messagegt ltportTypegt set of
operations performed... lt/portTypegt ltbindinggt
communication protocols and data formats used...
lt/bindinggt ltservicegt set of ports to service
provider endpoints lt/servicegt lt/definitionsgt
services ports
18
WSDL Types
  • lttypesgt element defines the data types that are
    used by the web service and exchanged in messages
  • Uses XML Schema syntax to define data types

lttypesgt ltcomplexType name"CompanyInfo"/gt
ltelement name"CompanyName" type"xsdstring"/gt
ltelement name"Address" type"xsdstring"/gt
lt/complexTypegt ltcomplexType name"ReimbursementR
equest"/gt ltelement name"amount"
type"xsdfloat"/gt ltelement name"date"
type"xsdstring"/gt lt/complexTypegt ... lt/typesgt
19
WSDL Messages
  • ltmessagegt element defines the operation signature
  • Each message can consist of one or more parts and
    zero or more attachments
  • Each part must have a name and a type
  • The parts and attachments are analogous to the
    parameters of a function call in a traditional
    programming language

lttypesgt ... lt/typesgt ltmessage name"Reimbursement
RequestInput"gt ltpart name"employeeId"
type"xsdstring"/gt ltpart name"info"
type"ReimbursementRequest"/gt ltattachment
name"hotelReceipt" uri"uri to image of hotel
receipt"/gt ltattachment name"carRentalReceipt"
uri"uri to image of rental car
receipt"/gt lt/messagegt
20
WSDL Port Types
  • ltportTypegt element defines the actual operations
    that can be performed and the messages
    (parameters) that are involved
  • Can be compared to a function library (or a
    module or a class) in a traditional programming
    language

ltportType nameanynamegt ltoperation
name"Reimburse"gt ltinput message"ReimbursementRe
questInput"/gt lt/operationgt ltoperationgt ...
lt/operationgt ltoperationgt ... lt/operationgt
ltoperationgt ... lt/operationgt ... lt/portTypegt
21
Types of Port Operations
  • Syntactically, an operation is a combination of
    input and output (and fault) messages indicating
    what role a message plays in the interaction
  • Each operation represents a message exchange
    pattern supported by the Web Service
  • A service requester's behavior in the transient
    period between two related messages defines the
    synchronous/asynchronous behavior in the client
    API.
  • In the synchronous case, invocation at the client
    API would block, and wait until the related
    message arrives at the destination.
  • In the asynchronous case, the client invocation
    continues without blocking, and when a related
    message arrives, it is correlated with earlier
    messages.

22
Message Exchange Patterns
  • One-way (in-only, fire and forget) The operation
    can receive a message but will not return a
    response (asynchronous)
  • Notification The operation can send a message
    but will not wait for a response (asynchronous)
  • Request-response (in-out, rpc) The operation can
    receive a request and will return a response
    (synchronous)
  • Solicit-response The operation can send a
    request and will wait for a response (synchronous)

23
WSDL Concrete Elements
  • Binding the interface to a transport protocol -
    What communication protocol to use to transport
    service requests and responses (e.g., SOAP over
    HTTP, HTTPS, SMTP, JMS)
  • The service as a collection of all bindings of
    the same interface - How to accomplish individual
    service interactions over this protocol (the
    interface in all its available implementations)
  • The endpoint or network address (port) of the
    binding - Where to terminate communication (i.e.,
    the network address of the service provider)

24
Example SOAP Binding
  • ltbinding nameAirportServiceSoapBinding
    typetnsAirportServicePortTypegt
  • ltsoapbinding transporthttp//schemas.xmlsoap.
    org/soap/http/gt
  • ltoperation nameGetFlightInfogt
  • ltsoapoperation stylerpc
    soapActionhttp//acme-travel/flightinfo/gt
  • ltinputgt
  • ltsoapbody useencoded namespacehttp//a
    cme-travel.com/flightinfo
    encodingStylehttp//schemas.xmlsoap.org/soap/enc
    oding//gt
  • lt/inputgt
  • ltoutputgt
  • ltsoapbody useencoded namespacehttp//a
    cme-travel.com/flightinfo
    encodingStylehttp//schemas.xmlsoap.org/soap/enc
    oding//gt
  • lt/outputgt
  • lt/operationgt
  • ltoperation nameCheckIngt
  • ltsoapoperation styledocument
    soapActionhttp//acme-travel.com/checkin/gt
  • ltinputgt
  • ltsoapbody useliteral/gt
  • lt/inputgt
  • lt/operationgt

ltservice nametravelservicegt ltport
nametravelservicePort bindingtnsAirportServi
ceSoapBindinggt ltsoapaddress
locationhttp//acmetravel.com/travelservice/gt
lt/portgt lt/servicegt
25
So Now We Have Web Services
  • Web Services distributed applications, services
    and components, described using XML-encoded WSDL
    interfaces, that process XML-encoded SOAP
    messages
  • XML, SOAP and WSDL constitute baseline
    specifications that provide a foundation for
    application integration

26
Example Web Service
  • http//www.webservicex.net/WS/WSDetails.aspx?WSID
    68CATID12

27
But
  • Additional standards beyond this baseline become
    necessary as WS applications become more complex,
    integrating multiple components across multiple
    organizations
  • Otherwise, WS developers are compelled to
    implement higher-level functionality in
    proprietary and often non-interoperable ways

28
Composable Services
  • Specialized Web Service specifications that are
    independent but can be combined
  • For example, it is possible to independently add
    transaction identifiers and reliable messaging
    sequence numbers
  • The two extensions do not conflict with each
    other and are compatible with pre-existing
    message structures
  • Developers and providers can integrate selected
    specifications that fulfill the requirements of
    their communicating processes

29
SOAP Inherently Supports Composition
  • SOAP uses a regular, multi-part message
    structure New message elements supporting new
    services may be added to message headers in a
    manner that does not alter the processing of
    existing functionality
  • SOAP body is for the ultimate recipient, SOAP
    header blocks may be targeted at any entity along
    the message path

30
(No Transcript)
31
Addressing
  • Messages and responses both go somewhere and come
    from somewhere (and errors also need to be
    reported somewhere)
  • By default, SOAP encodes the destination for a
    message with a URL placed in the HTTP transport
  • The destination for the response is determined by
    the HTTP return address
  • Builds on the basic browser-server model

32
Addressing
  • The source and destination information are not
    part of the message itself
  • But information can be lost if a transport
    connection terminates (e.g., if the response
    takes a long time and the connection times out)
  • Or if the message is forwarded by an
    intermediary, perhaps routed over multiple
    transports
  • Also does not allow for directing a response to a
    third party (e.g., request sent over HTTP but
    returned via SMTP)

33
WS-Addressing
  • Provides a mechanism to place the target, source
    and other addressing information directly within
    the message
  • Decouples address information from any specific
    transport model
  • Supports asynchronous communication patterns,
    both short and extended duration
  • Across multiple endpoint references
  • Does not match very well the request/response
    model over a single HTTP connection (see blog
    entry), more applicable to other transports
  • That is, messaging rather than RPC

34
Message Addressing Properties
  • To -- message destination
  • Action -- an action value indicating the
    semantics of the message, corresponds to WSDL
    porttype
  • From -- the endpoint of the service that
    dispatched this message
  • ReplyTo -- the endpoint to which reply messages
    should be dispatched
  • FaultTo -- the endpoint to which fault messages
    should be dispatched
  • Unique MessageId, required if there will be any
    response
  • RelatesTo previous messages (indicating previous
    From and MessageId)

35
(No Transcript)
36
Security Requirements
  • A sends a message to service B
  • B partially processes the message and forwards it
    to service C
  • HTTPS allows authentication, integrity and
    confidentiality between A-B and B-C
  • However, C and A cannot authenticate each other,
    or hide information from B
  • For A, B and C to use userid/password for
    authentication, they must share the same
    replicated user and password information
  • Instead need end to end security

37
WS-Security
  • Defines mechanisms for associating security
    related claims with a message
  • Signed, encrypted security tokens
  • Username/password (BASIC-Auth)
  • x509 certificates (public key infrastructure)
  • Kerberos tickets (secret key)
  • XrML eXtensible rights Markup Language (digital
    property rights)
  • SAML Security Assertion Markup Language (single
    sign-on)

38
WS-Security
  • A can generate a token that C can verify as
    having come from A, B cannot forge the token
  • A can sign selected elements or the entire
    message, this allows B and C to confirm that the
    message has not changed since A sent it
  • A can seal the message or selected elements, this
    ensures that only the intended service for those
    elements can use the information - prevents B
    from seeing information intended for C and vice
    versa

39
(No Transcript)
40
Reliable Messaging
  • In an Internet world, almost all communication
    channels are unreliable - messages disappear or
    are duplicated, connections break
  • Without a reliable messaging standard, WS
    application developers must build these functions
    into their applications
  • The basic approaches and techniques are well
    understood, e.g., many middleware systems ensure
    messages have unique identifiers, provide
    sequence numbers, and retransmit when messages
    are lost
  • If WS developers implement these models in their
    applications, they may make incompatible
    assumptions or design choices, resulting in
    little if any reliable messaging

41
WS-ReliableMessaging
  • Defines mechanisms that enable Web Services to
    ensure delivery of messages over unreliable
    communication networks
  • Supports bridging multiple different
    infrastructures into a single, logically
    complete, end-to-end model

42
WS-ReliableMessaging
  • The RM Source MUST assign each reliable message a
    sequence number beginning at 1 and increasing by
    exactly 1 for each subsequent reliable message
  • Every acknowledgement issued by the RM
    Destination MUST include within that
    acknowledgement the range or ranges of the
    sequence numbers of every message successfully
    received and MUST exclude sequence numbers of any
    messages not yet received

43
WS-ReliableMessaging
  • Delivery Assurances AtMostOnce, AtLeastOnce,
    ExactlyOnce, InOrder
  • Protocol Elements Sequence, Sequence
    Acknowledgement, Request Acknowledgement,
    Sequence Creation, Sequence Termination
  • Policy Assertions SequenceCreation,
    SequenceExpiration, InactivityTimeout,
    RetransmissionInterval, AcknowledgementInterval

44
(No Transcript)
45
Transactions
  • A complex business scenario may require multiple
    parties to exchange multiple sets of messages
  • The multiple messages exchanged between
    participants constitute a logical "task" or
    "objective"
  • The parties must be able to
  • Start new coordinated tasks.
  • Associate operations with their logical task -
    the parties may be performing multiple such tasks
    at the same time
  • Agree on the outcome of the computation

46
WS-Coordination
  • General mechanism for starting and agreeing on
    the outcome of multi-party, multi-message WS
    tasks
  • Coordination context is a message element that
    flows on all messages that Web Services exchange
    during the computation
  • The coordination context contains the
    WS-Addressing endpoint reference to the
    coordination service and the endpoint contains
    information to identify the specific task being
    coordinated

47
Coordination Service
  • Starts a coordinated task, terminates a
    coordinated task, allows a participant to
    register in a task, and produces a coordination
    context that is part of all messages within a
    group
  • Includes an interface that participating services
    use in order to be informed of the outcome of the
    coordinated task

48
(No Transcript)
49
WS-AtomicTransaction
  • Defines a specific set of protocols that plug
    into WS-Coordination to implement traditional
    atomic transactions
  • For activities that require the traditional
    atomic, consistent, isolated and durable (ACID)
    properties
  • Usually short-lived

50
Business Activities
  • May consume many resources over a long duration
  • May involve a significant number of atomic
    transactions
  • Individual tasks within a business activity can
    be seen prior to the completion of the business
    activity - their results may have an impact
    outside of the computer system
  • Responding to a request may take a very long time
    - human approval, assembly, manufacturing or
    delivery may have to take place before a response
    can be sent
  • In the case where a business exception requires
    an activity to be logically undone, transactional
    abort is typically impractical or impossible
  • Exception handling mechanisms may require
    business logic, e.g., in the form of a
    compensation task, to reverse the effects of a
    completed business task

51
WS-BusinessActivity
  • Another set of protocols that plug into
    WS-Coordination, to coordinate activities that
    apply business logic to handle business
    exceptions
  • Actions are applied immediately and are permanent
  • Compensating actions may be invoked in the event
    of an error
  • Enables existing business process and workflow
    systems to wrap their proprietary mechanisms and
    interoperate across trust boundaries and
    different vendor implementations

52
And many more
53
(No Transcript)
54
Summary
  • WS- specs add orthogonal features to SOAP
    headers
  • Implement a component model framework focused
    primarily on security, reliability and fault
    tolerance
  • Ease development of inter-organizational
    applications (as opposed to the
    intra-organizational applications targeted by
    most other component frameworks)

55
Contrast REST with Web Services
  • Web services based conceptually on
    service-oriented architecture (SOA), whose
    distributed objects predate the web (e.g., CORBA,
    DCOM)
  • SOA computation proceeds through connections
    between independent services communicating via
    rpc (e.g., SOAP over HTTP)
  • SOAs rich collection of methods (the services)
    with relatively limited parameter passing vs.
    RESTs small number of methods (HTTP) with rich
    parameter passing (web pages, form data)

56
Next Assignment Midterm Paper
  • Each paper must have a title, an author (with
    contact information), a brief abstract (about 100
    words), an introductory section, some number of
    body sections (3-5 is typical), a concluding
    section, and a bibliographic list of references
    most of which are cited somewhere in the paper
  • Do not simply survey some topic  Instead compare
    this to that, argue a position in favor or
    against something, evaluate something according
    to some meaningful criteria, etc. 
  • Pretend your reader will be another member of the
    class, who has heard all the same lectures you
    have/will, but may not know anything at all about
    the specifics of your particular topic

57
Midterm Paper Academic Honesty
  • All copied material must be short and must be
    explicitly quoted and cited
  • Non-copied material based conceptually on
    references must also be cited do not
    paraphrase, write in your own words
  • Example
  • If you dont like the Android phones on the
    market, just wait a minute. 1
  • 1 David Pogue, Android Phones Take a Power
    Trip,The New York Times, online edition, February
    8, 2012, http//www.nytimes.com/2012/02/09/technol
    ogy/personaltech/android-phones-go-on-a-power-trip
    -state-of-the-art.html

58
Midterm Paper Logistics
  • Due Tuesday February 28th by 10am
  • Approximately 15 pages (not including figures and
    reference list)
  • Submit by posting in Full Papers folder on
    CourseWorks
  • Must be in a format I can read, and the filename
    must adhere to the required naming convention
    (e.g., Full_Paper_Jane_Doe.pdf).

59
Upcoming Assignments
  • Full paper due Tuesday February 28th
  • Project proposal due Tuesday March 6th
  • Presentation proposal also due Tuesday March 6th

60
COMS E6125 Web-enHanced Information Management
(WHIM)
  • Prof. Gail Kaiser
  • Spring 2012
About PowerShow.com