hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. D." <j1234d2...@yahoo.com>
Subject Back-to-back HTTP User Agent
Date Thu, 04 Jun 2009 06:44:11 GMT
I need a system with a back-to-back HTTP user agent:

System Reqs:
1) HTTP Server  accepts HTTP requests from user.
2) An unrelated (w.r.t. HTTP protocol i.e. no proxy semantics) HTTP Client 
issues a request and elicit response from backend server(s) for request in (1).
3) Based on HTTP Client response and result of processing this response, 
a response must be sent back to the user's original HTTP Server Request.

  User <-> NIO Server+NIO Client <-> BackEnd

The HTTP response from backend servers will have response entity data - 
none of the other legs carry significant data.

High Level Design Items:
Based on my current research into HTTPComponent NIO, it seems like I need
1) An NIO Server:
  a) DefaultListeningIOReactor
  b) DefaultServerIOEventDispatch
  c) AsyncNHttpServiceHandler
  d) A custom MyServerHandler - a NHttpRequestHandler implementation 
     is registered in NHttpRequestHandlerResolver. 
     i) This will kick off connect to NIO Client using the NIO Client Reactor. 
     ii) NHttpRequestHandler#handle implementation retains HttpResponse and 
       NHttpResponseTrigger into an application construct for future 
       NHttpResponseTrigger#submitResponse when NIO Client receives response.
       HTTPContext of NIO Client retains an id to this application construct 
  e) Default timeout and exception processing.

2) An NIO Client:
  a) DefaultConnectingIOReactor
  b) DefaultClientIOEventDispatch
  c) AsyncNHttpClientHandler
  d) A custom MyClientHandler - a HttpRequestExecutionHandler  implementation
     is registered to AsyncNHttpClientHandler.

     i) handleResponse implementation processes the response and computes the
       response to be sent for NIO Server Response. It retrieves the NIO server
       saved NHttpResponseTrigger and HttpResponse and issues a submitResponse
       for NIO Server Response to the user.
     ii) Failure or timeout for HTTP Client triggers a failure
       response/exception on NIO Server.

1) Is this design idea feasible using current HTTP Component NIO implementation?
2) Is it safe to retain NHttpResponseTrigger and HttpResponse for future use.
Note that HttpResponse will be guarded for thread safety. 
3) Are there any constructs in the current HTTP NIO implementation that would
facilitate the synchronization across multiple sessions like the one between NIO
Server Session and NIO Client Session.

- J.D.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message