Supraja Kannaiyan wrote:I am using java.sql.ResultSet as return type from the method in Web Service.
Never,
ever return a type from the
Java Platform that doesn't have a specified Java-to-XML mapping. You are using Axis 1.x which is based on the JAX-RPC specification. JAX-RPC supported types are listed in
5. Java to XML/WSDL Mapping of the
Java API for XML-based RPC JAX-RPC 1.1 (JSR-101).
In general
you should avoid "contract last" development of web services because it leads to
contract-to-implementation coupling which ultimately leads to consumer-to-implemenation coupling. This means that only web service consumers that
are built on the Java platformare based on the Axis 1.x client platformhave access to your Axis 1.x specific serializer/deserializer beans
will be able to use your web service (easily) - which completely negates the purpose using "open standard" technologies (HTTP,XML,
SOAP,WSDL etc) that SOAP web services are based on - your "web service" has now become just as difficult to access as if it were using using proprietary communication technologies.
Contract first is the recommended approach to developing web services. That is, design an XML document that carries the contents of the java.sql.ResultSet, preferrably using a meaningful document type name (and element type names) and use that XML document to send the information back to the web service consumer as the payload in the SOAP response. That XML document type should be used in the web service contract (the WSDL) which describes the "capabilities" of the web service. The completed WSDL can then be used to generate a service skeleton with a WSDL-to-Code tool (
WSDL2Java for Axis 1.x; see also
WSDL2Java: Building stubs, skeletons, and data types from WSDL). The equivalent Java Classes for your XML types are generated for you and you just "wire up" the service skeleton to your service logic.
See also:
Bottom-up or Top-down
Starting Out
Webservice - WSDL or Java Class
JAX-RPC to JAX-WS (Client impact)