160 likes | 270 Vues
This paper presents a detailed comparison of WS-Transfer and WS-Eventing within the context of OGSA-based Grids, highlighting the goals of leveraging web services while minimizing maintenance efforts. The analysis focuses on interoperability and composability in services, reviewing key specifications and implementations. It discusses the complexities and performance differences between WSRF and WS-Transfer, providing insights from practical experiments. The findings indicate that while both stacks can achieve comparable functionality, important differences in complexity and usability could impact the choice of implementation.
E N D
Experiences with WS-Transfer and WS-Eventing for Grids Marty Humphrey Glenn Wasson Computer Science Department University of Virginia GGF14 OGSA-MWS BOF June 28, 2005
Some Goals of OGSA • Leverage Web services tooling and run-time infrastructure • Minimize the amount of “stuff” that our community has to provide and/or maintain • Promote interoperability and composability
WSRF.NET • M. Humphrey, G. Wasson, K. Jackson, J. Boverhof, M. Rodriguez, J. Gawor, S. Lang, I. Foster, S. Meder, S. Pickles, and M. McKeown. State and Events for Web Services: A Comparison of Five WS-Resource Framework and WS-Notification Implementations. 14th IEEE International Symposium on High Performance Distributed Computing (HPDC-14), Research Triangle Park, NC, 24-27 July 2005. • http://www.ws-rf.net
Comparing WSRF to WS-Transfer et. al. • Goal: Objective, scientific exploration and comparison of WSRF to WS-Transfer, WS-Eventing, et. al. • M. Humphrey, G. Wasson, Y. Kiryakov, S-M. Park, D. Del Vecchio, N. Beekwilder, and J. Gray. Alternative Software Stacks for OGSA-based Grids.Proceedings of Supercomputing 2005, Seattle, WA, Nov 12-18, 2005.
Methodology • Implement both stacks on .NET • Comparing the specs • Comparing the implementation of the specs • Comparing the performance of the implementation of the specs
Results: Comparing the Specs • Lack of “create” in WSRF is problematic • Lack of input/output schema in WS-Transfer is problematic • WS-Transfer is less complex (implications?) • WSRF: single “type” of resource; WS-Transfer is agnostic • WS-Notification is more complex than WS-Eventing • But much of WS-Notification is optional
Results: Implementing the Specifications • Both are resource-oriented, so not surprising that both are back-ended with an XML database (Xindice) • WS-Transfer was easier to implement than WSRF • Neither define a Programming model • Not many implementations of WS-Notification are going to implement all of it
Account Service Exec Service Data Service Resource Allocation Service Proc Spawn Win Service Reservation Service Client WSRF.NET Grid-in-a-Box WS-Resources are processes Claim reservation by lengthening resource’s lifetime WS-Resources are reservations 10b Does this user have an account in this VO? 9 Launch job WS-Resources are accounts 2 8 Create new reservation under client’s DN Start application 11 5 Async. notification when done 10a Data input/output 1 What resources are available for my application? 6 WS-Resources are allocatable resources Create new data resource 3 Available Exec/Data Services 7 Stage-in data WS-Resources are directories 4 Authorization based on DN, all messages X509 signed Reserve resources
Summary of Results • Is one spec/implementation faster? • No. • Is one spec/implementation easier to program clients/services? • No – both are complicated by resource vs. representation issue. Programming model is (arguably) orthogonal. • Can WS-Transfer imply mapping too much to CRUD? • Yes.
Summary of Results • If one is "more full-featured" than another, are the extra features useful? • Jury is still out on the additional functionality of WSRF (brokered notification, service groups, lifetime management, resource property queries) • How easy is it to switch from one stack to the other? • Switching from WS-Transfer/WS-Eventing to WSRF/WS-Notification is likely easier.
WSRF Translator Filter Web Service WS-T WSRF Client (any platform) WS-T Web Service (.Net based) WSRF WST Translationvia Server-Side Translation Filter WSRF request WSRF response Works similarly for a WS-T client and a WSRF service.
1. translate() WSRF request message 2. WS-T equivalent WSRF WS-T WSRF Client (any platform) WS-T Web Service (any platform) WSRF WST Translationvia Translation Service 5. translate() WS-T response message 6. WSRF equivalent TranslationService (.Net based) 3. WS-T request 4. WS-T response
Summary • We have concrete experience that Grid services can be built via WS-Transfer et. al. • Services comparable to WSRF-based services, in behavior and performance • Microsoft et. al. has enumerated plans to build on WS-Transfer et. al. • “these specs should be in a standards body within 1 year” • OGSA needs the plumbing to be “just there” • Is it time for an OGSA Profile based on WS-Transfer et. al.?