[omniORB] omniORBpy: persistent IORs and/or LifeCycle support?

[Mark Borges]

I am working on the interface between two applications, X and Y. Each
has their own servant and client implementations, Xs, Xc, Ys, and Yc,
respectively. Xc dispatches requests to Ys, and passes an IOR to Ys
corresponding to an interface and oneway method implemented by
Xs. Subsequently, Yc then uses this (oneway) IOR to report back status
changes to Xs.

This works about as well as can be expected[1], but, as you can
probably guess, problems arise if the Xs implementation dies while Yc
still has pending status changes to report using the original oneway
IOR. In this scenario, Yc will hold a "stale" IOR that will presumably
result in a COMM_FAILURE exception when it attempts another callback
to Xs.

Given that the interface design cannot be changed in the short
term[2], what is the best way to handle this situation?

The simplest thing that comes to my mind is to perhaps use a
persistent IOR; is this possible and/or feasible to do using
omniORBpy? (Xs is implemented using omniORBpy/omniORB-2.8.0.) I
skimmed the omniORB mailing list archive, but am unsure how step 2 as
described in:

  http://www.uk.research.att.com/omniORB/archives/1997-06/0021.html

is done using omniORBpy. (Also, as this article is nearly 3 years old,
I'm wondering if things have changed since it was written.)

Alternatively, I read a little about the LifeCycle Service at:

  http://www.uk.research.att.com/omniORB/doc/omniLifeCycle/lifecycle.pdf

but I didn't follow it very well (mostly because it's getting late
here :-) Is this something I should pursue further?

Are there any other suggestions or common approaches used to
work around this problem (and using only the BOA support of omniORB2)?

Thanks for any information and/or suggestions you can share.

Footnotes: 
[1] I've read some of the caveats concerning the use of oneway
    methods, and their unreliability, particularly the section in
    Henning and Vinoski. But this is a legacy interface that I must
    support in the short-term.

[2] Ideally, I think the Yc client implementation and Xs server
    implementation should use something like the CosEvent Service, or
    perhaps AMI. Or at the least, Yc should use a CosNaming or call an
    Xs factory implementation to get a valid Xs IOR when it needs
    one. However, it is very unlikely that this will change in the two
    month time-frame that this interface must be deployed within.

-- 
 -mb-