The project implements the support to add the web service support for a J2EE container. It provides a tool that generated the required code based on the “packaged J2EE web service” (explained in the third chapter) and the necessary runtime classes. EWS implementation is based on the JSR 109 “J2EE web services” specification by the JCP. It is also covered under the web service’s support for J2EE 1.4 specification. But it is not limited to the specification and in the security and the transaction the specification is exceeded.
EWS act as the part of the deploy tool for J2EE container to deploy the Web service in the J2EE container. EWS project provide a tool to accept the J2EE module as explained by the JSR109 specification and generated the required classes and the Runtime need to support the generated classes.
Figure: How the EWS fits in to the J2EE and Web services stack
Assembler should package those files in to a WAR file if it is the “scenario 1” and to an EAR file if it is “scenario 2”. Additionally EWS support deployment with JAR file as well.
When the above J2EE package is created the deployer will use the deploy tool called Ws4J2ee provided by the EWS project to deploy the web service in the J2EE container. According to the specification the deploy tool should do the following to deploy the web service in the J2EE container.
The deployment tool starts the deployment process by examining the deployable artifact and determining which modules are Web services enabled by looking for a webservices.xml deployment descriptor file contained within the module. Deployment of services occurs before resolution of service references. This is done to allow deployment to update the WSDL port addresses before the service references to them are processed.
A Servlet is provided / generated to handle parsing the incoming SOAP request and dispatch it to an java implementation class or the EJB of the of the Web Service. The Java Implementation class if present can be act like another dependency class used by the above servlet. If the implementation is a stateless session bean the servlet obtains a reference to an instance of an appropriate EJBObject and dispatches the request to the stateless session EJB. How the request is dispatched to the Service Implementation Bean is dependent on the deployment tool and deploys time binding information supplied by the deployer. Deployment of each port-component is dependent upon the service implementation and container used. If Webservices.xml file has security of transaction information the servlet and other J2EE artifacts will have the required information to enable the Security and/or Transaction in both J2EE and Web Service Domains.
The deployment tool must deploy and publish all the ports of all WSDL documents described in the Web services deployment descriptor. The deployment tool updates or generates the WSDL port address for each deployed port-component. The updated WSDL documents are then published to a location determined by the deployer. It could be as simple as publishing to a file in the modules containing the deployed services, a URL location representing the deployed services of the server, a UDDI registry.
For each service reference described in the Web services client deployment descriptors, the deployment tool ensures that the client code can access the Web service. The deployment tool examines the information provided in the client deployment descriptor (the Service interface class, the Service Endpoint Interface class, and WSDL ports the client wants to access) as well as the JAX-RPC mapping information. In general the procedure includes providing an implementation of the JAX-RPC Service interface class declared in the deployment descriptor service reference, generating stubs for all the service-endpoint-interface declarations (if generated Stubs are supported and the deployer decides to use them), and binding the Service class implementation into a JNDI namespace.
Once the Web services enabled deployable artifact has been converted into a J2EE deployable artifact, the deployment process continues using normal deployment processes.