Originally posted by Suresh: Can we expose the web service as a normal web service interface rather than servlet/EJB based SEI.
What do you consider consider a normal web service interface?
WSDL describes the SOAP/XML request/responses that an HTTP endpoint can accept/send back - i.e. the WSDL describes the web services interface. The fact that the endpoint is implementing a Java-based Service Endpoint Interface either as a servlet or and EJB is totally hidden from the WS client - i.e. the WS client cannot tell the difference between a servlet or EJB-based WS and more importantly, has no business knowing the difference.
posted 10 years ago
Normal web service as SEI is which can be deployed directly using admin console(without servlet/ejb mapping), like in Axis in Apache Tomcat. [ April 16, 2008: Message edited by: Suresh Kumar ]
posted 10 years ago
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 ]