Results 1 to 3 of 3

Hybrid View

  1. #1
    Senior Member
    Join Date
    Feb 2013
    Posts
    54
    ... continue



    The second technique uses a predetermined 'response' item, where all the responses will be published.
    The client subscribes to the 'response' item and it keeps the subscription active for the entire session.
    The client sends the request with the sendMessage and the reply will be received as an update on this predetermined item.
    The 'response' item must be subscribed in RAW mode to avoid to merge and lose responses.
    Actually there must be one distinct item for each session, because the client must receive the responses only for the request it submit. This requires to use the getItems method of the MetadataProvider to replace the predetermined 'response' item with a version decorated with the sessionID and thus unique per session.
    Each request, received by the notifyUserMessage method of the MetadataProvider will be passed to the DataAdapter with the corresponding sessionID, so that the DataAdapter is able to publish the response as an update on the corresponding item for the sessionID.
    This implies also that the MetadataProvider must know the DataProvider, and must be able to route the sendMessage requests to it.
    Since the response is received asynchronously by the client, this solution requires also that the client must have a way to match the responses with the corresponding requests.
    The single predetermined 'response' item technique uses network resources more efficiently.
    - on the single item approach you'll send one request to the server (the subscription) plus one request per each request (the sendMessage)
    - on the disposable item approach you'll send two requests to the server per each request (subscribe+unsubscribe)
    Note however that on websocket sessions the requests are all sent over the same wesocket so that there is not the overhead of a classic http request to a server.
    And note also that, even if on the server the handling of a subscription is slightly heavier than the handling of a message, using the disposable subscription will spare some logic, so that probably there will be not much processing differences between the two options.
    The single predetermined 'response' item technique may let you spares some messages but since it is slightly more complex than the disposable item one, it should be used only in case of a hight rate of requests and you have already verified the first solution does not perform well.



    There is also a third technique which is actually is a trick that exploits the capability of the sendMessage to receive errors messages from the metadata adapter.
    The use of this technique is not encouraged but may be handy in some cases.
    Be aware that this solution can only be used if the notifyUserMessage method in the Metada Adapter can actually execute fast.
    As before the client sends the request with the sendMessage API. but the server will process the request directly in the notifyUserMessage method of the MetadataProvider interface, and will reply throwing a CreditsException, bearing the response as error message.


    Client code:





    Server code: Metadata Adapter





    hth,
    Marco
    Last edited by marco.testa; April 28th, 2014 at 02:35 PM.

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 05:05 AM.