20 March 2007 COMS E6125 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 2007Spring 2007

20 March 2007 COMS E6125 2

Today’s Topic• Introduction to Web Services• WSDL (Web Services Description

Language)• SOAP (Simple Object Access

Protocol)• UDDI (Universal Description and

Discovery Protocol)

20 March 2007 COMS E6125 3

What are Web Services?

• The Web is more and more often used for application to application interaction

• Web Services are accessed through programmatic (machine-processable) interfaces

• 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

20 March 2007 COMS E6125 4

Web Services Standards

• Enable building Web-based applications using any platform, object model and programming language

• Allow any piece of software to communicate using a standardized XML messaging system (SOAP)

• Once a Web Service is deployed with a published interface (WSDL), other applications and Web Services can “discover” (UDDI) and invoke that service

20 March 2007 COMS E6125 5

Benefits: Interoperable• Can operate on the “system

boundaries”, outside of private company networks

• Applications and services developers build can enjoy a longer life span, outlasting proprietary equivalents

• Permit the use of a vast array of clients: Java, C++, .NET, JavaScript, Perl, etc.

20 March 2007 COMS E6125 6

Benefits: Ease of Use• Business logic of individual systems can

be exposed over the Web• Developers can use their own

programming language, component object model, architecture, and implementation strategy

• Functionality can be shared across the Web without knowledge of the target system’s environment

20 March 2007 COMS E6125 7

Benefits: Reusable• Component-based model of Web

Services enables to be reused whenever necessary

• Enable extension of existing code so that it can be exposed over the Internet

• Developers or business analysts can compose a custom, client-side solution to a particular business problem by combining Web Services

20 March 2007 COMS E6125 8

Benefits: Consumable by Humans and

Computers• By humans, for example, through

a desktop application• By computers, for example,

through an API

20 March 2007 COMS E6125 9

Benefits: Ubiquitous• Accessible from anywhere and use

existing infrastructure• Respect existing security systems

such as firewalls

20 March 2007 COMS E6125 10

Example Web Servicehttp://www.xmethods.com/ve2/ViewListing.po?key=uuid:477CEED8-1EDD-89FA-1070-6C2DBE1685F8

20 March 2007 COMS E6125 11

Example: Department Store Chain Enterprise Application Integration

• Background: The chain discovered that different credit approval applications had been developed in various parts of the company.

• Solution: The chain exposed one credit approval application as a Web Service. They linked this, in turn, to their point-of-sale, warehouse and financial applications.

20 March 2007 COMS E6125 12

Example: Department Store Chain Enterprise Application Integration

• Business Benefits: The chain was able to expose the new credit approval application and use it with the three distinct applications operating around the company. As a result:

• Credit approvals became more consistent • Maintenance costs decreased • Billing back to departments became more

efficient

20 March 2007 COMS E6125 13

Example: Car Rental Company

Interoperability with Key Partner

• Background: A major airline approached the car rental company about putting a link to the car reservation system on the airline’s website. Linking the two proprietary reservation systems presented an extreme challenge.

• Solution: The car rental company created a translation engine for sending data between the two systems.

20 March 2007 COMS E6125 14

Example: Car Rental Company

Interoperability with Key Partner

• Business Benefits: • Car rental company developed

another large sales channel • Solution got to market quickly

20 March 2007 COMS E6125 15

Example: Insurance Company

Interoperability across Several Companies

• Background: A large insurer needed to generate quotes for dental coverage and make them available on the intranet of one of their large corporate customers. But it had outsourced the maintenance of the dental providers directory and the credit rating service.

• Solution: The insurance company, credit rating service and dental provider orchestrated these applications to generate a quote that was requested by the customer on a corporate intranet.

20 March 2007 COMS E6125 16

Example: Insurance Company

Interoperability across Several Companies

• Business Benefits: The insurance company considered this a transformational competitive advantage for the following reasons:

• It generated quotes in half the time of its competitors and provided them via a corporate intranet to one of its major customers.

• It automated existing business relationships at the level of multiple, interoperating applications. As a result, outsourcing became much more valuable, cutting the cost of quote generation by one third.

• It increased profitability in a thin-margin business. • It provided a more seamless relationship with one of its

biggest customers.

20 March 2007 COMS E6125 17

Usage Scenario: Fire-and-Forget

