05 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

05 October 2006 Kaiser: COMS W4156 Fall 2006 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 is more and more often used for application to application communication

• The programmatic interfaces made available are referred to as Web Services


Web Services Overview

• Web-based technology for exchanging information and invoking services

• Modular, self-describing, self-contained applications accessible over the Internet

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

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

• 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

• Once a Web Service is deployed, other applications and Web Services can “discover” and invoke that service


Example Web Service

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





Benefits: Interoperable

• By operating on the “system boundaries” (outside of private company networks), Web Services achieve a higher level of commonality than previously available

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

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


Benefits: Ease of Use

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

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

• 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


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


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


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.

• 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


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.

• Business Benefits: Car rental company developed another large sales channel – Solution got to market quickly


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.

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


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


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


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, that is, an XML document • Used to describe Web services • Also used to locate Web services • Still not a W3C standard

– WSDL 2.0 “Candidate Recommendation” dated March 2006

– WSDL 1.1 “Note” dated March 2001


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, all you (typically) need is that service's WSDL file


Elements and Structure

<definitions> <types> data types used... </types> <message> messages used... </message> <portType> operations performed... </portType> <binding> communication protocols used...

</binding> </definitions>


WSDL Types

• <types> element defines the data types that are used by the web service

• Uses XML Schema syntax to define data types


WSDL Messages

• <message> element defines the data elements of an operation

• Each message can consist of one or more parts

• The parts can be compared to the parameters of a function call in a traditional programming language


WSDL Ports

• <portType> element is the most important• Defines a web 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


Port Operation Types

• One-way: The operation can receive a message but will not return a response

• Request-response: The operation can receive a request and will return a response

• Solicit-response: The operation can send a request and will wait for a response

• Notification: The operation can send a message but will not wait for a response


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 >


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 Bindings

• <binding> element defines the message format and protocol details for each port


WSDL Example

http://www.xmethods.net/sd/2001/TemperatureService.wsdl




Lots of Acronyms

• Web Services Description Language (WSDL)

• Simple Object Access Protocol (SOAP)

• Universal Description, Discovery, and Integration (UDDI)


SOAP = Simple Object Access Protocol

• XML-based protocol for exchanging information in a decentralized, distributed environment

• Defines a mechanism to pass commands and parameters between clients and servers

• Independent of the platform, object model, and programming language


SOAP

• SOAP-based applications easier to debug, because easier to read XML text than a binary stream

• Text-based protocols like SOAP over HTTP are firewall-friendly

• SOAP 1.2 is W3C “Recommendation”, June 2003


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

• The soap:binding element has two attributes – style attribute can be "rpc" or "document“– transport attribute defines the SOAP protocol to use, e.g., HTTP

• The 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"


Binding Example

<binding type="glossaryTerms" name="b1"> <soap:binding style="document"

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

</binding> <operation>

<soap:operation soapAction="http://example.com/getTerm"> <input> <soap:body use="literal"/> </input><output> <soap:body use="literal"/> </output>

</operation>


UDDI = Universal Description, Discovery and

Integration• Directory (or “registry”) for storing

information about web services

• Directory of web service interfaces described by WSDL

• Communicates via SOAP


UDDI

• The data in a UDDI registry can be divided into three different types of “telephone directories”: – White-pages that provide business contact

information– Yellow-pages that categorize businesses and

services– Green-pages that provide technical information about

the services that a business offers


Before UDDI

• There was no Internet standard for businesses to reach their customers and partners with information about their products and services

• Nor was there a method of how to integrate into each other's systems and processes


UDDI Benefits

• Making it possible to discover the right business from the millions currently online

• Defining how to enable commerce once the preferred business is discovered

• Reaching new customers and increasing access to current customers


UDDI Benefits

• Expanding offerings and extending market reach • Solving customer-driven need to remove barriers

to allow for rapid participation in the global Internet economy

• Describing services and business processes programmatically in a single, open and secure environment


Another Example

• http://www.xmethods.com/ve2/ViewListing.po?key=uuid:396577C1-EE97-6A65-AC0B-307B2C6943FA

http://www.xmethods.com/ve2/ViewListing.po?key=uuid:396577C1-EE97-6A65-AC0B-307B2C6943FA




Example WSDL

<definitions

name= "TemperatureConverterService"

<lots of namespace definitions>

…


Example WSDL

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

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

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

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


Example WSDL

… <portType name= "TemperatureConverter_Service">

<operation name= "FahrenheitToCelsius"> <input message= "InFahrenheitToCelsiusRequest"/> <output message=

"OutFahrenheitToCelsiusResponse"/> </operation>

</portType> …


Example WSDL

… <binding name= "TemperatureConverter_ServiceBinding"

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

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


Example WSDL

… <operation name= "FahrenheitToCelsius"> <soap:operation

soapAction= "urn:temperatureconverterservice"/>

<soap:body encodingStyle=

"http://schemas.xmlsoap.org/ soap/encoding/" namespace= "urn:temperatureconverterservice"

use="encoded"/> …


Example WSDL

… <service name= "TemperatureConverter_Service"> <port binding= "TemperatureConverter_ServiceBinding"

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

</port> </service> …


Then A Miracle Occurs


Example Java Service

