.NET & Legacy VB6 interop: Issues & Options
The Wiki returned File Not Found under the .NET heading and I have only seen bits and pieces of this issue discussed elseware. I would like to know how others are addressing this and choosing between the options.
My original Java based web services utilized Axis 1.2 over Tomcat. I was able to use these web services easily, including passing complex types as parameters or return values. The 2003 .NET handled it fine and I could use PocketSOAP for easy access from my legacy VB6 apps. I may not of been J2EE compliant, but then again everything worked splendidly.
Phase 2 of the transition to web services was to migrate to JBOSS. This has brought about a few complications. The rpcliteral encoding is not supported by 2003 .NET or PocketSOAP so I switched to documentliteral (per the documentation for interop). Unfortunately documentliteral, with its use of a complex type for request and response results in a 'clunkly' client proxy. I can do it (and perhaps take some comfort in conforming to the 'standard'), but the client code isn't as clean.
The Options (as far as I know):
So, where to from here? Well I found that 2005 .NET supports rpcliteral and the mssoap3.0 toolkit does as well. The downside here is that 2005 .NET is not yet released so I am working off of a beta and the mssoap3.0 toolkit is not nearly as slick as PocketSOAP in handling complex types.
So, to summarize here are my options and the corresponding pros & cons...
Standard (as far as interop goes)
Can use 2003 .NET
Can use PocketSOAP
Client proxy is a bit clunky
Clean .NET & Java clients
VB6 client stuck using mssoap3.0 toolkit
publish both documentliteral & rpcliteral pros:
Can use PocketSoap for legacy VB6 apps (albeit a bit clunky)
Can use .NET 2003 (clunky)
Can use .NET 2005 (clean proxy, but beta client)
Java clients have clean proxy
publish both documentliteral & rpcliteral cons:
Need to publish both (not a big deal, just adopt nomenclature)
I would really appreciate any comments from those of you who have been down this road before and may have some additional insights or options.
By clunky are you refering to the fact that .NET wraps everything with an object?
Their is a trick to get around this, and that is to edit the wsdl file and change the message name of the return and input messages to be "parameters". This is how .NET decides to unwrap messages.
I believe that wscompile actually uses parameters for the input message, but chooses something like response for the output message.
Yes, by clunky I was referring to the need to use the request and response types for my .NET and legacy VB6 client proxies. I like the cleaner interface that simply mimics the Java interface used to define the service.
With that in mind I am planning on proceeding with rpcliteral as the default. Both my Java and .NET 2005 will then have the 'clean' interfaces. For very simple services that pass and receive primatives this will also work for VB6 to using the MSSOAP30 toolkit. For those cases (hopefully few) where I am passing complex types to VB6 I will just use documentliteral. The PocketSOAP utility handles auto-gens the required classes fine (much slicker than MSSOAP30).
After getting a virtual non-response to my original post I have decided to go back to the web services development environment I have used in the past (Axis). After giving JBOSSWS a shot and dealing with increased interoperability hassles and more required 'plumbing' code (like beans for arrays of complex types) I have decided to deploy Axis within my JBOSS environment. For my purposes this provides me with a configuration which enables faster and easier development of web services. My primary reasons include the following:
* Better interoperability with legacy VB6 clients (using PocketSOAP)
- Don't need request and response wrappers, or array wrappers.
* Better interoperability with .NET 2003 clients
- Don't need request and response wrappers, or array wrappers.
* Fewer and easier deployment descriptors
* No need to write extra classes (and their descriptors) for passing and returning arrays of complex types.
I will continue to checkup with JBOSSWS to see if a future version may be a better match for my purposes.
I don't see how we didn't respond. Your last post didn't look like a question. We added automatic request/response object unwrapping for document/literal to 4.0.3 which was recently released.
No criticisim intended when I noted a limited response. I certainly did not expect someone from JBOSS to explain pros/cons to me. I simply took the limited response as an indicator that not many folks had been down this particular path, or if they had they did not have any particular insights to shed. As I am new to JBOSSWS it occurred to me I may of been missing something and I was simply looking for additional perspectives. As you noted in your reply the wrapping / unwrapping issue is addressed in 4.0.3 so 1 of my issues would be addressed if I rev'd to the later version.
Thanks for the reference to 4.0.3.
.Net does "parameters" in both the input/output message parts for doc/lit wrapped, whereas wscompile does parameters/result in input/output message parts - just to be in line with how rpc/style web services is done.
I found I had made my task of providing web services to legacy VB6 and .NET 2003 applictions more difficult than it needed to be. I started with the published docs and Wiki articles that emphasize documentliteral as the best way to achieve interoperability nirvana. While this may comply with WSI standards a more relevent question is "how do your existing legacy apps want to talk"?
The PocketSOAP toolkit I use to auto-gen VB6 proxies (as well as MSSoap toolkit) works great with wscompile's default of rpcencoded. .NET 2003 and new .NET 2005 work great with rpcencoded as well.
Now I am in 'happy land' deploying in JBOSSWS over JBOSS 4.0.2 and I have less non-value added code to deal with. My client proxies are not stuck using send and response wrappers nor do I need to write beans to wrapper my arrays of complex types that are returned from many of my methods (I have no web service methods that use arrays of complex types as parameters).
Are there limitations to rpcencoded that lead to WSI's backing of documentliteral? Certainly. Does rpcencoded work for everything I need in my existing use cases? Yes.
Here is the story.
rpc/encoding was invented first when xml schema was not finalized yet. So it worked great then. But it led to hell lot of interoperability problems, that the industry as a whole had to work towards WS-I, which felt that xml schema was rich enough for literal encoding.
rpc/encoding is dead. Every soap toolkit is moving towards literal encoding and are happy.
If you have legacy clients and are reluctant to move, write some form of intermediaries or bridges.
rpc/literal is useful mainly within intranet apps and doc/literal is the true form or intention of web services.