• One way operation of a web service that has no guaranteed delivery semantics

• The input message received as part of such an operation MAY be lost

• Example: A metrics collection service exposes an operation to client applications to report their application usage metrics

• Loss of a message is not critical as the next update provides an updated summary

20 March 2007 COMS E6125 18

Usage Scenario:Guaranteed Delivery

• One way operation of a web service that has guaranteed delivery semantics

• The input operation received as part of such an operation MUST NOT be lost

• Example: A messaging service allows applications to publish messages to a logical messaging channel

• Publishing clients need to know that the message has been delivered

20 March 2007 COMS E6125 19

Usage Scenario: Document Centric

Computing• A web service that MAY include message parts

that are document attachments <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>

20 March 2007 COMS E6125 20

Usage Scenario: Request-Response

• Two parties wish to conduct electronic business by the exchange of business documents

• Sending party packages documents into a request message

• Receiving party then processes the message contents and responds to the sending party

• Need to correlate the request with the response • Examples: purchase orders with order

confirmations, manufacturing information with change control information, patient healthcare information with contractual acknowledgements

20 March 2007 COMS E6125 21

Usage Scenario: Event Notification

• An application subscribes to notifications of certain named events from an event source

• When such events occur, notifications are sent back to the originating application (first party notification) or to another application (third party notification)

• Example: subscribe to notification of various aspects of a printer's status (e.g., running out of paper, ink, etc.)

20 March 2007 COMS E6125 22

Three Parts to Web Services

1. “Wire” protocols– Data encodings, RPC calls or

document passing, etc.

2. Describing what goes on the wire– Schemas for the data

3. “Service discovery”– Means of finding web services

20 March 2007 COMS E6125 23

Steps to Creating and Using a Web Service

1. Service provider creates a service and registers it with an Internet registry

2. Web Service defined in the form of a Web Service Description

3. Service requester searches the registry and finds corresponding Web Service

4. Retrieves Description5. Service requester writes the client to access

the service, using the protocol and input/output parameters specified in description

20 March 2007 COMS E6125 24

Purposes of Web Service Description

• Defines a contract that the web service implements - the client exchanges messages based on this contract

• Used by tools to generate proper stubs - ensure that the stubs implement the expected behavior for the client

• Captures information that allows one to reason about them semantically

20 March 2007 COMS E6125 25

WSDL = Web Services Description Language

• Written in XML, that is, an XML document • 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)

• Not yet a W3C standard – WSDL 1.1 “Note” March 2001– WSDL 2.0 “Candidate Recommendation” March

2006

WSDL Structure• Abstract part: application-level

service description (types of data to be exchanged, operation interfaces, etc.)

• Concrete part: protocol-dependent details that users must follow to access the service

port types & operations

messages

types

abstract part

concrete part

bindings

services & ports

WSDL specification

<definitions name=“ServiceName”> <types> data types used... </types> <message> messages used... </message> <portType> operations performed...

</portType> <binding> communication protocols

used... </binding> <service> the service providers

</service> </definitions>

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>

WSDL Messages• <message> element defines the data elements

of an operation• 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 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>

WSDL Port Types• <portType> element defines the actual

service: the operations that can be performed and the messages 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>

20 March 2007 COMS E6125 30

Types of Port Operations

• Each operation represents a message exchange pattern the Web service supports

• Syntactically, operation is a combination of input and output or fault messages indicating what role a message plays in the interaction

• Request-response: 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)

• One-way: 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)

20 March 2007 COMS E6125 31

One-Way Operation<message name="newTermValues">

<part name="term" type="xs:string"/> <part name="value" type="xs:string"/>

</message><portType name="glossaryTerms">

<operation name="setTerm"> <input name="newTerm"

message="newTermValues"/> </operation> </portType >

20 March 2007 COMS E6125 32

Request-Response Operation

<message name="getTermRequest"> <part name="term" type="xs:string"/> </message>

<message name="getTermResponse"> <part name="value" type="xs:string"/> </message>

<portType name="glossaryTerms"><operation name="getTerm">

<input message="getTermRequest"/><output message="getTermResponse"/>

</operation> </portType>

WSDL Abstract Elements<definitions name=“NameofWebService”

