A sample service implementation class corresponding to the sample ProductReviews service endpoint interface might look like this:

package reviews.server;

import javax.xml.rpc.server.ServiceLifecycle;
import javax.xml.rpc.server.ServletEndpointContext;
import javax.xml.rpc.ServiceException;
import reviews.ProductReviews;

public class ServletProductReviews implements ProductReviews, ServiceLifecycle {
    public String[] getReviewers(Integer productId) {
        ...
    }

    public ReviewData[] getReviews(Integer productId) {
        ...
    }

    public ReviewData getReview(Integer productId,
                                String reviewer) {
        ...
    }

    public void init(Object object) throws ServiceException {
        ServletEndpointContext ctx = (ServletEndpointContext)object;
    }

    public void destroy() {
    }
}

This example also implements ServiceLifecycle, which is optional and provides the init and destroy methods for the service implementation.

The service implementation is declared as a servlet, even though technically it is not a servlet (the entries in webservices.xml are used to figure out which Servlet declarations are allowed to not implement javax.servlet.Servlet). It requires a single servlet mapping entry, which (when added to the context path for the web application as a whole) overrides the URL path provided for the servlet in the WSDL. So the additional content in web.xml might look like this:

    <servlet>
        <servlet-name>ProductReviewsService</servlet-name>
        <servlet-class>reviews.server.ServletProductReviews</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>ProductReviewsService</servlet-name>
        <url-pattern>/ProductReviews</url-pattern>
    </servlet-mapping>

As part of the web application, the service is covered by the security settings applied to the web application as a whole. This means specific roles or transport guarantees may be applied by restricting access to the URL where the service is listening, and the service will use the same security realm as the rest of the web application.

	Warning
	Web services do not support form-based authentication, so the web application should use BASIC, DIGEST, or CLIENT-CERT authentication for secure web services.

For a servlet based web service, the following files must be included in the web application WAR:

A web application WAR including web services is deployed the same as any other WAR, whether in an EAR or standalone. Additional validation and code generation is performed during deployment, so new errors may crop up (typically caused by errors in the WSDL or JAX-RPC mapping files).

The host and port to reach the service are generated from the Geronimo web listener configuration. The path information used to reach the service is set using the servlet-mapping element in the web.xml deployment descriptor. In addition, the WSDL for the service can be found by adding ?wsdl to the end of the web service URL (and it updates the service URL in the WSDL it provides according to the listen host, port, and path).

A sample session bean implementation class corresponding to the sample ProductReviews service endpoint interface might look like this:

public class ReviewManagerBean implements javax.ejb.SessionBean {
    public void ejbCreate() throws javax.ejb.CreateException {}

    public void setSessionContext(javax.ejb.SessionContext ctx)
                                throws javax.ejb.EJBException {}

    public void ejbRemove() throws javax.ejb.EJBException {}

    public void ejbActivate() throws javax.ejb.EJBException {}

    public void ejbPassivate() throws javax.ejb.EJBException {}

    public String[] getReviewers(Integer productId) {
        ...
    }

    public ReviewData[] getReviews(Integer productId) {
        ...
    }

    public ReviewData getReview(Integer productId,
                                String reviewer) {
        ...
    }
}

Note that the bean class may have additional methods, including methods exposed via the local or remote interfaces but not the service endpoint interface. But it must at a minimum have all the methods required of session beans as well as the methods in the service endpoint interface.

The service endpoint interface is added to the block for the session bean in ejb-jar.xml like this:

<session>
  <ejb-name>ReviewManager</ejb-name>
  <local-home>review.ejb.ReviewManagerHome</local-home>
  <local>review.ejb.ReviewManager</local>
  <service-endpoint>reviews.ProductReviews</service-endpoint>
  <ejb-class>review.ejb.ReviewManagerBean</ejb-class>
  <session-type>Stateless</session-type>
  <transaction-type>Container</transaction-type>
</session>

The Geronimo EJB deployment descriptor can be used to customize the settings for the web service, including security options as well as the URL that the service is bound to. Full details of the available settings can be found in Section 12.3.3.1, “Session Beans as Web Services”.

<session>
  <ejb-name>ProductReviewManager</ejb-name>
  <web-service-address>/services/Review</web-service-address>
  <web-service-security>
    <security-realm-name>
      geronimo-properties-realm
    </security-realm-name>
    <realm-name>Product Review Service</realm-name>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    <auth-method>BASIC</auth-method>
  </web-service-security>
</session>

For a session bean based web service, the following files must be included in the EJB JAR:

An EJB JAR including web services is deployed the same as any other EJB JAR, in an EAR or standalone. Additional validation and code generation is performed during deployment, so new errors may crop up (typically caused by errors in the WSDL or JAX-RPC mapping files).

If the WSDL specifies a valid URL for the service, then the service is normally bound to that address (in truth, the host and port are ignored but the service is bound based on the path information present in the URL). Otherwise, the path information can be overridden using the web-service-address element in the Geronimo deployment plan for the EJB.

In either case, the WSDL for the service can be found by adding ?wsdl to the end of the web service URL (and it updates the host and port in the WSDL it provides to use whatever host and port you used to retrieve the WSDL).

  <wsdl:service name="ProductReviewsService">
    <wsdl:port name="ProductReviews"
               binding="ger:ProductReviewsSoapBinding">
      <wsdlsoap:address
  location="http://localhost:8080/test/services/ProductReviews"/>
    </wsdl:port>
  </wsdl:service>