A processThis Mismatch?
My recap of the processThis concept seems to have been interpreted as a suggestion for how I think things should be. To the contrary, I wrote it as a tool to verify that I understood what Jim and Savas were saying, not in advocacy of the scenario described.
I did so because I think there might be an impedance mismatch in the ongoing conversation, and I wanted to be sure I understood. Mark is making inroads to clarification as he addresses Savas’ model of GET:
I think the comparison between HTTP request/response and “processMessage” is incorrect; the comparison should be between HTTP POST and “processMessage”.
I perceive at least three possible interpretations of processThis, and it might help if the parties involved clarify which they mean (or give other choices altogether):
processThishas an input and an output, both of which are unconstrained.processThishas an input which is unconstrained and a status output.processThishas an input which is unconstrained and has no output.
I described (1) in my recap, and Jim Webber seemed to approve. I predict that Mark Baker sees (2), the equivalent to HTTP POST. And I suspect that Savas sees (3), by virtue of his Web Services model for GET.
May 20th, 2004 at 11:32 pm
Hmm, sorry Matt but I can’t figure out what you mean by “unconstrained” there, or even “status output” vs. “no output”.
May 24th, 2004 at 2:58 pm
Mark,
Judging by his response to my recap, Jim seemed to think processThis could have an output (it would be constrained by WSDL, not by processThis, hence “unconstrained”). This is contrary to what you and Savas are discussing, where processThis seems to never have an output document.
However, HTTP POST returns a status response. This is either being intentionally or accidentally overlooked when you and Savas agree that “processThis == HTTP POST”. I say intentionally because the discussion may be at a higher level of abstraction than the status response. But I say accidentally because I’ve yet to see anyone explicitly say that we’re talking about a higher-level abstraction, or talk about processThis returning similar status information.
I want to be sure that everyone means the same thing when they say “processThis”, so that we’re not all talking at angles to each other. Mutual agreement on definitions would help me immensely.
Does that make sense?
May 25th, 2004 at 12:29 pm
Hmm, it’s always a terminology issue at one level or another, eh?
The response to POST and my definition of processThis is “constrained” in a sense; that both are a result of the successful transfer of state, and therefore neither can (also) be used to indicate something else, such as the fact that a particular response document happens to be the results of a query specified in the input document (for the reasons I explained before). So I reckon that makes me either a #2 or #3 in that respect.
Regarding output, neither POST nor processThis need output, though it would certainly be useful to have at least a status response. But in some cases that isn’t possible. I’ve been tackling this is my current project where I have to support data streaming via TCP, UDP (without an explicit method), and HTTP (with POST). TCP at least has a backchannel upon which some status indicator can be piggybacked (including failed connection attempts), but UDP doesn’t at all in the general case. But the request semantics are the same in all three cases; please take this data. Moreover, it’s also possible for an HTTP POST to be accepted but the connection dies at such a point so that the server thinks it sent the response message but the client never received it. Yet another reason to decouple request and response semantics. I guess that makes me both #2 and #3.