asynchronous call to appserver from class - is there an even

Posted by gdb390 on 08-Sep-2010 03:19


I have an application which sends asynchronous calls to an appserver.

The call is initiated in a session super procedure...

In terms of moving forward we are now looking into transforming our applications into the OO world.

But is it possible to run asynchronous calls from a class ?

I guess you can do the run, but I'm wondering : what about the event-procedure ?

Is there something like event-method, the method to be executed when returning from the appserver ...?

kind regards


All Replies

Posted by maximmonin on 08-Sep-2010 03:27

create external procedure and run it as persistent.

set event response procedure as internal function of this persistent object.

for example:

CREATE asProcs.

RUN callback.p PERSISTENT SET asProcs.hProgress.

RUN serverprocedure.p PERSISTENT SET asProcs.hProc
      EVENT-PROCEDURE "OnEnd" IN asProcs.hProgress.
  process serverprocedure output parameters.

Posted by jankeir on 08-Sep-2010 03:41

I think that is what Gerd is doing now and he wants to know if it is possible to do the following

RUN serverprocedure.p PERSISTENT SET asProcs.hProc
      EVENT-PROCEDURE "SomeMethod" IN SomeObject.

I would like to know as well ;-)

Posted by maximmonin on 08-Sep-2010 03:47

AFAIK - not possible.

You can make persistent object call in class constructor and save handle to persistent object as private variable.

Delete object in destructor.

in this case external procedure will be part of class.

Posted by gdb390 on 08-Sep-2010 03:58

I thought it was not possible, that's why I tried to launch it on the communities.

Thanks for your responses !

@ Maxim : the solution you provided, was indeed the way I implemented it for the moment

@Jan : that's exactly what I wanted to know, but I think this is utopia

Posted by Admin on 08-Sep-2010 23:51

@Jan : that's exactly what I wanted to know, but I think this is utopia

Did anyone check if there's already something on the ERS for that? I'd like that feature as well. For now I can live with a supporting persistent procedure like done the two of you. When it's nicely encapsulated, I don't have a huge problem with it.

Posted by gdb390 on 09-Sep-2010 05:10

Hey Mike,

I suppose you mean Ehancement Request Site with ERS ?

I did check it and found the below :

EnhReq Id: 0000003880

Description: using event method on asynchronous call:
Prod Area: ABL LanguageStatus: ACTIVE
OS: AllWhen:
#Votes 5

Give a Detailed Explanation of       the Enhancement Request
06Mar09 - wvanbeek
when using the new  OO ABL you can make an asynchronous request to an appserver in a class  method. however, you still need a separate internal procedure to use as  the event-procedure.


Posted by Admin on 09-Sep-2010 05:31

Hi Gerd, yes that's the site.

I voted as well now.

Posted by Thomas Mercer-Hursh on 09-Sep-2010 11:36

Seems to me that this is in a category where votes and business cases should be unnecessary since it is so apparently a case of incompleteness in the OO implementation of the language.  It is one thing to tout the virtue of being able to mix procedureal and OO constructs, e.g., for gradual transition, but another thing to force an OO design to use procedural constructs simply because someone hasn't gotten around to making a statement like this compatable with an OO structure.

Posted by jankeir on 10-Sep-2010 02:42

We'll not talk about the inability to use/pass objects across the appserver boundary for now... Am I unreasonable to just assume all this will be available in OE11?

Posted by Thomas Mercer-Hursh on 10-Sep-2010 11:48

Actually, not to hijack this thread, but I think there are really two different levels of possible interaction across an appserver boundary ... or three if you want to include the current abilities and their relationship to use in classes as is the subject of this thread.

So, level 0 is the current call capabilities in the target is a run but the call can come from a class and we have this tacky problem of needing to use a callback *procedure* instead of a method.

The next level is to be able to use OO on the called end.  This is typically described by PSC in terms of being able to NEW and object, call a method on the object, and return the results of that method in a single appserver round trip.

The final level is, as you say, to actually pass an object across the boundary.  I'm not altogether sure this is actually a good idea, however.  It is certainly complex because the actual object in memory is a complex collection of allocations and pointers which are specific to the context of the AVM in which it is found.  It isn't clear how one would pass all that and, after all, one doesn't currently pass a .r across the boundary, so why do we even want to do this?

Note that it is a very different thing to pass the *state* of an object across the appserver boundary and reconstitute the object on the other side (which may or not be the same type of object; it just needs the same signature).  That requires no enhancement of the appserver connection, simply an easy and performant way to serialize the object (see my post in the OO forum on Progress.Lang.Object enhancements).

Note too that good OERA/OO design principles indicate strong separation of responsibilities as perhaps the most key architectural principle.  Clearly, the very existence of an appserver boundary is an extremely dramatic indicator of a layer boundary where we should have strong separation.  Thus, we really should only be passing messages across this boundary, not objects.  In fact, it would be a lot cleaner if AppServer worked more like Sonic, i.e., where a message went to an appropriate service and the service decided what to do with it instead of the current appserver structure where the client actually runs a specific procedure on the appserver, i.e., it knows too much about the implementation.

This thread is closed