add here XML namespaces fixsd and eticketnamespaces > <types> include here types used </types> <message name=“GetFlightInfoInput”> <part name=“airlineName” type=“xsd:string”/> <part name=“flightNumber” type=“xsd:int”/> </message> <message name=“GetFlightInfoOutput”> <part name=“flightInfo” type=“fixsd:FlightInfoType”/> </message> <message name=“CheckInInput”> <part name=“body” element=“eticketxsd:Ticket”/> </message> <portType name=“AirportServicePortType”> <operation name=“GetFlightInfo”> <input message=“tns:GetFlightInfoInput”/> <output message=“tns:GetFlightInfoOutput”/> </operation> <operation name=“CheckIn”><input message=“tns:CheckInInput”/> </operation> </portType></definitions>

20 March 2007 COMS E6125 34

WSDL Examplehttp://www.xmethods.net/sd/2001/TemperatureService.wsdl

20 March 2007 COMS E6125 35

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)

• The service as a collection of all bindings of the same interface - How to accomplish individual service interactions over this protocol (the interface in its all available implementations)

• The endpoint or network address of the binding - Where to terminate communication (i.e., the network address of the service provider)

20 March 2007 COMS E6125 36

SOAP = Simple Object Access Protocol

• Originally conceived as the minimal possible infrastructure necessary to perform RPC over the Internet

• XML-based protocol defines a mechanism to pass commands and parameters between clients and servers

• XML-based also means that SOAP messages transported over HTTP are firewall-friendly and relatively easy to debug

• Independent of the platform, object model and programming language

20 March 2007 COMS E6125 37

SOAP History• Initiated by Microsoft, IBM and friends• SOAP 1.0 was entirely based on HTTP• SOAP 1.1 (May 2000) added other transport

protocols (SMTP), never technically a standard• W3C formed the XML Protocol Working Group in

September 2000 to develop a formal SOAP standard

• SOAP 1.2 (June 2003) is a W3C Recommendation• Web Services Interoperability Organization (WS-I)

formed as an industry consortium in February 2002 “to Speed Development and Deployment of Web Services; Provide Support and Road Map for Developers and Customers”

20 March 2007 COMS E6125 38

SOAP Message• “A SOAP message is fundamentally a one-

way transmission between SOAP nodes, from a SOAP sender to a SOAP receiver, but SOAP messages are expected to be combined by applications to implement more complex interaction patterns ranging from request/response to multiple, back-and-forth "conversational" exchanges.” W3C SOAP 1.2

20 March 2007 COMS E6125 39

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

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 related names

<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=“John” last=“Doe”/> <et:flightInfo airlineName=“ZZ” flightNumber=“1111” departureDate=“2007-01-01” departureTime=“1234”/> </et:eTicket> </env:Body></env:Envelope>

The XML schema that defines the travel application types

POST /travelservice HTTP/1.1HOST: some.server.comContent-Type: application/soap+xml; charset=“utf-8”Content-Length: nnnn

<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=“Joe” last=“Smith”/> <et:flightInfo airlineName=“AA” flightNumber=“1111” departureDate=“2002-01-01” departureTime=“1905”/> </et:eTicket> </env:Body></env:Envelope>

HTTP POST

SOAP Envelope

SOAP CallSOAP Header

SOAP Body

Body subelements

Header subelements

20 March 2007 COMS E6125 42

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”>1111</flightNumber> </m:GetFlightInfo> </env:Body></env:Envelope>

20 March 2007 COMS E6125 43

Response ExampleHTTP/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”>10</gate> <status xsi:type=“xsd:string”>ON TIME</status> </flightInfo> </m:GetFlightInfoResponse> </env:Body></env:Envelope>

20 March 2007 COMS E6125 44

Fault Message• If failure, the contents of the SOAP

envelope will generally be a Fault message, along the lines of:

<env:Body> <env:Fault> <faultcode>env:Client</faultcode> <faultstring>Could not parse message</faultstring>…

20 March 2007 COMS E6125 45

The SOAP Header• The header is the holder of

administrative and control information• Typical uses: transaction identifiers,

security certificates

20 March 2007 COMS E6125 46

The SOAP Header• The SOAP role attribute specifies who should pay

attention to header entries: – none: propagate information, no need for processing– next: a node receiving the message can process that header

entry– ultimateReceiver: the header is intended for the final

recipient of the message– If a mustUnderstand flag is included, a node that matches the

specified role must process that part of the message, otherwise it must generate a fault and not forward the message any further

