Transcript Lecture 5 - Guest Lecture

Lecture 5 – Web Services
Dave Dopson
Program Manager, Microsoft
Connected Systems Division
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.
Last Class
Networking: communication between 2
systems
 RPC: expose an API across the network

Issues

What if I want to communicate across the
internet?
 Compatibility
 Firewall
traversal
 Intermittent connectivity
 Naming / discovery
 Load balancing
 Security and data transmission privacy
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
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
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
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)
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
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
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
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.
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
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
Messaging – how do I know if I got an IM?
 Event Logging – auditing, system diagnosis, billing,
etc
 Instant
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
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
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
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)

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? 3rd Party?
Infrastructure Services
 Amazon Web Services (AWS) – EC2, S3, SQS, etc
 Other building blocks – payment services, identity,
presence