Upload
heather-hopkins
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
05 October 2006 Kaiser: COMS W4156 Fall 2006 1
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/
05 October 2006 Kaiser: COMS W4156 Fall 2006 2
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 3
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 4
Example Web Service
http://www.xmethods.com/ve2/ViewListing.po?key=uuid:477CEED8-1EDD-89FA-1070-6C2DBE1685F8
05 October 2006 Kaiser: COMS W4156 Fall 2006 5
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.
05 October 2006 Kaiser: COMS W4156 Fall 2006 6
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 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
05 October 2006 Kaiser: COMS W4156 Fall 2006 8
Benefits: Consumable by Humans and Computers
• By humans, for example, through a desktop application
• By computers, for example, through an API
05 October 2006 Kaiser: COMS W4156 Fall 2006 9
Benefits: Ubiquitous
• Accessible from anywhere and use existing infrastructure
• Respect existing security systems such as firewalls
05 October 2006 Kaiser: COMS W4156 Fall 2006 10
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 11
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 12
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.
05 October 2006 Kaiser: COMS W4156 Fall 2006 13
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 14
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 15
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>
05 October 2006 Kaiser: COMS W4156 Fall 2006 16
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 17
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.)
05 October 2006 Kaiser: COMS W4156 Fall 2006 18
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 19
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 20
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 21
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 22
Elements and Structure
<definitions> <types> data types used... </types> <message> messages used... </message> <portType> operations performed... </portType> <binding> communication protocols used...
</binding> </definitions>
05 October 2006 Kaiser: COMS W4156 Fall 2006 23
WSDL Types
• <types> element defines the data types that are used by the web service
• Uses XML Schema syntax to define data types
05 October 2006 Kaiser: COMS W4156 Fall 2006 24
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 25
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 26
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 27
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 >
05 October 2006 Kaiser: COMS W4156 Fall 2006 28
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>
05 October 2006 Kaiser: COMS W4156 Fall 2006 29
WSDL Bindings
• <binding> element defines the message format and protocol details for each port
05 October 2006 Kaiser: COMS W4156 Fall 2006 30
WSDL Example
http://www.xmethods.net/sd/2001/TemperatureService.wsdl
05 October 2006 Kaiser: COMS W4156 Fall 2006 31
Lots of Acronyms
• Web Services Description Language (WSDL)
• Simple Object Access Protocol (SOAP)
• Universal Description, Discovery, and Integration (UDDI)
05 October 2006 Kaiser: COMS W4156 Fall 2006 32
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 33
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 34
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"
05 October 2006 Kaiser: COMS W4156 Fall 2006 35
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>
05 October 2006 Kaiser: COMS W4156 Fall 2006 36
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 37
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 38
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 39
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 40
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 41
Another Example
• http://www.xmethods.com/ve2/ViewListing.po?key=uuid:396577C1-EE97-6A65-AC0B-307B2C6943FA
05 October 2006 Kaiser: COMS W4156 Fall 2006 42
Example WSDL
<definitions
name= "TemperatureConverterService"
<lots of namespace definitions>
…
05 October 2006 Kaiser: COMS W4156 Fall 2006 43
Example WSDL
… <message name="InFahrenheitToCelsiusRequest"> <part name="tempFahrenheit"
type= "xsd:float"/> </message> <message
name="OutFahrenheitToCelsiusResponse"> <part name="tempCelsius"
type= "xsd:float"/> </message> …
05 October 2006 Kaiser: COMS W4156 Fall 2006 44
Example WSDL
… <portType name= "TemperatureConverter_Service">
<operation name= "FahrenheitToCelsius"> <input message= "InFahrenheitToCelsiusRequest"/> <output message=
"OutFahrenheitToCelsiusResponse"/> </operation>
</portType> …
05 October 2006 Kaiser: COMS W4156 Fall 2006 45
Example WSDL
… <binding name= "TemperatureConverter_ServiceBinding"
type=“TemperatureConverter_Service“><soap:binding style="rpc"
transport= "http://schemas.xmlsoap.org/soap/http"/> …
05 October 2006 Kaiser: COMS W4156 Fall 2006 46
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"/> …
05 October 2006 Kaiser: COMS W4156 Fall 2006 47
Example WSDL
… <service name= "TemperatureConverter_Service"> <port binding= "TemperatureConverter_ServiceBinding"
name= "TemperatureConverter_ServicePort"> <soap:address location= "http://localhost:8080/soap/servlet/rpcrouter/"/>
</port> </service> …
05 October 2006 Kaiser: COMS W4156 Fall 2006 48
Then A Miracle Occurs
05 October 2006 Kaiser: COMS W4156 Fall 2006 49
Example Java Service
public class TemperatureConverter {
public float FahrenheitToCelsius(
float tempFahrenheit) {
return
( tempFahrenheit - 32)*5/9;
} }
05 October 2006 Kaiser: COMS W4156 Fall 2006 50
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 ); } }
05 October 2006 Kaiser: COMS W4156 Fall 2006 51
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 52
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 53
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.
05 October 2006 Kaiser: COMS W4156 Fall 2006 54
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 55
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.
05 October 2006 Kaiser: COMS W4156 Fall 2006 56
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 57
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.
05 October 2006 Kaiser: COMS W4156 Fall 2006 58
Tier 3 -- Interoperability across Multiple Companies
• Companies want to extend their computing out to more partners and customers to build business ecosystems
05 October 2006 Kaiser: COMS W4156 Fall 2006 59
Business Ecosystem
05 October 2006 Kaiser: COMS W4156 Fall 2006 60
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 61
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 62
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 63
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 64
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 65
GXA
05 October 2006 Kaiser: COMS W4156 Fall 2006 66
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 67
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 68
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 69
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]
05 October 2006 Kaiser: COMS W4156 Fall 2006 70
[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
05 October 2006 Kaiser: COMS W4156 Fall 2006 71
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 72
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
05 October 2006 Kaiser: COMS W4156 Fall 2006 73
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, …?
05 October 2006 Kaiser: COMS W4156 Fall 2006 74
Upcoming
• Individual development assignment #3 due October 10th
• Revised project concept due October 17th
• First iteration plan due October 24th
05 October 2006 Kaiser: COMS W4156 Fall 2006 75
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/