Software Cells #2: Basic structures

In my last posting I introduced the term Software Cell to describe a software application. The minimally necessary ingrediences - a Host and my code to solve a problem (logic) - just looked like an organic cell once I drew some pictures of applications consisting of a Host EXE that contains some assemblies.

In this posting I want to drill down into the details of a software cell. Like organic cells it has a structure: A software cell has to deal with the outside world and I find it benefical to extract the necessary functionality for communication from the core. It´s a separation of concerns.

 

If an application is not selfsufficient but needs to get information from the outside world - or serves other applications as an information source -, then it needs structures to connect with or to be connected thru.

There are two categories of basic communication structures: Adapters and Portals.

Adapters reach out to other information sources/sinks, and adapt their interfaces to the needs of the core. The Core does not want to concern itself with the details of communication. It wants to live in its world of domain concepts and is shielded from the rough outside world by the adapters, who translate its requests to whatever the communication partners require.

Since there exist at least two general kinds of information sinks/sources, they are matched by two kinds of adapters:

A Resource Adapter connects to a "low level" data resource like a database or a FTP server or the file system. The abstraction level of the resource´s API is low compared to the level of the Core, there is quite an impedance mismatch to overcome. A Resource Adapter thus needs to do some "heavy lifting" in terms of adapting the low level data structures/operations of the resource (e.g. tables, rows or lines in text files) to the needs of the Core (e.g. Customer objects, SMS messages). (Although I used the common database barrell as a picture for a resource it´s perfectly ok to think of a resource as an application of itself. Unless however I write code to be hosted in the resource´s Host, I would not draw a triangle for it.)

An Application Adapter on the other hand connects to another application by a much higher level interface. Whether that´s a Web service or some other means is not important, though. The distinguishing characteristic of an Application Adapter as opposed to a Resource Adapter is the smaller (or even non-existing) impedance mismatch between the data model of the communication partner and the Core. If an Adapter does not need to do "heavy lifting" in order to connect the application to the outside world, I consider it an Application Adapter.

With both adapters the control flows from Core to the outside world.

Each Software Cell can contain an arbitrary number of adapters of both kinds.

If the outside world wants to use services of the Core, however, it needs to go through an Application Portal. The portal provides an interface of some kind thru which operations can be initiated and data can passed to the application. Control flow is from the outside into the application. Whether the portal is implemented as a SOAP Web service or as a custom protocol on top of TCP/IP is not important. The portal just defines some communication endpoint to connect to.

Of course each Software Cell can contain an arbitrary number of portals.

Now, after code for communication has been extracted from the core, what remains in the Core? The Core contains only code necessary for solving the problem. Call this logic or domain logic or business logic or whatever. For calculating prime numbers this could be just one method implementing Erathostenes´ sieve. That´s all. But it also could be many assemblies all working in concert to do some complex data analysis. The Core´s task is to do the problem solving, nothing more, nothing less. And when it needs to access outside information, it uses adapters. In turn, if the Core´s work is to help other applications, it is sent requests thru a portal.

For me it´s very important to distinguish the Core´s functionality from data access and data presentation. In essence, an applicaton should be able to do it´s work without any user interface. (Yes, even a highly visual game.) My recommendation is to design the "blind" Core of an application first without thinking of specific presentation requirements and the details of information access. Later on you can worry about all that, but don´t let uncertainities about a datagrid or database API distract you from your real business: solving a domain problem. Adapters, portals and even the user interface thus are more or less "infrastructure". And we all don´t want to waste too much time working on infrastructure; we´ve more important things to do ;-) (Yes, I know somebody has to position those text boxes and read the data from the database. I´m just trying to say, most of the time that´s not really the important stuff.)

Since I have mentioned the user interface what about it? Where does it fit into the Software Cell picture? I think, it should be another structure within the Cell:

The user interface is implemented by the User Portal. The User Portal is a portal, because again, control is flowing towards the core. The user controls the operations of the core by clicking buttons and menu items and entering data. But since it´s a less uni-directional communication than thru an Application Portal and (often) has to do with visualization, I used a pentagon as the shape for the User Portal to distinguish it from the Application Portal.

To finish off let me show you a couple of drawings for common Solutions:

(Please excuse me leaving the little lines with arrows out for the moment. I guess the informaiton flow is obvious.)

 

 

