Originally posted by nidhi sharma:
Is this Encoding problem used by axis.
No. The root of the problem is the RPC/encoding messaging mode and I actually suspect that SOAP:Lite's implementation is less mature than the Axis 1.x implementation.
State of the SOAP
It should consider severing itself from XML::RPC which is really a different protocol that operates under a totally different set of assumptions. SOAP::Lite should shift to a document-driven model, as opposed to an RPC driven one.
...
SOAP::Lite should be built from the ground up to conform to the WS-i's requirements. It should be built first and foremost around a wicked WSDL parser and engine.
...
What we endeavor to do is make SOAP::Lite easier to grok and easier to work with. What we hope to create is a new module, called SOAP::Easy.
Bottomline: SOAP:Lite is hopelessly outdated in the current SOAP web service environment. Current SOAP web service stacks have abandoned RPC/encoded with its SOAP encoding because it was always difficult to get two different web service stacks to talk to one another for all but the most basic communication. It's obvious that you fully intend to use it as a pure RPC mechanism. If that is your intention then you may want to stick with XML-RPC (
Getting started with XML-RPC in Perl,
XML-RPC in Java programming,
Apache XML-RPC)
SOAP web services have (unsuccessfully) tried to move away from the RPC paradigm and currently strongly favor the document/literal messaging mode (including the wrapped document/literal convention which ironically made things more RPC again).
I dont want to use SAAJ.
SAAJ gives you the most control over your SOAP messages, especially when using RPC/encoded and in the absense of a WSDL. So if you insist on using SOAP:Lite on the server side and wish to access it from Java then SAAJ is your best choice (
"Java Web Services in a Nutshell" Sample: Chapter 3 SAAJ (PDF)).
Bcos creating soap messages is problem
Welcome to the world of SOAP web services. As a SOAP web service developer you are expected to understand XML, XML Schema, SOAP and WSDL
in depth - don't let the plethora of WS tools fool you. In your case the absence of a WSDL is a problem. Clients want a WSDL so that they can use their tools to generate a client stub (i.e. so that
they do not have to build the SOAP messages from scratch). But wait - your clients may be using up to date web service stacks which only support the literal encoding style, so they can't access your web service even if you hand-craft a WSDL because your web service uses the RPC/encoded messaging mode!
Look
here for a simple example of the current
basic development environment for web services under Java SE 6.
Fact is SOAP web services and its extension protocols (collectively referred to as WS-* (sarcastically "Deathstar") ) have become so complex that Perl and Ruby seem have given up on them altogether. Those environments now tend to stick with XML-over-HTTP or RESTful HTTP web services.
Developing RESTful Web Services in Perl