Comments on transition from two tier to three tier architecture

[Ebenezer]

This is a little off topic, but the subjects come up here from time
to time so am posting here. A year or so ago I decided to make
some changes to my then newly developed command line interface
to the C++ Middleware Writer (CMW). At that time I called the command
line interface "direct" because it was directly connecting to the CMW.
Eventually I decided to transition from a two tier setup to a three
tier
and I introduced the C++ Middleware Writer Ambassador (CMWA) --
a server that is now the middle tier. Originally I made this
transition
because I recognized some efficiency gains that would result. Namely
that I wouldn't have to establish a long distance connection with the
CMW for each request as the CMWA would maintain that connection
and therefore passwords wouldn't have to be transmitted with each
request.

I posted about my plans at the time on gamedev.net and the feedback
there helped me to realize that there would also be administrative
advantages to the three tier approach. With the two tier approach
every user would have to be authorized to get around firewalls in
order to contact the CMW. But with the three tier approach just
one system has to be set up that way and then all user requests
get funneled through the system running the CMWA.

Some time after that I came to realize another advantage with
my chosen architecture: I would not need to use a library
like Poco or Boost ASIO for portability. I have two versions of
the CMWA -- a Linux and a Windows version. The original
"direct" program when refactored into two tiers had most of the
code in the (big picture) middle tier (CMWA)and a little (less
than 100 lines right now) in the leaf tier -- a program that
is expected to exit after completing it's task. I thought for a
while that I might need to use one of the aforementioned libs
to reach more than UNIX and Windows platforms with the
CMW. But as long as a company has a Windows or UNIX
machine available for the CMWA, we can just port the
small ( < 100 loc) leaf tier program and don't have to introduce
one of those libs for the CMWA. In other words, since most
companies have either a Windows or Linux machine available
to host the CMWA, the need for a library to help with
portability is significantly diminished. The only place where
using one of those libs might be helpful is on the leaf tier.
And at the moment since that program is so small it doesn't
seem like a very pressing need.

So I commend a three tier architecture to those using two tiers
and also think the term ambassador for the middle tier is helpful;
it mediates requests from users to the CMW and responses
from the CMW back to users. A lot has been made over the
years about portable libraries, so I was surprised to find my
need for them was not as much as I had thought.



Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
http://wnd.com

 

[Saeed Amrollahi]

This is a little off topic, but the subjects come up here from time
to time so am posting here.  A year or so ago I decided to make
some changes to my then newly developed command line interface
to the C++ Middleware Writer (CMW).  At that time I called the command
line interface "direct" because it was directly connecting to the CMW.
Eventually I decided to transition from a two tier setup to a three
tier
and I introduced the C++ Middleware Writer Ambassador (CMWA) --
a server that is now the middle tier.  Originally I made this
transition
because I recognized some efficiency gains that would result.  Namely
that I wouldn't have to establish a long distance connection with the
CMW for each request as the CMWA would maintain that connection
and therefore passwords wouldn't have to be transmitted with each
request.

I posted about my plans at the time on gamedev.net and the feedback
there helped me to realize that there would also be administrative
advantages to the three tier approach.  With the two tier approach
every user would have to be authorized to get around firewalls in
order to contact the CMW.  But with the three tier approach just
one system has to be set up that way and then all user requests
get funneled through the system running the CMWA.

Some time after that I came to realize another advantage with
my chosen architecture: I would not need to use a library
like Poco or Boost ASIO for portability.  I have two versions of
the CMWA -- a Linux and a Windows version.  The original
"direct" program when refactored into two tiers had most of the
code in the (big picture) middle tier (CMWA)and a little (less
than 100 lines right now) in the leaf tier -- a program that
is expected to exit after completing it's task.  I thought for a
while that I might need to use one of the aforementioned libs
to reach more than UNIX and Windows platforms with the
CMW.  But as long as a company has a Windows or UNIX
machine available for the CMWA, we can just port the
small ( < 100 loc) leaf tier program and don't have to introduce
one of those libs for the CMWA.  In other words, since most
companies have either a Windows or Linux machine available
to host the CMWA, the need for a library to help with
portability is significantly diminished.  The only place where
using one of those libs might be helpful is on the leaf tier.
And at the moment since that program is so small it doesn't
seem like a very pressing need.

