This week's CSLA study group sessions went nicely (see earlier post). I started off with a white-boarding session describing distributed objects and the trade-offs that must be considered before deciding when to split logical layers into physical tiers. We discussed network latency, “chunky“ vs. “chatty“ interfaces, how to turn a “chatty“ object interface into something more “chunky“ using a UI layer inside of a web service ... things like that.
Now Rockford has a great knack for explaining how things work in his books and that's a great talent. But I managed to take things down a step lower (or three) by explaining, not how, but why object serialization must occur. If objects could travel through a CAT5 Ethernet cable intact, the cable would have to expand with a lump much like you could imagine a large Anaconda who has just eaten an Ostrich. You can picture that lump slowly moving down the length of its body (not to mention feathers everywhere).
The plastic jacket that covers the actual wire inside a CAT5 cable is, actually, quite stretchy, so, in fact, business objects could indeed travel across the wire without requiring serialization. The problem is that some of our objects are quite large, and the lumps going through the wire would be quite like our now satisfied Anaconda friend. The difference being that our object lumps travel much, much faster.
The reason why Microsoft decided to create mechanisms to serialize objects into streams of teeny-tiny ones and zeros is because their lawyers (who are very smart) advised them against creating these object lumps. Plasterboard, the stuff that makes up much of the walls in our homes and offices is, as you know, very brittle. When big object lumps start flying down those wires at nearly the speed of light, the damage caused, and potential loss of life, from our walls exploding from the pressure of the expanding wires within, would bring lawsuits that would take the firm to its knees.
And so, the SOAP protocol was invented along with Binary Serialization so that our traveling, distributed, business objects wouldn't wreak havoc on known civilization.
OK, I jest. CAT5 cable does not expand, so objects can't really travel over the wire unless they're serialized first.
We made it through that discussion, and a discussion about UI in Charge, Class in Charge, Object in Charge ... though I think this last “in Charge“ topic is one we're going to have to revisit so all are quite clear on the differences. Some individuals in this group are very new to OO programming.
Next week, we shall continue on our journey through CSLA architecture concepts. I get to kick the week off with a discussion of Relational vs. Object Modeling; ERD's vs. Static Structure Diagrams and Object to Relational mapping.
I love this stuff!
Roy