Why I´m in love with applications as host-code-combinations: Software Cells #1

If you´re still sceptical and don´t believe the proposed definition of software applications as a combination of a host plus my problem solving code has any merit over the so far diffuse usage of the term "application", maybe I can convince you to rethink your position with a couple of pictures?

I think, once we are able to clearly delineate an application in the proposed way, we can start drawing pictures of software solutions in a new way. Let´s start with a single application:

I think, this is a simple picture and it is easy to understand. It does not imply much. There is just host and my assemblies. I think, all of your applications look like this, with one distinction: Except for when you develop an ASP.NET solution or a ServicedComponent, your Host is an assembly containing some custom logic specific to the solution you develop. But let that not stand in our way for the moment.

First let me make the picture even easier, let me replace the curved outline of the host:

I chose the simplest 2D shape to depict the host and put the custom assemblies right in the center in an opaque shape so we don´t get disturbed by to many details right now.
What we get is a Host with a custom code core at its center. The purpose of the core is to solve some problem, the purpose of the Host is to provide a convenient environment for the core to do its work.

Now let expand our picture: As you know, I think of the combination SQL Server + stored procs as a separate application. Then this is the simplied picture of a C/S solution consisting of two applications:

If we leave out the question how those applications communicate with one another, I´d say, this is a pretty simple picture: Two applications that belong together to form a solution. Their vicinity very naturally suggests a cooperation between the two. No statement is made and does not have to be made at this point about where those applications are deployed. They might run on the same machine or on different machines. But by distributing our code which solves a problem across two applications we know there is some gap between the distributed parts. Very likely this gap is expensive to bridge and needs special consideration.

But let´s move on to more complicated scenarios. How about a WinForms application (frontend) calling a Web service which functions as a facade for a COM+ component which in turn uses stored procedures in the backend?

I just needed to add a couple of triangles/Hosts and need not worry about the details of their cores.

I was just concerned with how the applications communicate with one another. But an intuitive premise of this kind of picture is: information flows between applications where they border on one another. That means, I could have drawn the picture also like follows to resemble the common 3 layered architectures:

You see, my definition of applications so far nicely complements our beloved application layer architecture model.

But before I dig any further into this new picture or model for application design - there a many details to flesh out -, let me give it a name.

Let me call those little triangles with the black core Software Cells, because putting many applications next to each other - e.g. in a large SOA picture - looks like a united cell structure from a biology text book, e.g.

Source: http://www.biolution.net

or

Source: http://www.digitalefolien.de

Each application for me thus is a software cell. The exact form does not really matter. A triangle is just the simplest 2D shape; so if you like, use squares, octagons or whatever you like to depict the outline of your application, to give it a surface other software cells can connect to. You can even go 3D: use a tetraeder or cube. Each edge or surface, though, should connect only two software cells/applications.

Also it´s ok, if you find regular shapes limiting to depict larger solutions consisting of many applications. A complex network of applications might need an n-dimensional space to connect all those software cells thru adjacency. But that´s hard to draw on a piece of paper :-) So what I suggest for complex networks is to view software cells not as simple onion cells (see 2nd picture above), but as nerve cells:

Source: http://www.mpg.de

Nerve cells reach out to other cells near and far. So can software cells. (Interestingly, the communication between nervce cells across synapses can be thought of a form of marshalling: electrical impulses have to be"serialized" into chemical messages (!) to cross the gap between two nervce cells.)

But more of that in an future posting.