Re: oaf async activation

[Maciej Stachowiak <mjs eazel com>]

Torsten Schulz <Torsten Schulz germany sun com> writes:

>  
> Thursday, October 05, 2000, 10:20:53 PM, Michael Rumpf wrote:
> 
> > To take AMI (Asynchronous Message Invocation) into consideration sounds
> > like a good idea because it represents the standard way of asynchronous
> > messaging in CORBA, which will be "officially" introduced by CORBA 2.4
> > around the end of the year.
> 
>     Until waiting for ORBit supporting AMI you can think about
> providing a replacement for that in the bonobo library. A special
> version of orbit-idl could generate asynchron request objects on
> demand for wanted IDL methods. This will not be any change of the
> language binding, but only a way to produce 'async sugar' to the
> client of CORBA objects. For example
> 

I'm afraid my thoughts are going to end up being negative about the
feasibility of this approach. They didn't start out that way, but the
more I thought about it, the more problems I saw with this
approach. Perhaps many of them can be rectified.

> 
> client example:
> 
> static void activate_reply_cb(BonoboAsyncRequest* request)
> {
>     if (request->ev->_major != CORBA_NO_EXCEPTION)
>     {
>         /* do error handling */
>         ...
>     }
>     else
>     {
>         OAF_ActivationResult* result =
>             ((ASYNC_REQUEST_OAF_ActivationContext_activate*)request)->return_value;
>         
>         switch (result->res._d)
>         {
>             ...
>         }
>     }
> }
> 
> {
>     ...
>     ASYNC_REQUEST_OAF_ActivationContext_activate*
>         request = ASYNC_REQUEST_CREATE_OAF_ActivationContext_activate();
> 
>     request->requirements = ...;
>     request->selection_order = ...;
>     request->flags = ...;
> 
>     gtk_signal_connect(GTK_OBJECT (request), "reply_received",
>                        GTK_SIGNAL_FUNCTION(activate_reply), NULL);
> 
>     bonobo_async_request_send(request);
>     ...
> }

This looks pretty hard to use, in particular, it compares pretty
unfavorably to the following possibility (OAF now provides something
close to this but only at the C wrapper level):

static void
activate_reply_cb (OAF_ActivationResult* result, CORBA_Environment *ev)
{
        ...
}

{
   OAF_ActivationContext_activate__async (requirements, selection_order, flags, activate_reply, NULL);
}

If this is going to use a special IDL compiler, why force the user to
marshall everything into a special async request and connect to a
signal? Why not generate stubs for an
OAF_ActivationContext_activate__async call that's similar to the
above?

Another issue is that OAF can't depend on Bonobo, at the very least
because Bonobo depends on OAF, so Bonobo is not the best place to put
this functionality. If we do have a special IDL compiler mode, I'm
pretty sure it should go in ORBit, of anywhere, to stay in sync with
the ORB itself.

Further, it wouldn't solve the problems I had with
Stream/PersistStream, because the way that works is that the component
makes synchronous calls to the app. You'd need not just a way to make
an asynchronous request, but also a way to handle an incoming call in
an asynchronous way, which the above does not provide. Since pairs of
mutally communicating objects is a common pattern in Bonobo, I'd guess
this crops up in other places as well.

And finally, how the heck would it work? It seems pretty hard
(impossible?) to do without mucking with ORBit internals. I'm not
really a CORBA or ORBit expert, so maybe I'm missing something, but as
I read the code, `ORBit_handle_incoming_message' (which ultimately
handles messages received on IIOP/GIOP connections, via a couple of
layers of indirection) doesn't do anything with incoming REPLY
messages except push them on a queue (via
`giop_received_list_push'). So you would need active periodic polling
of this queue, but sadly the only function you have as an exported API
for that is `giop_received_list_pop', when really you'd much prefer
the (sadly static) `giop_received_list_check_reply', which takes a
request ID.

Of course, mucking with the GIOP received message queue from non-ORB
code is likely to lead to Bad Things(tm). Really, what you'd want is a
way to hook reply handlers into `ORBit_handle_incoming_message'. But
if you're gonna hack ORBit that much, you may as well hack up async
code that actually implements the relevant CORBA spec.

This isn't even considering the possibility of in-process objects, of
course, where the stubs normally just make the call directly into the
servant's vepv.

Anyway, despite all these technical difficulties, I admire your
willingness to forge ahead and try to come up with a way out of the
dilemma posed by async app architecture.

It would be great if in the long run we could write ordinary
synchronous IDL and get nice async APIs for free. I don't think we're
very close to there yet though.

 - Maciej

(My sincerest apologies to people who had their brains melted by the
ORBit/CORBA minutiae in the message above; and my sincerest apologies
to Elliot for errors in the above, please correct 'em if you see 'em).