Back-to-back HTTP User Agent

["J. D." <j1...@yahoo.com>]

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
following:
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.

Questions:
----------
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.



      

Re: Back-to-back HTTP User Agent

[Oleg Kalnichevski <ol...@apache.org>]

On Wed, Jun 03, 2009 at 11:44:11PM -0700, J. D. wrote:
> 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
> following:
> 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.
> 
> Questions:
> ----------
> 1) Is this design idea feasible using current HTTP Component NIO implementation?

I think it is a fairly common setup for an HTTP proxy or an HTTP gateway.
Apache Synapse employs a very similar architecture.


> 2) Is it safe to retain NHttpResponseTrigger and HttpResponse for future use.

Yes, it is.

> 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.
>

Not really much. There are SharedInputBuffer / SharedOutputBuffer classes that
one can use to share content between an I/O dispatch thread of an I/O reactor
and a worker thread. These classes can be used as an adaptor between NIO and
classic (blocking) I/O models.

Hope this helps

Oleg


 
> - J.D.
> 
> 
> 
>       

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org