Rama Pulavarthi's Blog

March 2008 Archives

Status of WS-Addressing and MTOM Interop scenarios at Plugfest

I attended the Interop Plugfest @Microsoft from March 18th - 20th. This was my first time at Plugfest and to Microsoft campus. You can find more about the Interop Plugfest here, where all the test scenarios and wsdls are published. It was good meeting people face to face and interact with people working on the same technologies. I was mostly testing the WS-Addressing and MTOM scenarios between Metro and .NET 3.5.

You can find the last report from the Plugfest held in November 2007 from Harold's blog. Here is the status on WS-Addressing and MTOM scenarios.

WS-Addressing
--------------------------------------------------------------
Metro -> Metro:
WS-Addressing CR SOAP 1.1:                24/24
WS-Addressing CR SOAP 1.2:                29/29
WS-Addressing Member Submission SOAP 1.1: 18/18
WS-Addressing Member Submission SOAP 1.2: 19/19

Metro -> .NET 3.5:
WS-Addressing CR SOAP 1.1:                22/23 (1143 failed)
WS-Addressing CR SOAP 1.2:                24/25 (1243 failed)
WS-Addressing Member Submission SOAP 1.1: 10/10
WS-Addressing Member Submission SOAP 1.2: 11/11

*** Test 1143 and Test1243 have been rerun with updated enpoints made 
available on separate ports have been tried and verified to work 
and the fix might be available in upcoming major release of WCF. 

.NET 3.5 -> Metro:
WS-Addressing CR SOAP 1.1:                24/25 (1152 failed)
WS-Addressing CR SOAP 1.2:                26/26 (1152 failed)
WS-Addressing Member Submission SOAP 1.1: 10/11 (1152 failed)
WS-Addressing Member Submission SOAP 1.2: 11/12 (1152 failed) 

*** Test 1152 is being investigated by Microsoft.

*** Test 1299 has been added to SOAP 1.2 endpoints and has been tested separately. 
This test is added to test wsa:Action based Dispatching.
This has been tested to work in all the scenarios. 

MTOM:
--------------------------------------------------------------
Scenarios:
Soap11MtomSignEncrypt        4  
Soap11MtomSignOnly           5 
Soap11MtomUtf16              5 
Soap11MtomUtf8               5  
Soap12MtomUtf8               5  
Soap12MtomUtf8Aug04          5  
Soap12MtomUtf8Security       5   
Soap12MtomUtf8SecurityAug04  4 

As you can see a decrease in number of tests, testEchoBinaryHeaderasString 
in Soap11MtomSignEncrypt and  Soap12MtomUtf8SecurityAug04 has been removed from the test suite
(as there is no standard way for encrypting a SOAP Header in WSS 1.0 unlike in WSS 1.1)

Metro -> Metro: 38/38
Metro -> .NET 3.5: 38/38
.NET 3.5 -> Metro: 38/38 

***There are some random failures when I run the tests 
repeatedly in WCF -> Metro scenario. Metro service throws an exception and is being investigated.

As you can clearly see, there are very few failures in WS-Addressing and MTOM compared to the last Plugfest in November 2007 as we fixed some testcase issues and got some issues resolved by Microsoft. Its a good progress !!! Currently, There are no direct WS-Addressing 1.0 tests that use WS-Addressing 1.0 Metadata. WS-Addressing Metadata is being tested indirectly in some Security scenrios. Hopefully, some of these tests will be updated to use Metadata and that gives a way to test interoperability when we implement the Metadata specification.

Technorati:
JAX-WS   Metro   WCF  

A little update for JAX-WS 2.1 users with JDK 6 Update 4 and Update 5.

Some issues on compiling using classes in javax.xml.ws.wsaddressing package have come to our attention (You can follow the thread in the Metro User forum). As you can see, javax.xml.ws.wsaddressing package along with the classes W3CEndpointReference and W3CEndpointReferenceBuilder are infact there in rt.jar. But javac complains package javax.xml.ws.wsaddressing does not exist.

This is due to the fact that JAVA_HOME/lib/ct.sym was not updated with these new api. This problem is in the JDK 6 Update 4 and Update 5, should not effect you unless you are using W3CEndpointReference and W3CEndpointReferenceBuilder in your applications. We are actively working on providing a fix in future update release. In the mean while, you could use one of these following workarounds.

• Use the compiler switch -XDignore.symbol.file=true (Note that this is undocumented option).
• Put rt.jar explicitly in your claspath for javac
• Remove ct.sym from JAVA_HOME/lib ( not recommended as it requires changes to your JDK installation)

We will be very soon fixing this glitch. Thanks for your cooperation.

This work is licensed under a Creative Commons License.