[jboss-user] [JBoss Web Services CXF] - Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9

[Andrew Dinn]

Andrew Dinn [http://community.jboss.org/people/adinn] replied to the discussion

"Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9"

To view the discussion, visit: http://community.jboss.org/message/548945#548945

--------------------------------------------------------------
Hi Jim,
> I tested modify the schemaLocation to " http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/" can fix this issue .
I tried that and it did not seem to fix things. However, I have just tried it again and it does resolve the parsing problem -- thanks very much for the diagnosis.

Unfortunately, the tests are still failing because of another problem which is much more serious. I failed to notice it because it was masked by the parsing error. The fault is still not being delivered and the problem is still because of a failure to obtain a proxy under getPort. However, the reason I am getting the error is different.

The thing which has changed between the old native/cxf and the latest cxf and which is causing this error is the FaultTo endpoint used as the address for the fault I am sending via the SoapFaultService. The previous implementations did not contain metadata, they only contained the address of the Initiator service and the reference parameter identifying the transaction. Or at least if they did include metadata it was not used when creating the proxy and dispatching the fault. The current CXF includes metadata for my Initiator service i.e. it defines the service as InitiatorService and the port as InitiatorPortType. However, I am trying to obtain a port for the SoapFaultService with name SoapFaultPortType and use this port to route the fault back to my endpoint bean. The call to getPort is failing because the metadata does not mention a port with name InitiatorPortType.

Using this mechanism the way I have been doing is probably an abuse of JaxWS. However, it used to work and, in fact, it was the only way of sending an asynchronous fault to the originating endpoint. This is not the only place I had to bend the rules. I was also relying upon Native and CXF to accept an incoming fault addressed to the Initiator endpoint bean and invoke the soapFault() web method associated with the SoapFault Action attached to the fault. They both used to do this even though the wsdl which defines the service and port under which the endpoint bean was published do not include this web method. I am not sure if they will still do this however I had to rely on this in order to be able to send asynchronous faults using only JaxWS. I invented the SoapFaultService  provide a uniform way of dispatching faults on the client side but it is not part of the OASIS spec. The spec does not address how asynchronous faults are dispatched or delivered. It merely assumes that this can will happen.

Ok, so having diagnosed the problem what can be done about it? Well, there are two things I can try in order to get XTS working again JBoss to JBoss (I am not yet sure whta the implications are for interoperability). Firstly, when I create the FaultTo endpoint I can set the service and port in the endpoint to be SoapFaultService and SoapFaultPortType. So, if any of my services need to dispatch a fault then this will mean that they will be able to obtain a JaxWS proxy for the fault service and hence use JaxWS to dispatch the fault.

Once I have done this I will then be able to see whether CXF will deliver an incoming asynchronous fault to my endpoint beans according to the SoapFault Action even thoguht the endpoint wsdl does not define the web method. If it does then I can perhaps continue to use my endpoint beans to field the faults. If it doesn't (or if I decide not to rely on this continuing to work -- it is a maybe a little fragile) I will have to provide a SoapFaultService endpoint bean to field the incoming faults and route them back to the relevant XTS beans.

These two changesought to allow me to get JBoss to JBoss working again. My concern is that this may cause a problem for interoperability. Why? Well, lets recap the situation.

My code has to use JaxWS to dispatch an asynchronous fault to the FaultTo endpoint -- the whole point of the XTS redesign between 1.0 and 1.1 was to remove our own SOAP stack from the XTS codebase and rely entirely on JBossWS. I cannot change the the OASIS spec wsdl which my service bean simplement. Since  it  does not not define any operations allowing me to dispatch/receive faults I have had to invent an independent fault service for asynchronous fault delivery. This means I have to include the service and port names in the FaultTo endpoint and use the invented fault service wsdl to deliver the fault.

Now, if we are now handing out FaultTo endpoints which inlcude metadata referencing this invented service then it is not clear whether this will cause problems for other implementations which are not built over JaxWS. They might ignore any metadat and only consider the service address. However, they might also quite legitimately expect the metadata in the FaultTo endpoint to refer to the OASIS service and port which passed them the endpoint. After all that is the service which they expect to be communicating with. By contrast, any implementation which +is+ based on JaxWS will not be able to dispatch faults unless it uses my SoapFaultService wsdl. So, what was a protocol private to the JBoss implementation may now need to become a public protocol and require, at least, documentation and, at worst, agreement and standardization.

There is one further option I might pursue. When I create the FaultTo endpoint woudl it be possible to create it without any medtadata by not specifying a service/port? Will the CXF endpoint builder build such an endpoint? If it does then will ServiceImpl.getPort allow me to create a JaxWS port for the SoapFault service? I am half-convinced that a FaultTo endpoint really ought not to have any service/port metadata associated with it anyway. After all it is only supposed to be used for delivering faults.

I will experiment with making each of the two changes I described above, one after the other -- changing the endpoint metadata, adding an independent endpoint/bean for receipt of the fault messages. However, I would also be interested to hear what others think about what I am trying to do here. Here is a summary of my posiiton

* services which employ multi-message dialogues based on OneWay MEPs will benefit from being able to dispatch asynchronous faults to a FaultTo endpoint supplied in the OneWay message Message Addressing Properties (MAP)
* these services ought to be able to employ JaxWS to dispatch and deliver the fault
* if there is a need for metadata to be included in the FaultTo endpoint in order to guarantee dispatch and/or delivery then the metadata ought to reference a JaxWS standard wsdl defining the relevant service and ports (i.e. somethign liek my SoapFaultService ought to be agreed on as a standard way to do this)
* if there is no need for any metadata to be included in the FaultTo endpoint then it should be possible to create a FaultTo endpoint without specifying a sevrice/port name and pass this using the MAP

I'll follow up with progress on the results of making the changes I described above.

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/548945#548945]

Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2046]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100621/7b5d489a/attachment.html