Skip to main content

: WS-Addressing headers "supported": does this mean optional or required?

5 replies [Last post]
Anonymous

Hi Metro team, hi all,

we have a web service implementation running on Metro 1.0.1 for which
the WSDL specifies

as one of the policies for the SOAP binding.

My understanding has always been that this should cause the service
implementation to *optionally* support WS-Addressing headers:

http://www.w3.org/TR/ws-addr-wsdl/#uaee
"The inclusion of the wsaw:UsingAddressing element indicates that the
applicable WS-Addressing specifications are supported (...)"

(as opposed to: "are mandatory" or "are required").

But it looks like this is not how it has been implemented in Metro, as
we see the following exception with Metro 1.0.1_04:

[#|2009-01-28T11:30:35.194+0100|WARNING|sun-appserver-ee8.1_02|com.sun.xml.ws.addressing.WsaTube|_ThreadID=115;|A
required header representing a Message Addressing Property is not
present, Problem header:{http://www.w3.org/2005/08/addressing}Action
com.sun.xml.ws.addressing.model.MapRequiredException
at
com.sun.xml.ws.addressing.WsaTube.checkCardinality(WsaTube.java:221)
at
com.sun.xml.ws.addressing.WsaServerTube.checkCardinality(WsaServerTube.java:274)
at
com.sun.xml.ws.addressing.WsaTube.validateInboundHeaders(WsaTube.java:140)
at
com.sun.xml.ws.addressing.WsaServerTube.processRequest(WsaServerTube.java:150)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at
com.sun.xml.wss.jaxws.impl.SecurityServerPipe.process(SecurityServerPipe.java:284)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at
com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at
com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at
com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at
com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at
com.sun.xml.ws.transport.http.servlet.WSSpringServlet.doPost(WSSpringServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:767)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:264)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:178)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:223)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at
com.sun.enterprise.web.connector.httpservice.HttpServiceProcessor.process(HttpServiceProcessor.java:234)
at
com.sun.enterprise.web.HttpServiceWebContainer.service(HttpServiceWebContainer.java:2160)
|#]

which in our case causes the inbound request directed to our @Oneway
@WebMethod to be discarded before it ends up in our service
implementation class in case a SOAP action is only present within the
HTTP header:

Content-type: application/soap+xml;
charset=UTF-8;action="http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify";

but not within a SOAP Action element within the SOAP Header.

The following forum post also seems to suggest that this might point to
a Metro bug:

http://forums.java.net/jive/thread.jspa?messageID=301564
"From my reading of the source code - specifically
SEIInvoker.processRequest(), even though multiple
endpointmethoddispatchers are created (including a
SOAPActionBasedDispatcher), only the first dispatcher in the list is
called. If that first dispatcher fails, processing stops. There doesn't
appear to be logic to iterate through all of the dispatchers, and
because EndpointMethodDispatcherGetter adds ActionBasedDispatcher (if
WS-Addressing is enabled) and PayloadQNameBasedDispatcher instances
before SOAPActionBasedDispatcher, the SOAPActionBasedDispatcher is never
called. Sounds like a bug to me ..."

but there has been no reply to this from the Metro team so far, so I'm
trying again, looking forward to your comments... ;-)

Thanks in advance for your help & best regards,

Andreas

--
Andreas Loew
Senior Java Architect
Sun Microsystems (Germany)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ramapulavarthi
Offline
Joined: 2004-06-01

as a policy assertion means its required.
If the use of addressing is intended to be optional, the assertion should have wsp:optional = true

Andreas Loew

Hi Rama,

metro@javadesktop.org schrieb:
> as a policy assertion means its required.
> If the use of addressing is intended to be optional, the assertion should have wsp:optional = true

many thanks for your super-fast reply! :-)

Two follow-up questions:

1) From the Web Services Addressing 1.0 - WSDL Binding spec, I would
definitely have expected the default to be optional rather than
required. Also, has this default value been documented anywhere? (I was
unable to find it in any docs...)

2) Is it really wsp:optional="true" or rather wsdl:required="false" (or
maybe even both?)!?

From the following Metro page:

https://metro.dev.java.net/1.4/docs/wsaddressing.html
"W3C WS-Addressing WSDL Binding defines a new standard extensibility
element, wsaw:UsingAddressing, that can be used to indicate that an
endpoint conforms to the WS-Addressing specification. Metro generates
this extension element in the WSDL if W3C WS-Addressing is enabled on
the server-side. On the client side, the RI recognizes this extension
element and enforce the rules defined by the W3C specification. This
extensibility element may be augmented with wsdl:required attribute to
indicate whether WS-Addressing is required (true) or not (false)."

as well as from http://www.w3.org/TR/ws-addr-wsdl/#uaee I would rather
expect wsdl:required="false" to be conforming with the standard!?

Thanks again & have a nice weekend,

Andreas

--
Andreas Loew
Senior Java Architect
Sun Microsystems (Germany)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

ramapulavarthi
Offline
Joined: 2004-06-01

I thought you were asking about the policy assertion.
This is the common confusion with use of Addressing.

Addressing can be enabled in wsdl via

(1) a policy assertion in a Policy
When it is specified as a policy assertion, by default it is required unless wsp:optional="true" is present on the policy assertion

or

(2) a wsdl extension in wsdl:binding.
By default it is optional unless wsdl:required="true"

dinmichele
Offline
Joined: 2008-01-24

Hi Rama,
tks a lot for given help.

I have a single question.
Can I disable addressing header client side processing only for inbound message?

why?
Because the server side wsdl declares the policy, but the responses submitted to clients are without declared header. This because the server simulate a provider service enforcing setMessage on messagecontext with source(the response) that doesn't contain that header.

So the server (on Glassfish) requires a correct soap requests (with addressing header) but the client receive a not valid soap response (without addressing header) .

I cannot modify the server and I'm searching a workaroud to avoid client excpetion validation inbound messagge, throws by jaxws pipe.

If I use AddressingFeature (false) on getPort method on client I obtain a server side exception (missing required address)

Have you an idea?

Sorry for bad english.

ramapulavarthi
Offline
Joined: 2004-06-01

On server-side with provider based implementation, you can set the required headers like wsa:Action using JAX-WS RI API that will be used by JAX-WS runtime. Other headers like wsa:RelatesTo etc and others will be taken care of by the JAX-WS runtime.

On Client, You can set AddressingFeature(true,false) that makes use of Addressing optional instead of completely disabling it.