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:[EMAIL PROTECTED] 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