– SOAP 1.2 includes a relay attribute - if present, a node that does not process that part of the message must forward it (i.e., it cannot remove the part)

20 March 2007 COMS E6125 47

SOAP Document Interaction Style

• The apps agree upon the structure of the documents to be exchanged

• The body of the SOAP message contains a document

• For example to order goods, we send a PurchaseOrder document that contains subelements with product ID and quantity

• The response is also a document

Example Document-style

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation

xmlns:m="http://travelcompany.example.org/reservation"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Åke Jógvan Øyvind</n:name> </n:passenger> </env:Header> <-- cont. -->

Example Document-style

<env:Body> <p:itinerary

xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing><p:arriving>Los

Angeles</p:arriving> <p:departureDate>2007-03-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> <p:return> <p:departing>Los Angeles</p:departing><p:arriving>New

York</p:arriving> <p:departureDate>2007-03-21</p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p:seatPreference/> </p:return> </p:itinerary> <q:lodging

xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body></env:Envelope>

Document-style Response

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-

envelope"> <env:Header> <m:reservation

xmlns:m="http://travelcompany.example.org/reservation"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Åke Jógvan Øyvind</n:name> </n:passenger> </env:Header> <-- cont. -->

Document-style Response

<env:Body> <p:itineraryClarification

xmlns:p="http://travelcompany.example.org/reservation/travel">

<p:departure> <p:departing> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:departing> </p:departure> <p:return> <p:arriving> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:arriving> </p:return> </p:itineraryClarification> </env:Body></env:Envelope>

Response to Response<?xml version='1.0' ?><env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <-- as before --> </env:Header> <env:Body> <p:itinerary

xmlns:p="http://travelcompany.example.org/reservation/travel">

<p:departure> <p:departing>LGA</p:departing> </p:departure> <p:return> <p:arriving>EWR</p:arriving> </p:return> </p:itinerary> </env:Body></env:Envelope>

20 March 2007 COMS E6125 53

SOAP RPC Interaction Style

• The apps agree upon the method signatures as opposed to document structures

• 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

Example RPC-style <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction> </env:Header> <env:Body> <m:chargeReservation xmlns:m="http://travelcompany.example.org/" env:encodingStyle="http://www.w3.org/2003/05/soap-encoding“> <m:reservation

xmlns:m="http://travelcompany.example.org/reservation"> <m:code>FT35ZBQ</m:code> </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> <n:name xmlns:n="http://mycompany.example.com/employees">Åke

Jógvan Øyvind </n:name>

<o:number>123456789099999</o:number><o:expiration>2005-02</o:expiration>

</o:creditCard> </m:chargeReservation> </env:Body></env:Envelope>

RPC-style Response<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-

envelope" > <env:Header> <t:transaction

xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding"

env:mustUnderstand="true">5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse

env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/">

<m:code>FT35ZBQ</m:code> <m:viewAt>

http://travelcompany.example.org/reservations?code=FT35ZBQ

</m:viewAt> </m:chargeReservationResponse> </env:Body></env:Envelope>

RPC-style Response with return value

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction

xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true">5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse

xmlns:m="http://travelcompany.example.org/" env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc“> <rpc:result>m:status</rpc:result> <m:status>confirmed</m:status> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body></env:Envelope>

20 March 2007 COMS E6125 57

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)

• The service as a collection of all bindings of the same interface - How to accomplish individual service interactions over this protocol (the interface in its all available implementations)

• The endpoint or network address of the binding - Where to terminate communication (i.e., the network address of the service provider)

20 March 2007 COMS E6125 58

Binding, Service and Port Elements

• <binding> element defines the message format and protocol details for each port - how a given interaction occurs over the specified protocol– The communication protocol– The message encoding (literal or SOAP-encoding)– Interaction style (RCP-style or document-style) for all

operations/messages defined in a given portType• <service> element groups a set of port

elements• <port> element provides the “where”: a single

end point as a combination of a binding and a network address (URI)

20 March 2007 COMS E6125 59

Binding to SOAP• binding element has two attributes

– name attribute (any name you want) defines the name of the binding

– type attribute points to the port for the binding• soap:binding element has two attributes

– style attribute can be "rpc" or "document“– transport attribute defines the SOAP protocol to

use, e.g., HTTP• operation element defines each operation

