[Axis2] Rampart performance - always expands OM?

[Dennis Sosnoski <dm...@sosnoski.com>]

In running performance tests with Rampart I've found that just having 
the Rampart module engaged on the client appears to cause the OM to be 
expanded for every message, even if no WS-Security processing is 
required. This results in a major performance hit. The whole point of 
AXIOM is supposed to be to avoid doing this kind of unnecessary 
expansion, and there's no reason for the OM to be expanded unless the 
SOAP:Body is being signed or encrypted.

I thought I'd seen some reference to this in the past, but I assumed 
it'd been corrected. I don't see anything in Jira that looks relevant. 
Is this a known issue?

  - Dennis

-- 
Dennis M. Sosnoski
Java XML and Web Services
Axis2 Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117

Re: [Axis2] Rampart performance - always expands OM?

[Nandana Mihindukulasooriya <na...@gmail.com>]

Hi Deepal
            All the handlers in Rampart to a initial check to see whether
Rampart is engaged and return immediately if not engaged but Dennis's
scenario is different. In his scenario

1.) Rampart is engaged to service/client
2.) Service/client doesn't have security policy / configuration associated
with it.

In this scenario also we don't need to do the OM -> DOM convention as
Rampart won't be doing any processing in this scenario too. It's a problem
of where these checks are done. These checks has to be done immediately
before any processing is done. I will look in to this. Dennis, please go
ahead and create a JIRA under Rampart project.

regards,
Nandana

On Sun, Jun 14, 2009 at 8:12 AM, Deepal jayasinghe <de...@gmail.com>wrote:

> As I know this is not a know issue, I know Rampart handler does
> OM->DOM->OM conversion, which is performance killer. So I think Rampart
> handler has to check whether a given module is engage for a give request
> and then invoke the handler.
> In the case of encryption it has to decrypt it, I think that is ok.
>
> Let's create a JIRA, I think this is a big performance problem.
>
> Deepal
> > In running performance tests with Rampart I've found that just having
> > the Rampart module engaged on the client appears to cause the OM to be
> > expanded for every message, even if no WS-Security processing is
> > required. This results in a major performance hit. The whole point of
> > AXIOM is supposed to be to avoid doing this kind of unnecessary
> > expansion, and there's no reason for the OM to be expanded unless the
> > SOAP:Body is being signed or encrypted.
> >
> > I thought I'd seen some reference to this in the past, but I assumed
> > it'd been corrected. I don't see anything in Jira that looks relevant.
> > Is this a known issue?
> >
> >  - Dennis
> >
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
> http://deepal.org
>
>


-- 
Nandana Mihindukulasooriya
WSO2 inc.

http://nandana83.blogspot.com/
http://www.wso2.org

Re: [Axis2] Rampart performance - always expands OM?

[Deepal jayasinghe <de...@gmail.com>]

As I know this is not a know issue, I know Rampart handler does
OM->DOM->OM conversion, which is performance killer. So I think Rampart
handler has to check whether a given module is engage for a give request
and then invoke the handler.
In the case of encryption it has to decrypt it, I think that is ok.

Let's create a JIRA, I think this is a big performance problem.

Deepal
> In running performance tests with Rampart I've found that just having
> the Rampart module engaged on the client appears to cause the OM to be
> expanded for every message, even if no WS-Security processing is
> required. This results in a major performance hit. The whole point of
> AXIOM is supposed to be to avoid doing this kind of unnecessary
> expansion, and there's no reason for the OM to be expanded unless the
> SOAP:Body is being signed or encrypted.
>
> I thought I'd seen some reference to this in the past, but I assumed
> it'd been corrected. I don't see anything in Jira that looks relevant.
> Is this a known issue?
>
>  - Dennis
>


-- 
Thank you!


http://blogs.deepal.org
http://deepal.org