Proxy Style

[GregTomkins]

We expose several of our .p's as Java proxies in the following style:

/* real_work.p - known only to us, the vendor of the application */
DEF INPUT PARAM p_account AS CHAR. /* etc. etc. */
/* a ton of real work goes here, RUN, FIND, FOR EACH etc. */

/* proxy.p - known to Java users, our customers; proxied using ProxyGen */
PROCEDURE do_real_work:
  DEF INPUT PARAM p_account AS CHAR NO-UNDO.
  /* Generally and ideally, there is little to no additional code here */
  RUN real_work.p(p_account).
END.

I think I am aware of all the plusses and minuses of doing it this way (I thought about enumerating them here, but decided it would make this post overly tedious).

My question is whether this style is typical or whether people tend to just proxy the 'real_work.p' style procedures directly? Any other comments on how people go about exposing .p's through proxies?

EDIT: added code tags in the hopes Stefan might read this.

 

[medu]

If you want to have a single entry point then a proxy approach is best - for authentication, authorization, session management and those sort of things. If you have internal entries in that proxy (like in your code) then you'll waste some extra time for nothing - first run the proxy persistent and then run an IP in it, do you really need that extra appsrv round-trip?

Will see how 'singleton run' works in new version, that might save you some time in case you want the proxy to be a bunch of IP.

A 'generic' proxy can be designed just as a dispatcher that will either use the call interface (procedural) or dynamic-new on "appsrv-objects" (interface - have an 'execute' method or something in it)... the problem is with variable parameters, can use a temp-table (or even a longchar with xml/json serialization) from Java side while the interface between dispatcher and appsrv-objects can be a 'message object' - getNumParameters, getParameter(index), etc.

 

[Stefan]

EDIT: added code tags in the hopes Stefan might read this.

Sorry... no Java proxy experience. Our Web Services proxies on the other hand all have a (generated) main block only. The 'proxies' for our WebClient are nearly all single call - to prevent the extra AppServer round trips.

 

[RealHeavyDude]

I always prefer to directly call a .p on the AppServer vs. "binding" a state-less or state-free AppServer with a persistent procedure across multiple AppServer roundtrips. One day you might end up with a persistent procedure on the AppServer not being cleaned correctly and the AppServer agents stays bound ...

Furthermore we use the concept of dispatchers that have a ProDataSet defined as input-output that contains a context Temp-Table which tells the dispatcher what to do - call. This way we almost have a single point of entry on the AppServer and we don't need to rebuild the Java proxy each time we add / change funtionality on the server side. Of course this will take some management overhead too but you need to have some session management anyway which handles security and for example the context for batching when dealing with larger sets of data.

Heavy Regards, RealHeavyDude.

 

[GregTomkins]

We have a monitoring system in place so that if an AppServer stays bound for more than X seconds, we blow it away. This is partially for the purpose of catching people who forget to clean up their PP's and partially to deal with errant long-running queries.

We also have a dispatcher/entry point system that we use a lot internally, but ironically, not for proxied API's. I am going through a whole thought process of why we treat calls from our own app so differently than calls from the outside.

Anyhow, thanks for the various replies.