that the port exposes– For each operation the corresponding SOAP action

has to be defined– Also specify how the input and output are encoded,

e.g., "literal“ (using XML Schema types)

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>

20 March 2007 COMS E6125 61

UDDI = Universal Description, Discovery and

Integration• Directory (or “registry”) for storing

information about web services• UDDI takes SOAP requests to add and

query web service interface data• UDDI 3.0.2 (October 2004) is an OASIS

(Organization for the Advancement of Structured Information Standards) standard, not W3C

20 March 2007 COMS E6125 62

UDDI = Universal Description, Discovery and

Integration• White-pages provide business contact

information• Yellow-pages categorize businesses and

services according to a taxonomy• Green-pages provide technical

information about the services that a business offers – how to interact with the services, business process definitions, pointers to WSDL files, unique ID for each service

20 March 2007 COMS E6125 63

UDDI Registry Structure

• An entry in an UDDI registry is an XML document with:– businessEntity: white-pages information– businessService: a list of all the Web services

offered by the business entity.– bindingTemplate: describes the technical aspects

of the service being offered.– tModel: (“technical model”) is a generic element

that can be used to store additional information about the service, typically additional technical information on how to use the service, conditions for use, guarantees, etc.

– publisherAssertion: describes relationship between businessEntities (e.g., department, division)

businessEntity Element<businessEntity businessKey=“A687FG00-56NM-EFT1-3456-

098765432124”> <name>Acme Travel Incorporated</name> <description xml:lang=“en”>Acme the best in online travel

services </description> <contacts> <contact useType=“US general”> <personName>Acme Inc.</personName> <phone>1 800 CALL ACME</phone> <email useType=““>acme@acme-travel.com</email> <address> <addressLine>Acme</addressLine> <addressLine>12 Maple Avenue</addressLine> <addressLine>Springfield, CT 06785</addressLine> </address> </contact> </contacts> <businessServices> ... </businessServices> <identifierBag> ... </identifierBag> <categoryBag> ... <keyedReference tModelKey=“UUID:DB77450D-9FA8-45D4-A7BC-

04411D14E384” keyName=“Electronic check-in” keyValue=“84121801”/> </categoryBag></businessEntity>

businessService Element

<businessService serviceKey=“894B5100-3AAF-11D5-80DC-002035229C64”

businessKey=“D2033110-3AAF-11D5-80DC-002035229C64”>

<name>ElectronicTravelService</name> <description xml:lang=“en”>Electronic Travel

Service</description> <bindingTemplates> <bindingTemplate bindingKey=“6D665B10-3AAF-11D5-80DC-

002035229C64” serviceKey=“89470B40-3AAF-11D5-80DC-

002035229C64”> <description> SOAP-based e-checkin and flight info </description> <accesssPoint URLType=“http”> http://www.acme-travel.com/travelservice </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey= “D2033110-3BGF-1KJH-234C-09873909802”> …</tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> <categoryBag> ... </categoryBag></businessService>

20 March 2007 COMS E6125 66

Registries• Several UDDI registries are promoted by industry

organizations and companies• Large portion of registered services are

experimental (“hello-world”)• Some registries:

– XMethods [www.xmethods.net] – Web Service List [www.webservicelist.com] – WSIndex [www.wsindex.org] – RemoteMethods [www.remotemethods.com]

20 March 2007 COMS E6125 67

UDDI in Perspective• Original idea was that registries

would just magically organize so that people could find anything they wanted

• Today UDDI is basically a catalog of services, which can be queried with standard APIs

20 March 2007 COMS E6125 68

Another Example• http://www.xmethods.com/ve2/Vie

wListing.po?key=uuid:396577C1-EE97-6A65-AC0B-307B2C6943FA

20 March 2007 COMS E6125 69

Example WSDL<definitions

name= "TemperatureConverterService"

<lots of namespace definitions>

…

20 March 2007 COMS E6125 70

Example WSDL… <message

name="InFahrenheitToCelsiusRequest"> <part name="tempFahrenheit"

type= "xsd:float"/> </message> <message

name="OutFahrenheitToCelsiusResponse"> <part name="tempCelsius"

type= "xsd:float"/> </message> …

20 March 2007 COMS E6125 71

Example WSDL… <portType

name= "TemperatureConverter_Service"> <operation name= "FahrenheitToCelsius">