So I commend a three tier architecture to those using two tiers
and also think the term ambassador for the middle tier is helpful;
it mediates requests from users to the CMW and responses
from the CMW back to users.  A lot has been made over the
years about portable libraries, so I was surprised to find my
need for them was not as much as I had thought.

Brian Wood
Ebenezer Enterpriseshttp://webEbenezer.nethttp://wnd.com

Hi Brian
I believe your experience is more than me, Just off the top of your
head
I mention the followings:
1. I use 3-tier architecture mostly in classical model:
UI layer, Business Objects layer and DB layer
In data-centric programs the DB layer is thick,
in user-centric programs the UI layer is thick,
in computation-centric programs the middle layer is thick.
The 2-tier architecture has the first and third layers and we do
Reading data from DB to UI
writing data from UI to DB
I guess in your case you had 2-tier:
Command Line Interface (UI)
CMW (like DB)
and now you have
Command Line Interface (UI)
CMWA (like business objects layer)
CMW (like DB)
2. In a serious architecture-driven OO program, the middle
layer is very important. It contains the main abstractions
of the system. I prefer to use 3-tier arch.
because I think in long-term the maintenance is easier.
3. I think you use CMWA as a mediator to other layers.
It's like a mediator design pattern. Using such technique,
I guess the communication between several (a lot of?) abstractions
in command line interface and CMW are dramatically reduced.
4. As you mentioned by using CMWA, the command line interface is
thinner, because a lot of code is re-factored to middle layer.
5. I think, using 3-tier model, you have more robust and
scalable architecture.
6. For a good discussion on Multi-tier architecture, please see:
Grady Booch. Object Solutions. Benjamin-Cummings, 1996.
Although, it's somehow old book, but it contains a lot of
good experiences.

Regards,
-- Saeed Amrollahi

 

[Ebenezer]

Hi Brian
I believe your experience is more than me, Just off the top of your
head
I mention the followings:
1. I use 3-tier architecture mostly in classical model:
  UI layer, Business Objects layer and DB layer
In data-centric programs the DB layer is thick,
in user-centric programs the UI layer is thick,
in computation-centric programs the middle layer is thick.
The 2-tier architecture has the first and third layers and we do
   Reading data from DB to UI
   writing data from UI to DB
I guess in your case you had 2-tier:
   Command Line Interface (UI)
   CMW (like DB)
and now you have
   Command Line Interface (UI)
   CMWA (like business objects layer)
   CMW (like DB)
2. In a serious architecture-driven OO program, the middle
layer is very important. It contains the main abstractions
of the system. I prefer to use 3-tier arch.
because I think in long-term the maintenance is easier.
3. I think you use CMWA as a mediator to other layers.
It's like a mediator design pattern. Using such technique,
I guess the communication between several (a lot of?) abstractions
in command line interface and CMW are dramatically reduced.
4. As you mentioned by using CMWA, the command line interface is
   thinner, because a lot of code is re-factored to middle layer.
5. I think, using 3-tier model, you have more robust and
   scalable architecture.
6. For a good discussion on Multi-tier architecture, please see:
   Grady Booch. Object Solutions. Benjamin-Cummings, 1996.
Although, it's somehow old book, but it contains a lot of
good experiences.

Saeed,

Thanks for mentioning the book. I haven't read it.
I'd like to think that I would have had this transition
from two to three tiers finished years ago if I had more
to invest in my company.
I've thought about another aspect of this since
posting. The CMW only runs on one platform, currently
Linux, but am not sure that is the best choice. The CMWA
runs on two platforms and the command line client runs on
two platforms but as I mentioned it would be easy to port
the command line client to run on other platforms.