Devs, I made some progress with the SOAP/UDP scenario that uses an UDP endpoint configured at the transport level (and thus WS-Addressing for dispatching). Here is what works: * In this scenario, the generated WSDLs for the transports exposed over UDP now have bindings with EPRs in the form udp://localhost:3333/axis2/services/Version?contentType=text/xml. * WS-Addressing based dispatching works, as shown by the following logs: [DEBUG] [MessageContext: logID=urn:uuid:043604c8-190b-414e-bea0-6d4c22ad3820] Invoking Handler 'AddressingBasedDispatcher' in Phase 'Addressing' [DEBUG] [MessageContext: logID=urn:uuid:043604c8-190b-414e-bea0-6d4c22ad3820] Checking for Service using target endpoint address : udp://localhost:3333/axis2/services/Version?contentType=text/xml [DEBUG] org.apache.axis2.i18n.resource::handleGetObject(servicefound) [DEBUG] [MessageContext: logID=urn:uuid:043604c8-190b-414e-bea0-6d4c22ad3820] Found AxisService : Version There is one thing that is not yet working correctly, but that is not related to WS-Addressing. I'm trying to use the "nc" utility to send the message and get the response. That doesn't work: I'm not seeing the response. I think that is because normally (although not strictly required), when replying to a UDP packet, the source and destination addresses/ports in the response should simply be switched with respect to the request. E.g. if the client sends from port 2222 to 3333, then the response should be sent from 3333 to 2222. I think the UDP sender currently uses a new source address allocated by the OS in that case. That works for some clients (in particular the UDP transport itself), but not for all. It would also cause troubles if there is a firewall between client and server, because the firewall wouldn't be able to correlate the response packet to an existing UDP "connection". Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org For additional commands, e-mail: java-dev-help@axis.apache.org