When talking about multi-tiered architectures, we need to remember that the tier boundary is significant. The tier boundary is where distribution happens and if you remember the “fallacies of distributed computing“, you know not to take that lightly.
A tier is a physical boundary (versus, for example, an Edge in a SOA which is a logical boundary within the service). The implications of that are numerous. For instance, you need to consider:
- Trust–who do you let in?
- Security–what do you send out?
- Performance–you need to serialize to pass the boundary, and remote data is expensive to fetch.
- Availability–what happens if you crash?
- Manageability–can anyone see what’s your state? Help you recover?
- Temporal coupling–can you afford to make synchronous calls?
- and many similar questions.
Yet many times people think passing a tier is as simple as passing a logical layer. I should know. I made this stupid mistake more than 15 years ago in one of the first distributed systems I designed. I planned this beautiful separation of the UI controls from the business logic (I didn’t know it was called “MVC” and that someone else had figured it out ages ago, so I was pretty proud of myself). When you clicked on a button you just used metadata to say that BL should catch it. I had all this wonderful “infrastructure”that handled passing the call to its destination.
But then we wanted to take this n-layer application and put the BL in an “application server” which will handle multiple clients. Oh–now we need to move events over the wire , handle calls from multiple unrelated clients, pass a lot of data back and forth, and what about security… you can imagine the fiasco.
Thus, as Niels Bohr once said, “An expert is a person who has made all the mistakes which can be made in a very narrow field.” But you don’t have to make the same mistakes. Just remember that a tier is a natural boundary. You know what? You should think of a tier as the edge of a cliff, right there – at the end of your application. You know you want to be careful and not fall down.
[Originally posted Aug. 2006]
Illustration: ‘Derek J’ by Phil Watt