02 october 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

02 October 2007 Kaiser: COMS W4156 Fall 2007 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



What are Web Services?

• The Web infrastructure is increasingly used for application to application interaction (as opposed to human/browser 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

Important note: Just because its accessible via the Web (e.g., http) and it’s a service does not make it a Web Service


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

• Also a “discovery” mechanism (UDDI)


Example Web Service

http://www.webservicex.net/WS/WSDetails.aspx?WSID=68&CATID=12




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. [Sometimes] “Service discovery”– Means of finding web services


Steps to Creating and Using a Web Service

1. Service provider creates a service or application2. Service provider defines a corresponding Web Service

Description (and possibly registers it with an Internet registry)

3. Service requester is informed of the Web Service Description (or possibly searches a registry and finds a corresponding Web Service)

4. Service requester writes the client to access the Web Service, using the protocol and input/output parameters specified in its Web Service Description


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


WSDL = Web Services Description Language

• 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)– Often used to generate parts of the client and server code

• W3C standard – WSDL 1.1 “Note” March 2001– WSDL 2.0 “Recommendation” June 2007 (many changes

analogous to EJB 2.1->3.0)


WSDL• Metadata language of Web Services• For writing the “user’s manual” for Web Services, defining how

service providers and requesters communicate with each other

• Extensible to allow the description of endpoints and their messages, regardless of what message formats or network protocols are used for communicating

• Can be used to design specifications to invoke and operate Web Services on the Internet and to access and invoke remote applications and databases

• If you want to create an application that communicates with a particular Web Service, in principle all you need is that service's WSDL file (although would also be nice to know what the Web Service does - there’s an optional wsdl:document element for human readable documentation)


WSDL (1.1) 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>


WSDL Types

• <types> element defines the data types that are used by the web service and exchanged in messages

• By default 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 the 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>


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

• 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)

• 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

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken">

<wsdl:input name="nmtoken"? message="qname"/>

</wsdl:operation> </wsdl:portType > </wsdl:definitions>

• The input element specifies the abstract message format for the one-way operation


Notification

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"?

message="qname"/> </wsdl:operation>

</wsdl:portType > </wsdl:definitions> • The output element specifies the abstract

message format for the notification operation


Request-Response<wsdl:definitions ... ><wsdl:portType ... > *

<wsdl:operation name="nmtoken" parameterOrder="nmtokens">


<wsdl:output name="nmtoken"? message="qname"/>

<wsdl:fault name="nmtoken" message="qname"/>*

</wsdl:operation> </wsdl:portType></wsdl:definitions> • The input and output elements specify the abstract message format

for the request and response, respectively• The optional fault elements specify the abstract message format for

any error messages that may be output as the result of the operation


Solicit-Response<wsdl:definitions ... ><wsdl:portType ... > *

<wsdl:operation name="nmtoken" parameterOrder="nmtokens">

<wsdl:output name="nmtoken"? message="qname"/>


<wsdl:fault name="nmtoken" message="qname"/>*

</wsdl:operation> </wsdl:portType></wsdl:definitions>

• The output and input elements specify the abstract message format for the solicited request and response, respectively

• The optional fault elements specify the abstract message format for any error messages that may be output as the result of the operation


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>


WSDL Example







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 or HTTPS)

• 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)


SOAP

• Written in XML• Originally conceived as the minimal possible

infrastructure necessary to perform RPC over the Internet – Predecessor XML-RPC ~1998– 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)• W3C standard

– SOAP 1.1 “Note” May 2000 Simple Object Access Protocol– SOAP 1.2 “Recommendation” June 2003 renamed Service

Oriented Architecture Protocol, revised April 2007


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


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

HTTP POST

SOAP Envelope

SOAP Call SOAP Header

SOAP Body

Body subelements

Header subelements


Request Example

POST /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>


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


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>…


The SOAP Header

• The header is the holder of administrative and control information

• Typical uses: transaction identifiers, security certificates


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)


SOAP Document Interaction Style

• The applications 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>2007-01-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-09-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-09-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>2007-01-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>


SOAP RPC Interaction Style

• The applications 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>2008-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>


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)


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)


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, SMTP• operation element defines each operation that the

port exposes– For each operation the corresponding SOAP action has to

be defined– Also specify whether the input and output are “encoded”

(give URI for abstract type definitions) or "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>


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 a standard from OASIS (Organization for the Advancement of Structured Information Standards), not W3C


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


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=““>[email protected]</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>


Registries

• Several UDDI registries are promoted by industry organizations and companies

• Large portion of registered services are experimental (“hello-world”)

• Some registries:– webserviceX.NET [www.webservicex.net]– Web Service List [www.webservicelist.com] – WSIndex [www.wsindex.org] – RemoteMethods [www.remotemethods.com]

http://www.webservicex.net/WCF/default.aspx



http://www.webservicelist.com/



http://www.wsindex.org/




http://www.remotemethods.com/





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

• Mostly used within intranets (within a company) to dynamically bind client systems to implementations


Another Web Service Example

• http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=22

http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=22

http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=22


Benefits: Interoperable

• Can operate on the “system boundaries”, outside of private company networks

• Developers can use their own programming language, component object model, architecture, and implementation strategy

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


Benefits: Ease of Development

• Business logic of individual systems can be exposed over the Web

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


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


Benefits: Consumable by Humans and Computers

• By humans, for example, through a desktop application

• By computers, for example, through an API


Benefits: Ubiquitous

• Accessible from anywhere and use existing infrastructure

• Respect existing security systems such as firewalls


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


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


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>


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


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.)


So Now We Have Web Services

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

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


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


Revised Project ConceptDue Next Week!

• Tuesday 9 October, 10am

• Assignments posted on course website

• Submit via CourseWorks

• Revised Project Concept

http://york.cs.columbia.edu/classes/cs4156/assignments.htm

https://courseworks.columbia.edu/

http://york.cs.columbia.edu/classes/cs4156/homeworks/revisedconcept.htm


Upcoming Deadlines

• First iteration plan due October 16th • First iteration progress report due October 23rd • First iteration demo week October 30th –

November 8th • First iteration final report due November 9th

http://york.cs.columbia.edu/classes/cs4156/homeworks/firstplan.htm


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


02 october 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

Documents

web service implements

web service descriptionkaiser

web serviceskaiser

web infrastructure

web servicekaiser

web services standardsenable

web serviceservice provider

webbased applications