1 / 49

Savas Parastatidis Principal Research Associate School of Computing Science

Building Grid applications using Web Services (The Web Services Grid Application Framework) CERN – 4 March 2004. Savas Parastatidis Principal Research Associate School of Computing Science University of Newcastle upon Tyne savas@parastatidis.name http://savas.parastatidis.name. Outline.

Download Presentation

Savas Parastatidis Principal Research Associate School of Computing Science

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. Building Grid applications using Web Services(The Web Services Grid Application Framework)CERN – 4 March 2004 Savas Parastatidis Principal Research Associate School of Computing Science University of Newcastle upon Tyne savas@parastatidis.name http://savas.parastatidis.name

  2. Outline • The Grid • Service Orientation and Web Services • WS-GAF • WS-RF • Conclusions & future plans

  3. “What is the Grid?” • “Neo, the Grid is everything you would like it to be” • IBM: on-demand computing • HP: utility computing • Microsoft: seamless computing • ORACLE: 10g • Sun: Sun Grid Engine • Intel: Seti@home or whatever makes money • Globus: Distributed computing revisited • … • The Newcastle team: Internet-scale distributed computing

  4. The Grid vision • Build applications that span organisations • Create virtual organisations • Seamless integration • Hide use of resources, network, infrastructure • Provide a new computing experience • Enable e-Science, new commercial applications

  5. The promise of Web Services • Cross- and intra-organisation integration • Interoperability • Glue for heterogeneous platforms/applications/systems • Standards-based distributed computing • Based on the concepts of Service Orientation

  6. Service Orientation • Built around the concepts of service and message • A service is the logical manifestation of some physical resources (like databases, programs, devices, humans, etc.) and/or some application logic that is exposed to the networkand • Service interaction is facilitated by exchanging messages • A service adheres to a contract • Describes the format of the messages exchanged • Defines the message exchange patterns in which a service is prepared to participate

  7. Service Orientation • Don Box’s four tenets about Service Orientation • Boundaries are explicit • Services are autonomous • Services share schema and contract, not class • Service compatibility is determined based on policy Source: “A Guide to Developing and Running Connected Systems with Indigo” http://msdn.microsoft.com/Longhorn/understanding/mag/default.aspx?pull=/msdnmag/issues/04/01/Indigo/default.aspx and various talks

  8. The Anatomy of a Web Service • Large grained, loosely coupled • Performance, scalability, maintenance, re-use, etc.

  9. A Web Service

  10. Web Services (SOAP and WSDL)

  11. Service-orientation vs Resource-based • Loose-coupling • Encapsulation • Good scalability SOA • Tight-coupling • Easily breakable applications • Poor scalability Resource-based

  12. Interactions and State • Stateless interactions allow for loose-coupling • State remains internal to the service (encapsulation) • Applications are built through message exchange patterns and well-defined message formats

  13. The “stateless vs statefulness argument” Web Services just “computational entities” or “procedures”? Two types of state • Service internal state Not our concern • Interaction state Contextualisation as the means for message correlation State

  14. Web Services Interaction • Stateless interaction Hey, I am savas

  15. Web Services Interaction • Stateless interaction Welcome Savas

  16. Web Services Interaction • Stateless interaction I would like £100, please

  17. Web Services Interaction • Stateless interaction No can’t do Don’t know you

  18. context Web Services Interaction • Stateful interaction Hey, I am savas ctx

  19. Web Services Interaction • Stateful interaction Welcome Savas ctx

  20. Web Services Interaction • Stateful interaction I would like £100, please ctx

  21. Web Services Interaction • Stateful interaction Your £100 Have a nice day! ctx

  22. WS-GAF

  23. Motivation • We believed that OGSI unnecessarily introduced a new mandatory infrastructure layer on top of Web services • which was object-oriented in nature • Our goals • Analyse Grid requirements • Propose an alternative solution based on current WS specifications and practices • Start a technical discussion within GGF • Emphasize the importance of OGSA and its high-level services • Build solutions using WS-I and WS-Security

  24. Grid requirements • Stateful interactions • Contextualisation • Resource identification • Metadata • Grid Resource Specification • Lifetime management of resources • Just a high-level service interface • Lifetime information • Part of the metadata WS-Context, WS-Security, WS-Transactions, WS-Coordination, BPEL (message correlation), etc. etc. etc. URN: Uniform Resource Names Just an XML Schema document At the OGSA level

  25. Identity • Resources are usually hidden • There are cases where resources need to be identifiable outside an organisation’s boundaries • Grid Resource Identifier (GRI) (like an LSID) • Everlasting, unique resource identifier (Uniform Resource Name, URN) • Can be stored in a database or printed in a journal • Decoupling of identity from interface The resource is identified separately from the interface that can provide access to it

  26. Use of identity

  27. The Grid Resource Metadata Document • Functionality equivalent to Service Data Elements • Everything implemented using existing technologies and tooling • Not Grid-technology specific (it’s just an XML Schema document)

  28. Example: Using a registry

  29. From Web services to the Gridand back again

  30. The story so far • OGSI was accepted as a specification in June 2003 • Issues with meeting the “interoperability requirements” but everyone ignored them • We published our views in August 2003 • A response was announced by Ian Foster but was never delivered • We presented WS-GAF in GGF9 (October 2003) • End of October 2003 IBM announces to the WSDL working group that they are changing their position on “state” • WS-RF is partially released in January 2004 • It’s pitched as the “convergence point” between Web Services and the Grid

  31. Other developments • Microsoft are currently not supporting it • HP are interested in WS-RF for their single-systems management products • Oracle are not keen • Sun? we don’t know • Debate in UK on best route forward • And while the discussions on how to change the underlying infrastructure (again!) are starting, we have decided to build Grid applications with what we have now • But first…

  32. WS-Resource Framework - Introduction • A suite of specifications • Half of the specifications were introduced in January • WS-Resource Properties, WS-Notification, WS-Resource Lifetime • WS-Renewable References, WS-Service Groups, WS-Base Faults

  33. Initial Impressions • As per our August 2003 document (http://www.neresc.ac.uk/ws-gaf) • A clear separation between the terms “service” and “resource” • Services are not dynamically created; they are deployed • Services provide operations on multiple resources (one-to-many; no implicit one-to-one association between the two) • Factorisation on the functionality into separate specs (not all the way yet though) • A document-based approach to resource properties • Notification as a separate, higher-level service • WSA-friendly specs (no more GWSDL) • Respect to existing tooling; use it without modifications • Still issues with the conceptual model (scalability, loose coupling, is there an actual need for it… use cases?)

  34. The conceptual model • Very similar with OGSI • Effectively it’s J2EE or CORBA with angle brackets • Resource identity part of the infrastructure • Stateful interactions only with resources • Applications built through resource sharing rather than message interactions

  35. The conceptual model Talking to service instances that have an 1-1 association with a resource Talking to resources

  36. Examples (using URNs)

  37. Examples (using URNs)

  38. Examples (using URNs)

  39. Examples (WS-RF)

  40. Examples (WS-RF)

  41. Examples (WS-RF)

  42. Conclusions

  43. Benefits of WS-GAF • Simplicity and Minimalism • Meets Grid requirements without inventing new infrastructure • Uses existing contextualisation and addressing specs • Uses URN for resource identification • Low entry and maintenance costs for new Grid services • W3C Web Services Architecture conformant • No changes in the semantics/characteristics • Synergy with existing WS specifications and practices • Avoid effort involved in influencing WS community • Avoid risk associated with not being able to influence WS community • Moves the focus from the low-level “networking” to the more important OGSA platform • OGSA should be the focus for Grid standards

  44. Benefits of WS-GAF • Supporting tools • No divergence from WS technologies and tools (e.g., WSDL) • Do not need anything other than existing industry and open-source provided WS tools and platforms (e.g., ASP.NET, Axis, etc.) • Education materials • Industry investment • Performance and scalability • Encourages large granularity, loose coupling (richer, fewer message exchanges) • Explicit identification of resources • Resource lifetimes, everlasting resource IDs • Distributed system technology independence where possible

  45. Summary • We believe that WS-GAF meets the requirements for building Grid applications while using today’s WS specifications and practices • We believe that WS-GAF has a range of benefits • We are interested in building on existing WS specifications and utilise middleware that is made available by companies or the open source community (e.g., .NET, Axis, IBM WSDK, Java JAXB, etc.) • What’s next?

  46. WS-GAF Application • We need to build large-scale Grid applications using Web Services in order to find out what is actually required • Aims • Define the characteristics of a “typical” Grid application • Demonstrate the applicability of the WS-GAF approach in building Grid applications • Learn from the challenges of constructing a truly global, distributed, scalable, loosely-coupled application • Working on a “typical”, global-scale Grid application with international partners • We encourage everyone’s involvement

  47. Searching for “White Dwarfs” • Jim Gray’s SkyServer • Combine info from other databases • Utilise computational resources • Visualise We are looking for these

  48. People and Links • Paul Watson (Paul.Watson@newcastle.ac.uk) • Savas Parastatidis (Savas.Parastatidis@newcastle.ac.uk) • Jim Webber (Jim.Webber@newcastle.ac.uk) Web Services Grid Application Framework (WS-GAF)http://www.neresc.ac.uk/ws-gaf ws-gaf@newcastle.ac.uk Join by sending a message to mailbase@newcastle.ac.uk including the following line in the body join ws-gaf YourFirstName YourLastName

  49. Thanks • DTI • JISC • UK e-Science Core programme

More Related