Iterating multiple soap responses with Yield Return
  Posted April 23, 2004    PermaLink    Comments (0)  

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.

Still more than 3 ways to loop it...
  Posted April 22, 2004    PermaLink    Comments (0)  

A discussion on looping in C# misses my favorite approach to looping, of course this only works if order of execution does not matter...

for (int i = foo.Length - 1; i >= 0; i--) {}

The big advantage here is that we are not going up to some unknown number that has to be stored on the side or accessed from a (potentially mutable) field. This saves one value on the register stack

It also works if you are trying to index the first occurance, although going forward and breaking out of the loop seems to work better in those cases.

21 Apr 2004 9:15 pm MDT: Edited to explain what I think is novel about it.

Streaming Multiple SOAP Responses
  Posted April 16, 2004    PermaLink    Comments (0)  

Sometimes it's just hard for the newest fangled spangeled technology like SOAP and WSDL to beat tried and true technologies like Comma Separated Values, and sometimes it is the most benign of examples that seem to prove it.

Consider the following situation: you are searching or listing some potentially large data set, like a file system. You don't know how much stuff you are getting, but you know when you do find something you know all you will ever need know about it. But conversly this knowledge is atomic: you know nothing until you know everything. Furthermore getting that information has some non trivial cost that is basically static. And for the sake of argument all of this API is hidden behind some horrible facade that you cannot access (yea, I could be less abstract but, you know, NDA this, trade secret that, confidential interface here, yadda yadda yadda). How would you write a SOAP service to access that and get the data?

The obvious solution is to queue all of the result up into a single query. That's all fine and dandy, except that you then get all of the data at one time. That may not be desireable: what if you are showing a table with that data north of the one comma when you pretty printed range and after five minutes without data the user/QA Engineer/Customer thinks the query is hung and kills the app, never mind the fact that the data was available within 2 seconds of submission, essentially we have made the time to first data the same as time to all data plus network overhead. Why? Because of Well-Formed XML constraints; I don't know the soap response is valid XML until I receive the close tag, and for an unbounded element I don't how many there are until the close tag for the wrapper appears, and then because of threading issues it just doesn't deal well with common soap toolkits.

Can we could cache the results from the query and get the results in multiple calls? Then we have to cache it on the server side which means we need to keep soap sessions or handle callback objects or other such messiness. And what if the query is aborted? Then how do you deal with left over data no one ever came to get? LRU methods could also cause the data to be pushed out before you could get it when you have a high number of users or calls unless you make the chances very big, not to mention the bug potential. And even if we could do a quicker call to get just some key for each piece of data and return that quicker we still would have to go back and make N calls, which if the overhead of each individual SOAP call is any single digit fraction of the time to get the data from the key (or worse yet, a multiple) then the first row may be 2 seconds but the total time to get all of that data is now 150% to 300% what it was before if the overhead was 1/2 or 2x.

So how does CSV fit into this? First off a CSV file can have full context for any given row taken out of the file at any point (the agreement of column meanings is the same as needing a WSDL to describe it). Parsing single lines is a rather trivial state machine that college freshmen could implement as a weekly CS101 lab. You don't need some magic end of content marker like a close tag, it's always a newline outside of quotes. Detecting when you are done is as simple as detecting the fact the file is closed, and if a user abandons a request mid stream the socket errors tell the querying engine to stop creating more data. It's much like feeding a baby: you move the stuff in the jar one spoonful at a time to the baby and you stop when the baby spits up, gets resistant, or you run out of baby food.

Optimizing Web Services are much like other optimization tasks, there are hot spots where you focus on tweaking the algorithm or dropping down to assembly language if you have to. And when you optimize for raw speed sometimes you get other pleasant surprises too: it's 10x to 100x smaller as well.

Make your MFC Apps look like Metal?!
  Posted April 09, 2004    PermaLink    Comments (0)  

Some people see beauty in the strangest things, like this abandoned project to provide MFC controls that look like Swing Components. It is four years abandoned, but even four years ago the author refused to make the fonts bold and use the horrible Lucida fonts.

That fonts are the biggest problem with the swing look and feel, even more than the "Owe my eyes it's purple" color scheme. So why did the ocean theme just fix the colors and never the fonts? That's going to make the ocean theme the least used new feature of JDK 1.5.

GridBagLayout, Best Done Visually
  Posted April 08, 2004    PermaLink    Comments (2)  

When Eclipse first rolled out their visual editor there were a couple of things I didn't like. The first was something that I had grown accustomed to in NetBeans (mostly because I saw how much it failed in Visual Cafe). The management of the components was not managed by a seperate code area or data file but it is extracted from the source and compiled code. What a recipe for screwed up code. What NetBeans does is it manages a <foo>.form file next to your <foo>.java and uses "guarded blocks" to render the meaning of that .form file, blocks you cannot edit directly. However you can render and insert code anyplace in that process (via the properties sheet) if you are an absolute control freak. It was hard to get used to initially, but for writing GUIs I think that it is the way, ultimately, to handle GUI writing in an IDE. What Eclipse is trying to do is Two-Way Editing, which I've never been able to be a well behaved enough coder to live with. It's usually turned into two way farking within the first ten minutes of use, and that's the ten minutes I decide that what I have is better.

That problem was a little annoyance compared to the second major hole in the Visual Editor, one that alan also found. This crippling problem is that there is no support for GridBagLayout. This is more than "a little way to go" but is a gigantic hole right in the bulls eye IMHO. I knew that this was going to be an issue when the demo video for the Visual Editor totally glossed over layout managers and went straight to absolute positioning. Absolute positioning is bad. It lives in that 20% of the 80/20 rule: the 20% that is english/windows/defaults only. Of course I am not targeting the 20% of the market that is english only, windows only, and default graphics setup (that other 80% either uses a non-windows platform, a language other than english, or they do things like crank up their font points). NetBeans does have a GridBagLayout editor, and a good one to boot. In fact if it didn't have one I may still to this day be a "code GUIs by hand" bigot.

Thank goodness for quality tools.