1 / 75

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/. What are Web Services?. The Web is more and more often used for application to application communication

tamekah-moss
Télécharger la présentation

COMS W4156: Advanced Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ 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 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 Kaiser: COMS W4156 Fall 2006

  4. Example Web Service http://www.xmethods.com/ve2/ViewListing.po?key=uuid:477CEED8-1EDD-89FA-1070-6C2DBE1685F8 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. 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 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 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 Kaiser: COMS W4156 Fall 2006

  9. Benefits: Ubiquitous • Accessible from anywhere and use existing infrastructure • Respect existing security systems such as firewalls 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 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 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. 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 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 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> 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 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.) Kaiser: COMS W4156 Fall 2006

  18. Steps to Creating and Using a Web Service • Service provider creates a service and registers it with an Internet registry • Web Service defined in the form of a Web Service Description • Service requester searches the registry and finds corresponding Web Service • Retrieves Description • Service requester writes the client to access the service, using the protocol and input/output parameters specified in description 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 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 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 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> 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 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 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 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 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 > 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> Kaiser: COMS W4156 Fall 2006

  29. WSDL Bindings • <binding> element defines the message format and protocol details for each port Kaiser: COMS W4156 Fall 2006

  30. WSDL Example http://www.xmethods.net/sd/2001/TemperatureService.wsdl 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) 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 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 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" 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> 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 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 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 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 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 Kaiser: COMS W4156 Fall 2006

  41. Another Example • http://www.xmethods.com/ve2/ViewListing.po?key=uuid:396577C1-EE97-6A65-AC0B-307B2C6943FA Kaiser: COMS W4156 Fall 2006

  42. Example WSDL <definitions name= "TemperatureConverterService" <lots of namespace definitions> … 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> … Kaiser: COMS W4156 Fall 2006

  44. Example WSDL … <portType name= "TemperatureConverter_Service"> <operation name= "FahrenheitToCelsius"> <input message= "InFahrenheitToCelsiusRequest"/> <output message= "OutFahrenheitToCelsiusResponse"/> </operation> </portType> … 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"/> … 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"/> … 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> … Kaiser: COMS W4156 Fall 2006

  48. Then A Miracle Occurs Kaiser: COMS W4156 Fall 2006

  49. Example Java Service public class TemperatureConverter { public float FahrenheitToCelsius( float tempFahrenheit) { return ( tempFahrenheit - 32)*5/9; } } Kaiser: COMS W4156 Fall 2006

  50. Example Java Client public 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 ); } } Kaiser: COMS W4156 Fall 2006

More Related