We use the Wrong Patterns

One of the pronounced themes of Udi’s advanced SOA course is that we have misapplied familiar software patterns in an attempt to abstract away the complexities of distributed computing.

For a long time it was reasonably hard to do application level computing over a network. Even simple client /server operations required programming at the socket level. Yet application developers being who we are, we wanted abstractions. We had business needs to address. We didn’t want to get down into the weeds just to get computers talking to each other.

As object oriented programming was such a singular, dominant paradigm in the 80’s and early 90’s, object oriented solutions were developed to the network problem. So entered CORBA and DCOM. These technologies should have showed us once and for all how badly object orientation maps to distributed computing. But instead of realizing that the pattern was mismatched to the needs of distributed computing, the implementation and interpretation were blamed.

The rapid growth of the Internet exacerbated the problem as software vendors scrambled to create tools that met existing customer mental models while answering the question of how we were going to get all of this networking stuff to work. It was in this period that .NET became the premier tool for writing business code on the Windows platform. With it came the promise of “web services”.

If you are old enough to remember .NET’s launch, it was about web services. The plan was we would give up the component based VB6 application development model and move our apps to the web. Component vendors would become web service vendors, billing us per request. For example, instead of adding a spell checking component to our applications, we would send our documents into the ether for a remote spell check by a vendor, paying a mere penny or so for the privilege.

Inspired, us developers started building applications using web services and our trusty three tiers. It became a “best practice” to not let a web application UI (sitting on a server) talk to a database (often sitting on the same server) without going through a web service business layer (you got it.. on the same server). Developers were told that a tiered architecture was a decoupled architecture and that a decoupled architectures would be more manageable, more agile, and let us scale as future needs dictated.

So it wasn’t until we started moving these services to different physical boxes, often even in the same subnet, that the complexity of distributed computing suddenly came to bare. We had been fooling ourselves in our development environments and in our simple deployments -with all these things on the same box it was just interprocess object oriented computing.

Unlike in CORBA and DCOM where the pain was felt immediately and profoundly, object oriented web service architectures delayed the pain until we really needed the architecture to work.

The problem is object orientation just doesn’t map well to distributed computing. In the Gang of Four book, oft thought of as the most important pattern text, recall the authors were creating a Word Processor – a single process mammoth application.

The irony is as early as 1994 we should have known knew better. It was then that Peter Deutch drafted his assumptions on the fallacies of network computing. It states clearly the errors traditional application developers will make moving to a network model. So it is doubly sad that these became adopted by vendors as best practices.

Prior to taking the course, I debated with a friend how wrong I thought it was that Udi called himself the “software simplist” given how complex his architecture seems to be. But afterwards, I believe Einstein’s paraphrased quote is appropriate. “Everything should be made as simple as possible, but no simpler.” If our object oriented patterns are not up to tackling distributed computing, then we need better, slightly more complex patterns.