I've noticed an interesting trend in the world of software, and it’s starting to occur in more places. We used to write programs taking either a top-down or bottom-up approach, but the paradigm is shifting. We're starting to architect our applications using an inside-out methodology and gain powerful benefits from the new perspective. Interestingly, the benefits seem to come at very little cost.
One of the earliest examples that comes to mind is Object-Oriented Programming (OOP). With OOP, the function, which used to be the smallest quanta of software, was encapsulated into the class, which became the new fundamental building block. Objects called methods, rather than functions operating on data. One exception here is that OOP was not a low-cost endeavor. I still remember spending a year not knowing how to write a program anymore, as I tried to rewire my brain for OOP.
Another early example is event-driven environments, in which the operating system or windowing system would call into your code as events took place, rather than your code driving the flow and calling the operating system. Again, learning to write Windows programs hurt. Badly.
What I've noticed recently, though, is that examples of inside-out architecture are starting to multiply, and they’re not nearly as painful as the two examples above. It's happening in multiple domains and in more subtle ways. You don't have to completely change the way you architect an application, yet these subtle tweaks in architecture are having significant impacts without being completely invasive.
One example of this is Inversion of Control (IoC)/Dependency Injection. This is such a wonderfully simple concept, but hugely powerful. Your code is cleaner, because objects are given what they need, rather than having to actively go get it for themselves. You write only the code that you really care about, and the glue code is provided by a lightweight container. You get a lot of benefits including simplicity and testability, and it costs little more than providing some setters and a bit of wiring in XML.
Similarly, there is Aspect-Oriented Programming (AOP) . With AOP, you conceptually assign the execution point to your code, rather than placing your code at the point of execution. Again, you get so much power and productivity from such a deceptively simple variation in approach. The Spring framework gives you the benefits of both IoC and AOP with so little effort that it seems to violate the laws of thermodynamics.
Hibernate and JDO have changed the way we deal with databases. Rather than placing database read/write code within an object, we now look within an object and persist it with external code in a sort of pseudo-container. Reflection and bytecode manipulation are important enabling technologies that are themselves an example of software turned inside-out.
Closures are another place where things get turned inside-out. Rather than calling code from a function, you pass the code into the function. It's a concept that's been around for years in some languages, but it's starting to become more popular and available.
Service-Oriented Architecture (SOA) is another increasingly popular inside-out architecture. Rather than writing an application with internal functions or services, the services have become external resources that any number of applications can access. DLLs, COM, DCOM, and CORBA were early examples of this, but the concept has moved from a deployment strategy to an application architecture.
One of the newest structures in integration architecture is the Enterprise Service Bus (ESB), which makes application integration an entity in itself. Rather than writing integration code within your application, your integration layer provides the mechanism to integrate everything in one place. ESB is like applying IoC and AOP concepts to application integration. This realization led me to two new acronyms and a nursery rhyme:
- Aspect-Oriented Integration (AOI)
- Integration-oriented Inversion of Control (IoIoC)
- Old MacDonald had a bus, IoIoC
And on that bus he had some apps, IoIoC…
If you connect the dots, I think will find that there's something evolutionary and unconscious going on here with this trend of turning architectures inside-out. Even though there are clear differences in these various technical advances, I find a hint of commonality among them. With apologies to Sun, perhaps the container is the application.
Are you aware of other places where architectures or structures are turned inside-out and yield disproportionately large benefits from a seemingly simple twist? What else might we turn inside-out? What unwieldy or difficult architectural problems might improve when put through this topological wringer? Maybe an awareness of this trend will lead us to more deliberate innovations of this type.
I believe in what you do I believe in watching you It's what you do I could turn you inside-out What I choose not to do I could turn you inside-out What I choose not to do "Turn You Inside-Out" R.E.M.