Hi Chinthaka, Ruchith: >> Since RequestURIBasedDispatcher is the only possible mechanism to >> figureout the service without accessing the other SOAP headers (e.g. >> wsa headers) and the SOAP bosy, can we change the order of the >> dispatchers, or can we make it configurable such that its possible to >> change the dispatch order (to have the RequestURIBasedDispatcher >> first), when the security module is engaged? > > Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service > identification based on the socket information ? If so, fine. > > So lets have a phase called "DispatchPhaseOne". And the rest in > "DispatchPhaseTwo".
1) Transport-based dispatchers should be in the transport phase, not the global dispatch phase. Thus they should always run before anything like WS-Addressing dispatch. Doing dispatch based on URI or port or any kind of binary/text header outside the SOAP envelope is always going to be faster than cracking the body and reading WSA headers, so we should let that happen first.
2) -1 to "DispatchPhaseOne"/"DispatchPhaseTwo". I don't think this is necessary.
3) I still don't see the need for a "PreDispatch" or a "PostDispatch" phase. Isn't the whole point of configurable phases/handlers that you can say things like "BEFORE Dispatch" and "AFTER Dispatch" as rules? What's the difference between having an explicit "PreDispatch" container and just saying "BEFORE Dispatch"?
--Glen
