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 Fri, 23 Feb 2001 11:42:10 GMT
I think I goofed - I think I mixed ChainContainer with just Chain.  We
dropped chain container - sort of - the notion of having something
that performs the SOAP semantics/checks is needed and so I guess
that's the thing you've been talking about - and I agree.  So, now back
to Chains.  Do all chains have to be defined in the req/piv/res model?
If so then we no longer have a pluggable Chain model and everyone
will be forced to fit their own definition of a chain into ours
(req/piv/res).
This certainly would make our lives easier - but do we lose too
much flexibility?
-Dug


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




Yep.  I guess I'm questioning the whole notion of just what a CC *is*, and
why you would want to have different kinds.  (use-case, use-case, use-case)

It seems to me the only reason to have a separate CC-type object is exactly
to impose some semantics on top of a series of interrelated Handlers (i.e.
input/service/output).  As such, I'd call the thing in question a
"ServiceEngine" or something like that, though I don't think it warrants a
separate base class/interface.

--G

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, February 22, 2001 3:38 PM
> To: axis-dev@xml.apache.org
> Subject: RE: normal flow
>
>
> (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