savas parastatidis

WS-Transfer: I must be missing something (and I feel lonely)

It must be me... I can't explain it otherwise. I must have the wrong understanding.

First, it was the Grid community with OGSI and their non-standard-based, object-oriented approach to building Grid Services, then it was WS-RF with their resource-oriented view of the world and their state lifetime management, and now it's WS-Transfer which looks like REST but it's not exactly REST.

Conceptually, messages are no longer targeted to services but, rather, to resources. This is the case with REST and WS-RF too. I pointed this out in a previous post and in a message to the WS-RF mailing list. Jimwrote about the same issue too.

The problem is the particular use of WS-Addressing. I don't have a problem with the specification, which is great, but with the way it's used by WS-RF and WS-Transfer where it effectively becomes the equivalent of an object/resource pointer/identifier. I like the use of WS-Addressing in specifications like WS-Eventing (apart from the unsubscribe message). It makes it easy to build message-oriented applications, protocols, and patterns (e.g., "third-party delivery" and "multi-node flow" posts).

So what's the issue with the particular use of WS-Addressing? Let me take you through a simple example.

If you had already ordered two cars from a car dealer and you wanted to update the orders with new colours, what would you do? Would you have done business with a car dealer that required you to send each update in turn? What if you had 1,000 orders or 1 million? Would you be prepared to send each of those updated orders in turn?

What REST, WS-RF, and now WS-Transfer tell us is that each order can be treated as an addressable resource whose state is represented onto the network as a document. This means, at the architecture level, we don't reason in terms of services anymore but, rather, in terms of resources. My updated order for car 415,324 would be sent as...

<soap:Envelope>
<soap:Header>
<soap:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Put </soap:Action>
<soap:To>uri:car-dealer </soap:To>
<car:order-number>415,325</car:order-number>
</soap:Header>
<soap:Body>
<car:order-update>
<car:colour>blue</car:colour>
</car:order-update>
</soap:Body>
</soap:Envelope>

So, where do we send the new state?

Well... to the order-resource; not the service that knows about the resource. At least that's what we do conceptually. That's how we reason about this at the application's architecture. Here we have a case where a specification changes our view of the architecture. It seems that services have disappeared (at the architecture level) and given their place to resources.

What's wrong with doing this instead?

<soap:Envelope>
<soap:Header>
<soap:Action>why:do:I:need:an:action?</soap:Action>
<soap:To>uri:car-dealer </soap:To>
</soap:Header>
<soap:Body>
<car:order-update>
<car:order>
<car:order-number>415,325</car:order-number>
<car:colour>blue</car:colour>
<car:order>
</car:order-update>
</soap:Body>
</soap:Envelope>

This says that the document order-update should be delivered to the car dealer. What's more, we can now do the following which is not easy with the resource-oriented approach:

<soap:Envelope>
<soap:Header>
<soap:Action>why:do:I:need:an:action?</soap:Action>
<soap:To>uri:car-dealer </soap:To>
</soap:Header>
<soap:Body>
<car:order-update>
<car:order>
<car:order-number>415,325</car:order-number>
<car:colour>blue</car:colour>
<car:order>
<car:order>
<car:order-number>415,326</car:order-number>
<car:colour>pink</car:colour>
<car:order>
<car:order>
<car:order-number>415,327</car:order-number>
<car:colour>red</car:colour>
<car:order>
</car:order-update>
</soap:Body>
</soap:Envelope>

You see? Three updates in one go and the logical recipient is always the service, not the resource.

Yes, yes, yes... you can model solutions where the resource receiving the message is the representation of an order-processing system but that's forcing you to expose as a resource yet another aspect of your service's internals, a process. Autonomy? Service boundaries?

Don Box suggests that we are eventually going to like the concept. Well, I've been trying to understand REST for some time now and I think I got it (Mark Baker?) but I still prefer service-orientation and the transfer of documents through message exchanges (always SOAP). But then again, who am I to talk to Don! about service-orientation?

