[omniORB] From COM to CORBA...

[Len Holgate (Mail List Account)]

Duncan,

Thanks for taking the time to comment on the articles, I appreciate the
comments.

> I don't want to sound rude, but the impression I get from reading your
> articles is that you have started trying to learn about CORBA from the
> wrong viewpoint.

I'm not sure that I have. I had been working through H&V and had got to the
point where I wanted to write a real server that did something useful. I
worked through a simple client/server Chat system, needed something better
than a sequence to return a list of users. At that point, because of my COM
background I implemented an enumerator and found it very difficult to get
the damn things to go away when I'd finished with them. I dont like
non-deterministic destruction so decided to see if there was a more
predictable way to control their lifetimes than the evictor pattern shown in
H&V. This led to the investigation into reference counting etc. I'll now go
back and try the evictor stuff with the enumerator/iterator...

> You have taken your knowledge of some very specific

I personally wouldnt class reference counting and enumeration/iteration low
level concepts. But perhaps that's just that in the COM world they're
pervasive.

> I think that that approach will only lead to awkward and
> inefficient CORBA designs.

Possibly, but then if you just accept the gospel without questioning it
you'll never learn why you're doing something in a particular way. I'd
rather make some mistakes and learn from them. Anyway, point me at some
documentation on elegant and efficient CORBA designs and I'll go read it.

> Also, the problems with your early refcounting examples stem from a basic
> lack of knowledge about how CORBA manages servant life-times, rather
> than from any difference between COM and CORBA.

Hmm. The early examples are supposed to show the problems that you encounter
if you're coming to CORBA from COM and trying to add reference counting in a
way that would seem "obvious" to a COM programmer. The article is supposed
to show that you cant do this in this way because of the differences in the
way that CORBA manages servant lifetimes and explains how the POA is
managing the lifetime of your servant objects... Perhaps they need reworking
if this isn't clear.

> In CORBA, reference counting is only one of many schemes which
> can be used to manage objects' life-cycles. In many circumstances,
> there are much better schemes to use. Coming from the COM perspective
> that everything is reference counted can prevent you from seeing
> simpler and better alternatives.

Well, although all client side objects will use reference counting in COM
that doesnt prevent you doing something else on the server side if you want.
The server object isnt forced to maintain a reference count, or to delete
itself when nobody references it anymore. So, in COM it's easy to use all of
these alternative CORBA life-cycle management styles- admittedly you have
the overhead of the DCOM ping, but as far as I can remember it's one ping
per client machine rather than one per object and I'm pretty sure you can
turn it off with some gnarly registry hack. In CORBA, it's hard to do a safe
reference counted implementation.

> Of course, reference counting is sometimes the best thing to use. In
> that case, the conventional CORBA way would be to use interface
> inheritance:

I expect I should have factor the reference counting methods out into their
own interface at the point where I factor the code out of the object and
into a base class for reuse...

> The important thing to realise here is that your implementation code can
> also use inheritance to avoid replicating the refcounting code.

Which it does when I eventually factor out the code into a base class in the
second article.

> Something like this: (All this code is untested, so there are probably
> some mistakes...)

Which is pretty much the code that I have at the end of the first article.

I didnt like that solution too much so continued working with the problem
until I ended up with the servant locator version which had a much lower
cost per object. Would you advise not doing it this way?

> Imagine that a client on machine A holds a (reference counted)
> reference to an object on machine B. Machine A now crashes. How can
> the object on B find this out?  How about the case that the network
> joining A and B breaks temporarily, but comes back later?  Should the
> object be deleted then?  What if A maliciously keeps creating new
> objects and holding reference counts to them?

It's unfortunate that CORBA doesn't provide something similar to the client
pinging that DCOM does under the covers for you. It does make reference
counting less usable on CORBA if you can't trust your clients. I should
mention this in the articles as it is an important difference.

I think the malicious client scenario is fairly contrived and not really
related to reference counting anyway. Using alternative server side
life-cycle control you're going to have problems if you have someone doing
this. Either the server runs out of resources and stops creating objects for
clients (maybe because it's hit a soft limit on the number of objects of
this type that it can hand out at one time) or the server starts garbage
collecting objects too quickly (and a client never gets a chance to
make a call before their object ref is invalidated). Either makes the server
unusable. Am I missing some solution to this one?

> Iterators (or enumerators if you want to use the COM term) are a good
> example of where a pattern other than reference counting
> can be useful. A simple timeout or evictor pattern (as described by
> Henning & Vinoski) is probably more suitable.

I'll take another look at the lifetime section of H&V and work through using
the evictor pattern with the iterator object.

My problem with this kind of method is that the client code is made more
complicated, due to the fact that the server can just decide that your
object reference is no longer valid. If the client wants to hold onto the
object for a long time but uses it infrequently it's hard work.

So, how would you replace reference counting in the named counter example ?
The evictor pattern wouldnt seem to work in that situation.

As you said, it's not an easy problem to solve and one solution wont suit
all circumstances.

> My recommendation is that you resist the temptation to map your COM
knowledge onto CORBA.

Ah, the old "I wouldn't start from here" method of giving directions ;) The
problem is that people with experience of COM will look for similarities and
will try and use the things that they know to help them undertsand the
things that they dont know. The articles are supposed to help with that by
pointing out where that mapping doesnt work.

> Then
> as you approach the low-level details, you will be able to see the
> differences between COM and CORBA in a more productive light.

I didnt realise that the articles weren't productive. :) Your responses have
certainly made me think more about the problem, so it's worked for me ;)

Len