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

From: Khandelwal, Amit (amit.khandelwal_at_[hidden])
Date: 2008-05-30 10:25:52

Appreciate your inputs. Is there an open source library/framework
similar to what Tibco rvd does?

-----Original Message-----
From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Ray Burkholder
Sent: Thursday, May 29, 2008 12:13 PM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] Off topic: Interface / design question

> 
> 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.
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.
--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.