Upload
clinton-cox
View
219
Download
1
Tags:
Embed Size (px)
Citation preview
February 14, 2012 COMS 6125 1
COMS E6125 Web-COMS E6125 Web-enHanced Information enHanced Information Management (WHIM)Management (WHIM)
COMS E6125 Web-COMS E6125 Web-enHanced Information enHanced Information Management (WHIM)Management (WHIM)
Prof. Gail KaiserProf. Gail Kaiser
Spring 2012Spring 2012
February 14, 2012 COMS 6125 2
Topics covered in this lecture
• Introduction to Web Services• SOAP and WSDL• Web Services Component Model• WS-* Specifications
September 22, 2011 COMS W4156 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
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.
February 15, 2011 COMS 6125 4
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 6
Example Web Servicehttp://www.webservicex.net/WS/WSDetails.aspx?WSID=68&CATID=12
September 22, 2011 COMS W4156 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
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)
September 22, 2011 8COMS W4156
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 Header
SOAP Body
SOAP Envelope
Body subelements
Header subelements
September 22, 2011 9COMS W4156
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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)
SOAP Envelope Structure<env:Envelope
xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/”> <env:Header> <!-- content of header goes here (optional) --> </env:Header> <env:Body> <!-- content of body goes here (mandatory) --> </env:Body></env:Envelope>
XML namespace that defines SOAP tags
<env:Envelope xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/”> <env:Body> <et:eTicket xmlns:et=“http://www.acme-travel.com/eticket/schema”> <et:passengerName first=“Jane” last=“Doe”/> <et:flightInfo airlineName=“ZZ” flightNumber=“9999” departureDate=“2011-09-21” departureTime=“1234”/> </et:eTicket> </env:Body></env:Envelope>
The XML schema that defines the travel application types
September 22, 2011 12COMS W4156
September 22, 2011 COMS W4156 13
SOAP Request ExamplePOST /travelservice HTTP/1.1Content-Type: application/soap+xml; charset=“utf-8”Content-Length: nnnn
<env:Envelope xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/”> <env:Body> <m:GetFlightInfo xmlns:m=“http://www.acme-travel.com/flightinfo” env:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <airlineName xsi:type=“xsd:string”>ZZ</airlineName> <flightNumber xsi:type=“xsd:int”>9999</flightNumber> </m:GetFlightInfo> </env:Body></env:Envelope>
September 22, 2011 COMS W4156 14
SOAP Response Example
HTTP/1.1 200 OKContent-Type: application/soap+xml; charset=“utf-8”Content-Length: nnnn
<env:Envelope xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/”> <env:Body> <m:GetFlightInfoResponse xmlns:m=“http://www.acme-travel.com/flightinfo” env:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <flightInfo> <gate xsi:type=“xsd:int”>1337</gate> <status xsi:type=“xsd:string”>ON TIME</status> </flightInfo> </m:GetFlightInfoResponse> </env:Body></env:Envelope>
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:
<env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>rpc:BadArguments</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en-US">Processing error</env:Text> </env:Reason> <env:Detail> … </env:Detail> </env:Fault> </env:Body>
September 22, 2011 15COMS W4156
September 22, 2011 COMS W4156 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
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
port types & operations
messages
types
abstract part
concrete part
bindings
services & ports
WSDL specification
<definitions name=“ServiceName”> <types> data types used... </types> <message> parameters used... </message> <portType> set of operations performed...
</portType> <binding> communication protocols and data formats
used... </binding> <service> set of ports to service provider endpoints
</service> </definitions>
September 22, 2011 17COMS W4156
WSDL Types• <types> element defines the data types that are
used by the web service and exchanged in messages• Uses XML Schema syntax to define data types
<types> <complexType name="CompanyInfo"/> <element name="CompanyName" type="xsd:string"/> <element name="Address" type="xsd:string"/> </complexType>
<complexType name="ReimbursementRequest"/> <element name="amount" type="xsd:float"/> <element name="date" type="xsd:string"/> </complexType> ... </types>
September 22, 2011 18COMS W4156
WSDL Messages• <message> 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
<types> ... </types>
<message name="ReimbursementRequestInput"> <part name="employeeId" type="xsd:string"/> <part name="info" type="ReimbursementRequest"/> <attachment name="hotelReceipt"
uri="uri to image of hotel receipt"/> <attachment name="carRentalReceipt"
uri="uri to image of rental car receipt"/></message>
September 22, 2011 19COMS W4156
WSDL Port Types• <portType> 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
<portType name=“anyname”> <operation name="Reimburse">
<input message="ReimbursementRequestInput"/> </operation> <operation> ... </operation> <operation> ... </operation> <operation> ... </operation> ...</portType>
September 22, 2011 20COMS W4156
February 15, 2011 COMS 6125 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.
February 15, 2011 COMS 6125 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)
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)
September 22, 2011 23COMS W4156
Example SOAP Binding<binding name=“AirportServiceSoapBinding”
type=“tns:AirportServicePortType”> <soap:binding transport=“http://schemas.xmlsoap.org/soap/http”/>
<operation name=“GetFlightInfo”> <soap:operation style=“rpc”
soapAction=“http://acme-travel/flightinfo”/> <input> <soap:body use=“encoded”
namespace=“http://acme-travel.com/flightinfo” encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>
</input> <output> <soap:body use=“encoded”
namespace=“http://acme-travel.com/flightinfo” encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>
</output> </operation>
<operation name=“CheckIn”> <soap:operation style=“document” soapAction=“http://acme-
travel.com/checkin”/> <input> <soap:body use=“literal”/> </input> </operation></binding>
<service name=“travelservice”> <port name=“travelservicePort” binding=“tns:AirportServiceSoapBinding”> <soap:address location=“http://acmetravel.com/travelservice”/> </port></service>
24
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 26
Example Web Servicehttp://www.webservicex.net/WS/WSDetails.aspx?WSID=68&CATID=12
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 30
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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)
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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)
September 22, 2011 COMS W4156 35
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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)
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 39
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 44
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 48
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 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
September 22, 2011 COMS W4156 52
And many more…
September 22, 2011 COMS W4156 53
September 22, 2011 COMS W4156 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)
February 14, 2012 COMS 6125 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)
• SOA’s rich collection of methods (the services) with relatively limited parameter passing vs. REST’s small number of methods (HTTP) with rich parameter passing (web pages, form data)
7 February 2012 Kaiser: COMS E6125 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
7 February 2012 Kaiser: COMS E6125 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 don’t 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/technology/personaltech/android-phones-go-on-a-power-trip-state-of-the-art.html
7 February 2012 Kaiser: COMS E6125 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).
7 February 2012 Kaiser: COMS E6125 59
Upcoming Assignments• Full paper due Tuesday February 28th
• Project proposal due Tuesday March 6th
• Presentation proposal also due Tuesday March 6th
February 14, 2012 COMS 6125 60
COMS E6125 Web-COMS E6125 Web-enHanced Information enHanced Information Management (WHIM)Management (WHIM)
COMS E6125 Web-COMS E6125 Web-enHanced Information enHanced Information Management (WHIM)Management (WHIM)
Prof. Gail KaiserProf. Gail Kaiser
Spring 2012Spring 2012