axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@macromedia.com>
Subject Re: writing handlers
Date Fri, 01 Jun 2001 14:29:16 GMT
I don't think it's a bad idea at all.  I just think there are a spectrum of
cases, which are more or less appropriate/hard depending on how much "extra"
information you might need.

The point is basically that I expect that a small percentage of the actual
services (body processors) are going to fall into the "hard" case, whereas due
to the nature of headers (orthogonal extensions relating to a message) I expect
a lot more of those use cases will require a richer information model.

That may start to be the case with body processors as well, especially ones
which rely on attachments or other bits of context, the more popular SOAP
becomes.

I do expect that by the time we release v1.0, we'll support introspecting an
RPC service class to see if we should tack a Context argument of some kind onto
each method call, for instance.  This kind of thing would work fine with your
idea for headers as well.  You'll still need Axis imports, but it's a question
of syntactic sugar at that point.

--Glen

----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Friday, June 01, 2001 10:18 AM
Subject: Re: writing handlers


> Everything you mentioned here that might make this a bad idea
> or hard could apply to the body itself.  So I don't see what the
> problem is - however we solve it for the body would apply to the
> header.
> As for a use-case - write a header handler.  Would you rather
> write something like DebugHandler+DebugHeader or just a simple class
> with one method in it?  I know which one is easier to me.
> -Dug
>
>
> "Glen Daniels" <gdaniels@macromedia.com> on 06/01/2001 10:14:44 AM
>
> Please respond to axis-dev@xml.apache.org
>
> To:   <axis-dev@xml.apache.org>
> cc:
> Subject:  Re: writing handlers
>
>
>
> 1) Standard RPC bodies (w/sec 5 encoding) have no attributes, whereas many
> headers probably will.  Therefore you'll still need a custom deserializer
> to
> turn your SOAP header into something that can be consumed by your Java code
> that doesn't want to understand SOAPEnvelope structure.  XML would be an
> exception to this, but then your code will still need to "understand" the
> structure.  And what about HREFs?  Would we expect their code to deal with
> them?  How?
>
> 2) The model now is to have the Handler set the processed bit on any
> headers it
> deals with.  We'd need to move to a model where each call out to custom
> code
> that is made for a header marks that header as processed if no exception is
> thrown, for instance.  The problem with that is that sometimes you might
> have
> interrelated headers such that you can't be sure you've "processed" the
> first
> one until you get the second one.  If you don't have a model for the whole
> message, you can't do that easily.  That said, we could certainly pass a
> Message to their custom code, but then what's the real difference between
> that
> and a Handler?
>
> 3) It seems like what you're talking about here is a Handler which can
> arbitrarily turn Headers into various forms and then dispatch them to some
> piece of custom code (determined by options on the Handler, but I'd assume
> you'd want to call other methods on the same object that implements your
> RPC
> service, so that lifecycle/object association issues don't get too hairy).
> This is a cool and interesting idea, but IMHO not something that's critical
> for
> version 1.  I think a lot of the use-cases for header processing won't
> easily
> fit into this model.
>
> 4) I'd like to see some detailed usage scenarios for this.
>
> --Glen
>
> ----- Original Message -----
> From: "Doug Davis" <dug@us.ibm.com>
> To: <axis-dev@xml.apache.org>
> Sent: Friday, June 01, 2001 8:55 AM
> Subject: writing handlers
>
>
> > Right now when we think of people processing headers
> > we're assuming they'll subclass Handler, but why?
> > We've all basically agreed that processing
> > a header is really the same thing as processing the
> > body so why not allow them to treat it that way?
> > (Note: the spec does too)
> > Why not allow them to specify the RPCDispatcher
> > should be used to process their header and then
> > we'll just call their method for them.  Then all
> > they need to write is their application logic and
> > no SOAP/Axis header processing code.
> > Likewise, they may want the header handed to them as
> > a block of XML (messaging instead of rpc), like
> > the Admin service does.  No Axis/header coded needed
> > here either.
> > Of course well still allow them to write a handler
> > if they want, but for probably 90+% of the cases
> > people won't need to import Axis code at all, leaving
> > them to focus on their business logic.
> > Really this isn't such a radical change, but rather
> > how we present the "preferred" way of doing things.
> > Not sure, but I think it does require a little bit
> > of code changes inside of Axis but I doubt it would
> > be very much.
> > Thoughts?
> > -Dug
> >
>
>
>


Mime
View raw message