1. Lecture 5 – Web Services CSE 490h – Introduction to Distributed Computing, Winter 2008 Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License. Dave Dopson Program Manager, Microsoft Connected Systems Division

2. Last Class Networking: communication between 2 systems RPC: expose an API across the network

3. Issues What if I want to communicate across the internet?  Compatibility  Firewall traversal  Intermittent connectivity  Naming / discovery  Load balancing  Security and data transmission privacy

4. Solution Web Services: Evolution of RPC RPC: started being used in early ‘80s XML RPC created 1998 Evolved into SOAP (Simple Object Access Protocol)  SOAP v1.2 was endorsed as a “recommended” standard by W3C in 2003 Alternative forks: DCOM, CORBA, REST

5. Compatibility Goal: interoperation between heterogeneous systems Common wire format  No need to know vendor / platform / version to call procedure WSDL: Web Services Description Language  Standard way of describing methods, arguments, etc  Can be automatically compiled into a proxy stub

6. Firewall Traversal Goal: Route traffic between systems given political complexities of internet Many organizations are hesitant to expose RPC over the internet SOAP can be routed over HTTP / HTTPS  HTTP more compatible with standard traffic inspection tools

7. Intermittent Connectivity WS-RM: Web Services – Reliable Messaging  Assurances Best Effort (BE) At Least Once (ALO) At Most Once (AMO) Exactly Once (EO) In Order Use a Queue to decouple two services with different lifecycles (eg Amazon SQS)

8. Security and Data Privacy No snooping of packets No unauthorized access Transport Level Security (TLS)  HTTPS provides standard privacy and authentication methods (eg PKI) WS-Security provides end-to-end security  Needed for proxy scenarios

9. REST vs SOAP Big ongoing architectural debate about the future of the internet Both use HTTP 4 “verbs” in HTTP  GET: retrieves data from URI, must be side-effect free  PUT: write to a URI  POST: send data to a URI (“call a method”)  DELETE: delete a URI

10. SOAP SOAP abuses HTTP to send messages across the internet  Only uses POST (typically)  Unlimited number of methods  “nouns” are hidden in method parameters rather than via publicly visible URI’s  SOAP maps more directly to well known programming techniques

11. REST REpresentative State Transfer More of a philosophy than a technology Use all 4 of HTTP’s “verbs” Use a unique URI for every noun in the system REST is more “inspectable” and “cacheable”. Adds an extra common abstraction layer.

12. WCF (Windows Communications Foundation) Microsoft’s SOAP framework (part of.NET) Provides  Hosting / Message handling  Instance Management  Concurrency Management  Message exchange patterns (request/reply, one-way, duplex)  Transaction support  Full integration w/ C# &.NET

13. WS-Eventing Unratified Standard (under development) Useful for implementing publish / subscribe design pattern How do I send messages / events if I don’t know a priori who is interested in receiving them  Instant Messaging – how do I know if I got an IM?  Event Logging – auditing, system diagnosis, billing, etc

14. Transactions Guarantee that two operations on two different systems either both succeed or both fail Transactions that include more than one machine require a Distributed Transaction Coordinator (DTC) WS-Transactions provides a standard protocol for communicating transactions context between caller and callee

15. Future of Web Services Transition to truly distributed apps Most interesting scenarios fundamentally involve communication  Email / Facebook / IM / Airline Booking  Collecting data  Giving orders  Event notification

16. Benefits of Software as a Service Deployment is easy for clients Superior development model (ship early, ship often) Data can stored and hosted reliably Economies of scale Consistent experience when roaming Access to more powerful resources than available on client (esp. mobile) Service can act as agent, doing work without user Easier to enforce software licensing / other business models

17. Drawbacks of Software as a Service Data Privacy / Ownership What if service provider goes out of business? Lack of control of service provider Service provider has to pay for hosting Unintended service uses (gmail file system)

18. Interesting scenarios Offer an API to interact with the service  Eg, Airline booking  Leverage other services Plug-Ins expand functionality of service  Eg, Facebook  Where does plug-in run? Facebook? 3 rd Party? Infrastructure Services  Amazon Web Services (AWS) – EC2, S3, SQS, etc  Other building blocks – payment services, identity, presence