To me these little drawings are quite easy to understand. The clearly show the boundaries of each application and they show how much work has to go into "communication infrastructure" in each application, i.e. which adapters and portals are needed.

What´s left now? We need to talk about the substructures of adapters and portals. We need to talk about interfaces. And we need to talk about the "inter software celluar space". And, yes, I guess I need to say a couple of words about why I think this kind of model is valuable even though we have layered architectures and onions and fiefdoms.

4 Comments

  • I am enjoying this series of articles please keep them up. Also just to confirm, what are you using for your drawings?

  • @dru: Thx for your positive feedback! Stay tuned for some more posts on Software Cells.



    I use Visio for the drawings.

  • This is really good stuff. I came across your series of “software cell” blogs yesterday and really like your approach (as in “yes, yes, that’s what I’ve been trying put my finger on”.) I don’t know if I’m sold on the term “Solution” to explain a cohesive grouping of software cells (applications). The term seems so tightly coupled to a .Net .sln I just don’t know if everyone will easily make the thought transition. However, your overall description of Software Cells, cores, application adapters, resource adapters, portals and their described inter-relations and intra-relations is sweet.



    In my mind, this same story could be told with traditional terms but, unfortunately the terms have been used/misused by so many people (myself included) in so many different ways that it becomes difficult to have an objective conversation, and perhaps the Software Cells story can help. I think I’ve traditionally used the term Application where you have used the term Solution, and I’ve traditionally used the term Tier in place of your Software Cell. In my mind a Tier is a group of code that performs some core job, and needs to be hosted (IIS, ES/Com+, windows service, or some other executable host) I’ve also always been very clear and explicit about differentiating which Layers of code within a Tier have contact with the edge of the Tier, as you would describe your “adapters” and “portals” to have. Even though I’ve used the term Layers to describe this separation of duties from core code, I have not really looked at them as stackable layers (although I end up drawing them as if they were), but simply a way of codifying separation of responsibility from “core”. Your Software Cell depiction does a good job of removing the unwanted perception of stacked’ness that might come along if the phrase “adapter layer” or “portal layer” was used, even if the intended meaning was the same.



    Unfortunately though, using terms like Tiers couples thinking to “n-tier”, and as such isn’t general enough that people can easily extend to the SOA world. I think your Software Cell story is general enough that it can help describe these units of stuff regardless if we are talking n-Tier relationships or SOA.



    I am also of the mindset, that a single service that might be part of some larger SOA is really an Application (in a traditional sense), which means that it is really a cohesive grouping of 1 to n Software Cells (or Tiers in my traditional sense), with 1 to n defined “Potals” of entry? I think this is what you are saying too? Which, if I’m following your train of thought, could also mean that a SOA service could be a Solution in and of it’s self if that was it’s intended solution purpose was; such as Map Point?



    Additionally, a large Solution might be made up of:

    o a Software Cell with an exposed User Portal or Application Portal

    o some application adapters that speak to other “Solution” Portals (as in a Public service such as Map Point)

    o some application adapters that speak to Applications (as in the portal of a private service built as part of my overall Solution and consisting of a group of hosted software cells, which could be hosted in IIS, ES, Window Service, or some other exe, etc),

    o some resource adapters to (file systems, DBs, etc.)

  • @Scott: Thanks for your detailed feedback! I´m glad you like the concept of Software Cells.



    I share your concern about the term "solution". But still I don´t know any better description, since a set of Cells is supposed to provide a solution to a problem. Maybe a more general term would be "System" or "Software Cell System"?



    Of course my "story" can be told using different and existing terminology. And I don´t claim to have invented anything. To the contrary: I want to clarify the existing and put concepts into a more precisely defined position, like Host or data access.



    Another reason for me to come up with a new model was frustration over the use of terms like "layer" and "tier". The German language cannot easily differentiate between the two (they are both called "Schicht"). So in Germany we have an additional problem, when talking about "Schicht": what do I mean, layer or tier. But with Software Cells its easy: you´re either talking about a single application or several applications. Whether they are organiszed as layers (building on each other) or not is irrelevant.



    I agree with you on a SOA service probably often being a Software Solution (or System) rather than a single Software Cell aka Application. But in the end this too is irrelevant for many discussions. SOA is on another abstraction level. Only when you drill down into a SOA service you see whether it´s a single Software Cell or several.



    When a service is constituted by severeal Software Cells, then the service´s portals are the sum of the published portals of the participating Applications.

Comments have been disabled for this content.