Re: oaf async activation

[Michael Rumpf <michael rumpfonline de>]

Hi,

I must admit that I did not use Bonobo yet, but I think the issue is not
connected to Bonobo and thus resides on a lower level: CORBA.

I had another look at two CORBA Messaging papers by Douglas C. Schmidt
and Steve Vinoski, because it has been quite long since I read about it
the first time.

http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col15.pdf
http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col16.pdf

They contain a very good introduction to the topic and it's worth
reading !!!

Small summary:
=====================================

AMI (Asynchronous Method Invocation) provides two different extensions
to the three CORBA call models (synchronous twoway, oneway, deferred
synchronous):

1. Polling Model
----------------
>From the IDL file a Poller class for an interface is created which can
be used on the client side to query the status of the request. The
client can decide to block on the status call, or wait until the
response is finished. The evaluation in the second paper says: "...An
implementation-related drawback to using AMI polling is that it requires
to use Objects-by-Value (OBV) ... Another drawback with the AMI polling
model is that it doesn't really solve the inefficiency of waiting for
long latency calls to complete, ...." (C++Col 16, chapter 2.2, p.3)
Because ORBit does not provide OBV it is not possible to implement the
polling model easily.

But hold on, better news will follow...

2. Callback Model
-----------------
The AMI callback model does not have those limitations. The IDL compiler
must create a callback object with special methods for each operation
(e.g. get_quote()) or attribute, e.g. operations are prefixed by
"sendc_" and followed by the normal operation name. The first parameter
is the object reference to the callback object and then in parameters
will follow (sendc_get_quote(AMI_QuoterHandler*, const char*)). The
client is responsible for implementing the callback object. This object
is derived from ReplyHandler which is defined in the Messaging spec.
Methods for normal replies and exceptional replies are provided by the
callback object (get_quote(CORBA_Long),
get_quote_execp(AMI_QuoterExceptionHolder)) 

The evaluation of the callback model comes to a promising conclusion:
"A benefit of the AMI callback model is that it helps solve the problems
with waiting efficiently for long latency calls to complete. ... It
allows single-threaded applications to avoid blocking while waiting for
responses. This feature potentially makes programming easier and avoids
to determine the best threading model to use for the application."
(C++Col. 16, chapter 2.3, p. 5)

The paper concludes also that it puts more work to the client developer
because he needs to implement the callback object and poll for replies
frequently. BUT, this approach does *nothing* to the IDL interfaces,
that means no special methods need to be introduced. Everything is
handled by the ORB together with the IDL compiler which produces the
necessary skeleton implementations. AND, no special CORBA 2.3 features
like OBV are used, so the impact on ORBit shouldn't be _that_ big
(Elliot ?) ! From what I oversee currently this should only be an
orbit-odl issue !?!?


For me it sounds like a good solution to the problem discussed in this
thread. For the CORBA purists out there the benefit would be that the
solution is standard compliant and can be used independently from
Bonobo.

Michael

Torsten Schulz wrote:
> 
> 
> 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
> 
> special-orbit-idl --async-request OAF::ActivationContext::activate ./oaf.idl
> 
> /*--------------------------------------------------------------------------
>   generated header begin
> */
> #include <bonobo/bonobo_async_request.h>
> 
> typedef struct {
>     BonoboAsyncRequest base;
> 
>     CORBA_Object        return_value;
>     CORBA_char*         param_requirements;
>     GNOME_stringlist*   param_selection_order;
>     OAF_ActivationFlags param_flags;
> } ASYNC_REQUEST_OAF_ActivationContext_activate;
> 
> BonoboAsyncRequest* ASYNC_REQUEST_CREATE_OAF_ActivationContext_activate();
> 
> /* generated header end
> --------------------------------------------------------------------------*/
> 
> the function ASYNC_REQUEST_CREATE_OAF_ActivationContext_activate() has
> to create the request object, initialize the members and set two
> function pointers into the base member, which sends the request
> (asynchron) and tries retrieve the reply (non blocking). A first look
> at the present code generation from orbit-idl makes me feel that it
> is not to difficult. It is nearly to break down the generated code of
> OAF_ActivationContext_activate() into two pieces.
> 
> /*--------------------------------------------------------------------------
>   bonobo_async_request.h could look like:
> */
> 
> typedef GIOP_unsigned_long Request_id;
> 
> typedef struct {
>     GtkOjectBase base;
> 
>     CORBA_Object       request_target;
>     CORBA_Environment* ev;
> 
>     /* marshal in and inout parameters and send the request.
>        returns the request id */
>     Request_id (*send_request) (BonoboAsyncRequest* request);
> 
>     /* try to retrieve the reply and unmarshal return value,
>        exceptions and out parameters.
>        returns true, if the reply was pending or the original request
>        was oneway
>        returns false, if the reply is not pending yet
>     */
>     gboolean (*try_to_retrieve_reply) (BonoboAsyncRequest* request,
>                                        Request_id _ORBIT_request_id);
> 
> } BonoboAsyncRequest;
> 
> typedef struct {
>     GtkOjectBaseClass base_class;
> 
>     /* signals */
>     void (*reply_recieved) (BonoboAsyncRequest* request);
> 
> } BonoboAsyncRequestClass;
> 
> /* async request runtime function */
> 
> bonobo_async_request_send(BonoboAsyncRequest* request);
> bonobo_async_request_send_multiple(GList* request_list);
> 
> /*
> --------------------------------------------------------------------------*/
> 
> In my imagination this could be implemented without threading problems
> with GTK or ORBit. The benefit will be a easy way to use all synchronously
> designed IDL interfaces in a asynchchron way. And you will use a similar
> concept as it will come with further CORBA version.
> 
> 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);
>     ...
> }
> 
>     Sorry for so many placeholders and mistakes I've made with the
> GTK object model. But if this could be a acceptable way to keep the
> IDL definitions clear and consistent, I would like to work a more
> detailed proposal.
> 
> --
> Best regards,
>  Torsten                            mailto:Torsten Schulz germany sun com