🚀 go-pugleaf

I was going to jump in on this earlier, and didn't have the time...

I am using Java and COM, and it works fine.  However, we are only now 
really ramping up on distributed objects, and are also facing the same 
questions.  When thinking about this, I tend to look at it both from the 
delivery mechanism standpoint, and the interface implementation 
standpoint (i.e. protocol/ORB).  Since Sun has acquiesced and will now be 
using IIOP instead of their own proprietary ORB, the choice for 
delivery/protocol seems to be DCOM/CORBA, and the coding client 
components it seems to be DCOM/CORBA/RMI.

I like your basic decision matrix of Java-Java == RMI, etc. etc., but I 
think there are also some other "real-world management" type issues that 
come into play as well. 

For us, there is a definite cost/deployment/productivity triangle that we 
are trying to maximize.  DCOM is by far the cheapest solution 
(particularly when you include the TP monitor and message queueing side 
of the distributed object puzzle), but it is more limited in deployment 
(i.e. only NT/95 boxes), and there is a question in my mind about its 
scalability.  After all, DCOM hasn't really been out and in wide-
spread use all that long and I am having a hard time finding real-life 
examples of large installations (100's or 1000's of users) PERIOD, much 
less lots that are happy with it.  I have read about many such instances 
using CORBA.

Further, there have been some messages here and in other newsgroups I 
monitor that state that DCOM sends a *lot* (5x-10x) more traffic over the 
wire than does CORBA.  Can you verify this?  Even if this is true, I am 
not sure if it is significant in the real world or not (because of MS's 
cluster/multi-workgroup, non-centrally focused model).  Finally, is 
having to do all the COM registration stuff on clients (I assume we can 
deal with it on our own servers) a PITA or is it pretty straight forward 
these days?

Tad Frysinger