Uploaded image for project: 'Blacktie'
  1. Blacktie
  2. BLACKTIE-399

Provide an alternative client response implementation that does not use TAO and use this as the default



      Currently we have a dependency on TAO for two reasons:
      1. To talk to the transaction manager - Mike has resolved this in BLACKTIE-308
      2. To be able to return messages to callers which have sent messages via stomp/HornetQ

      I would like to remove the need for 2 above so that it is one less dependency that we have.

      To be clear, the initial message will travel over JMS as it does today, but wheras today an IOR is sent for the responder to connect to, now an ipaddress/port will be sent and the responder will be expected to connect to that socket to respond.

      Each entity should open a single server socket (configured by btconfig.xml) so multiple remote entities will need to connect to this and the code will dispatch it to the correct thread.

      1. When a client initially boots up it will create a single local "dispatcher" thread, which has server socket so that it can accept incoming requests
      2. When it sends an initial message to a service, it usually sends an IOR for responses, doesn't it? The service can then connect to that IOR to send any response.
      3. Instead, what I propose is that the client when it sends its request will request from the dispatcher a token (a "conversation id", an incremental long lets say).
      4. The client thread will notify the local "dispatcher" that if the dispatcher receives a message with this conversation id, it should pass the message to it (using wait/notify possibly).
      5. Then, when the client sends the message instead of the IOR, it can now encode:
      a. its ip address,
      b. the port that the server socket is listening on, and
      c. the "conversation id"
      6. When a service receives a request, it can connect to the ip/port specified in the clients request (i.e. the remote clients "dispatcher"). The initial response it sends will contain the "conversation id", thereby allowing the clients "dispatcher" to determine the correct thread to pass the request.
      7. Remember, in the case of tpconnect/tpsend/tprecv/tpdiscon there could be several exchanges over this socket now but these should be over the same socket connected to in step 6 above

      NOTE: Clearly we need to be sure that there are no valgrind errors with this work

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  zhfeng Zheng Feng
                  tomjenkinson Thomas Jenkinson
                • Votes:
                  0 Vote for this issue
                  2 Start watching this issue


                  • Created: