Software Cells #7: Putting Software Layers et al. into Perspective

In my previous posting I added the missing pieces to the Software Cell puzzle: communication technologies like .NET Remoting, MSMQ, but also ADO.NET. Now you know all the basic structures of any software:

• At the heart of your solution always is processing logic, the Core.
• Processing logic always needs to communicate with the outside, because software still is about processing input and producing output. I/O is done via Adapters and Portals.
• Core as well as Adapters and Portals run inside and under control of a Host. Logic + Host make up an Application or Software Cell.
• If non-functional requirements require it, you can split up your Core logic into several pieces that run in different Hosts. By distributing logic across severeal Hosts you produce a distributed Software Solution consisting of several Applications.
• Hosts can be chosen from a readily available set to which belong COM+, IIS/ASP.NET, BizTalk, and SQL Server, but also MS Word, MS Outlook, and even simple Console or WinForms EXE assemblies. Host differ in their offering of infrastructure.
• The communication technology for each Adapter and Portal can also be chosen from a set of technologies like Web Services, MSMQ, .NET Remoting, System.Net, System.IO, ADO.NET and many others. Which technology to choose depends again on non-functional requirements, but also on whatever the communication partner on the other end supports/requests.

So much for a wrap-up of the details of Software Cells. But what about the big picture? In how far Software Cells close a gap in the software universe, I tried to explain in a previous posting. But that still leaves the question, how Software Cells compare to the traditional Software Layer architecture and others?

Software Layers

First of all, Software Layers are a conceptual model of software, whereas Software Cells are very concrete. Software Layers distinguish between three fundamental parts within a software: frontend, business logic, data access.

