«

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

On Nov 14, 8:45*am, Ebenezer <woodbria...@gmail.com> wrote:
> 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

On Nov 14, 5:37*am, Saeed Amrollahi <amrollahi.sa...@gmail.com> wrote:
> 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.