RE: Axis2 - Dispatch Phase

["Ben Malek, Hamid" <HB...@us.fujitsu.com>]

Hi Ric. Thanks for taking the time to look at this issue, as it was a
major obstacle in my implementation and I did not like it at all. I was
planning to submit this problem to Axis2 dev list, and I am still
wondering whether I should do that. In any case, here are my comments
inline below in blue color...

 

You know what, I am going to copy axis2 dev list in this email hoping
some expert would be so kind to shade some light on this problem. To
brief axis2 dev list on the context of the problem, this is a brief
story: 

=================== Brief summary of the problem for axis2 developers
==============

I am implementing ebXML version 3 using axis2-1.2 stack. The
implementation consists of a module and a custom MessageReceiver.
Services deployed behind my custom MessageReceiver are not necessarily
"webservices" in the classical sense (WSDL-based RPC invocations).
Services deployed behind my custom MessageReceiver don't declare any
action and the ebXML sender that sends messages to my services don't
know what action to use because the concept of "action" does not exist
in our ebXML spec. If the ebXML sender sends its message using axis2
API, axis2 by default will always include a soapAction. The problem is
that such a message, when received by my axis2 stack, it does not go
through my ebXML module, then be handed to my custom MessageReceiver. It
gets rejected by the stack at the dispatch phase itself because
supposedly the soapAction is not found in the services.xml file.

===================== End of
summary======================================

 

-----Original Message-----
From: Ric Emery [mailto:remery@us.axway.com] 
Sent: Tuesday, August 28, 2007 7:44 AM
To: Ben Malek, Hamid
Subject: Axis2 - Dispatch Phase

 

Hamid,

 

Regarding our discussion pertaining to SOAPAction and if SOAPAction is

required by Axis for dispatching to the correct Service and Operation. I

have been looking at Axis2 and it is apparent that populating SOAPAction
is

not required for dispatching a incoming SOAP Message to the correct
Service

and Operation. 

 

<Hamid>: It is not required, but the class DispatchPhase (located in the
org.apache.axis2.engine package) does some post check. That is, after
all the dispatchers do their job, the DispatchPhase class invokes some
internal method to do some checking to see if anything is wrong. Among
these checking, it looks whether the http header soapAction (or
wsa:Action when present) is found in the metadata of the service
(services.xml). If that's not the case, it does not let the message go
through. Most likely the soapAction (wsa:Action also if present) is used
to find out the name of the operation (the service's method). Since I
don't have the name of the operation in my URL, and the soapAction
automatically created by Axis2 API does not correspond to any action
declared in my service, this causes a problem. 

 

Using an unmodified Axis2 install, the User's Guide sample code, and

TCPMonitor I was able to prove that SOAPAction can be blank or missing
and

Axis2 can still properly dispatch a message. What I did was to setup
Axis2

and deployed the users guide samples, then I ran a sample client call

through TCPMonitor. By default the samples include the SOAPAction. Using

TCPMonitor, I then modified the client SOAP and resubmitted the SOAP

message. The only trick is that I had to modify the URL to include the

operation. 

 

Originally the HTTP headers looked like:

 

POST /axis2/services/MyService HTTP/1.1

Content-Type: text/xml; charset=UTF-8

SOAPAction: urn:echo

User-Agent: Axis2

Host: localhost:8080

Transfer-Encoding: chunked

 

My modified HTTP Headers looked like

 

POST /axis2/services/MyService/echo HTTP/1.1

Content-Type: text/xml; charset=UTF-8

User-Agent: Axis2

Host: localhost:8080

Transfer-Encoding: chunked

 

This experiment showed that SOAPAction is not required for properly

dispatching an incoming message.

 

Looking at the architecture guide and the Axis2.xml file reveals the set
of

dispatchers which are used to try to find the correct service and action
for

the incoming message. The default configuration includes (in order)

RequestURIBasedDispatcher, SOAPActionBasedDispatcher, and Addressing.

 

<Hamid>: Apparently the order of the dispatchers is not universally
unique. It depends on the Axis2 version and maybe even on some builds.
All the axis2 versions I have on my computer have a different order than
yours. They all have AddressingBasedDispatcher class declared first. But
I don't think it is the order of the dispatchers that cause the problem,
because I tried many tricks including changing the order of the
dispatchers, and still a message that has a wrong soapAction or a wrong
wsa:Action ("wrong" meaning that the action is not declared in
services.xml) will always be rejected and not allowed to reach the
service. All the dispatchers are enclosed inside the DisptchPhase tag
and it is the DispatchPhase class that causes the problem I think.

 

The hack that you did by changing the address (appending the method name
to the URL) may solve the dispatch problem but it is not a good solution
for me, because I cannot change that URL by appending the method name
since I need the original URL when I try to find which PMode the message
is using (the URL of the service is one of the parameters I use to find
out the PMode that is being used when the pmode attribute is missing
from the eb:AgreementRef element).

 

What I was trying to say when we last spoke about SOAPAction was that a

populated SOAPAction is not required for dispatching. My experiment

illustrates that point. It is possible that I could be convinced that

SOAPAction could be included by agreement between two trading partners.
But

I won't be convinced that it is necessary for all Axis2 based MSHs to

require SOAPAction.

 

-Ric