Q
Problem solve Get help with specific problems with your technologies, process and projects.

Which standard should I follow in attempting to link a VB 6.0 client to a Java server?

Over the last month, I have been trying painfully to link a Visual Basic 6.0 client to a Java server using Web services. I am using Apache Axis as the server and Microsoft SOAP Toolkit 3.0 as the client. My problems were mainly related to custom data type mapping as I had to create the Visual Basic versions of my Java classes/beans and then create some mapper classes to do the mapping. Apparently, given exactly same methods and parameters, results from an Axis server are significantly different from the results from a Microsoft SOAP Server. This makes custom data type mapping a painful exercise. Since I am building my application with scalability in mind, which 'standard' should I follow?
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

The case for document-centric Web services development

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.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close