If Web Services are the Answer, What's The Question


Published on

IMG seminar by Michael Parkin at the University of Manchester, January 2006.

Published in: Economy & Finance, Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

If Web Services are the Answer, What's The Question

  1. 1. If Web Services are the Answer, What’s the Question? Michael Parkin Supervisor: John Brooke IMG Seminar 17 January 2007
  2. 2. Acknowledgments & Sources • Thanks to Dean Kuo, Mark McKeown, Bruno Harbulot, Donal Fellows • Lots of stuff taken from blogs and web articles • All quotes are acknowledged and linked to where possible IMG Seminar 17 January 2007
  3. 3. Overview • Grid computing & it’s requirements • Introduction of architectural styles: • Web Services Architecture (WSA) and WS-* • Representational State Transfer (REST) • Instant Messaging (IM) • Evaluation of Web Services, REST and IM • Using the requirements of Grid computing • The question is? IMG Seminar 17 January 2007
  4. 4. Grid Computing IMG Seminar 17 January 2007
  5. 5. Grid Computing is... ... a new infrastructure that builds on today’s Internet and Web to enable and exploit large-scale sharing of resources within distributed groups. “The Grid” Ian Foster, ClusterWorld Magazine (January 2004) ... coordinated resource sharing among dynamic collections of individuals, institutions, and resources. “The Anatomy of the Grid” Ian Foster, et al (2001) ... internet-scale distributed computing. “Distributed Computing Economics” Jim Gray [Microsoft Research] IMG Seminar 17 January 2007
  6. 6. Non-functional Requirements • Scalability and interoperation • Large/internet-scale dynamic sharing of resources • We need to connect lots of diverse/heterogeneous entities together • Pervasiveness • ... through simple clients and consistent implementations • Network efficiency • ... this is a distributed system, after all • Return to these later ... IMG Seminar 17 January 2007
  7. 7. Web Services Architecture & WS-* IMG Seminar 17 January 2007
  8. 8. Web Services Architecture The only game in town Anon (though attributed to many) A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (WSDL). Other systems interact with the Web service ... using SOAP messages. Web Services Architecture, W3C • WSA is just SOAP (structured XML) + WSDL IMG Seminar 17 January 2007
  9. 9. WSA Constraints [An Architecture’s] properties are created by the application of constraints Roy Fielding’s PhD. Thesis • A constraint is a condition that a solution must meet in order to be acceptable - a confinement of all possible solutions • Lack of constraints on the WSA other than • Use of SOAP + WSDL • Service specific interfaces • i.e. no restriction on interfaces or message representations • Sender / receiver pattern • “Effectively unconstrained” - all possible solutions are acceptable IMG Seminar 17 January 2007
  10. 10. No constraints... IMG Seminar “The Sugar House” Richard Greaves, 2001 17 January 2007
  11. 11. Web Services Standards Web services standards compose together to provide interoperable protocols ... in loosely coupled systems. The specifications build on top of the core XML and SOAP standards. “Web Service Specifications” Microsoft • Collectively known as Web Service stack or WS-* • 50+ specifing aspects of reliability, security, transactions, etc. • WS-* are constraints on the WSA • Defined though standards bodies (OGF, W3C, OASIS, EMCA?) before being implemented • No reference implementations IMG Seminar 17 January 2007
  12. 12. Grid & WS-* • Since 2002 Grid computing is officially implemented using WS-* • First through Open Grid Services Infrastructure ... • ... then through the WS-ResourceFramework (WS-RF) family (2004) • WS-RF describes the relationship between WSA & WS-* • As Web Services are stateless WS-Resource describes a stateful resource • “Each message carries some information that identifies the [stateful] resource behind the service which should be the logical receiver of the message” Savas Parastatidis [Microsoft] IMG Seminar 17 January 2007
  13. 13. The WS-RF Family • WS-Resource • WS-ResourceProperty • WS-ResourceLifetime • WS-BaseFaults • WS-RenewableReferences • WS-ServiceGroup • WS-Notification IMG Seminar 17 January 2007
  14. 14. REST Architecture IMG Seminar 17 January 2007
  15. 15. REST • REpresentational State Transfer • The architecture of the Web introduced in Roy Fielding’s PhD. thesis Fetch representation Client Resource Representation • Not a standard, but it uses common standards • Best known implementation of REST is HTTP • Resource - not service - orientation IMG Seminar 17 January 2007
  16. 16. Service vs Resource Orientation /jobs GET - list all jobs PUT - unused • The resource is the central abstraction - POST - add new job DELETE - unused not the service /job/[id] GET - get job details PUT - update job JobManagementService POST - unused + ID submitJob (u_id: ID, j:Job) DELETE - cancel job + void cancelJob (j_id: ID) + Job getJobDetail (j_id: ID) + Job[] getJobs(u_id: ID) <<interface>> /users Resource GET - list all users GET PUT - unused PUT POST - create user POST DELETE - unused DELETE UserManagementService + ID createUser (u: User) /user/[id] + User getUser (u_id: ID) GET - return user + User[] getUsers () PUT - update user POST - unused DELETE - unused /user/[id]/jobs GET - return user's jobs PUT - IMG Seminar POST - create new job Adapted from: “REST - The Better Web Services Model”, Stefan Tilkov DELETE17 January 2007 -
  17. 17. REST Constraints • Highly constrained architecture (cf. WSA) • Self-descriptive messages • ... stateless interaction • ... resource representation • “Hypermedia as engine of client state” • Resource identification • Name things with unique URIs • Uniform interface IMG Seminar 17 January 2007
  18. 18. Architecture with Constraints IMG Seminar 17 January 2007
  19. 19. REST and the Grid • REST style is not used by the Grid • Why can’t a Grid Virtual Organisation (VO) be a REST resource? • Find VO member: • Fetch /myVO/people/fred • Returns representation of Fred in format requested • If no representation returned, Fred’s not a member • Used for role-based access control as part of my work • Very lightweight and interoperable ... IMG Seminar 17 January 2007
  20. 20. Instant Messaging Architecture IMG Seminar 17 January 2007
  21. 21. Instant Messaging • Hub and spoke/email-type infrastructure • Not just text: Google’s Jingle library can stream VOIP and Video IMG Seminar 17 January 2007
  22. 22. IM Constraints • Asynchronous, routed messaging • Open connection to server is used as bi-directional message pipe • Document-style interaction • Complexity is in the message - not the interface (cf. REST self- describing message) • Unique naming of servers and clients • Number (ICQ) or email style (name@domain) • Presence of clients can be determined • Clients may have multiple sessions with one or more other clients and multi-user chats IMG Seminar 17 January 2007
  23. 23. Wider Constraints IMG Seminar Eixample, Barcelona 17 January 2007
  24. 24. Just for Multi-User Chat? • Multi User Chat can be used as a messaging ‘bus’ • ‘Plug-in’ services across domains • Each client listens for a message it’s interested in • Ignores other messages • A lightweight collaborative environment • Implemented using XMPP IMG Seminar 17 January 2007
  25. 25. Grid Computing Requirements • Scalability • Interoperation • Pervasiveness / simple clients • Network efficiency • How does each architecture do? IMG Seminar 17 January 2007
  26. 26. Scalability / Interoperability IMG Seminar 17 January 2007
  27. 27. WSA Scalability • Remember - no constraints • ... therefore an infinite number ways to do things... • ... which promotes coupling • “Web services are effectively unconstrained, and therefore much more tightly coupled.” Mark Baker [W3C Working Groups] • Loose coupling is better than tight coupling for scalability IMG Seminar 17 January 2007
  28. 28. WS-* Scalability / Interoperability • Requires each service to be predictable and implement the same set of specifications in the same way • Specifications MUST be unambiguous • Interoperability through consistency of implementations • Most WS-* specifications aren’t unambiguous ... • ... and sometimes they’re deliberately ambiguous - e.g. WS-BA • There’s no reference implementation to code to • No consistency, therefore no reliability IMG Seminar 17 January 2007
  29. 29. WS-* Scalability / Interoperability This document does a disservice to the community; it is ambiguous in many places, incomplete in others, and riddled with errors throughout. Indeed any company that implemented it would end up with an unreliable system. Werner Vogels [CTO, Amazon] on WS-Reliability IMG Seminar 17 January 2007
  30. 30. ? IMG Seminar “Untitled” Richard Greaves, 2001 17 January 2007
  31. 31. WS-Interoperability Conformance to the Web services Addressing Test Suite does not by itself enable a party to claim conformance with the Web Services Addressing specification. Disclaimer from the WS-Addressing test suite IMG Seminar 17 January 2007
  32. 32. WS-Incoherence • WS-Reliability or WS-ReliableMessaging ? • WS-Management or WS-DistributedManagement ? • WS-Eventing or WS-Notification ? • WS-Context or WS-Session ? • WS-RF or WS-Transfer ? • Multiple ways of doing things • e.g. SOAP vs Literal encoding, Document vs RPC style • e.g. “4 ways to send SOAP attachments (DIME, MTOM, SOAP w. Attachments, WS-I Attachments)” Dan Diephouse [XFire author] IMG Seminar 17 January 2007
  33. 33. WS-* Stack Criticism No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure. Tim Bray [Director of Web Technologies, Sun Microsystems] Much of [WS-* is] recently invented, untested and unproven in the real world. Sean McGrath [CTO, Propylon] IMG Seminar 17 January 2007
  34. 34. “If you don’t like it, don’t use it” Are there too many specs? If you think so, then there are. So don't use them all. You don't have to use any of them. Matt Powell [Web Platform and Tools Marketing Team, Microsoft] • OK, if within the same administrative domain - you are ‘God’ • Sixth fallacy of distributed computing is that “there is a single administrator” Peter Deutsch [author of the definitive Smalltalk implementation] via Mark Baker IMG Seminar 17 January 2007
  35. 35. Across Administrative Domains • Grid computing is about creating virtual organisations across organizational boundaries • “[Grid computing ] is distributed computing across multiple administrative domains” Dave Snelling (via Mark McKeown) • You can’t control who implements what WS-* specifications ... • ... or how they interpret and implement it ... • ... or which version they implement • Tighter - not looser - coupling is required to solve these problems IMG Seminar 17 January 2007
  36. 36. WS-Tooling Support Tools are being created by people everywhere to make it so you can just indicate the capabilities you need and the rest will be done for you. Matt Powell Each toolkit vendor is likely to interpret the specification somewhat differently. Werner Vogels [CTO, Amazon] IMG Seminar 17 January 2007
  37. 37. REST Scalability & Interoperability • The best known implementation of REST is HTTP • The Web: I look at Google and Amazon and EBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I can’t help noticing that they don’t seem to need much WS-apparatus. Tim Bray • All clients can immediately interact with a resource once we know it’s address because of uniform interface and operation semantics IMG Seminar 17 January 2007
  38. 38. Even Looser Coupling • Loose coupling in time is also possible • HTTP has asynchronous communications built in ... • GET empty job representation • POST completed job representation to asynchronous job submission resource (URL contained in empty job) • Server returns a ‘202 Accepted’ message and either: 1. With “Reply-To” request header: a notification is sent to that URL when the job is complete 2. Without “Reply-To” request header: a “Location” response header is returned with a URL with the status/result • ... in a standard way IMG Seminar 17 January 2007
  39. 39. IM Scalability & Interoperability • Considering XMPP, an open XML message based IM implementation... • Scales very well • Jabber has 40-50 million users (source: Wikipedia) • Each XMPP server can support ~30-50,000 concurrent users • Interoperability seems to be no problem • Lots of heterogeneous clients connecting to lots of heterogeneous servers • Gateways to ‘closed’ IM implementations • AIM, ICQ, etc. • Well-defined and accepted message semantics IMG Seminar 17 January 2007
  40. 40. Network Efficiency IMG Seminar 17 January 2007
  41. 41. Network Efficiency - A Note • In a network-based application it is often the communications which are the bottleneck • Generally increased through the use of network intermediaries • Caches, proxy servers, etc. • Reduce the ‘distance’ a request has to go • Relieves stress on the server/application • An intermediary can only make a decisions when a client’s request shows, in the clear, the targeted resource, and the method requested is understood IMG Seminar Adapted from: “REST”, Roger L. Costello 17 January 2007
  42. 42. WSA Network Efficiency • Most (all?) Web Services use SOAP/HTTP • Can they re-use Web caches to increase efficiency? • A SOAP message is always a HTTP POST operation • A cache cannot know from the HTTP method whether the client is doing a read, write, update or delete • I don't know what operation is being A SOAP URI is always to the SOAP server, not to the actual requested. target • I don't know which resource is being Cache server cannot know from the URI what resource is being requested. requested. I must forward the request Message Web Client Cache EPR operation = highFive() IMG Seminar 17 January 2007
  43. 43. Reuse or Abuse? [Web Services are] on the web but they aren’t of the web. They don’t use any of the web’s features, or interact with anything else on the web. They just use HTTP as a transport protocol. They could just as easily run over TCP and get better performance. Leonard Richardson [co-author “REST Web Services”] IMG Seminar 17 January 2007
  44. 44. REST Network Efficiency • Uniform, clear semantics of the interface’s operations • GET always means “retrieve the resource identified” • PUT always means “replace resource identified with this new one” • POST always means “submit this data for processing” • DELETE always means “delete the resource identified” • URI’s can be compared • Allows optimization of the network (i.e. caching, comparison of metainformation) IMG Seminar 17 January 2007
  45. 45. IM Network Efficiency • Connection overheads removed (client only connects once to server) • Login to server once • Open pipe is used as an asynchronous bi-directional messaging bus • Only send messages once • Stored on server if destination is unavailable • Guaranteed in-oder delivery when client reconnects • No need to poll - response comes asynchronously when ready • But, all messages are routed via server - not the most efficient route IMG Seminar 17 January 2007
  46. 46. Pervasiveness pervade, v. “To spread, extend, diffuse; to be present and apparent throughout.” (Source OED) IMG Seminar 17 January 2007
  47. 47. WS-* Pervasiveness • Complexity of WS-* limits overall uptake of technology • Clients are service specific • Clients must be ‘active’ • ... no information about the possible state transitions for the client in SOAP messages • ... must process each message even if content has not changed • ... therefore client more complex • Stack overhead unsuitable for restricted/lightweight clients IMG Seminar 17 January 2007
  48. 48. REST / IM Pervasiveness • Simpler clients than WS clients as all possible state transitions are contained in the returned message through hypermedia • “REST is particularly useful for limited-profile devices such as PDAs and mobile phones” Sun Microsystems • More complex clients than REST, but simpler than WS-* • New York Times: “... instant messaging is used in more than 80 percent of corporations” • No of IM accounts in 2006: 995 million (Source: Radichi Group) IMG Seminar 17 January 2007
  49. 49. Evaluation Network Client Simplicity Scalability Interoperation Efficiency - - -- - WS-* ++ ++ ++ + REST + +/++ +/++ + IM IMG Seminar 17 January 2007
  50. 50. Finally ...What is the question? • If Web Services are the answer: What foundations do we choose for limited-scale, tightly-coupled, implementation dependent Grid? • The question should be: What foundations do we choose for massively-scalable, loosely-coupled, implementation independent, consistent Grid? IMG Seminar 17 January 2007
  51. 51. Or... vs No architectural constraints? Architectural constraints?
  52. 52. Summary • Grid computing is based on WS-* • WS-* is widely acknowledged to be complex • Across administrative domains you can’t control who implements what and how they implement it • Other architectures and technologies that meet the Grid’s requirements should be considered • These have been proven to be interoperable and scalable - the ultimate goal of the Grid IMG Seminar 17 January 2007
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.