sirable, while others might not see that
feature as important.
Standards. Another topic of disagreement concerns the importance
of standardized specifications. Unfortunately (but not uncommonly in the
world of Web services), we are faced
with not one but two sets of Web services specifications, similar in purpose
and design but different in minor aspects of syntax and semantics. WS-RF
has been submitted to, and reviewed
and approved by, a standards body (
OASIS); WS-Transfer has been submitted
to W3C but is not yet a W3C recommendation. The proposed consolidation of
the two, WS-ResourceTransfer, adds
to the confusion. Thus, we get a mix of
opinions, including the following:
˲ WS-RF, having undergone intensive community review by a standards
body, is therefore technically superior
and/or morally preferable to the “
˲ WS-RF is superior to WS-Transfer
for technical reasons—for example, its
support for access to subsets of a resource’s state, which can be important
if that state is large. (In WS-Transfer,
the same effect can be achieved, but
only by defining an auxiliary operation
that returns an EPR to a desired subset.)
˲ WS-Transfer is superior to WS-RF
for technical reasons—for example, its
˲ As a general principle, we should
employ only specifications that are stable, widely accepted, and supported by
interoperable tooling. Because neither
WS-RF nor WS-Transfer is supported
by all major vendors, neither passes
this test. This view argues for the no-conventions approach.
˲ HTTP is widely used on the Web
and, as a result, it should be preferred
over any WS-based solution.
Implementation reuse. Proponents
of conventions such as WS-RF and
WS-Transfer argue that the adoption
of conventional patterns can facilitate code reuse. Every WS-RF or WS-Transfer service performs such things
as state access, lifetime management,
concurrency control for incoming requests, and state activation/deactiva-tion in the same way. Thus, the code
that implements those behaviors can
be reused in service implementations.
Proponents of the no-conventions
approach, however, reply that service
implementers can also use the same
code. In other words, there is certainly
value to providing service implementers with standardized implementations of common tasks, but this need
not imply that those patterns are exposed outside the service.
Simplicity vs. structure. Proponents
of the HTTP/REST approach emphasize that it provides for more concise
requests and permits the use of simpler client tooling than approaches
based on Web services. Critics point
out that the use of HTTP/REST means
that users cannot leverage the significant investment in Web services technologies and platforms for message-based interactions.
We have presented four different approaches to modeling state in (Web)
service interactions. Each approach
defines roughly comparable constructs
for referring to, accessing, and managing state components, but differs according to both its precise syntax and
the use made (or not) of conventional
domain-independent encodings of operations.
Thus, when defining state management operations, the WS-RF and WS-Transfer approaches both use EPRs
to refer to state components and to
adopt conventions defined in the WS-RF and related specifications and in
the WS-Transfer and related specifications, respectively. In contrast, the
no-conventions and REST approaches
adopt domain-specific encodings of
operations, on top of SOAP and HTTP,
Analysis of the debates that have
occurred around these different approaches emphasizes the difficulties
inherent in separating technical, political, and stylistic concerns. Some differences of opinion relate to well-defined
technical issues and reflect either different philosophies concerning system
design or different target applications.
Others relate to differing target time
scales. For example, no-conventions
proponents initially argued against
the use of WS-Addressing because of
lack of support for that specification
in certain tools, while WS-RF and WS-Transfer proponents argued in favor,
believing that WS-Addressing would
eventually become universal. Support
for WS-Addressing has since become
quasi-universal, and now few find its
We are grateful to Karl Czajkowski, Jim
Gray, and Sam Meder for comments
on an earlier version of this document.
Needless to say, the characterizations
of the different arguments are our
own. The work of the first author was
supported in part by the Mathematical,
Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing
Research, U.S. Department of Energy,
under Contract W-31-109-Eng- 38. The
work at Newcastle was supported by the
UK eScience Programme, with funding
from the EPSRC, DTI and JISC.
1. Booth, D., Haas, H., McCabe, F., Newcomer, E.,
Champion, M., Ferris, C. and Orchard, D. Web Services
Architecture, W3C, 2003.
2. Chervenak, A., Schopf, J.M., Pearlman, L., Su, M.-H.,
Bharathi, S., Cinquini, L., D’Arcy, M., Miller, N. and
Bernholdt, D. Monitoring the Earth System Grid with
MDS4. 2nd IEEE Intl. Conference on e-Science and
Grid Computing. Amsterdam, Netherlands, 2006.
3. Fielding, R. Architectural styles and the design of
network-based soft ware architectures. Information
and Computer Science, University of California Irvine,
4. Foster, I., Czajkowski, K., Ferguson, D., Frey, J.,
Graham, S., Maguire, T., Snelling, D. and Tuecke, S.
Modeling and managing state in distributed systems:
The role of OGSI and WSRF. Proceedings of the IEEE
93, 3. 604–612.
5. Helland, P. Data on the Inside vs. Data on the Outside.
Microsoft Corporation, 2004.
6. Parastatidis, S., Webber, J., Watson, P. and Rischbeck,
T. WS-GAF: A framework for building grid applications
using Web Services. Concurrency and Computation:
Practice and Experience 17, 2–4, 391–417.
Ian Foster ( email@example.com) is the director of the
Computation Institute at Argonne National Laboratory,
where he is also an Argonne Distinguished Fellow, and the
University of Chicago, where he is also the Arthur Holly
Compton Distinguished Service Professor of Computer
Savas Parastatidis ( Savas.Parastatidis@newcastle.ac.uk)
is an architect in Microsoft Research. He investigates
the use of technology in eResearch and is particularly
interested in Cloud Computing, knowledge representation
and management, and social networking.
Paul Watson (Paul. Watson@newcastle.ac.uk) is a
professor of Computer Science at Newcastle University,
and Director of the North East Regional e-Science Centre
in the U. K.
Mark McKeown was a grid architect at the University of
Manchester, U.K., at the time of this work.