[jboss-svn-commits] JBL Code SVN: r21314 - labs/jbosstm/workspace/interop/WSTX11-interop.

[jboss-svn-commits at lists.jboss.org]

Author: adinn
Date: 2008-07-31 10:06:18 -0400 (Thu, 31 Jul 2008)
New Revision: 21314

Modified:
   labs/jbosstm/workspace/interop/WSTX11-interop/README.txt
Log:
update to status

Modified: labs/jbosstm/workspace/interop/WSTX11-interop/README.txt
===================================================================
--- labs/jbosstm/workspace/interop/WSTX11-interop/README.txt	2008-07-31 13:34:31 UTC (rev 21313)
+++ labs/jbosstm/workspace/interop/WSTX11-interop/README.txt	2008-07-31 14:06:18 UTC (rev 21314)
@@ -1,9 +1,10 @@
 This latest version of the WSTX11 test code uses the JaxWS based
-implementation of XTS 1.1 which runs on JBoss AS 5.0.0Beta4 overlaid
-with JBossWS 3.0.1 Native 2.0.4.GA.
+implementation of XTS 1.1 (JBossTS 4.4.CR1 onwards) which runs on
+JBoss AS 5.0.0.CR1 with the default deployed version of Web Services,
+JBossWS 3.0.2 Native.
 
 Implementation of this version of the interop code required modifying
-the interop Initiator and Participant services os that they
+the interop Initiator and Participant services so that they
 communicate via JaxWS. This is because they have to use the WSCOOR
 CoordinationContext types generated by the JaxWS wsdl compiler when
 talking to the 1.1. services and hence when talking to each other
@@ -11,31 +12,41 @@
 soap stack (a plus point is that they can use use JaxB to
 serialise/deserialise these types so the switch is not very complex).
 
-One outstanding problem with using JaxWS is that the WSDL does nto
-allow any way of notifying faults associated with the asynchronous
-(oneway) protocol messages in the WS-AT and WS-BA protocols. So, in
-certain circumstances where the old code could notify a caller of an
-invalid request or a failure to process a request the JaxWS based code
-merley lgos a server-side error. This causes certain badly behaved
-programs to hang or, worse, continualy retry message sends. This
-behaviour means that two of the tests (AT5_5 and BA1_7, both of which
-exercise error conditions) fail and, in doing so, wedge the test
-program. These tests have been knobbled so they fail up front.
+The JaxWS fault notification problem has been resolved in the XTS code
+and in this code. In summary, the problem arises because JaxWS only
+provides for dispatch of faults as immediate (failure)
+acknowledgements to incoming messages while the WS protocols require
+asynchronous dispatch of faults to known endpoints after the
+originating one way message has been acknowledged and the transport
+closed.
 
-When the test suite is run using an initiator and participant service
-located in the same JBoss server all the other tests finish
-successfuly and generate a sequence of messages satisfying all the
-requirements in the interop 1.1 AT and BA specs. The tests stil need
-to be run against competitor implementations.
+The solution for both XTS and the iterop application is to
+define a fault dispatch service API (wsdl) use JaxWS to generate a
+corresponding client service class and stub. On the client side the
+stub is invoke to send a fault message to the reply/fault address with
+the requisite action in the message header. On the server side the
+service implementation class implements a WebMethod specifying the
+corresponding action. Note that this fault handling method is not
+specified in the published XTS/interop wsdl.
 
-n.b. the Test Runner jsp interface is mapped at
+With JBossWS native this solution works fine. With JBossWS Metro it
+fails on two counts. Firstly, Metro compains about a the
+implementation class providing a WebMethod which is not defined in the
+wsdl (this is definitely over-picky -- someone could quite
+legitimately want to employ the same class to implement several web
+services). Secondly, even if the wsdl is modified to include the extra
+fault dispatch operation Metro refuses to deliver a message whose
+input is a soap fault (this is totally brain dead!).
 
-    http://localhost:8080/interop11/
+All the AT and BA interop tests run successfully against another JBoss
+XTS instance (with the exception of BA Mixed Outcome which is not
+implemented).
 
-The AT test participant is mapped at
+They all run successfully against the IBM interop endpoint when JBoss
+provides the initiator service and IBM provides the participant
+service.
 
-    http://localhost:8080/interop11/ATParticipantService
-
-The BA test participant is mapped at
-
-    http://localhost:8080/interop11/BAParticipantService
+They all run successfully against the IBM interop endpoint when JBoss
+is providing the participant service and IBM provides the initiator
+service apart from two failures caused by an error in the IBM
+implementation.