1 / 9

IBM Position W3C Enterprise Web Services WS

IBM Position W3C Enterprise Web Services WS. Christopher Ferris Senior Technical Staff Member. Feb, 2007. Debunking the Myth. Many “RESTafarians” have taken the position that REST and Web services are somehow incompatible with one another

wesley-acosta
Download Presentation

IBM Position W3C Enterprise Web Services WS

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. IBM PositionW3C Enterprise Web Services WS Christopher Ferris Senior Technical Staff Member Feb, 2007

  2. Debunking the Myth • Many “RESTafarians” have taken the position that REST and Web services are somehow incompatible with one another • Fact: recent versions of SOAP and WSDL have been designed specifically to enable more RESTful use of Web services • SOAP1.2 • SOAP1.2 Response MEP • Web Method • WSDL2.0 • HTTP binding permits assigning verbs (GET, POST, etc.) on a per-operation basis • Attribute to mark an operation as safe • Unfortunately, the implementations of Web services runtimes and tooling have made RESTful use of Web services difficult

  3. IBM’s Vision “… a single scalable stack, offering the best of the Web in simple scenarios, and scaling gracefully to SOAP based Web services with the addition of optional extensions when more robust quality of service features are required. We believe that the right steps have been taken in the development of some of the more recent WS-* specifications to enable this vision to become reality.”

  4. URI vs EPR • A URI is an identifier http://www.weather.com/outlook/travel/businesstraveler/local/01534 • An EPR is not (supposed to be) an identifier • May carry reference parameters (similar to HTTP Cookies) • No defined means of equivalence comparison • EPR Address (URI) is the “address” of the service <wsa:EndpointReference> <wsa:Address>http://www.weather.com/weatherService/</wsa:Address> <foo:ZipCode>01534</foo:ZipCode> </wsa:EndpointReference> • Some uses of EPR reference parameters treat the EPR as if it were an identifier • WS-Naming

  5. Uniform Interface • Web services don’t expose a uniform interface • (although, this is changing a bit with the emergence of WS-ResourceTransfer and WS-MetadataExchange) • WSDL is used to provide a description of the service interface that clients may use to interact with that service • This means that deploying a new Web service requires socialization of the specifics of its interface before any prospective client may interact with that service • Uniform interface lowers the barrier to entry of new services • In contrast, new HTTP-based services can be made available without the need to upgrade everyone’s browser

  6. Choose Wisely, Grasshopper • It is important to note that REST and Web services are not mutually exclusive architectural styles. There may be many circumstances in which an application will want to take advantage of both styles. • Examples • Electronic Manufacturing • RosettaNet RAE and Web services bindings • Automotive • When dealing with smaller supply-chain partners, they have need to expose an interface that is more accessible (e.g. web based) • Financial • Web-based (portal) access for individuals, Web services for enterprise-level interactions, some leveraging the same functions • Others…

  7. When it makes sense to use “REST” • To leverage direct integration with the Web • Caching of resource representations for scalability and to mitigate against transient failures • Streaming of large amounts of data • Direct access to the resource representation from a Web browser • Manipulate the same resource interactively (e.g. using HTML forms) and programmatically (e.g. via SOAP or POX over HTTP)

  8. When it makes sense to use WS-* • Message-level security, such as when you need permanent total or partial encryption of message content, or when you need to have the authentication credentials bound to the message content • Multi-protocol exchanges (e.g. HTTP to WebSphere MQ) • Intermediation of message content between original sender and ultimate recipient such as an XSLT transformation to or from a standardized representation of the message content • Integration into an automated business processes orchestration engine using a standard such as WS-BPEL • Additional quality of service capabilities such as reliable messaging, transactions and advanced security capabilities

  9. Thank You! Thanks for listening. chrisfer@us.ibm.com

More Related