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 17:23:18 GMT

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