It seems to me that you'll still need to call the handler with the
message since the determination might need the message.
So, doing:
  loop over chain
     call each handler to see if it wants to be invoked
  loop over chain again
     call each handler that wants to be called

doesn't seem any faster to me than just asking the handler
to do the "do I want to be called" check as the first thing in
its invoke() method and just looping once.
Or am I missing something?
-Dug


Richard Sitze/Austin/IBM@IBMUS on 09/26/2002 11:32:13 AM

Please respond to [EMAIL PROTECTED]

To:    [EMAIL PROTECTED]
cc:
Subject:    [axis] Smart(er) Handlers


Given a list of handlers to load:

        H1, H2, H3

in WSDD, what I'm proposing is that the runtime query each handler as it
identifies it in a service configuration and *ask* the handler if it wants
to be loaded in the current environment:

        if (handler->isEnvironmentallyFriendly())
                put handler in chain...

Semantically, we can do the same thing by letting the handler (when
called) return immediately IF it doesn't have anything to do.

Why:
        - I'm a performance bigot, and if the handler isn't going to *do*
anything, then I don't want it called.
        - It's easy to code.

Example 1:
        A Service Handler: verify that required service/classes are
(loadable) and disable handler if not.

Example 2:
        Debug Handler: enable only if debug-mode ON


****

So, having put some effort into trying to give you an example (I can't
really SAY what my internal requirements are, now can I :-), it stricks me
that a reasonable and cool alternate might be:

        realHandler = configuredHandler->getRealHandler();
        if (realHanderl != null)
                put realHandler in chain...

[names should be changed to protect the innocent..]

Default behaviour is getRealHandler() { return this; }

So, the method getRealHandler can act as a factory...  a security handler
could return a 64 or 128 bit security scheme.


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development



Reply via email to