My previous post on Streaming Multiple SOAP Responses actually was going somewhere web services related (other than 'CSV Rules! (for tabular data)'), but it got rather long in the tooth so I truncated it.
So how could you solve this with SOAP? You cannot use an array of returns, because you have to parse that last closing element to established well formedness before you pass the response out of the soap layer. But of course, you could just use multiple responses in the same stream, complete with multiple soap envelopes. Kind of like when you and your three roommates get the same credit card offer, the post office box has three slightly different envelopes. Message Queues, SMTP, and other strange transports may have difficulty expressing a complete set of the responses and linking them with a request. But In HTTP (the most common transport) this is simple: you send the documents back to back, and when you would normally complain about data following the document element instead you sever the stream and start a new document, as though it's in a different stream. You could do more strange stuff like require one envelope per chunk to aid in parsing, but intermediaries that don't understand that requirement may make new chunks or even merge chunks, it's their rights as proxies.
Interestingly enough, in the 2.0 work of WSDL the W3C separated the semantics of the content of the operations from their use. Part 2 explains Message Exchange Patterns. Even though all the patterns are zero or one request responses my quick perusal did not indicate any prohibitions from extension patterns supporting multiple responses (correct me if I'm wrong), so in theory some semantic like this could be done with enough standardization, like say a
in-multiple-out pattern. I suppose you could do multiple requests, but that is about as usable as a multiple-instruction-single-data CPU architecture; theoretically robust and complete but practically useless.
But there was one piece missing from this puzzle... how does this gently transition to simple language features? If you return an array and stream the responses you then have to wait yourself to get all the data before returning, which really defeats the purpose of a dribbling stream. ONDotNet however shows a potential answer in a new C# language construct, the
yield return. When you have a piece of data you immediately call
yield return foo and that signals the language to go in and out of your method context to push the result down the wire. In a non C# context rather than using goofy context methods and listeners a similar thing could be done by modeling the methods as stateful iterators.
It could happen, in a standards driven world in 2-3 years on a broad basis perhaps. This may be the most compelling reason to do something other that zero or one request or response patterns already described. But I'm a realist, CSV will have to do for a good while.