Re: oaf async activation

[Torsten Schulz <Torsten Schulz germany sun com>]

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