I share your pain.
Unfortunately the containers defined by the JAX-RPC API don't correspond very well to the containers used by Microsoft. The JAX-RPC containers are part of a Java standard, so I doubt that they will change. And I also doubt that Microsoft would consider adapting their containers to conform with the Java standard, so it seems unlikely that we'll see a resolution to this problem any time soon.
Therefore I suggest that you examine your requirements. You say that scalability is important in this case, so that would probably sway me to use native containers on the server side. But this decision puts a nasty burden on your clients, and it dramatically increases the administrative overhead associated with configuring each client. Will you be responsible for developing and deploying all the client interfaces to your service? If so, you're the only one that has to accept the burden. If you want to make the service available to lots of people to use as they see fit, then it might be more appropriate to deal with the server-side scalability issues.
Your other choice is to use a different SOAP implementation on the server. Both Apache Axis and the JAX-RPC reference implementation only provide support for the JAX-RPC containers. Other Java SOAP implementations often give you a choice. For example, Systinet WASP and The Mind Electric GLUE support both JAX-RPC and Microsoft containers, but they use the Microsoft containers by default. You might find this documentation from Systinet helpful to you.
Dig Deeper on Topics Archive
Related Q&A from Anne Thomas Manes
Anne Thomas Manes explains the differences between open source clients and open source implementations. Continue Reading
Anne Thomas Manes discusses the best way to go about creating an enterprise data dictionary and why the systems works well. Continue Reading
Anne Thomas Manes explains the difference between 'hard' real time and 'live' real time systems. Continue Reading