axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manish Balsara <mani...@aumsoft.com>
Subject RE: normal flow
Date Fri, 23 Feb 2001 13:26:59 GMT
Steve

I had thought that increasing the number of handlers could have been the
reason for introducing the concept of pivot.

I do not know what use cases were considered for handlers, but I can see
handlers being used for:
logging, authentication, notification, transaction, persistence 
(reliability), digital signature, dispatch... 

Most of these handlers (except logging and maybe notification) have
different behavior for input and output. I do not see a lot of duplication
or increase in complexity, if I look at the standard handlers, as
mentioned above. Not to mention it would be more object oriented
(I am not a purist)

Since, this has already been discussed, Can you please point me where I
can find the use cases or discussion on the pivot vs sepaarte
request/response handlers.


thanks
manish


On Fri, 23 Feb 2001, Steve Graham wrote:

> Manish:
> We had hoped to avoid having separate handlers for request processing and
> response processing.
> This would (nearly) double the number of handlers, increasing admin
> complexity for the Axis admin and complicating the deployment engineers job
> having to worry about putting the right "kind" (request or response) of
> handler on the right chain.
> 
> By modeling a getRequestMessage(), getResponseMessage(), getCurrentMessage
> () in the MessageContext, the engine itself can encapsulate away these
> details from the handler; allowing many handlers to be deployable on either
> request or response processing chains.  Now for those handlers that are for
> some reason specific to request or response processing, then the handler
> can be coded to do getRequestMessage() explicitly.
> 
> sgg
> 
> ++++++++
> Steve Graham
> sggraham@us.ibm.com
> (919)254-0615 (T/L 444)
> Web Services Architect
> Emerging Internet Technologies
> ++++++++
> 
> 
> Manish Balsara <manishb@aumsoft.com> on 02/22/2001 07:38:39 PM
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> cc:
> Subject:  RE: normal flow
> 
> 
> 
> I don't know whether this was already discussed, but why not have
> different handlers for Request and Response messages? This would remove
> the need for a pivot, since the handlers would know what they are
> supposed to do.
> 
> For example:
> public class LogHandler extends Handler
> {
>      public void process(MessageContext context)
>      {
>           // do something...
>      }
> }
> 
> public class LogRequestHandler extends LogHandler
> {
>      public void process(MessageContext request, MessageContext
> response)
>      {
>           process(request);
>      }
> }
> 
> public class LogResponseHandler extends LogHandler
> {
>      public void process(MessageContext request, MessageContext
> response)
>      {
>           process(response);
>      }
> }
> 
> 
> 
> This might work well for any handlers which do distinct operations on
> request/response (example: Dsig, Authentication,...). The drawbacks I can
> see are:
> - namespace pollution
> - performance might get impacted, if the handlers are stateful
> 
> manish
> 
> > >
> > > Glen Daniels <gdaniels@allaire.com> on 02/22/2001 12:23:18 PM
> > >
> > > Please respond to axis-dev@xml.apache.org
> > >
> > > To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> > > cc:
> > > Subject:  RE: normal flow
> > >
> > >
> > >
> > >
> > > OK - here's a thought for how this works:
> > >
> > > public class MessageContext {
> > >     ...
> > >     boolean responseProcessing = false;
> > >     ...
> > >     public Message getCurrentMessage()
> > >     {
> > >         if (responseProcessing)
> > >             return responseMessage;
> > >         return requestMessage;
> > >     }
> > >
> > >     public Message getResponseMessage() throws AxisException
> > >     {
> > >         if (responseProcessing)
> > >             throw new AxisException("Can't get response message for a
> > > response!");
> > >         return responseMessage;
> > >     }
> > > }
> > >
> > > In other words, Handlers deal with their current message,
> > > which is either
> > > the request or the response depending on whether we've passed
> > > the service
> > > handler / pivot point.  If a Handler wants to write something to a
> > > "response" message (NOTE: this is one reason "incoming" and
> > > "outgoing" were
> > > good terms; what I mean here is the response relative to the
> > > Handler - i.e.
> > > a Handler which checks for an authentication header in the
> > > current message
> > > and wants to respond with a challenge header if it's
> > > missing), that can
> > > ONLY
> > > work on the input side of things.
> > >
> > > If we want certain Handlers to work only on input or output
> > > chains, we can
> > > add that information to the deployment configuration of the individual
> > > Handlers, and the WSDD interpreter will know an error has
> > > occurred if you
> > > try to break the rules by including one in an inappropriate chain.
> > > --Glen
> > >
> > > > -----Original Message-----
> > > > From: Steve Graham [mailto:sggraham@us.ibm.com]
> > > > Sent: Thursday, February 22, 2001 6:44 AM
> > > > To: axis-dev@xml.apache.org
> > > > Subject: Re: normal flow
> > > >
> > > >
> > > > Yuhichi:
> > > > When a handler is developed, the normal case is that the
> > > > handler should
> > > > work on request or response chain.  We had talked about
> > > > adding API to the
> > > > MessageContext to allow the Axis Engine to specify which is
> > > "current"
> > > > message (request or response).  Pivot would also use this API
> > > > to mark the
> > > > change from request processing to response processing.  We
> > > > need to work
> > > > these details out.
> > > >
> > > > Certain handlers are specifically designed to work on request
> > > > or response
> > > > message.  The deployment engineer should take care when
> > > > deploying these.
> > > >
> > > > So to address your last question,  at WSDD configuration
> > > > time, the handler
> > > > is designated as request processing or response processing by
> > > > which chain
> > > > it is included on.
> > > >
> > > > sgg
> > > >
> > > > ++++++++
> > > > Steve Graham
> > > > sggraham@us.ibm.com
> > > > (919)254-0615 (T/L 444)
> > > > Web Services Architect
> > > > Emerging Internet Technologies
> > > > ++++++++
> > > >
> > > >
> > > > "Yuhichi Nakamura" <NAKAMURY@jp.ibm.com> on 02/21/2001 11:11:43
PM
> > > >
> > > > Please respond to axis-dev@xml.apache.org
> > > >
> > > > To:   axis-dev@xml.apache.org
> > > > cc:
> > > > Subject:  Re: normal flow
> > > >
> > > >
> > > >
> > > >
> > > > Steve,
> > > > I want to understand some aspects of handlers.
> > > > Obviously we have three types of handlers here:
> > > > request, pivot and response handlers.
> > > > They are distinguished when message are processed, but not
> > > > distinguished
> > > > at the API (single API).  I hope, so far, right.
> > > >
> > > > So, when I develop a handler, should I know (decide) the type
> > > > of handler,
> > > > or is the type
> > > > of the handler decided at the configuration time (based on WSDD)?
> > > >
> > > > Best regards,
> > > >
> > > > Yuhichi Nakamura
> > > > IBM Research, Tokyo Research Laboratory
> > > > Tel: +81-46-215-4668
> > > > FAX: +81-46-273-7428
> > > >
> > > >
> > > > From: "Steve Graham" <sggraham@us.ibm.com> on 2001/02/21 04:47
> > > >
> > > > Please respond to axis-dev@xml.apache.org
> > > >
> > > > To:   axis-dev@xml.apache.org
> > > > cc:
> > > > Subject:  normal flow
> > > >
> > > >
> > > >
> > > > Recall that we had two alternative "models" for service deployment:
> > > > targettedWebService (request, pivot, response) and "normal"
> > > > (just a chain)
> > > > models?
> > > > I am now of the opinion that we should drop "normal" model.
> > > > The reason is,
> > > > we need to have an mechanism where we can tell which handlers are
> > > > processing the request message ,and therefore are candidates
> > > > to satisfy
> > > > mustUnderstand constraints of headers in the request message.
> > > >
> > > > This makes the WSDD simpler, and I think removes a potential
> > > > confusion area
> > > > without making severe restrictions.
> > > >
> > > > sgg
> > > >
> > > > ++++++++
> > > > Steve Graham
> > > > sggraham@us.ibm.com
> > > > (919)254-0615 (T/L 444)
> > > > Web Services Architect
> > > > Emerging Internet Technologies
> > > > ++++++++
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> 
> 
> 
> 






Mime
View raw message