skip to content

What are the four WSDL 1.1 operation types, and which of them can a SOAP-over-HTTP service actually expose?

level: juniorimportance: should knowfreq 14%

answer

  1. who sends first, who answers
  2. order of input and output
  3. only two get a binding
  4. one-way still gets an HTTP response

basics

~10 s

WSDL 1.1 defines one-way, request-response, solicit-response and notification operations. WSDL 1.1 itself binds only one-way and request-response, and WS-I Basic Profile forbids the other two, so a SOAP-over-HTTP service exposes those two.

solid answer

~40 s

WSDL 1.1 calls its operations transmission primitives, seen from the endpoint: **one-way** (it receives a message), **request-response** (it receives and sends a correlated reply), **solicit-response** (it sends and receives a correlated reply) and **notification** (it only sends). The order of `input` and `output` inside a portType `operation` tells you which one it is. WSDL 1.1 defines bindings only for one-way and request-response, and WS-I Basic Profile 1.1 says a description MUST NOT use the other two. Over HTTP a one-way call still gets an HTTP response: the profile requires an empty entity body, recommends `200` or `202`, and forbids the caller to read a `2xx` as proof the message was valid or processed.

go deeper

for a junior

Recall the four names and who sends first in each, and that only one-way and request-response are used with SOAP over HTTP.

for a middle

Explain how element order reveals the type, why WSDL 1.1 binds only two primitives, and what the HTTP response to a one-way call may contain.

for a senior

Show the operational consequence: one-way calls hide failures, so you design confirmation or callbacks explicitly instead of trusting a 2xx.

for a principal

Decide when an interaction should be one-way at all, weighing caller simplicity against silent loss, and how callback services change ownership.

## Four primitives, seen from the endpoint WSDL 1.1 describes an endpoint's abstract interface as a `portType` holding `operation` elements. It calls the message patterns **transmission primitives** and names four, always from the point of view of the endpoint being described: | Operation type | What the endpoint does | Elements, in order | |---|---|---| | **One-way** | receives a message | `input` | | **Request-response** | receives a message, sends a correlated message | `input`, `output`, optional `fault`s | | **Solicit-response** | sends a message, receives a correlated message | `output`, `input`, optional `fault`s | | **Notification** | sends a message | `output` | There is no attribute that names the type. A reader works it out from **which elements are present and in which order**: an `input` followed by an `output` is request-response, an `output` followed by an `input` is solicit-response. A one-way operation has no `fault` element in its grammar, so it has no way to describe an error reply. WSDL 1.1 explains why it models request-response and solicit-response as primitives rather than as two one-way messages: they are common, the pairing can be correlated without extra flow information, and some endpoints can only receive messages that answer a synchronous request. ## Only two of them have a binding The four primitives are abstract; a binding says how they travel. The Note is explicit: "WSDL only defines bindings for the One-way and Request-response primitives", and it expects specifications for the other two to bring their own binding extensions. None became part of the SOAP-over-HTTP picture. WS-I Basic Profile 1.1 closed the door for interoperable services: - **R2303:** a description "MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition." The intuition is the transport. With HTTP, the endpoint described by the WSDL is the HTTP server; it can answer requests but it cannot open a conversation to a client whose address it does not know. Solicit-response and notification need exactly that. ## One-way over a request/response transport HTTP always produces a response, so a one-way operation still receives one. The profile pins down what it may contain: 1. **R2714:** for one-way operations an instance MUST NOT return an envelope; "the HTTP response entity-body must be empty". 2. **R1112:** a successful response without an envelope SHOULD use `200 OK` or `202 Accepted`, and the profile asks the caller to treat the two as equivalent. 3. **R2727:** a consumer MUST NOT read a `2xx` as meaning "the message is valid or that the receiver would process it". 4. **R2750:** a consumer MUST ignore an envelope that arrives anyway. The profile spells out the consequence: a one-way operation cannot produce processing-level responses or errors, so a `500` carrying a Fault cannot come back. The `2xx` only says the transmission was accepted. SOAP 1.2's HTTP binding agrees on the mechanics: when no response envelope is available it answers `202`. ## Designing with only two primitives Because the endpoint cannot call out, designers model asynchronous interactions differently: - **Callbacks as a second service.** The client side publishes its own WSDL with a one-way or request-response operation, and the service calls it later. Each side is then a server for the operations it receives. - **Correlation in the messages.** The two calls are tied together by an identifier in the payload or by addressing headers, which are a separate specification's concern. - **Choosing one-way deliberately.** Use it only when the caller truly does not need to know whether processing succeeded, because no fault can return on that exchange. WSDL 2.0 replaced the four primitives with message exchange patterns identified by URI, such as in-out and in-only; that is the WSDL contract's story, not the binding's. ## Interview angles - Naming all four types and saying which side sends first. - Explaining why a one-way call over HTTP still returns a status, and what that status does not prove. - Recognising that a WSDL 1.1 portType with an `output`-first operation will not pass a profile check. A compact portType shows two of the four shapes; the element order is the whole signal: ```xml <wsdl:portType name="OrderPort"> <wsdl:operation name="SubmitOrder"> <!-- one-way --> <wsdl:input message="tns:SubmitOrderMsg"/> </wsdl:operation> <wsdl:operation name="GetStatus"> <!-- request-response --> <wsdl:input message="tns:GetStatusRequest"/> <wsdl:output message="tns:GetStatusResponse"/> <wsdl:fault name="unknownOrder" message="tns:UnknownOrder"/> </wsdl:operation> </wsdl:portType> ``` Reversing the `input` and `output` of `GetStatus` would turn it into a solicit-response operation, which no SOAP-over-HTTP binding in WSDL 1.1 can carry.

  • A partner's one-way SOAP operation returns 202, but the order never appears in their system. What does the 202 tell you?
    Only that the HTTP transmission was accepted. WS-I Basic Profile 1.1 says a consumer must not read a 2xx on a one-way operation as meaning the message was valid or will be processed, and no Fault can come back on that exchange. You need a separate confirmation path, or a request-response operation if the caller must know.
  • How does a WSDL 1.1 reader tell a request-response operation from a solicit-response one?
    By element order inside the portType's operation. Request-response lists input then output; solicit-response lists output then input. No attribute names the type.

saying these in an interview costs you the question

  • Notification operations let a SOAP-over-HTTP service push events to its clients.
  • A one-way operation over HTTP gets no HTTP response at all.
  • A 202 on a one-way call confirms the receiver processed the message.
  • WSDL 1.1 has an attribute that declares each operation's type.
  • A one-way SOAP operation can return a Fault with HTTP 500.