No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Encapsulating asynchronous servives on server side


    I am working on creating SmartGWT datasources for a legacy application.
    I am using server-side integration, with DMI calls.

    This works well when the API that provides the actual data is synchronous,
    but in my case, there are some asynchronous calls as well, which return the data via callbacks.

    What is the recommended approach in this case?

    When I get a DSRequest, I must answer with a DSResponse synchronously. Should I manually spawn a new thread (and wait for the asynchronous callbacks to arrive), or is there a better solution?

    Thank you for your help:


    Another option would be to subclass the IDACall servlet, and override processRPCTransaction()

    Note that the httpRequest that came from the client can contain multiple queued rpcRequest and dsRequest objects.

    In your override, you can call getRequests() on the rpcManager object passed in, and iterate through the requests.

    For RPCRequests that aren't DSRequests, or DSRequests that don't need custom asynchronous handling you can call "handleRPCRequest" or "handleDSRequest" to get a DSResponse immediately (via the standard codepath, which will 'execute()' the request, respect all DMI overrides, etc), and then call send() on the rpcManager object to queue them up for sending back to the client.

    For requests that do need asynchronous handling on the server, you can run your asynchronous logic and then in a callback, build the DSResponse and call 'send()' on the rpcManager.

    Once "send" has been called on all rpc requests, the actual HTTPResponse will be sent back to the client.

    Make sense?