axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Waqar Sadiq <>
Subject RE: where are handlers (sb headers) blown away?
Date Mon, 05 Feb 2001 17:59:32 GMT

Does the transport listener really have to be SOAP specific.  Most protocols
using HTTP as the transport will somehow expose their identity.  For
example, an ebxml message will have MIME multipart component with
content-type = application/vnd.eb+xml.

So my question is, is Axis being designed to handle only SOAP/XP or is it
general enough to even handle ebxml TRP?  The architecture suggested so far
seems to be extensible enough to handle a wide set of XML messaging
standards.  The encapsulation of the message into abstract types "Message"
seems to be a good way of encapsulating the actual message and bury the
detail of interpreting specific messages to specific implementations of
Message interface...  Could the transport listener possibly guess the xml
messaging protocol based on what appears in the HTTP header and based on
that guess, instantiate the correct kind of message object?

Does this make sense or I am off the wall here?


Waqar Sadiq
Vitria Technologies
13727 Noel Road
Tower 2, Suite 700
Dallas, TX 75240
Phone:   (972) 739-2450 x 126
Fax:       (972) 739-2465

-----Original Message-----
From: Yuhichi Nakamura []
Sent: Sunday, February 04, 2001 3:15 AM
Subject: Re: where are handlers (sb headers) blown away?

Re: MustUnderstand
Let me check the spec.  Wait for a while.

Re: Output chain
The application we have devloped for a customer requires
digital signature for responses.  More specifically, a company (A)
asks another company (B) to send a order form with dig-sig.
A is a requestor and B is a service provider in this case.
Make sense?

Re: TransporListener
T/L is SOAP-specific in the sense that it constructs
SOAP message objects, and serializes the objects for
response.  I think this is our agreement.

p.s. As I informed in a private mail to you, I will be out of
office by Wednesday.  Let's discuss as soon as I come back.


Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413

From: "Steve Graham" <> on 2001/02/04 10:29

Please respond to

Subject:  Re: where are handlers (sb headers) blown away?

Section 2 of the soap spec indicates that:

"Verify that all mandatory parts identified in step 1 are supported by the
application for this
message (see section 4.2.3) and process them accordingly. If this is not
the case then discard the
message (see section 4.4)."

It seems to me that the mustUnderstand checking must happen up front in
order to
remain compliant with soap spec.  Don't you agree?

Interesting point about output chain.  Are you imagining that some
component will insert
a header in the response envelope that will be targetted at some

Interesting.  Can you give me a scenario that demonstrates this?

In general, I would not have a transport listener implement anything that
is related
to SOAP semantics.  If we agree that we need to check this on the output
chain, then
I imagine that it would need to happen by some component in the chain
before the
message is given to the transport sender.


Steve Graham
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies

"Yuhichi Nakamura" <> on 02/03/2001 10:14:58 AM

Please respond to

Subject:  Re: where are handlers (sb headers) blown away?

Although I do not like pre-processing of MustUnderstand,
except for this, I think you get a point.
I suggest to remove the pre-processing portion, and add a post
-processing.  Before executing header removal
etc, the dispatcher checks if mustUnderstand headers are
processed.  This is naive, but covers all cases, I think.

p.s.  Output chain is processed in the same manner?  So,
TransportListener for example has to perform header
removal, etc.


Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413

From: "Steve Graham" <> on 2001/02/03 07:19

Please respond to

Subject:  Re: where are handlers (sb headers) blown away?

sorry folks
The subject line of my original posting was misleading.
We blow away headers (technically headerEntries) not handlers.

Dynamically changing input and output chains are fascinating but of
questionable use :-)

Steve Graham
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies

Steve Graham/Raleigh/IBM@IBMUS on 02/02/2001 05:05:55 PM

Please respond to

Subject:  where are handlers blown away?

I propose the following mechanism to handle mustUnderstand and
header deletion/redirection semantics in SOAP.

This is based on the interpretation that the entire contents of
the Axis Engine (eg the sum of all the handlers on the input path
upstream of the dispatcher) is considered the SOAP application.

Each individual handler is *not* a SOAP application (I used to
believe a handler could be interpreted as a SOAP application, but
I have now recanted).

- Axis Engine does mustUnderstand check before any chain is invoked
  - This check is required by SOAP v1.1 section 2
  - check builds a selection comprised of each HeaderEntry in the
    message that is both targeted for the Axis Engine and is marked
  - Engine verifies that for each HeaderEntry in the selection there
    is a handler on the pre-processing set (eg upstream of a dispatcher)
    that canHandleBlock() returns true for that kind of headerEntry
  - If there are HeaderEntries in the selection for which there are
    not handlers in the chain which can handle that headerEntry, the
    MustUnderstand fault is thrown.

- Handlers do not delete HeaderEntries.  Handlers mark headerEntries
  for delete.  Note: Handlers may also mark handlers for "copy/forward"
  by including an actorURI indicating the new target actor for the

- It is the responsibility of the Dispatcher to execute the headerEntry
  deletes and copy/redirection.  The Dispatcher examines the message
  before dispatching it.  For each header marked delete, it deletes it.
  For each header marked for copy/redirect, it changes the actorURI to
  the new target actorURI specified by the handler.  For all other
  headerEntries targeted for the dispatcher's Axis Engine, it deletes
  those headers.

By delaying the deletes of the headers we satisfy some scenarios Yuhichi
described where logging happened only after a handler for DigSig
processed a MustUnderstand headerEntry.


Steve Graham
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies

View raw message