Requires Free Membership to View
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.
This was first published in November 2002
Join the conversationComment
Share
Comments
Results
Contribute to the conversation