axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruchith Fernando <ruchith.ferna...@gmail.com>
Subject Re: Supporting permanent storage based reliability
Date Thu, 08 Dec 2005 11:49:27 GMT
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 <chamikaramj@gmail.com> 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, jaliya@opensource.lk <jaliya@opensource.lk> 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: sandesha-dev@ws.apache.org
> > 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

Mime
View raw message