Non-interoperable Interoperability Standards

I have been dealing with a rather interesting problem at one of my client sites.  This client (my former employer) is working on a .Net application suite which generates and deploys Java J2EE applications.  Currently this suite generates the business tier, data access tier, and a meta-model based DB.  All entities at the business tier are publicly exposed via RMI and Web Services (this is where the interoperability comes in).  Everything was working great until we tried connecting a .Net client to the Java middle tier using web services.  In order to secure the application, the middle tier uses Basic Authentication over SSL.  Building a Java client to communicate via web services was pretty straight forward.  The .Net client seemed to work fine until we threw in the Basic Authentication requirement.  It seems that Microsoft hides much of the underlying communication between the client and server and makes it very difficult to setup the authentication mechanism.  Most of the available documentation discusses connecting .Net client to .Net server.  While this is great, and is easy to setup, the same is not the case when using a non-.Net server.  Microsoft assumes that certain security information will be presented in the WSDL which Java chose not to include.  Without the correct information in the WSDL, the generated classes don't pass the correct headers needed to initiate authentication.  As you can imagine, this has caused no end of heartache for the development team.  This is only one small aspect of the problems with Web Service Interoperability.  Seems Microsoft and Java worlds still have some work to do.