<input message= "InFahrenheitToCelsiusRequest"/>

<output message= "OutFahrenheitToCelsiusResponse"/> </operation>

</portType> …

20 March 2007 COMS E6125 72

Example WSDL… <binding name=

"TemperatureConverter_ServiceBinding" type=“TemperatureConverter_Service“><soap:binding style="rpc"

transport= "http://schemas.xmlsoap.org/soap/http"/> …

20 March 2007 COMS E6125 73

Example WSDL… <operation name= "FahrenheitToCelsius">

<soap:operation soapAction= "urn:temperatureconverter-

service"/> <soap:body

encodingStyle= "http://schemas.xmlsoap.org/ soap/encoding/"

namespace= "urn:temperatureconverter- service"

use="encoded"/> …

20 March 2007 COMS E6125 74

Example WSDL… <service name= "TemperatureConverter_Service">

<port binding= "TemperatureConverter_ServiceBinding"

name= "TemperatureConverter_ServicePort"> <soap:address location= "http://localhost:8080/soap/servlet/rpcrouter/"/>

</port> </service> …

20 March 2007 COMS E6125 75

Then A Miracle Occurs

20 March 2007 COMS E6125 76

Example Java Servicepublic class TemperatureConverter {

public float FahrenheitToCelsius(

float tempFahrenheit) {

return

( tempFahrenheit - 32)*5/9;

} }

20 March 2007 COMS E6125 77

Example Java Clientpublic class TemperatureClient {

public static void main( String[] args ) throws Exception{ TemperatureConverter_ServiceProxy tempConv = new TemperatureConverter_ServiceProxy(); float tempFahrenheit = 100; System.out.println(

"The temperature in Fahrenheit is: " + tempFahrenheit ); float tempCelsius =

tempConv.FahrenheitToCelsius(tempFahrenheit); System.out.println(

"The temperature in Celsius is: " + tempCelsius ); } }

20 March 2007 COMS E6125 78

So Now We Have Web Services

• Web Services are built on XML, SOAP, WSDL and UDDI specifications

• These constitute a set of baseline specifications that provide the foundation for application integration and aggregation

20 March 2007 COMS E6125 79

But…• Additional standards beyond this

baseline become necessary as Web Service applications become more complex

• Web Service developers are compelled to implement higher-level functionality in proprietary and often non-interoperable ways

• Next time: WS-* set of specifications

20 March 2007 COMS E6125 80

Next Assignment: Detailed Project Plan

• Due Monday, March 26th, 5pm• Post on CourseWorks• Max 5 pages not including figures (there should

be figures!)• Please inform of any changes in team

composition• Include a brief “demo plan” (demos will be

approx. 15 minutes each during the period Monday April 16th – Monday April 30th)

• Respond to any concerns expressed in proposal feedback!

20 March 2007 COMS E6125 81

For System Building• Explain what exactly you plan for your system to "do".  • Describe for what prospective user community it is targeted

and what value it will provide to that community. • Sketch the top-level architecture of your project, indicating

each component that runs on a separate OS process or host.• Diagram and explain the communications flows between

these components, including protocols to be used and typical messaging sequences. (Include expected "error" cases.)

• Document any components or toolkits that you are not implementing yourself, but that are required for your application to operate - and then make sure you've found such components/toolkits that you can use and that work the way you think they do.

20 March 2007 COMS E6125 82

For System Evaluation• Explain what you plan to measure and how you will measure

it.  • Briefly define what qualities and quantities in particular that

you will compare/contrast or otherwise investigate, and discuss why these are significant or important for the relevant user community.

• Present the top-level architecture of those systems as they will operate during your experiments, but you do not need to document "internal" flows within the systems.  Make sure that you can indeed use and operate these systems.

• Discuss the design of your test application(s) and/or benchmark(s), and include in the architecture any addon drivers, scripts, etc. you plan to construct for your experiments along with the corresponding "external" communication flows.  

20 March 2007 COMS E6125 83

Reminders

• Detailed project plan due March 26th

• Project demos during period April 16th through April 30th, schedule with TA

• Final report due April 30th

• Presentations due April 9th through April 24th, seeking signups for April 17 and April 24 (April 10 “full”) – if planning to present outside of class, schedule with TA

20 March 2007 COMS E6125 84

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 2007Spring 2007