WSDL 2.0 Operation Confusion I started this originally as a comment to Dave Orchard's blog entry about leaks in protocol abstractions, but it got kinda long. So, I moved it here as a proper entry.

As I don't claim to be an expert on WSDL (1.1 or 2.0), I'm slightly confused by the fact that you can apparently declare an operation style in WSDL 2.0. I haven't looked at the specification since around December, but in some of the work that I'm doing at the moment, I ended up bumping into it trying to determine if the message exchange patterns specified by the JBI specification implicitly assumed synchronous or asynchronous behavior.

Somehow in all of this and a few google searches later, I discovered David's blog entry. I'm wondering if the specification of the optional operation type at the interface level isn't another example of this type of protocol leaking.

The reason that I say this is that my understanding of the old 1.1 portType/operation was to specify an abstract description of the messages supported by the interface. The 1.1 specification seems to provide a derived or implied MEP based on the child elements (input/output/fault), however it stresses that the mechanisms for obtaining those messages were left to the binding:

Note that a request-response operation is an abstract notion; a particular binding must be consulted to determine how the messages are actually sent: within a single communication (such as HTTP request/response), or as two independent communications (such as two HTTP requests) [WSDL 1.1].

I realize this is only tangentially related to his post (and that David and the rest of the working group have probably thought about this quite a bit), but I don't understand why it is important to restrict the interface operation semantics globally. From a service interface perspective, isn't it equally valid to use asynchronous messaging or synchronous RPC (potentially performed over two asynchronous calls)? You would get the same messages for input/output and fault in both cases. You may actually want to specify different QoS at the binding layer to make your application code simpler if you're consuming the service by connecting to a different endpoint (for example, using a request/response HTTP call).

With what we have at the moment, the service and the consumer just need to know what messages they're going to get, but that communication can happen over asynchronous or synchronous channels. I was planning on taking advantage of the fact that the abstract operation didn't care about the calling semantics of obtaining the messages and let that part of the picture be filled in by the binding (I'm not using SOAP or regular HTTP). The way it was, I was going to have to come up with some clever custom binding stuff anyway, but the 2.0 spec may blow that plan out of the water because I'll need to at least support 1.1 for a while in addition to planning for supporting 2.0 when it is final.

Any clarifications/rationale would be most welcome from David or anyone else. I'm sure I'm missing something obvious here...  ¶ 2:11 AM 0 comments