I’m currently working on a book about, among other things, software architecture for J2EE applications. A few days ago I sent off a rewritten draft of one of the chapters to my co-author, who sent it back with, among other comments, the observation that one of my diagrams was upside down.
One thing I’d mentioned in the chapter was that, in an ideal world, the various tiers in an enterprise application “look up to each other”. That is, the lower tiers are aware of the interfaces to the higher tiers, but the higher tiers don’t know about the lower tiers. This is a pretty well accepted design principle–there’s no need for an EJB (or whatever) to know anything about the servlet/Swing GUI/whatever that’s invoking it.
However, my explanation only works if you think about the business tier as the “top tier”. Which is what I’ve always done. When I’m visualizing an application I think about the presentation tier passing information requests “up” to the middle tier and the middle tier passing things “further up” to the database. Of course, the tiers get progressively more generic as you head away from the presentation layer towards the database. So it’s just as logical to draw the picture from the bottom up, with the presentation layer sitting on top of the middle tier, which sits on top of the database, and so forth. And this is, indeed, what a lot of people do.
Sun’s no help here. Their official picture goes left to right.
Seems like a trivial observation…but…I’d never overtly noticed the difference until I started explaining “looks up” to people. And since I’m trying to introduce people to the concept of tier separation in the first place, I want to do it in a way that is broadly intuitive to the largest possible audience. So, I’m going to do a little poll: do you put your business tier at the top of the picture, the bottom, or on the side? If you’ve got an opinion (or have ever thought about this at all), let me know below, or by email.
Top, bottom, left or right?
Top down
I recently started studying computer science in a university, and one of the thing tought this semester was 3-tier applications. The way this was tought was that the presentation layer was on top, logic in the middle and data manipulation at the bottom. Each layer is only aware of the layer below.
So that's the way I'm used to viewing this at the moment.
Einar Jonsson
einar@binary.is
flow
the presentation tier being shown on the bottom is dependent on the web-based view that presentation requires less technical knowledge than the other tiers (a viewpoint that I think we all pretty much agree with). As such it is not a representation of the logic of an application but a representation of the logic of an employee hierarchy, and of what people are more important to a project.
This is to say that one reason for choosing your starting point at the top of a hierarchy is dependant on your valuation of it.
We move down in describing a family tree because our ancestors should be shown as more elevated than us.
We move up in most representations of our psychologies because those impulses supposed to be the source of our beings are often thought of as ignoble.
Tree hierarchies are presented as moving downwards, pyramids(remember the food pyramid, that value laden bit of FDA propaganda with meat as the supreme good towards which we must strive) are often represented as moving from the base upwards, although both are in essence the same shape.
Directionality, in the representation of a process, is also determined by where a process ends. If we start with a tree hierarchy representation of a build then we show a single start point with multiple results.
If we start with a pyramidal we show multiple initial qualities or start points moving towards some final result.
Showing the structure dependent on the awareness of a higher level for a lower level seems to me a good representation of one form of logic involved in a process. It may be that you should, in some cases show it in such a manner, with a notation that you do so, and in other cases find what manner best suits presentation.
I do not see at all how the tiers get progressively more generic as you head from the presentation level, but the difficulty I have with this concept is such that I cannot easily define it here.
Think "is built on top of"
You are doing it upside down. When reading a diagram like this, it is handy to see what your forefathers have done before you. W Richard Stevens describes the OSI networking stack on page 3 of Unix Network Programming as going from Application (on Top) to Physical (on bottom). The logical way to read these diagrams is then to say...
The data link layer is built on top of the physical layer. The network layer is built on top of the data link layer. etc. Like building a house. Although it is possible to build the roof first, most people start with a foudation and then work their way up. By the same token, programmers use what the system gives them (system calls), build libraries on top of them (libc), build libraries on top of that ... until they have a working program. And all that with a foundation (way down there) of the bios trying to read one special bootblock with some magic numbers thrown in it...
example diagram
As you can see at:
http://www.mentata.com/ldaphttp/sdd/ldaphttp_framework.jpg
when discussing design, I put business logic (red) to the left. I wanted it to be the primary concern, and so the diagram cascades down and right from there.
But this is a design document. If I were advertising a service, I'd probably put the customer (client) on top in a dominant position, where they tend to be found these days.
'Uses' goes downwards
The standard approach is definitely as described in the anonymous post 'Think "is built on top of"'. Layers on top use the layers below, i.e. they rely on their correctness. FFI see http://www.sei.cmu.edu/publications/documents/00.reports/00sr004/00sr004chap02.html