Using the Ws4J2ee tool

EWS tool accept a module (jar,war,ear file) as explained by the WebService for J2EE specification and generate Axis specific artifacts for deploy a J2EE Web service inside a J2EE contianer. Axis Geronimo module support the deployment of the generated artifacts inside the Geronimo container. For Other J2EE continers users have to deploy the artifacts manually.

Content of the Module

1. webservices.xml file
2. SEI(class file)
3. Implementation bean(class file)
4. ejb-jar.xml/web.xml file
5. (optional wsdl file and jaxrpcmapping file/both or none)

Packaging

ejb based Jar file

 
	/-META-INF/webservice.xml
	 -META-INF/ejb-jar.xml
         -SEI class
         -service implementation bean class
         -any other referance classes

Web based jar file

 
	/-META-INF/webservice.xml
	 -META-INF/web.xml
         -SEI class
         -service implementation bean class
         -any other referance classes

Appendix

Service Endpoint Interface

The JAX-RPC specification requires that a JAX-RPC service endpoint interface must follow the following rules:

1. Service endpoint interface must extend java.rmi.Remote either directly or indirectly
2. All methods in the interface must throw java.rmi.RemoteException. Methods may throw service specific exceptions in addition to the RemoteException.
3. Method parameters and return types must be the JAX-RPC supported Java types (refer to the section 5.1, “JAX-RPC Supported Java Types”). At runtime, values of a supported Java type must be serializable to and from the corresponding XML representation.
4. Holder classes may be used as method parameters. These Holder classes are either generated or those packaged in the standard javax.xml.rpc.holders package.
5. Service endpoint interface must not include constant (as public final static) declarations. WSDL 1.1 specification does not define any standard representation for constants in a wsdl:portType definition.

Service Implementation Bean

The Stateless Service Implementation Session Bean.

A Stateless Session Bean, as defined by the Enterprise JavaBeans specification, can be used to implement a Web service to be deployed in the EJB container. A Stateless Session Bean does not have to worry about multi-threaded access. The EJB container is required to serialize request flow through any particular instance of a Service Implementation Bean. The requirements for creating a Service Implementation Bean as a Stateless Session EJB are repeated in part here.

1. The Service Implementation Bean must have a default public constructor.
2. The Service Implementation Bean may implement the Service Endpoint Interface, but it is not required to do so. The bean must implement all the method signatures of the SEI.
4. The Service Implementation Bean methods are not required to throw javax.rmi.RemoteException. The business methods of the bean must be public and must not be final or static. It may implement other methods in addition to those defined by the SEI.
5. A Service Implementation Bean must be a stateless object. A Service Implementation Bean must not save client specific state across method calls either within the bean instance’s data members or external to the instance.
6. The class must be public, must not be final and must not be abstract.
7. The class must not define the finalize() method.
8. Currently, it must implement the ejbCreate() and ejbRemove() methods which take no arguments. This is a requirement of the EJB container, but generally can be stubbed out with an empty implementation.
9. Currently, a Stateless Session Bean must implement the javax.ejb.SessionBean interface either directly or indirectly. This interface allows the container to notify the Service Implementation Bean of impending changes in its state. The full requirements of this interface are defined in the Enterprise JavaBeans specification section 7.5.1.
10. The Enterprise JavaBeans specification section 7.8.2 defines the allowed container service access requirements.

Exposing an existing EJB

An existing Enterprise JavaBean may be used as a Service Implementation Bean if it meets the following requirements:

1. The business methods of the EJB bean class that are exposed on the SEI must meet the Service
2. Implementation Bean requirements defined in section 5.3.1.
3. The SEI must meet the requirements described in the JAX-RPC specification for Service Endpoint Interfaces.
4. The transaction attributes of the SEI methods must not include Mandatory.
5. The developer must package the Web service as described in section 5.4 and must specify an ejb-link from the port in the Web services deployment descriptor to the existing EJB.

WebEndpoint Based Serivce Implementation Bean

The Service Implementation Bean must follow the Service Developer requirements outlined in the JAX-RPC specification and are listed below except as noted.

1. ?The Service Implementation Bean must have a default public constructor.
2. ?The Service Implementation Bean may implement the Service Endpoint Interface as defined by the JAX-RPC Servlet model. The bean must implement all the method signatures of the SEI. In addition, a Service Implementation Bean may be implemented that does not implement the SEI. This additional requirement provides the same SEI implementation flexibility as provided by EJB service endpoints. The business methods of the bean must be public and must not be static.
3. If the Service Implementation Bean does not implement the SEI, the business methods must not be final. The Service Implementation Bean may implement other methods in addition to those defined by the SEI, but only the SEI methods are exposed to the client.
4. ?A Service Implementation must be a stateless object. A Service Implementation Bean must not save client specific state across method calls either within the bean instance’s data members or external to the instance. A container may use any bean instance to service a request.
5. ?The class must be public, must not be final and must not be abstract.
6. ?The class must not define the finalize() method.