axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@allaire.com>
Subject RE: normal flow
Date Thu, 22 Feb 2001 20:29:37 GMT

I don't see how we're dropping the notion of pluggable chain containers.  I
conceive of a "chain container" as being really more of a "protocol engine".
So I see a SOAPEngine class replacing the SimpleTargetedChain, and
implementing not only what's in there now, but also the mustUnderstand
processing, etc.   I also envision an XMLPEngine class which plugs in in the
same way, although it remains to be seen how feasible that is.

In any case, I don't see how the MessageContext having an explicit notion of
request and response and "current" causes any problems in plugging in
different semantics for containers.  If you have a one-way thing, you never
use the response and never flip the responseProcessing bit.

I guess I'm not understanding your concern.

--Glen

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, February 22, 2001 3:21 PM
> To: axis-dev@xml.apache.org
> Subject: RE: normal flow
> 
> 
> This to me implies that we're dropping the notion of "normal" flows
> for everything not just for service definitions which means 
> that pluggable
> chain containers (that define something different than our 
> list of handlers
> chain containers) is gone too.  I know this isn't what people 
> have said
> but I don't see how you avoid it when everything must go on either a
> request, response or pivot point and the Message stuff explictily has
> the notion of req/res.  Now, I'm not against this idea, but I 
> want people
> to know that that's where we're headed - at least that's where *I* see
> us headed.
> -Dug
> 
> 
> 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