This is all good and well, and it helps in structuring your thinking. But it does not help you much when you start implementing. Layers can´t really help you decide for example, where to put business logic. Also, the distinction between business logic and data access sometimes is not very clear. (Hence the ever recurring question from developers: "Should I put business logic in the frontend? Is it ok to have business logic in my database as stored procs?" Or to say it more generally: Software Layers don´t provide much help on deciding how many tiers your software needs and on which tier to put your code.

Also, Software Layers lack a sense of orientation. Where are they in terms of the software universe? Are Software Layers about a single application? Or are they about multiple applications?

According to the Software Cell terminology, though, Software Layers suddenly fall into place: Software Layers are a conceptual model for Software Solutions. If anything, they help you to structure your thinking about a whole solution - which possibly may later on consist of several Applications.

However, in my opinion, the importance of Software Layers is largely exaggerated. They are a concept from the mid 1990s when there was only single or two tier software and we needed a model to describe software with a third tier: an application server like MTS. But since then the world has moved on and we have a lot more choices for hosts of logic and we have a lot more connections between parts within the same Software Solution as well as different Solutions.

I´d even say, Software Layers stand in the way of flexible software architecture because they suggest, a Solution mainly consists only of three tiers (or Applications in Software Cell speak) and those tiers are strictly building upon each other (plus some orthogonal functionality like security, caching etc.). But this view is too limited. Why shouldn´t I distribute (business) logic across 5 Software Cells if this leads to a good solution? Why shouldn´t I encapsulate security functionality in a separate Application? Software Layers either don´t provide answers to these questions or they suggest this kind of thinking as inappropriate.

Now for my last blow to Software Layers: I think it is absolutely contraproductive Software Layers stack the frontend on top of the other layers. This has led to countless misunderstandings and bad designs, because it lures developers into giving the frontend a higher priority than other parts of the software. Again and again it seems to suggest starting development by thing about the frontend was ok. But it isn´t! "Frontend first" is maybe the most widespread reason for bad architectures/designs.

I see only one way to save the spirit of Software Layers, that´s by giving up the layering...

...and instead arrange the logical party of an application in a way so none has a higher priority than the others. This way, we´d retain whatever is helpful from Software Layers and get rid of their limitations and invalid suggestions.

Onions

To face new challenges brought upon by Web services, fellow Microsoft Regional Director Clemens Vasters and Microsoft´s Steve Swartz have come up with a variation and evolution of Software Layers: the Onion.

Source: www.newtelligence.com

They wrapped the layers around a center which led to concentric circles, and renamed the layers.

And this is indeed a step forward, I´d say.

But first, let´s see, what Onions are about: They are about services, that means, they are about software that´s accessible via SOAP/WS-* From the point of view of Software Cells that means, they are about Software Solutions and collections of Solutions aka Software Societies. How a service is structured (if it´s a single Application or several) is not important to the Onion model. Onions thus are on the next higher level of abstraction above Software Layers. And what they are trying to say is: Several cooperating solutions are structured like a single solution, there is some frontend, some inner logic and some data/resource access:

Source: www.newtelligence.com

This really makes for nice drawings, I´d say. The Software Universe almost looks fractal: You can drill down and down and down and on each level you find more details. (However, as opposed to the usual fractal structures, each level of detail looks the same. It´s always public interface, implementation, resource access.)

Theoretical this has some appeal, but in the end I don´t find it very enlightening. What does this notation add to software layers? Why use circles instead of layers? The only benefit I see is a circle has a clear surface. This suggests all access to the implementation has to go thru the outer Onion layer. Hm... ok, that´s not bad. But other than that... the fractality of the model could have been depicted with real layers, too.

And I´d even say, the circular nature of Onions is not helpful in depicting larger systems.

Source: www.newtelligence.com

Can you imagine to draw a Society consiting of several Solutions with their Applications using these Onions? I can´t. So where I see the Onions is at the level of very coarse grained architectural thinking. Thinking of a Solution or Society as a shape with a clear surface is beneficial.

However, I think also the Onion suffers from a wrong suggestion of priorities: At their center is the resource access, at their rim is the frontend/public interface. The logic, that what really is the heart of any Solution is just a thin layer wedged between input and output.

From the point of view of Clemens this might be understandable. He´s concerned with SOAP, WSDL; WS-*, Indigo and the like which are all commuication technologies. So in his mind the outer interface service layer and the resource access at the Onions´ core are on his mind all the time. But in the end they are of comparatively little importance. What is most important is the processing logic of any Application or Solution or Society. It´s what needs to be done, not where the data comes from or goes to.

Please, get me right: Without I/O there is no processing. But the whole purpose of software is processing and not I/O. So I´d say, we should put processing at the heart of our thinking, models, and designs. Just because communication technologies need to mature for real world cross-platform interop does not make them more important than the processing logic.

Also, I don´t see, why Onions list COM on the public interface and not as a resource access technology. Or why isn´t "WS" (for Web service) a public interface option? Why do Onions put communication technologies into two categories at all? As Clemens says "On the next higher level of abstraction, presentation services may very well play the role of data services to other services. And so it all repeats." But why doesn´t this insight show up in the model? It means on service´s output is another service´s input, and that means, both ends need to use the same I/O technology. If one service outputs data to a database (resource access and "SQL" in the Onion picture), then another service is going to read it from there thru it public interface.

Or, hm, do Onions want to limit us to communicating between services via the technologies listed on the public interface? I don´t want to believe that.

So, what do I think about Onions? I´d say, I like them for trying to provide a model for describing cooperating Solutions. The step up Software Layers from the Solution-only view to a Software Society view. But I don´t like them for being inconsistent in their statement about communication technologies and limiting in their visualization capabilities.

Fiefdoms

Microsoft´s Pat Helland has introduced the term "Fiefdom" into the discussion about software architecture. Fiefdom stands for an autonomous piece of software that performs a task, guards its resources and allows access from the outside to its service in a controlled way. Hence Fiefdom is a metaphorical description of a service as in SOA (Service Oriented Architecture).

Fiefdoms thus are a pure conceptual construct and are orthogonal to the notion of Software Cells etc. A Fiefdom can be a single Application, or a Solution, or a Society. It depends all on your point of view, the level of abstraction you´re on in the Software Universe.

As long as Fiefdoms are not misunderstood as implementation guidelines, I think they really help to "think in services." Or to say it the other way ´round: Fiefdoms are not concerned with implementation. They don´t want to guide you in choosing how to distribute logic across Hosts like COM+ or IIS. They don´t guide you in choosing between SOAP over HTTP vs MSMQ. They just say: Think clearly about your boundaries! And view whatever is within the boundaries as an autonomous entity.

And that´s a very helpful message - right in the line of Software Cell´s Contract First thinking.

Side note: Interestingly Pat Helland has had some difficulties with the term "application" like I had before Software Cells. And he has come to almost the same conclusion: "I would propose that we use the word application exactly as it has meant in the past. An application is a collection of functionality that is tightly interrelated. For the most part, applications have historically stood alone." Yes, let Application be something that stands alone and can be clearly identified. But we differ fundamentally in our final conclusion! Pat says "An application may be implemented out of services.", but Software Cells map services to a group of Applications. Since the world´s software still mostly is not a service and Applications as the Software Cells model defines them fills a gap in the Software Universe I´m sorry to say, but I don´t see any value in Pat´s use of the term "application" and his discouragement of using it. "Application" is a valuable term if clearly defined.

SOA

Now, at last a word about SOA. What is SOA? Or is there SOA at all? Clemens Vasters in the meantime has come to the conclusion, there is no such thing as SOA - and I agree with him. The SOA hype was/is around communication technologies. But communication does  not equal architecture (which is also about how to arrange structures).

Nevertheless let me describe what SOA could have ment in terms of Software Cells: In Software Cell terminology a service is a Software Solution, or: a service is a special case of a Solution. Not any Solution is a service, but every service is a Solution. And it´s only a special case again, if a Solution consist only of a single Application. So in general a SO architecture looks like this:

Several Solutions communicate with each other to fulfill an overall purpose thereby forming a Software Society.

Since there is not physical container for a solution, each application in a Society could belong to several Solutions at the same time (or even several Societies). Solutions and Societies are just logical concepts, whereas Applications are tangible entities.

What Clemens is saying: SOA never made a statement about how code is hosted or arranged but mostly talks about how Solutions are connected (e.g. by using SOAP/HTTP or MSMQ). SOA thus talks about communication technologies and maybe Adapters/Portals, but nothing more. From a SOA perspective a service (Solution) has its own contract(s). To translate this into the Software Cell world I maybe could depict a Society like this:

Communication always flows thru Adapters and Portals, so Solutions should have Adapters and Portals, too. Or shouldn´t they? Logically they sure define contracts. But physically they don´t implement them, since Solutions themselves are no physical entities. The contract of a Solution (service) is the sum of the contracts published by its Applications for inter-Solution communication. So I´d rather say, the Adapters and Portals of a Solution are logical or even virtual, whereas the Applications´s Adapters/Portals are real and tangible:

Any Application within a Solution can contribute a Portal to the Solutions contract. And any Application within a Solution can access another´s published Portals via an Adapter that matches the contract. I don´t think it is necessary to introduce the logical notion of special "surface applications", who are the only ones allowed to publish a contract to other Solutions. I don´t think, it´s benefical to categorically assign Applications to one of the Onion´s layers.

However, I think communication between (!) Solutions should be limited to cross-platform technologies, which today means to contracts defined by XML Schema/WSDL and WS-*. Why? To grant Solutions full autonomy in terms of implementation. Which means they are free to choose the number of Applications needed to provide their service(s). And they are free to choose the Application Hosts. And they are free to choose how they keep state. (This is along the lines of Fiefdoms.)

So, my bottom lines for SOA is: It´s true, the SOA discourse does not really revolve around architecture but around communication. But if you like, you can perfectly well and easily map SOA´s concepts to the Software Cells model. And I´d even go further and say, Software Cells make it clear, that SO lacks a clear definition of what is the contract of a service (consisting of several Applications all publishing contracts). There is no physical place where the potentially many pieces of a service´s contract come together or are defined. A service´s contract is just a set of several Application contracts logically tied together. And it´s even worse than the set of public types in an assembly which are at least bound by the assembly manifest.

A general word about architectural patterns

Besides popular patterns like Software Layers or Onions there are many others, e.g. Pipes and Filters or Enterprise Bus. What do Software Cells mean for them? Or do those patterns stand in the way of Software Cells and are incompatible with them?

No, right to the contrary! Software Cells embrace all those patterns and provide a vocabulary to guide their implementation. Take Pipes and Filters for example:

The pipes&filters picture in the middle is from the Microsoft document. And as you can see, Software Cells allow for a variety of implementations. (You could even think about pipes as Applications/Solutions if you like.)

Software Cells are a very general model for software. You can use it to depict any architecture. Just be clear about:

• Where/what are my Applications? How do I map conceptual entities to physical entities?
• What´s the best Host for an Application?
• Where are Solution boundaries? Think about Contracts!
• Which communication technologies do I choose?