Re: [Boost-users] Off topic: Interface / design question

From: Ray Burkholder (ray_at_[hidden])
Date: 2008-05-29 12:13:17

> 
> 1. Have your CV somewhere online, that lists some serious projects
> done with both ACE and Boost.
> 
> 2. Have a blog post or article that specifically names the
> "wrong design choices" that ACE forces one into?
> 
> If so, can you provide links to those?
> </rant>
> 
> I *don't* have direct experience with ACE, so I'm not going to defend
> it
> here, and I also assume you have good reasons to criticise ACE, but
> your
> email does not communicate them well. Calling a established project a
> "ugly, monolithic monster" without good justification written down does
> not seem a constructive, or fair, thing. Especially given that Boost is
> fairly monolithic and fairly big, too.
> 

Staying on the positive side of the discussion, I'll put in my two pennies
worth, and describe my evaluation journey through various inter-process
communication libraries.

I've started working on a number of distributed system projects.  As a
consequence, I started looking for distributed system libraries.  References
to ACE were most pervasive.  I implemented a number of trial applications
with the library.  That was after plowing through relevant sections in the
three primary ACE reference books.  That was a good learning experience, if
only to find out the various patterns in distributed architecture
definition.  I had the inter-process/inter-server communications (which only
sent simple stuff) working well within ACE's Acceptor/Connector framework.
ACE has a number of other patterns one can use.  I was really impressed with
the fact that the examples I used from the books worked as advertised, and I
was able to bend them to my will.

ACE is based upon an interaction of classes, macros, and templates.  One has
to spend some time with the environment in order to become proficient with
it.  It has a large API.  A number of lower level API's upon which higher
level API's are based.  For example the Acceptor/Connector uses constructs
described earlier in the books.

Once I had my basic communications going, I realized I needed to get some
form concrete messaging infrastructure in place.  I had an impression that
TAO, which is a layer above ACE, would be quite extravagant to implement,
with it being an implementation of the CORBA specification.  I wanted
something a little lighter (a whole lot lighter actually).

As I worked through that project, I started hearing about ASIO, indirectly
through some other libraries I was using.  ASIO is now a member of Boost.  I
read a review somewhere that ASIO is a 'modern' replacement for ACE.  If you
want to get into real template structures and Boost oriented philosophy, I'd
say that is a valid statement.  I'd also say that ASIO is 'more to the
point' and straight forward than is ACE, at least for the things I want to
accomplish.  But like ACE, ASIO is the basic communications infrastructure,
no real messaging capability, which is what distributed computing is all
about.  ASIO turned out to be a little harder to get my head wrapped around
as it uses a number of advanced C++ and Boost related idioms.  For a
run-of-the-mill C++ programmer, ACE would be better.  For someone steeped in
the power and obscurity of advanced C++, and is looking to advance their
skill set, ASIO would be better.

I came across RCF
(http://www.codeproject.com/KB/threads/Rcf_Ipc_For_Cpp.aspx), which is a
messaging framework riding atop of ASIO.  Flexible, lightweight, and to the
point.  I worked through the examples and things worked as advertised.  It
has the encryption, publisher/subscriber, oneway/twoway idioms, and a few
other nifty features.

At the same time I was doing that, seemingly coincidently, I learned a few
more interesting facts.  Going into this, I realized that I need a message
dispatcher/proxy, some decent failover techniques, and some additional event
handling for non-IPC related activities.

Someone suggested ICE from www.zeroc.com for an RCF-like solution, but
working to a larger scale.  I've heard that the library's originator is
someone who spent much time on CORBA standards and redid the concept without
the 'benefit' of committee involvement.  I think the library has all the
bases covered in terms of lightweight message handling, dispatching,
resiliency, and higher level distributed processing philosophies.  The
drawback is that it will have a steeper learning curve than would an
implementation using RCF.  I like RCF, but I think I'm going to have to tilt
towards ICE (itself, like RCF, developed and focused towards C++ in a
multiple license environment).

On the non-IPC front, Qt's QCoreApplication looks to be a good substrate on
which to build event driven daemons.

In the end, I think my solutions are going to involve:
* ZeroC's ICE for primary inter-process communications
* a little legacy layer 3/4 ACE in one library I'm using, but with some
work, I think I can convert the ACE stuff to ASIO
* Qt QCoreApplication as a base for daemon development (which has built-in
stuff for threads/locks, slots/signals)
* http://www.webtoolkit.eu/wt/, a C++ based web toolkit for distributed GUI
development
* boost libraries to fill in all the little holes 

Hopefully this didn't turn out to be too off topic.

Ray.

-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.