Drill down into a view on application architecture: Communication between frontends and application

In my last blog entry I suggested a new view on basic application architecture (at least for "business applications"). The purpose: to change the patterns in which developers think, so concepts like Application Server no longer are deemed esoteric tools for only a few.

However, yesterday´s post only showed a very high level picture. Today I want to clarify two things and drill down a bit.

First, as Christian Weyer pointed out, the picture left it open, if a frontend would be allowed to access a resource directly. The answer of course if no! So the picture now puts the application and the resources in a box, and the only entry point into that box is the application.

The frontend is not allowed to access any resource directly.

Second, the question arises, where does SOA (Service Oriented Architecture) fit into my view? As far as I understand SOA, it´s all about communication between services. Since in my view applications are the equivalent of services, I´d say, SOA is concerned with connecting different applications. SOA is about the orange boxes and the red lines in the following picture:

SOA is about communication between services, so it´s about connecting applications.

Sure, this is a broad generalization, but I guess I´m at least not mistaken when saying, SOA is not concerned with frontends, nor with resource access.

That said, now for the drill down. Several parts of my view of the application architecture need refinement. Let´s start on the left of the picture. The relationship between frontends and application:

Frontends interact with the application thru service interfaces. Whether these are implemented as Web services or Serviced Components or something else, is of no concern here. That´s an implementation detail. Most important is...

• those interfaces are just plain lists of functions.
• data is exchanged between frontends and application by value. (All parameter data types need to be serializable.)

Complex data (e.g. database records) needs to be put in a container.

Communication between frontends and application always uses containers for data transport.

That means, communication between frontends and application essentially is message based. All data passed to frontends is disconnected from its source. So don´t even think about scrolling thru some 5,000,000 records in a grid in some WinForms frontend.

Frontends don´t do any (heavy) data processing. So there should be no need to return large amounts of data to them from the application or pass large amounts of data to the application. Yes, that means, frontends don´t do data import themselves. And frontends also don´t do reporting (on large amounts of data). There is no streaming data access by a frontend!

If you feel the urge to retrieve large amounts of data (where large means, you don´t trust a dataset with it) whatever component you´re thinking of, it can´t be in the frontend!

This might sound rigorous and it is. I mean it.

Why? Because we need firm (!) guidelines for architecting applications. And my opinion is, this is a good guideline for 98% of all business applications. (Ok, maybe just 95% of all business applications ;-)

It provides several benefits:

• It decouples frontend and application.
• It makes the relationship between frontend and application robust.
• It makes it easy to understand.
• It makes it easy to test.
• It allows for orthogonal services on the service interfaces.
• It assigns clear responsibilities.
• It is the foundation for distributing frontends and application to increase scaleability.

Does that mean, an application system necessarily is a distributed system? No. But more on that on another day.