Masterminds of Programming Book

O'Rielly's new Masterminds of Programming book includes interviews of me and Tom Love (Objective-C), Falkoff (APL), Kurtz (BASIC), Moore (FORTH), Milner (ML), Chamberlin (SQL), Aho, Weinberger, and Kernighan (AWK), Geschke and Warnock (PostScript), Stroustrup (C++), Meyer (Eiffel), Wall (Perl), Jones, Hudak, Wadler, and Hughes (Haskell), van Rossum (Python), de Figueiredo and Ierusalimschy (Lua), Gosling (Java), Booch, Jacobson, and Rumbaugh (UML), Hejlsberg (Delphi). Its an honor to be part of that crowd!

My interview reiterates and expands on the brick analogy I've developed in this blog. My interests are more in the components that languages produce, not languages themselves. I have often described Objective-C as the soldering gun that helps to build and use Software-ICs. I had exactly that metaphor in mind when I invented it.

However OOP-style classes are very small granules; grains of sand when bricks (and even larger) components are needed. SOA services are very large-granuarity components. The trusted security components mentioned below are small (sub-SOA) components used to make them. In other words, if the enterprise is a city, SOA services are buildings, trusted security components are bricks to make the buildings, and OOP classes are sand, mud and straw used to make bricks.

The problem is that our industry has not yet started making real bricks, fully encapsulated (no dangling dependencies), standards-compliant interfaces, tested for compliance, and certified as trusted components. Rather we use mud bricks constructed at each building site from whatever mud and straw is at hand (JBOSS, java.net, Spring, etc) by whoever is part of that project. Since components aren't trusted, every SOA service must be individually tested and certified from the ground up since the qualiity of mud bricks depends entirely on the skill of whoever made them. It's a big problem.

Certification and testing is just one of the differences. As with mud vs real bricks, there are technical differences involved in tightening up encapsulation so that changes in underlying dependencies won't invalidate a trusted component. That is why I use OSGI as the basis for SoaKit, a SOA security components suite I've been working on for several years. I'll describe that in more detail when I get a moment.

I'll close here by relating this analogy to the Free and Open Source (FOSS) movement. FOSS is typically involved in producing low-level classes (mud and straw) for others to make higher level components from. FOSS components are free, like mud bricks, which anyone can build from the mud and straw at any construction site. Real bricks, on the other hand, are not free, although they are  made from exactly the same no-cost materials. The trust requirement leads to an obvious business model.

It may seem odd that anyone would choose to buy real bricks when mud bricks are available for free. Yet that is the norm in every industry but ours.