A study of the technology and sociology
of Web services specifications
There is nothing like a disagreement concerning an
arcane technical matter to bring out the best (and worst)
in software architects and developers. As every reader
knows from experience, it can be hard to get to the bottom of what exactly is being debated. One reason for this
lack of clarity is often that different people care about
different aspects of the problem. In the absence of agreement concerning the problem, it can be difficult to reach
an agreement about the solutions.
In this article we discuss a technical matter that has
spurred vigorous debate in recent years: How to define
interactions among Web services to support operations
on state (that is, data values associated with a service that
persist across interactions, so that the result of one operation can depend on prior ones).
4 An airline reservation
system and a scheduler of computational jobs are two
examples of systems with this requirement. Both must
provide their clients with access to information about
ongoing activities: reservations and jobs, respectively.
Clients typically want to name and/or identify state (refer
to a specific reservation or job), access that state (get the
status of a flight reservation or the execution progress of
a job), modify part of that state (change the departure
time of a flight or set the CPU requirements of a job), and
destroy it (cancel a reservation or kill a job).
Ian Foster, Argonne National Laboratory
Savas Parastatidis, Microsoft Research
Paul Watson, Newcastle University
Mark McKeown, University of Manchester