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
Edmund Smith, a software engineer at EMB, in Cambridge, England, recently co-authored a white paper, "Rethinking the Java SOAP Stack," with Steve Loughran, a scientist from HP Labs in Bristol, England. In the white paper, the authors make the argument that the Java application programming interface (API) for XML-based Remote Procedure Call (RPC), formerly known as JAX-RPC (now JAX-WS), is fundamentally flawed. Moreover, they claim that any SOAP API that relies on a perfect two-way mapping between XML data and native language objects is flawed.
The authors have proposed an alternative SOAP stack for Java, dubbed Alpine, which takes a more document-centric approach to Web services development. Rather than mapping between XML and custom Java classes, Alpine will provide access to SOAP messages using modern XML support libraries. Alpine will require an understanding of XML, which the authors claim is needed to develop robust Web services, and they advocate that Web services developers should acquire that skill.
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
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.