Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
From: "James M Snell" <jasnell@us.ibm.com>
Importance: Normal
To: axis-dev@xml.apache.org
Subject: Re: Life after service response?
Message-ID: <OFFF9D84FD.868CE2A8-ON88256B0B.00240549@boulder.ibm.com>
Sender: "James M Snell" <jasnell@us.ibm.com>
Date: Tue, 20 Nov 2001 23:35:18 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

+1 on seeing undo getting undone. ;-)

- James M Snell/Fresno/IBM
    Web services architecture and strategy
    Internet Emerging Technologies, IBM
    544.9035 TIE line
    559.587.1233 Office
    919.486.0077 Voice Mail
    jasnell@us.ibm.com
=================================================================
Have I not commanded you?  Be strong and courageous.  Do not be terrified, 

do not be discouraged, for the Lord your God will be with you wherever you 
go.  
- Joshua 1:9

Please respond to axis-dev@xml.apache.org 
To:     <axis-dev@xml.apache.org>
cc: 
Subject:        Re: Life after service response?


I'd like to see undo() taken out totally. The semantics of
undo() in the context of chains of handlers is pretty flaky.

The difficulty I have with Rick's proposal (below) is that it
requires the service implementation to be Axis-aware. The right
way is for something like JSR 109 to define the J2EE standard
way for a service implementation to interact with the service
container.

In the meantime I can see the need to experiment with proper
service <-> container in Axis for example, but few customers
would be willing to commit to such as API (my intuition).

Sanjiva.

----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Monday, November 19, 2001 1:17 AM
Subject: Re: Life after service response?


> This might be a good time to revisit the entire
> init()/cleanup()/undo() methods.  The original intent of
> these methods was so that people could do the
> sort of thing you're talking about (except on the
> handler level) but it could be expanded to a pattern
> where the "cleanup/undo" should include the type of work
> you're talking about.  Perhaps we should take the
> existing framework and actually turn it on.
> -Dug
>
>
> Rick Rineholt/Raleigh/IBM@IBMUS on 11/18/2001 01:05:46 PM
>
> Please respond to axis-dev@xml.apache.org
>
> To:   axis-dev@xml.apache.org
> cc:
> Subject:  Life after service response?
>
>
>
> I can see a scenario with attachments where a web service generates an
> attachment as a response to a request and in some situation it would be
> preferable for the attachment to be deleted once its sent .  In other
cases
> the attachment could be static content and would be sent again in the 
next
> request in which case it would be preferable for it not to be deleted.
And
> in some cases it might depend on the actual request at hand as whether 
the
> attachment should be deleted after it is sent or not.  I see the need 
for
a
> service to be able to register an interface (i.e an object to receive an
> event) that will be called back once the response has been sent.  I 
think
> there should also be a method on this interface that if an exception is
> generated after the response is returned to Axis that the  targeted web
> service is called with the exception so it may do something that is
> appropriate too.
>
> interface AxisResponseStatus{
>    /**'
>      *  Called immediately once the response message has been 
successfully
> sent.
>      */
>    public void success( MessageContext m);
>    /**
>     *  Called sometime after  the targeted method has finished the
response
> and
>     *  Axis unsuccessfully  delivers the response.
>     */
>
>    public void failed( MessageContext m, Exception e);
> }
>
> Is there already an appropriate mechanism in Axis that could handle 
this?
> I know with handlers there is some fault processing, but can they be
> notified once the actual message has been successfully sent?  I see the
> above as being possibly useful in cases besides attachments.  Thoughts?
> Alternatives?  ? Yea? Nay?
>
> Rick Rineholt
> "The truth is out there...  All you need is a better search engine!"
>
> rineholt@us.ibm.com
>
>