axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject RE: normal flow
Date Thu, 22 Feb 2001 20:37:39 GMT
(Yes all of the must-understand/soap semantics are a different issue)
I guess that's my point - say someone comes up with a CC (chain container)
that doesn't fit the req/pivot/res model - we're gonna make them fit it
into
that model.  It might work just fine if they have it map onto just the
request side
but that to me says that we're not really pluggable and as flexible
anymore.
There are reasons why we're telling people to distinguish between request
and response and those reasons will probably apply to all types of CC's
so if someone comes up with one that doesn't easily map to req/piv/res
then we're not as flexible as we claimed.  Maybe it's not a big isssue, but
I always envisioned a more flexible CC model - but in order to get some
of the SOAP semantics in there we(or just I) might need to drop that
notion.
-Dug


Glen Daniels <gdaniels@allaire.com> on 02/22/2001 03:29:37 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 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