Hi All, IMHO security handler should be the last, when sending a message and should be the FIRST when receiving the message. And I think we should be able to achieve what you want with a few changes to Axis2 and the security module.
Now the objective is to be able to store the message and re-inject it into Axis engine. But if we preserve the original (secured) message and try to re-inject it, it will fail since most of the time the message is protected against replays by the use of a signed timestamp. Therefore if we are re-injecting the message, we _must_ re inject the 'processed' SOAP message and avoid the security handlers. The best way to do this is to introduce a 'Security' phase into Axis2, and then the RM module can insert the 'Persistence' handler as the last handler of the security phase and it can take care of storing the message. Where should we place this 'security' phase? Right now the security IN handler is placed after the URL dispatcher in the 'Dispatch' phase, since we MUST have the service dispatching complete before we invoke the security handler (To pickup the service specific config). But when we introduce the new 'Security' phase we will have to breakup the 'Dispatch' phase into two phases (described below): Transport based dispatch phase (TBDP) - Here we will try to do service/operation dispatching *ONLY* using transport information - E.g. URL or SOAPAction in the case of HTTP and we MUST find a service based on transport information. Message based dispatch phase (MBDP) - Here we will try to do Operation dispatch using information from the SOAP message. Now we can insert the 'Security' phase in between the TBDP and MBDP: See the following illustration: http://people.apache.org/~ruchithf/phases.txt Now since 'persistence' handler is the last handler of the security phase it will be able to store the processed (signature verified and decrypted) message and the dispatching info about the service/operation. This info (service/operation and processed SOAP message) can be used by the other RM handlers for re-injection. Comments...? Thanks, Ruchith p.s. Posting to the Axis-dev list as well On 12/8/05, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: > Hi Jaliya,All, > > hmm. Very Good point. > We can easily put a handler that does this (lets call this RMPersister). It > seems like this has to be the very first handler of the inFlow. But since we > are after the transport level we will have to save any changes that happened > there. At a glance it seems like we should save following > > SOAPEnvelope -> We can easily save this in a database. > Transport Information -> We have to save the name of in and out transports. > And transport header > information. > > > If we try to save every message this could greatly reduce the performance. > So we could try to detect the messages that go towards RM enabled services. > We could identify them by inspecting the SOAP envelope. > > But When security is present and messages come in an encrypted form a major > problem could arise. We cannot inspect messages without decrypting them. So > the security handler has to be present before the RMPersister handler. But > if Security IN Handler edit the SOAP envelope, it could get confused when we > re-inject message when recovering. But if we have the original SOAP > Envelope available (without decrypting), we can inject that. But we need > some help from the security guys :) > > Thanx, > Chamikara > > > > > On 12/8/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Chamikara and all > > > > I was thinking this sometimes back and had this kind of idea. Need to > > clarify regarding the feasibility with other modules. > > If we need to provide failure safe RM then we need to store messages. > > So if we store them just after the transport level with some id then in a > > crash, RM can make that message to inject into axis2 engine at the module > > initialization method. (That is why we add the module init method in the > > initial design of Axis2) > > Since we store messages before they get processed, we do not want to store > > the context information( assume that RM store everything in a DB) > > > > Please comment. > > > > Thanks, > > > > Jaliya > > > > > > > > ----- Original Message ----- > > From: Chamikara Jayalath > > To: [email protected] > > Sent: Tuesday, December 06, 2005 6:23 AM > > Subject: Supporting permanent storage based reliability > > > > > > Hi all, > > > > I'm trying to implement failure safe reliability for Sandesha2. The idea > > is to allow a Axis2+Sadesha2 system to continue a reliable message > > sequence even after a failure (may be due to a sudden shutdown of > > Sandesha2, or may be due to power failure). Since Sandesha2 itself is > > going to be based on a database, it can protect its state from a crash. > > > > However protecting the state of Axis2 system is a problem. It seems like > > to continue correctly Axis2 will need the contexts to come back with the > > same relationships and state ( flow information ect. ) it had before . > > > > Does this mean that we have to ask axis2-devs to bring back the Context > > Hierarchy Serialization methods we agreed to remove from it sometime back. > > Or is there a better/different way? > > > > Thanx, > > Chamikara > > > > -- Ruchith
