Andreas > * By acquiring a RequestDispatcher for a servlet from the foreign > context and invoking forward or include on this object. > > The first approach can be discarded, again because of class loader > issues and the fact that it would require changes to the second > application. The second approach is more promising because it allows > to invoke the servlet that implements the target service. Note however > that there is an important restriction imposed by the servlet > specification on the use of RequestDispatcher#include/forward: "The > request and response parameters must be either the same objects as > were passed to the calling servlet’s service method or be subclasses > of the ServletRequestWrapper or ServletResponseWrapper classes that > wrap them." This means that these methods can't be called with > arbitrary HttpServletRequest/Response implementations. Obviously this > requirement is there to guarantee that the server gets access to the > original request/response objects. It could be that some servers do > not enforce this requirement, but for those that do, the practical > consequence is that the RequestDispatcher approach would only work if > the original request is received by SynapseAxisServlet, which is > perfectly compatible with the use case described here. > > My question is whether anybody on this list is aware of an existing > Axis2 transport implementation that uses this approach or if anybody > here sees any obstacle that would make it impossible to implement this > kind of transport. Since Synapse would most frequently modify the original request and forward a new (e.g. transformed request of the original) to the back end service, I doubt if this approach would be feasible.. however, although you could theoretically use Synapse with a servlet transport, we built the non-blocking http/s transports for Synapse, as acting as an ESB it needs to handle many connections concurrently passing them between the requester and the actual service. If using a servlet transport, the thread invoking Synapse would block until the backend service replies, and this could lead to the thread pool being exhausted very soon. The objective of the non-blocking http/s transport is to prevent this and it works very well when load tested.. Anyway when two apps communicate on the same host, the TCP overheads are reduced AFAIK by the OS's and the calls passed through locally
asankha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
