4:50 a.m.
Well, the good news is that I've just successfully converted my Web Service
Transactions (WSCOOR/WSAT/WSBA 1.1) implementation over JaxWS which was running on
Glassfish to run successfully on JBossWS native 3.0.1/AS 5.0.0.B4. So, thank you for
delivering this latest release.
There's not really any corresponding bad news but the port from Glassfish has thrown
up an interesting issue regarding the combined use of WS AddressingProperties and
W3CEndpointReference instances. The WS-T protocols require use of both these datatypes for
the following reasons.
WSCOOR services hand out endpoints to clients to provide access to related services;
endpoints are configured with reference parameters which are automatically attached to
service requests to identify the transaction context.
The asynchronous messaging protocol requires clients and services to configure WSAddr
MessageIds and validate WS-Addr RelatesTo properties in order to tie together certain
sequences of messages. Services also need to specify the WSAddr Action associated with a
request.
So, at various points where a service request is performed the client needs to obtain a
port from its endpoint and then configure the MessageIdand Action properties to be used
for the resulting communication. Here is a typical bit of code which does this job:
| . . .
| CompletionInitiatorService service = getCompletionInitiatorService();
| CompletionInitiatorPortType port = service.getPort(endpointReference,
CompletionInitiatorPortType.class);
| BindingProvider bindingProvider = (BindingProvider)port;
| List<Handler> customHandlerChain = new ArrayList<Handler>();
|
| /*
| * we have to add the JaxWS WSAddressingClientHandler because we cannot
specify the WSAddressing feature
| */
| customHandlerChain.add(new WSAddressingClientHandler());
| bindingProvider.getBinding().setHandlerChain(customHandlerChain);
| Map<String, Object> requestContext =
bindingProvider.getRequestContext();
| AddressingProperties requestProperties =
(AddressingProperties)requestContext.get(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES_OUTBOUND);
| // overlay supplied addressing properties on request properties
| AddressingHelper.installCallerProperties(addressingProperties,
requestProperties);
| // we should not need to do this but currently JBossWS does not pick up the
value in the addressing properties
| requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
requestProperties.getTo().getURI().toString());
| return port;
|
Ignore the hand cranking of the WS Addressing handler and endpoint address property --
they are stop-gaps until the WSAddressing Feature is fully functional.
Now, this works because I know that the call to getPort installs an AddressingProperties
instance on the port under the outbound client addressing properties property of the
request context. This instance is configured with the To address embedded in the
W3CEndpointReference. It's ReferenceParameters field has also been initialised using
the reference parameters embedded in the W3CEndpointReference. The call to
AddressingHelper.installCallerProperties adds the Action and MessageId. It overlays
non-null fields found in the supplied AddressingProperties instance, addressingProperties,
onto requestProperties, the instance obtained from the port.
Now, in the Glassfish implementation there was no client addressing properties instance
on the request context, So, I had to install my own addressing properties in order to
supply the MessageId and Action. This caused a problem because there was no To field
specified in AddressingProperties (it's embedded in the opaque W3CEndpointReference so
only the Glassfish implementation can get at it). Glassfish actually makes the address
available using the endpoint address property -- the call to getPort installs this on the
requestContext via the endpoint address property. It also somehow managed to install the
reference parameters into the message but they were not available via the requestContext
as far as I could see. So, I had to fetch the address from the requestContext and install
it in my addressing properties before installing them i.e.
| . . .
| CompletionInitiatorService service = getCompletionInitiatorService();
| CompletionInitiatorPortType port = service.getPort(endpointReference,
CompletionInitiatorPortType.class);
| BindingProvider bindingProvider = (BindingProvider)port;
| List<Handler> customHandlerChain = new ArrayList<Handler>();
|
| /*
| * we have to add the JaxWS WSAddressingClientHandler because we cannot
specify the WSAddressing feature
| */
| customHandlerChain.add(new WSAddressingClientHandler());
| bindingProvider.getBinding().setHandlerChain(customHandlerChain);
| Map<String, Object> requestContext =
bindingProvider.getRequestContext();
| String address =
(String)requestContext.get(BindingProvider.ENDPOINT_ADDRESS_PROPERTY);
| try {
| addressingProperties.setTo(builder.newURI(address));
| } catch (URISyntaxException use) {
| // TODO -- log unexpected error here
| }
| requestContext.put(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES,
addressingProperties);
| return port;
|
So, my question is how can I guarantee that this merging of the client and endpoint
addressing properties will be performed correctly. I am obviously concerned about what
happens with JBossWS-Metro/CXF and would hope that I can rely upon the first code example
above working on these ports. If not then we need to establish some way of making this
work. Also, it would be nice to know if there is supposed to be some sort of standard way
of doing this. In the absence of any such standard I would be interested to know whether
and how far this requirement was considered when defining the WS Addr and JaxWS specs and
when implementing this for JBossWS.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142302#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...