savas parastatidis

Putting the operation name in body of a SOAP message

Mark Baker talks about the WSDL WG's decision not to require the name of an operation in the body of a SOAP message. I personally think that this is good. Web Services are all about exchanging information and not identifying methods, operations, functions, procedures that must be called. What services do with the information they receive, through message exchanges, it's up to those services. It's all about not making any assumptions about the programming model or architecture at the other end.

7 responses to “Putting the operation name in body of a SOAP message”

  1. Ram Gooding
    So Web services are about sending streams of opaque data to opaque end points and not having to know what’so in the data and the semantics that’re associated with it? Seems to me that we just need to standarize on a single WSDL portType called doWork. It’d make tooling a whole lot easier too.
  2. Savas Parastatidis
    Ram, If you think about it your suggestion is not very far from what we have now. We have a “receiveMessage” method. And i’d argue that it’s all we need. What the receiving service does with the message, how it processes and what how it maps it to internal programming model (that may have or may not have operations/methods/functions/procedures) it’s not of our concern. When we give an order form to a car dealer, we don’t care how they process it. We expect an outcome, sure. But we don’t ask them to call a method, procedure, operation, function. We just give them the order form and, according to the contract which says “if you give me an order form I’ll give you a car”, we expect a car in response. That’s the exchange message pattern.
  3. Ram Gooding
    Savas, the problem with that paradigm is that it was tried back in the 70’s and was called (I’ll paraphrase) “network programming using sockets and ports”. What you’re suggesting is that we should have stopped working on higher-level programming languages and stuck with TCP/IP or UDP/IP sendmsg and recvmsg. The reason we didn’t is that it makes it horrible to maintain, difficult to program and almost impossible to reason about. Taking your car dealership example, somewhere else I’ve got to be able to know that a specific endpoint is a car dealership and what message format it expects for the various operations it supports. Now, I’d like that to be the service interface, so I can immediately see the functional aspects of the service (these aren’t non-functional aspects). If it isn’t, then I could be sending my “buy me a car” form to a porn site! And I don’t think I’d want them to have my credit card details! If you look at your example from the real world, what you’re saying is akin to making all shops (let’s call a car dealership a shop for simplicity) have the same neutral facade. From the outside a consumer can’t see whether a shop sells cars, food, or porn. How do I know? Have I really got to visit each one to find out? Where’s the equivalent of signs and “functionality”? Now I suppose you might say “look in the yellow pages”, but all that tells me is that “neutral looking shop on street X is a car dealership”. It doesn’t tell me what documents it accepts. Sometimes perceives simplicity just hides (or shoves off to later) added complexity.
  4. Savas Parastatidis
    Ram, I absolutely agree with you that we need agreements in place to support meaningful interactions as to avoid situation where my “car order form” is given to a porn site. That’s why we have contracts in place. WSDL is a contract. It’s not a contract of what we instruct the service to do but, rather, it’s about the structure (and perhaps the semantics through other means, like RDF) of the information that the service is telling us is prepared to accept. I am not suggesting that contracts should not be in place. I am only arguing about the lack of assumptions about the way a service is to process the messages we are sending. We define interesting interaction patterns through this basic concept of message exchange. Policies and contract agreements are in place to guarantee interoperability. At no point I made an assumption about the programming model used to implement the processing of those messages.
  5. Mark Baker
    We’ve already got a handful of standardized “doWork port types”; HTTP POST and SMTP DATA, for example. But that’s VERY different than “receiveMessage”.
  6. Ram Gooding
    Mark, I agree (I think). Your post was a bit short, so maybe I’m reading too much into it, but here goes: I’d say that HTTP POST, SMTP DATA etc. are very different to receiveMessage because there’s some semantic meaning associated with them (albeit pretty basic, but it’s there nonetheless). Also,given these it’s been clear over the last decade that you can write some pretty impressive and scaleable applications. I always wished that the extensions to the HTTP method-set had arrived as the original spec. doc. described, but c’est la vie. However, I see POST et al as the basic building blocks (like TCP/IP sendmsg and recvmsg). I’d expect a Web service interface to tell me what operations it supports (e.g., buyCar or buyPorn). How it implements them (as HTTP POST, for instance) is not really my concern – I’ll leave that to the tools and deployment platform I run on.
  7. adara michaels
    Very nice guestbook. Keep up the good work!