A processThis Recap
I’m a recent entrant to the blogging community, but I was getting so much out of one side of the conversation, I wondered how much better having both sides would be. I suppose I knew that someone would eventually respond to one of my entries, but I still managed to be surpised when it happened!
Jim Webber stumbled across my entry on uniform interface, and took issue with requiring an interface definition for a web service. His commentary there, and Savas’ recent piece, On the REST verbs vs. “processThis” discussion, are helping me understand their position.
Some key points that I missed early on:
processThisis an imaginary method- the imaginary
processThismethod has the same semantics as POST does in REST, but can be bound to any underlying transport mechanism processThisby itself is constraintless- WSDL constrains which messages are exhanged and how that happens.
To come back to concrete examples, let me offer the following:
I want to find some light reading for my upcoming vacation. I send a message to BookMonger, Inc. requesting books on Web Services. Let’s say that is a TopicSearch message. BookMonger returns me a TopicSearchResult message with some titles, descriptions, prices, etc. I form and submit a BookOrder to order Jim’s book “Developing Enterprise Web Services: An Architect’s Guide”. BookMonger sends back an OrderStatus indicating that the order is approved and that they expect it to ship within 24 hours. I’m impatient, and I send an OrderStatusInquiry every hour to check on my order. BookMonger obligingly responds with an OrderStatus each time. When the book (finally!) ships, they send me an unsolicited OrderStatus letting me know that the order has shipped.
There appear to be as few as two endpoints involved in this exchange. One for BookMonger, and one for me (to receive that unsolicited OrderStatus message). Perhaps the BookMonger endpoint is bound to HTTP, since BookMonger’s services seem to be mostly request/response. My endpoint is receive-response-only, and so might be bound to SMTP.
Any time a message is posted to an endpoint, the endpoint recognizes the message and handles it. In this way, the imaginary processMessage verb is invoked.
Not every endpoint recognizes every message, though. If I posted my BookOrder message to ToasterMonger, they wouldn’t know what to do with it and would presumably reject my message. And so enter WSDL. WSDL seems capable of making it clear that ToasterMonger doesn’t accept book orders; ToasterMonger wouldn’t define a BookOrder message.
BookOrderShredders, on the other hand, could conceivably define a BookOrder, but surely the results of posting a message to their endpoint are different! So I potentially have to distinguish between the outcomes of posting the same message to two different web services. I’m not aware that WSDL provides the means for making this distinction. Savas claims that
There are no semantics attached to the imaginary ?receiveMessage?
They must be attached to something, though, so I suppose that it’s the combination of the endpoint and the message.
Thanks for putting your thoughts out there, guys. Is this an accurate description of the processThis concept? Jump in and clarify it for me.
April 30th, 2004 at 9:15 pm
Right on mate!
Now you’re telling it like it is, or at least how it should be
And a wonderful choice of book to order too!
Jim
May 4th, 2004 at 11:00 am
My response;
http://www.markbaker.ca/2002/09/Blog/2004/05/02#2004-05-garland-processthis
May 11th, 2004 at 5:37 pm
Mark,
Insightful as always; thanks for your contribution!
I’m guessing that the Web Services folks are saying “processThis” while imagining that both the input and output messages are defined in WSDL. If I strike the sentence that equates processThis to POST, I think the recap becomes self-consistent and represents what Jim and Savas are getting at. Re-read it in that light and see if you agree.
Significantly, what you seem to have hit upon is that the semantics of processThis may not be the same as those of POST.