Application architecture - tiers versus layers

While this distinction is a valuable one, there is a certain twist to it when thinking in terms of ABL applications. When I first started considering these kinds of architectures, I became dis-enamored of the whole focus on N-tier because the tiers really were only about the specific deployment. Behind any one deployment instance, one had the logical division into layers, which was a valuable conceptual organization, and the concrete manifestation of the components or services of which the application was composed. Those components could all run in a single process space or they could run spread across dozens or hundreds, or even thousands of process spaces, potentially with replicated components and the like. The difference between the two was the requirement of the specific deployment instance in terms of performance, physical distribution, security, etc. Indeed, it was common in the Forté environment to start with one deployment design, but to end up evolving that design with experience as one discovered bottlenecks and the like. In many cases, the component or services model did not change, but the deployment did.

We have a weakness in this respect in ABL applications because we are not able to deploy multiple cooperating components within a single process space without creating a single threaded service. So, to realize this freedom of deployment design, we either need a multi-threaded session (see http://www.oehive.org/MultiThread ) or, at the least, some kind of high performance link between sessions so that we can do a sort of manual multi-threading design.

Yes very interesting. I'll give you a simple example (based on the arguement that layers/tiers add complexity).

In my own time, I've been building a "shop front" type system in J2EE (well Spring, Hibernate and JSF) using AndroMDA (i.e. and MDA tool). Now its all lovely and its got tiers (and layers) but changes to the architecture can take a couple of hours to implement (and its only me).

Now, last week I downloaded PHP (just for a try) and within 15 or 20 minutes had a complete set of screens up and running (never seen PHP before). About 2 hours later it was plugged into Google maps and saving the long/lat into a database for caching. Had I done that in the MDA tool (i.e. added the long/lat to the model and posted it though all the layers) we could be looking at 2 days (lets say 8 hours). Now, would you consider PHP to be multi-layered or multi-tiered??? Its not that much different to a client/server CHUI 4GL system (only harder I think to maintain - oh and it uses SQL - which isn't all that bad really). So, bad to the layers/tiers, yes it does have physical tiers (MySQL, Apache/PHP and the Browser for Java script). Logically, it sort of has layers but the boundary is much more blurred I feel .... During development there are logical layers, in production its more mashed into one big HTML file on the client which is generated by PHP on the server ... I'll leave it up to you the read to decide on what they think.

I don't necessary agree with the article that tiers imply network boundaries ... and not even process boundaries. They "can" but I don't think it always means that they "do". Crossing these boundaries in VERY expensive which is why most people in EJB 2.1 use local rather than remote calls. Its also helped Spring take off as you don't even need the EJB container in all cases.

I'm not sure about this either.

As a good architect you should be dragged kicking and screaming into adding tiers to your system. But there really are good arguments and reasons for adding tiers, and it is important to accommodate them as appropriate.

Today with SOA and WebServices we are often pushed to created such tiers as a first priority. So, since 2005 when the article is written, I do think a lot has changed and will continue to do so.

Anyway, thats my $0.02 worth (I'm off to get my first morning coffee now)

Murray, I'm not sure that you are using tier and layer quite the way the author intended. It is, after all, just one person's definition, but I think that Phil believes that this is a valuable distinction to make and I agree with him, although obviously some of the participants in that conference call were not on the same program.

From what I can tell of your description, the PHP code has neither tiers nor layers. It really is just a big ball of mud. Because of the nature of the language, you can throw together something fairly simple in almost no time, but that productivity is unrelated to the benefits of either tiers or layers. The only real tier or layer distinction I see there is the actual database versus everything else and one doesn't usually count it as part of the tiers and layers of the code.

I don't necessary agree with the article that tiers imply network boundaries ... and not even process boundaries

Then I think you are using a different definition. How can one have a tier separation in something that isn't separated into at least two parts. You can have components from multiple layers in one process, often do, but not multiple tiers. The whole point of client-server is that the code is in two different places. And for N-tier, at the very least there needs to be separate processes, but really it should be separate machines. Otherwise, if one had multi-threading, it would clearly be more efficient to make them a part of the same process space.

Today with SOA and WebServices we are often pushed to created such tiers as a first priority. So, since 2005 when the article is written, I do think a lot has changed and will continue to do so.

Certainly, one of the criticisms of SOA is that it divides things up into pieces and thus creates boundaries where the cost of sending a message is far higher than it is within a process. This is why one needs to be careful to divide up services in order to minimize the amount of this kind of traffic.

But, I don't think services are either tiers or layers intrinsically. Any one service is likely to have components from multiple layers, certainly. E.g., an inventory service is going to have domain objects and data access objects and communication objects, even if it has no direct UI. Services on a bus is more similar to tiers, but I would be reluctant to use that terminology because tier implies order. I.e., from user to database there is a specific sequence of tiers that communicate in a particular order, each tier only communicating with the tier on either side of it. With services, it is much more an everybody talks to everybody environment. There may be things might want to call tiers, but I think SOA is really a level of complexity beyond that we associate with tiers. There are some related issues, which one needs to keep in mind, but the vocabulary doesn't really fit.

An interesting example of failing to understand this distinction has come up on the PEG at http://www.peg.com/lists/peg/web/msg43734.html

Ahh - sigh. I think the KISS principle should always apply - keep it simple ...

I think in this case KISS stands for Keep It Simply Stupid.

I think in this case KISS stands for Keep It Simply

Stupid.

Now thats what I always thought it stood for !!

Yes it does but I didn't want to say that. Down here in Aus we have the greatest "sue" rate per head of capita in the world (yes we beat America in something). A woman recently won $20k because someone opened a car door for her ... Hence I'm not going to put in the "stupid" in case it seen as defamation .... Stupid YES but a fact of life. A little bit like this article if you have not seen it .... A GREAT one for layers (of a difference kind) ...

http://www.joelonsoftware.com/items/2006/11/24.html .. coming fro here: http://www.drizzle.com/~lettvin/2006/11/windows-shutdown-crapfest.html

Muz