Software Cells #3: Drilling down into the cell structures

Now that I have explained the basic structure of Software Cells I need to drill down into the details of its structures. What´s the design of a Core, of Adapters and Portals?

Let´s start with the central piece of every Software Cell, the Core. The Core´s task is to solve a problem, e.g. calculate the digits of Pi, manage invoices, edit bitmaps, or compile computer language source code. Whatever the purpose of your application is, there Core is the one to control everything towards your satisfaction. There is no Application without a core. But there are Applications without Adapters or Portals.

Since the Core is the workhorse of an Application it sure should not be implemented as one piece. Right to the contrary! You should modularize it as much as possible. So a Core can look like this:

It consists of several components. (For now lets leave any "priorization" out of the picture.) They work together to solve the Application´s problem. But they are not concerned with direct data access or user interaction or application interop. That´s all the task of adapters and portals.

Since user interfaces traditionally are so at the center of application development, let´s look at the User Portal next.

As you might have guessed, a User Portal implements the MVC pattern. It can contain many views and controllers and models. Most important to note is, the controller manages the access to the Core. (In simple scenarios, a single WinForms form might implement view and controller at the same time.) The user interacts with the view (e.g. by pressing a button or seeing a chart), which reports any user interaction to the controller thru events.

The other path from the outside to the Core is thru an Application Portal. It allows other applications to access Core functionality.

To fulfill this task, an Application Portal needs at least a facade, i.e. an entrypoint into the application with a published interface other applications can connect to. Although the facade is called facade it needs not necessarily be a class callabled via SOAP. The facade could be a TcpListener/TcpClient combination implementing some network protocol (e.g. FTP or homegrown). If an Application Portal needs more substructures before a call to the Application reaches the Core depends on the type of Portal, operations and messages.

The Application Adapter works the other way round: it lets the Core access another application.

The low level access is done thru a proxy (like a Web service proxy generated from a WSDL document). But a Core should make itself not dependent on an interface description it might not control. (Think of a WSDL document published by some service offering on the Internet. You never know when and if and what way this WSDL will change.) Rather the Application Adapter should contain a layer called "High Level Application Access" shielding the Core from the details of accessing another application.

Finally the Resource Adapter should follow the same pattern:

The Core does not know about the details of accessing a resource. It wants to see a high level interface of it. That´s provided by the High Level Resource Access layer (HHRAL) of the Resource Adapter. At the other end is the resource´s API. And in between might sit a Low Level Resource Access layer to unify different APIs for the HHRAL, e.g. a generic ADO.NET managed provider to level out differences between database products.

You see, a Software Cell is not just a shape with a blob in it, but consists of a rich set of structures and substructures. The Core has the responsibility to solve a problem, and Adapters and Portals connect it to the outside world, since information processing still is about input/output.

The main purpose of the substructures of Adapters and Portals is to bridge the impedance mismatch between the outside world and the core, as well as isolate it from changes happening out there. At the basis of Adapters lies an API (either a dedicated API like ADO.NET or a automatically generated one like a Web service proxy (which again is based on System.Net)).

Since Adapters are layered, now you might ask, why I think Software Cells are a valuable concept? Well, my answer is, the well known layer model has two flaws.

Source: www.microsoft.com

1. It is only concerned with logical concepts. There is no connection to the implementation of an application, i.e. to assemblies or hosts. In addition I find the layer model imprecise in its use of the term "application".

2. The layer model seems so easy to understand, because we are used to the 7 layer OSI model for network communication. But there is a fundamental difference between the two: OSI layers raise the abstraction level one by one - but the fundamental task of each layer is the same: transport information from A to B. In the layer model, though, the abstraction level does not (necessarily) rise from layer to layer. Instead the tasks of the layers differ fundamentally (one layer is concerned with accessing a resource, one with complex algorithms, another one with presenting information). To depict such fundamentally different things as layers, I think, is contraproductive. I makes it harder than necessary to understand what layers are, which functionality to put into each layer, how to design their interaction.

Software Cells try to overcome the limitations of the layer model. They integrate logical concepts (e.g. Adapter, Portal) with physical artifacts like a Host. They precisely describe what an application is, and what "distributed application" means. And they still allow you to model the traditional layers - either within an Application or as a system of Applications.

And finally in Software Cells the different tasks are depicted differently. Also, whether the abstraction level is equal among the structures is not of any concern. Different responsibilities are assigned to different parts without any suggestion of a "priority".

So where are we now? We know the structures and substructures of a Software Cell. But we don´t know how they interact. And we don´t know how Software Cells interact. That will be the topic of my next posting on Software Cells.