specific. For example, a service implementer may decide large. (In WS-Transfer, the same effect can be achieved, to retain information about destroyed jobs (by changing but only by defining an auxiliary operation that returns their status to “destroyed”) so that information about an EPR to a desired subset.) them can still be retrieved. In this case, the state would • WS-Transfer is superior to WS-RF for technical reasons— not be destroyed. for example, its greater simplicity.
Finally, WS-RF and WS-Transfer focus on interaction • As a general principle, we should employ only specifi-with single states (for example, DestroyMultiple had to be cations that are stable, widely accepted, and supported custom defined) and so may not provide useful conven- by interoperable tooling. Because neither WS-RF nor tions in cases where operating on multiple states is the WS-Transfer is supported by all major vendors, neither common case; for example, all Amazon REST and Web passes this test. This view argues for the no-conventions services can consume multiple ASINs. approach.
Ideally, we would like to evaluate the relative merits • HTTP is widely used on the Web and, as a result, it of these two positions in should be preferred over terms of concrete metrics any WS-based solution. such as code size. Such Implementation reuse. an evaluation, however, The debates Proponents of conven-requires agreement on tions such as WS-RF and
the requirements that the WS-Transfer argue that the interfaces should support. different adoption of conventional
Unfortunately, proponents patterns can facilitate code
of the different approaches reuse. Every WS-RF or WS-tend to differ also in their emphasize the Transfer service performs views of requirements. For such things as state access,
example, a proponent of lifetime management, common patterns might concurrency control for
in separating the
see the ability to use WS- technical, political, incoming requests, and
Resource Lifetime opera- state activation/deactiva-tions for soft-state lifetime tion in the same way. Thus,
and stylistic
management as desirable, concerns. the code that implements
while others might not see those behaviors can be
that feature as important. reused in service imple-
Standards. Another mentations. topic of disagreement concerns the importance of stan- Proponents of the no-conventions approach, however, dardized specifications. Unfortunately (but not uncom- reply that service implementers can also use the same monly in the world of Web services), we are faced with code. In other words, there is certainly value to providing not one but two sets of Web services specifications, simi- service implementers with standardized implementations lar in purpose and design but different in minor aspects of common tasks, but this need not imply that those pat-of syntax and semantics. WS-RF has been submitted to, terns are exposed outside the service. reviewed, and approved by a standards body (OASIS); WS- Simplicity vs. structure. Proponents of the HTTP/REST Transfer has been submitted to W3C but is not yet a W3C approach emphasize that it provides for more concise recommendation. The proposed consolidation of the two, requests and permits the use of simpler client tooling WS-Resource Transfer, adds to the confusion. Thus, we get than approaches based on Web services. Critics point out a mix of opinions, including the following: that the use of HTTP/REST means that users cannot lever- • WS-RF, having undergone intensive community review age the significant investment in Web services technolo-by a standards body, is therefore technically superior and/ gies and platforms for message-based interactions. or morally preferable to the “proprietary” WS-Transfer. • 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
We have presented four different approaches to modeling state in Web services interactions. Each approach defines roughly comparable constructs for referring to, accessing,
References:
Archives