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