dev@jax-ws.java.net

One-way invocation and properties

From: Kohsuke Kawaguchi <kohsuke.kawaguchi_at_sun.com>
Date: Tue, 31 Jan 2006 16:45:23 -0800

Hi Roberto and Marc,

Kathy and Jitu pointed out that when an user is making an one-way
invocation, he should nevertheless see the response HTTP headers, HTTP
status code, and other information through ResponseContext.

This turns out to be a problem with the renewed architecture, since
internally it's built around the notion of sending/receiving messages
--- so without a reply "message", it doesn't have a place to put those
information so that it gets carried from the transport to the stub.

The obvious way to fix it is to introduce a "message envelope" (don't
confuse this with SOAP envelope) that has an optional message in it, and
use the envelope to keep the related information around. In this model,
I'd be creating an envelope without a message, but just with envelope
information like HTTP headers.

But for a few reasons, I'm reluctant to make changes.

- it's a considerable change. It can be done, but it's something I'd
   like to avoid if possible, because it affects all the Tango people.

- I found it conceptually bit strange that one-way transport needs to
   return some information back to the client (especially when the
   "real" reply might come back on another communication channel later.)
   I thought one-way is one-way; no information coming back.

There are a few hacks to make it work without introducing a considerable
change, but I'd like to investigate what my options are first. Hence
this e-mail.

Do you think clients should see HTTP response information on one-way
invocations? On more generally speaking, when the transport is used as
one-way, should it yield any data upon a successful completion (if it
fails to send a message, then all sorts of information would be coming
back, for sure.)

-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi_at_sun.com