IMHO, the use of the term "operation" in WSDL has done a lot of harm. I now wish that Jim and I had fought harder to support our recommendation to the WSDL WG to rename "operation" to "interaction". There are many who think that a "portType" or an "interface" carry application semantics. If we ignore the bad choice of names, a WSDL document only describes message exchanges while the input and output elements describe the format of the messages that make those exchanges. There is no suggestion (at least there shouldn't be) about the existence of operations or any other abstractions and their dispatch-related mechanisms. Any application-specific semantics are defined in the specifications that govern the documents being transferred.

I believe that we don't need multiple verbs/operations; we don't even need a limited number of them; but if we are absolutely desperate for a verb, then we can assume that there is only one called "ProcessMessage" which represents a door to the service boundaries. Messages entering the door disappear beyond those boundaries. As both Jim and I have previously described (just google "ProcessMessage" or "ProcessThis") we only have this one logical operation which is eventually replaced by transport-specific mechanisms like TCP/IP send/receive, SMTP verbs, HTTP PUT/POST, etc. So why introduce additional verbs? What do they add? And, offering an alternative to Don's example, couldn't we send the following message instead of having to overload the semantics of PUT?

<soap:Envelope>
<soap:Header>
<soap:Action>why:do:I:need:an:action?</soap:Action>
<soap:To>uri:machine-management-service</soap:To>
</soap:Header>
<soap:Body>
<management:shutdown-request>
<management:log>logging-service-EPR</management:log>
</management:shutdown-request>
</soap:Body>
</soap:Envelope>

The semantics of receiving a management:shutdown-request document are defined by the "WS-MachineManagement" specification. No operations. Just documents being transferred using SOAP.

(I never imagined I was going to disagree with Don... I must be wrong or I must be missing something. I do hope we'll see more descriptions/explanations/examples of the indented use of WS-Transfer.)

Finally, it seems to me that the idea of allowing representations of state to be referenced and becoming logical recipients of messages, albeit only through basic operations, goes against the principles that Pat Helland describes in his "Data on the Outside vs. Data on the Inside" paper to which I recently linked. Data inside the boundaries of the service are referred in the outside world by name. They are not addressed explicitly and certainly don't become recipients of messages; that's what services are for.

It seems to me that fewer and fewer people believe in the pure service-oriented approach. I start to feel lonely in this world (ok... there is also Jim but he doesn't count because he's a friend 🙂

10 responses to “WS-Transfer: I must be missing something (and I feel lonely)”

  1. Mark Baker
    FWIW, in REST, data isn’t identified, a resource is. Data is but a representation of the resource. This corresponds exactly with “Data inside the boundaries of the service are referred in the outside world by name”. Hmm, sounds like an interesting paper; I’ll have to give it a look.
  2. MikeD
    > Conceptually, messages are no longer targeted to services but, rather, to resources. This is the case with REST and WS-RF too I think that in REST, the messages are targeted towards a service, but they are /about/ a resource. Subtle but important difference. That’s why HTTP evolved the Host: request header (sort of) – so that a single service (defined by port 80) can process requests about many resources.
  3. Savas Parastatidis
    Hey Mark, I understand that REST is not only about data. I wasn’t suggesting that. That’s why I said that it may be possible to expose the “order processing system” as a resource. However, the architecture deals with the resources and not services. That’s the difference I am trying to point out.
  4. Savas Parastatidis
    Hey Mike, my point is that at the architecture level you don’t reason at all about that service, then one listening at port 80. In fact, if we had an implementation of the architecture that didn’t involve a process listening at that port, we wouldn’t notice and our applications would still be architected in the same way. The building blocks for applications in REST are resources while in Service-Orientation are services.
  5. Mike
    I must admit that, on first reading of WS-Transfer, I’ve come away with the same impression as you. What I don’t really get is why the payload (i.e. the GET message contents) has been placed into a WS-Addressing header rather than in the SOAP body. My reasoning up until today was that SOAP headers carried “out of band” information whereas, for me, the resource identification for a GET operation seems very much like “in band” information – i.e. it’s the very crux of the messsage so does it belong in a SOAP header? I’m sure there’s a great reason for it and it enables a bunch of scenarios that I haven’t figured out yet so I probably need to go and read some more.
  6. MikeB
    I was wondering what the body of ProcessMessage in a WS-MachineManagement service would look like. Would there simply be a switch/if statement to select the appropriate logic depending on which type of message was received? (assuming the service can process more than one type of message)
  7. Savas Parastatidis
    By “body of ProcessMessage” you mean the implementation, right? Well, since “ProcessMessage” is an architectural concept its concrete implementation may differ between hosting environments. First of all, there is no real operation called “ProcessMessage”. Instead, “ProcessMessage” represents the receipt of a message in an implementation (e.g., TCP/IP receive(), SMTP protocol, HTTP PUT or POST). Once a message is received through any of those mechanisms, the implementation details are irrelevant. One may choose to have a large switch statement with all the possible messages or a dispatch mechanism for method abstractions a la ASP.NET and Axis.
  8. MikeB
    Ok thanks for the explanation. I guess I was getting confused at the relationship between ProcessMessage and the ‘process’ method in your WS-Addressing code sample.
  9. Savas Parastatidis
    Ooops! You are right. That’s a WSE method that I overloaded but has nothing to do with the architectural concept that Jim and I call “ProcessMessage”. I guess it’s based on the same idea. Good point. Thanks!
  10. Omri Gazitt
    Savas, I agree that one has to be very careful with respect to abusing the state transfer metaphor. I don’t believe that everything in the world should be modeled as a resource. Transfer simply codifies the very useful REST pattern on top of the SOAP infrastructure. The intent is to do coarse-grained retrieval and replacement of representations, much like HTTP GET and PUT, but with all the extra benefit you get from composition with the other WS-* specs (security, RM, etc).