public class TemperatureConverter {

public float FahrenheitToCelsius(

float tempFahrenheit) {

return

( tempFahrenheit - 32)*5/9;

} }


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 ); } }


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


But…

• Additional standards beyond this baseline become necessary as WS applications become more complex

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


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.


Tier 1 -- Enterprise Application Integration

• Companies initially use Web Services to integrate internal applications

• Web Services allow them to expose legacy applications to business applications in heterogeneous environments without having to rewrite significant amounts of code


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.


Tier 2 -- Interoperability with Key Partners

• The next step is to integrate one or two key partners outside the company

• Web Services allow for interoperability between applications across the public Internet

• But companies must agree upon the technologies they will use to develop these interoperating Web Services


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.


Tier 3 -- Interoperability across Multiple Companies

• Companies want to extend their computing out to more partners and customers to build business ecosystems


Business Ecosystem


Business Ecosystem Requirements: Security

• The most common concern for companies implementing Web Services solutions

• Developers need an end-to-end security architecture that is straightforward to implement across companies and trust boundaries


Business Ecosystem Requirements: Routing

• Companies building Web Services solutions are concerned about the scalability and fault-tolerance of the business ecosystems they are building

• Developers need a way of specifying messaging paths and the ability to configure those message paths dynamically


Business Ecosystem Requirements:

Reliable Messaging• A key requirement for mission-critical

applications• Developers need an end-to-end guarantee of

message delivery across a range of semantics such as: – at-least-once– at-most-once– exactly once


Business Ecosystem Requirements: Transactions

• Require database-like transactions across companies

• ACID properties – atomic, consistent, isolated, durable

• But because of the nature of decentralized computing, developers need flexible process and compensation-based transaction schemes


A Solution?

• GXA = Global XML Web Services Architecture • Augments Web Services with generic higher-

level services like security, reliability, and transactions - which are required by many distributed applications and not specific to a particular domain

• Proposed by Microsoft and friends• Not (yet) a W3C activity


GXA


GXA Design Tenets: Modular

• Rather than define large, monolithic specifications that offer end-to-end functionality, GXA is built on modular components

• These can be composed into solutions to offer the exact set of features required by the problem at hand, neither omitting features nor burdening implementations with unnecessary ones

• As new or extended features or capabilities are required, new components can be created


GXA Design Tenets:General Purpose

• GXA is designed for a wide range of XML Web service scenarios, from B2B and EAI solutions to peer-to-peer applications and B2C services

• Each module is uniformly expressed whether used individually or in combination with others, and is independent of any limited application domain


GXA Design Tenets:Federated

• GXA does not require central servers or centralized administrative functions

• The architecture enables communication across trust boundaries and autonomous entities

• Neither the modules nor the protocols make any assumptions about the implementation technology at the message endpoints

• Any technology can be used; technologies can be transparently upgraded over time; services can be delegated or brought inside over time


GXA Design Tenets:Standards-Based

• GXA builds entirely on the baseline XML Web services specifications SOAP, WSDL, and UDDI

• Microsoft is committed to working with industry partners to standardize future specifications critical for Web services interoperability [and all the proposed specifications to date have authors from other companies as well as Microsoft]


[Some] GXA Specifications

• WS-Addressing*• WS-Policy*• WS-MetadataExchange• WS-Security• WS-Trust• WS-SecureConversation

* W3C Activity

• WS-Federation• WS-ReliableMessaging• WS-Coordination• WS-AtomicTransaction• WS-BusinessActivity• BPEL4WS


Project Deliverables

• Project concept (P/F)• Revised concept (P/F)• First iteration (25%)

– 1st iteration plan – 1st iteration progress

report – 1st iteration demo– 1st iteration final report

• Second iteration (25%)– 2nd iteration plan – Code inspection– 2nd iteration progress

report – 2nd iteration demo– 2nd iteration final report


Revised Project Concept due Tuesday October 17th

• Each team must submit one assignment all together: individuals and pairs should not submit separately.

• Revise your original proposal based on feedback and any team composition changes

• Make sure to propose a very small system, something your team can easily implement from scratch within three (3) weeks

• All main system facilities must be coded in some programming language (e.g., Java, C++, C#), using some component model framework (EJB, COM+ or the .NET variant of COM+ - you must obtain permission of the instructor in advance to use any other component model framework)

• The intent is that your eventual implementation actually USE several (not all) of the various services provided by the chosen component model framework in some non-trivial manner, as opposed to ignoring or working around them


Revised Project Concept: Deliverable

• Cover page (1 page): Indicate the name of your team, and list all team members with their full names and email addresses. Indicate that this document presents your Revised Project Concept– Please use same team name as project concept unless

substantial team composition changes (e.g., merging two teams)– Indicate any team members lost or gained since project concept

• Basic concept (max 4 pages): Briefly describe the system your team proposes to build. Write the requirements in the style of user stories or (informal) use cases

• Controversies (1 page): For example, are you in 100% agreement as to language, framework, OS platform, …?


Upcoming

• Individual development assignment #3 due October 10th

• Revised project concept due October 17th

• First iteration plan due October 24th


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


05 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

Documents

coms w4156

webbased applications

web servicesdevelopers

web serviceskaiser

example web servicehttp

business benefits

service kaiser

financial applications