axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <NAKAM...@jp.ibm.com>
Subject Re: New Handler design - what do you think??
Date Fri, 25 May 2001 06:21:35 GMT

Rob,
I see your point.  I am concerning the release timing of
the new parser stuff (with a fairly good stability).
Since I myself is working on other portions (security etc.),
I need a functional stuff ASAP rather than a nicely designed one.
It might be a good idea to have a DOM-based implementation (I mean,
same API, but not elegant implementation) for
two reasons: 1. you can realize how fast the new arch is that the
naive one.  2. We can get a functional stuff by DOM easily.

I also want to know if this architecture requires multi threads.
Most J2EE servers do not allow applications to create their own
threads.

Finally I personally want to put some handlers on EJB Containers,
yet receiving messages by servlets.  This indicates that you have to
serialize SOAP messages when sending them to EJB Container
via RMI.  Have you consider such case?

Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668


From: Rob Jellinghaus <robj@unrealities.com> on 2001/05/25 14:30

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org, axis-dev@xml.apache.org
cc:
Subject:  Re: New Handler design - what do you think??



Most of this handler work is not so much about performance, though that is
part of the picture.  The main driver, I think, is trying to separate
parsing flow (which is totally determined by the arbitrarily-reordered
structure of the envelope) from handler control flow (which may need to
happen in a well-defined sequence).

Some main use cases:

- Authentication -- verifying that an authentication header is valid before
any method dispatch or other time-consuming processing takes place.

- Debug handling -- processing certain headers (which set, say, debug state
that must be configured before the processing to be debugged) before all
subsequent envelope processing occurs.

In general, the problem is that SOAP envelope field order is
underspecified, and we want a system that will function well independent of
envelope field order.

Cheers,
Rob


At 01:41 PM 5/25/2001 +0900, Yuhichi Nakamura wrote:
>
>Agreed.
>
>Performance on XML parsing would be critical, but we don't know how it
>affect the total performance.  My preference is that Axis mainly provides
>a functional platform, allowing to plug in performance-oriented components
>mentioned here (at lease for now).
>I am not sure if we have enumerated all performance-related factors in
>terms of the whole Axis architecture.  Parsing is just one piece, I think.
>
>Regards,
>
>Yuhichi Nakamura
>IBM Tokyo Research Laboratory
>Tel: +81-462-73-4668
>
>
>From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com> on 2001/05/25 11:52
>
>Please respond to axis-dev@xml.apache.org
>
>To:   <axis-dev@xml.apache.org>
>cc:
>Subject:  Re: New Handler design - what do you think??
>
>
>
>I didn't read it very carefully (I tried, but I'm too sleepy to
>follow it right now), however, it seems overkill to me. Are there
>really well-motivated use cases that demand this level of
>flexibility?
>
>This is again beginning to sound like a workflow engine
>implementation.. pretty close to a WSFL impl ;-).
>
>Maybe I am being too simplistic (and probably too tired) but I
>just don't see real, practical use cases that require this
>of flexibility.
>
>Sanjiva.
>
>
>
>





Mime
View raw message