Web Services Grids Paul Watson University of Newcastle Paul Watson University of Newcastle

2 Plan Why Build Grids from Web Services? Choosing Specifications Our Approach WSRF Reducing Technology dependence Conclusions

3 Why Build Grids from Web Services? Leverage huge investment by industry Development Tools, Platforms, Standards, Services, Educational Materials, Skilled workforce, students Web Services technologies help us to build applications based on the Service Orientation design principles good for Internet-Scale computing, including Grid applications

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

5 WS Standards & Specifications Standards are important stability interoperability tool support implementation re-use But very few standards in Web Services young technology Lots of specifications e.g. transactions, security, workflow, notification even if there is a clear need, it can still take a long time to produce a widely accepted standard e.g. WS-Notification & WS-Eventing e.g. WS-AtomicTransaction & WS-TransactionManagement e.g. WS-Reliability & WS-ReliableMessaging

6 Picking Specifications to Use What to look for in a specification support from the key industrial players Microsoft AND IBM, Sun, Oracle, BEA, HP …. considered important stability interoperable implementations available from multiple vendors and open source community tooling composable with other specifications good understanding of how spec should be used Dangers of picking too early specification may change significantly as it goes through standardisation process lack of stable implementations and tooling may not be widely adopted

7 Which Specifications to pick? We talked to IBM, Microsoft and Oracle All agreed on WS-I (SOAP & WSDL) and WS-Security WS-Reliability and WS-ReliableMessaging are considered close, and technically sound All agreed that BPEL is an important, emerging spec (for workflow)

8 Beyond the core set After that, there was no consensus But, there was a general feeling that specs agreed by both Microsoft and IBM were the next safest WS-Addressing, WS-Policy, WS-MetadataExchange, WS- Federation, WS-Coordination, WS-Atomic Transactions, WS- BusinessActivity see “Secure, Reliable, Transacted Web Services: Architecture & Composition” by Ferguson, Storey et al. implementations available from IBM & Microsoft still concerns from parts of industry over ownership and stability

9 Our Approach to Building Applications Aims for “Production Grid Applications” low-risk – longevity interoperability with other services developer productivity focus on the science and not on taming the technology Therefore, stick to safe, stable specs where possible Adopt less stable specs only if definitely required functionality needed implementation(s) available better alternative that building our own Understand risks of early adoption be prepared for instability or (worst case) abandonment design architecture rather than for particular specification

10 Not a New Idea basically the approach adopted by many successful grid projects: MyGrid Geodise SkyServer …all build on basic, stable WS specifications 2-3 years of experience in building grid applications in this way Also the approach taken by commercial, mission-critical Web Services Amazon, Google “Google, Amazon and Beyond”, Nakhimovsky & Myers

11 Experimentation with Early Specifications We also believe in experimenting with interesting, emerging specifications that may have an impact on grid application design though we would avoid using them in “production” applications e.g. WS-CAF (Composite Application Framework), WS-RF

12 WS-RF Abandoning OGSI was a big step in the right direction WSRF has a much more conventional mapping onto underlying WS technologies can choose whether or not to use WSRF on a case by case basis Very early days for WSRF it will take (est.) at least a year for the specs to stabilise through the standardisation process longer for implementations of the standard Issues on which we would like reassurance/ discussion/ further investigation before commitment…..

13 WS-RF Currently, lacks endorsement from some key players Microsoft, Oracle, Sun Political and Technical reasons… Is wider support needed for WSRF to be a meaningful standard? Unusual Conceptual Model for a WS specification retained from OGSI …..

14 Conceptual Model: Service Orientation vs Resource Orientation Service Orientation Resource Orientation

15 WS-RF Conceptual Model Questions raised… is a good idea to base grid application design on the idea of exposing the internal “resources” of services to clients? traditionally discouraged does it encourage breaking encapsulation? can lead to brittle applications? is it “for system management within an enterprise, rather than for internet-scale grid applications”? Need guidance on when and how WSRF should be used experience needs to be gained in how to use it to build grid applications

16 WSRF Composability The unusual, resource-based conceptual model gives rise to issues of composability with existing specifications WSRF won’t interoperate with the current BPEL (workflow) spec

17 WSRF Conceptual Model If you wish to build services in a resource-oriented way then you need an infrastructure to support it WSRF If not, then you don’t e.g. MyGrid, SkyServer, Amazon, Google N.B. all these applications have services that encapsulate state

18 Our approach to WSRF It is early days for WSRF Would like more reassurance/ discussion/ further investigation before commitment We are taking a watching brief doesn’t yet meet our criteria for a “production grid” spec “experimental track” specification This is not a parting of the ways… WSRF not mandatory for services in grid applications applications can be built combining WSRF and non-WSRF services (pace composability concerns) we may choose to adopt it for some services if and when things are clearer

19 Reducing Technology Dependence Technologies change faster than the applications and artefacts we deal with in e-science We should try to avoid dependence on specific technologies where possible… Use technology-independent global identifiers e.g. URN … c.f. LSID NOT protocol dependent like URL, WS-Addressing, GSH registries can map to (changing) specific technologies In designs, try to separate out: high level description of operations and data exchanged mapping to a particular technology see DAIS WG

20 Summary WS are a good technology for building Grid applications The WS space will become clearer over time initially only low-level infrastructure specifications standardised later, higher-levels will stabilise (notification, workflow…) It’s early days for WSRF the situation will become clearer over time not an either/or decision for the e-science community We see benefits in building services from stable Web Service specifications leverage benefits of industrial investment Try to avoid over-dependence on specific technologies We should expend our (limited) effort where it can have the greatest effect high level services and science let industry sort out the lower level infrastructure for us