Originally posted by Suresh Kumar:
Normal web service as SEI is which can be deployed directly using admin console (without servlet/ejb mapping), like in Axis in Apache Tomcat.
... which means that it is exposed as a JSE (JAX-RPC Service Endpoint - i.e. Servlet) because all service classes are exposed through the Axis servlet in Axis 1.x.
Furthermore you are not deploying a web service. You are deploying a
Java (service) class which implements an endpoint interface (which itself extends java.rmi.Remote) which the
SOAP stack then exposes as a web service. The points are:
You cannot deploy the SEI by itself - you need a class that implements it. The SEI is primarily a Java/J2EE concept - not a web service concept. It's association to web services is created by the Java SOAP stack which is capable of exposing Java classes that implement an interface derived from java.rmi.Remote as web services. From a pure web services perspective there is no guarantee that even a Java client will have access to the (Java) SEI as the SEI isn't captured directly in the WSDL. The only way a client will get a stub that implements the SEI is if the stub is generated at the same time as the service skeleton (i.e. the client bypasses the WSDL entirely). In a "normal web service" environment the client would generate a stub from the WSDL - and the stub would implement an interface derived from the WSDL which be may be slightly different from the SEI that the service class in the server is implementing. So strictly speaking the SEI isn't a "web service interface". It is the Java interface that a Java class implements so that the server/SOAP stack can expose the class as a web service.
You would be well advised to clearly delineate between "web service" concepts (XML, XML Schema, SOAP, WSDL, UDDI) and "Java/J2EE" concepts (JAXP, SAAJ, JAX-RPC, JAXR) and then make some correlations between both domains - otherwise you are going to hopelessly confuse yourself.
[ April 16, 2008: Message edited by: Peer Reynders ]