Return-Path: Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 38877 invoked from network); 23 Feb 2001 18:18:01 -0000 Received: from web.qlcomm.com (206.86.127.251) by h31.sny.collab.net with SMTP; 23 Feb 2001 18:18:01 -0000 Received: (qmail 11797 invoked from network); 23 Feb 2001 13:26:59 -0000 Received: from web.qlcomm.com (HELO web) (206.86.127.251) by web.qlcomm.com with SMTP; 23 Feb 2001 13:26:59 -0000 Date: Fri, 23 Feb 2001 13:26:59 +0000 (GMT) From: Manish Balsara X-Sender: manishb@web Reply-To: Manish Balsara To: axis-dev@xml.apache.org Subject: RE: normal flow In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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 on 02/22/2001 07:38:39 PM > > Please respond to axis-dev@xml.apache.org > > To: "'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 on 02/22/2001 12:23:18 PM > > > > > > Please respond to axis-dev@xml.apache.org > > > > > > To: "'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" 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" 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 > > > > ++++++++ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >