Web Svcs and .NET compatability: documentliteral encoding vs

[sjquinn]

Good day,

Problem:
JBOSS based web service using document literal encoding is much more cumbersome for the client side than my prior Axis 1.2 based web service that utilized soapenc.

Background:
I am currently migrating development to Java and initially took advantage of Axis 1.2 for it's ease of developing web services. My web services interop'd fine with legacy VB6 apps utilizing PocketSOAP and recent .NET clients worked great as well.

Now, step 2 is to move onto an appliction server. I have diligently followed the example in Chapter 12 of the JBOSS Admin guide to develop a sample web service. The problem, however, is I could not use the service from .NET or VB6. After looking around it seems the recomendation is to use the f:documentliteral option on ws-compile and while this works it seems much more awkward to deal with. Now the client is dealing with a complex type to define the methods and another complex type to accept the result. This makes the client coding much more awkward and less intuitive (therefore slower, less productive).

Question:
Can you please direct me to documentation and perhaps an example that provides the interoperability needed with the simplicity of the client interface (using soapenc) I had with Axis 1.2?

Environment:
JBOSS 4.0.2
Windows XP Pro
Java 1.5
Dev Studio 2003

Thanks for any assitance!

[sjquinn]

Seems a combination of issues related to JAX-RPC and JBOSS contribute to this problem. See http://dev2dev.bea.com/soa/developer_journal.pdf for a very nice write-up. The article explicitly calls out this problem. Unfortunately there is no acceptable work-around so I guess I am stuck.

Because I value what I am getting with the JBOSS app server I am just going to 'lump it' for now and have ugly proxies for my clients when just passing primatives back and forth. In > 50% of the methods I am dealing with complex objects anyway, but it sure would of been nice to have a cleaner proxy on the simple methods.