practice

Doi: 10.1145/1378727.1378739

A study of the technology and sociology
of Web service specifications.
BY ian fosteR, saVas PaRastatiDis,
Paul Watson, anD maRK mcKeo Wn
how Do
i model state?
let me count
the Ways

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. ⁴ 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 (for example, 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 (for example, change the departure time of a flight or set the CPU requirements of a job), and destroy it (for example, cancel a reservation or kill a job).

The debate over this issue does not concern the need for such operations but rather the specifics of how exactly to model and implement service state and the associated interactions on that state. For example, state may be modeled explicitly by the distributed computing technology used (for example, as an “object” with create, read, update, and destroy operations) or implicitly by referring to application domain-specific concepts within the interactions (for example, “create reservation,” “update reservation,” messages that include a domain-specific identifier like an Amazon ASIN in the body). Along a different dimension, we may use HTTP or SOAP as an implementation technology.

Our goal here is to shed light on possible approaches to modeling state. To this end, we present four different approaches and show how each can be used to enable access to a simple job management system. Then we summarize the key arguments that have been made for and against each approach. In addition to providing insights into the advantages and disadvantages of the different approaches, the discussion may also be interesting as a case study in technical debate. As we will see, the four approaches are remarkably similar in terms of what they do, but differ in terms of precisely how they do it.

 

some Preliminary observations First, a few observations about what we mean by modeling state. The systems with which we want to interact