axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James M Snell" <jasn...@us.ibm.com>
Subject Re: Compromise on streaming
Date Tue, 29 May 2001 04:01:13 GMT
Glen...

Looks good to me. 

- James Snell
     Software Engineer, Emerging Technologies, IBM
     James M Snell/Fresno/IBM - jasnell@us.ibm.com
    "God placed me on the earth to do a certain number of things. Right 
now, I am so far behind, I will never die." - Anon.

Please respond to axis-dev@xml.apache.org 
To:     <axis-dev@xml.apache.org>
cc: 
Subject:        Compromise on streaming



OK, after thinking a bunch about the proposed new design for
Handlers/Deserializers, I came up with what I think is a reasonable
compromise which gets us in the region without going all the way into a
full-streaming architecture.  I would like to propose the following:

1) Introduce a new Handler method:

   public void registerDeserializers(DeserializationContext ctx);

   The purpose of this is to allow Handlers/Chains to register themselves 
as
SAX handlers for particular elements (esp. headers), and also any specific
type mappings they want to enable for deserialization.

2) AxisServer.invoke() will, before invoke()ing any Handlers, create a
DeserializationContext and allow all Handlers we know about (i.e. 
Transport
Input, Global Input) to register deserializers as described in (1).

3) Whenever the service is determined (i.e. as a result of calling
MessageContext.setTargetService()), we will ask the service Handler to
register its deserializers and any type mappings into the
DeserializationContext.  This will often happen before the parse starts 
(in
a transport-specific dispatch handler like the URLMapper or
HTTPActionHandler).

4) If the service has NOT been determined by the time the SOAPSAXHandler
arrives at the first <Body> element, it will attempt to set the service in
the MessageContext based on the QName of that element.  This will result 
in
calling the logic in (3) and therefore registering any service-specific 
type
mappings.

So basically, we have what we've got now.  Handlers are invoke()d down the
chain until someone triggers the parse by asking for a Header/Body 
element.
The difference is that at that point, some of the Handlers on the 
processing
chain MAY have registered themselves as the "ElementHandlers" for 
particular
headers - this lets developers choose to write a single class that both
deserializes and processes headers.  And also, service specific type
mappings will be engaged as soon as we figure out what the service is -
which MAY now happen during the parse when we get to the 1st body element.
This solves the problem Sam had with not registering all the type mappers
before doing the parse.

This model will parse the entire message as soon as someone asks for a
Header/Body element.  It does NOT provide for "streaming processing" (we
still rely on the AxisServer to walk the chain of invoke()s), but I 
believe
it solves some of the problems that streaming solves, and it will be 
pretty
simple to add to the current code, and won't necessarily change the way
Handlers are written now.

Once I get commit access again, I can probably implement this in a day or
two.

Thoughts?

--Glen





Mime
View raw message