JAX-WS application packaging

You can package a Java™ Application Programming Interface (API) for XML Web Services (JAX-WS) application as a web service. A JAX-WS web service is contained within a web application archive (WAR) file or a WAR module within an enterprise archive (EAR) file.

A JAX-WS enabled WAR file contains:
  • A WEB-INF/web.xml file
  • Annotated classes that implement the web services contained in the application module
  • [Optional] Web Services Description Language (WSDL) documents that describe the web services contained in the application module
A WEB-INF/web.xml file is similar to this example: 
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
         http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
         version="2.4">
</web-app>

The web.xml might contain servlet or servlet-mapping elements. When customizations to the web.xml file are not needed, the WebSphere® Application Server runtime defines them dynamically as the module is loaded. For more information on configuring the web.xml file, see customizing web URL patterns in the web.xml file for JAX-WS applications.

Annotated classes must contain, at a minimum, a web service implementation class that includes the @WebService annotation. The definition and specification of the web services-related annotations are provided by the JAX-WS and JSR-181 specifications. The web service implementation classes can exist within the WEB-INF/classes or directory within a Java archive (JAR) file that is contained in the WEB-INF/lib directory of the WAR file.

You can optionally include WSDL documents in the JAX-WS application packaging. If the WSDL document for a particular web service is omitted, then the WebSphere Application Server runtime constructs the WSDL definition dynamically from the annotations contained in the web service implementation classes.

Starting with WebSphere Application Server Version 7.0 and later, Java EE 5 application modules (web application modules version 2.5 or later, or EJB modules version 3.0 or later) are scanned for annotations to identify JAX-WS services and clients. However, pre-Java EE 5 application modules (web application modules version 2.4 or before, or EJB modules version 2.1 or before) are not scanned for JAX-WS annotations, by default, for performance considerations. In the Version 6.1 Feature Pack for Web Services, the default behavior is to scan pre-Java EE 5 web application modules to identify JAX-WS services and to scan pre-Java EE 5 web application modules and EJB modules for service clients during application installation. Because the default behavior for WebSphere Application Server Version 7.0 and later is to not scan pre-Java EE 5 modules for annotations during application installation or server startup, to preserve backward compatability with the feature pack from previous releases, you must configure either the UseWSFEP61ScanPolicy property in the META-INF/MANIFEST.MF of a web application archive (WAR) file or EJB module or define the Java virtual machine custom property, com.ibm.websphere.webservices.UseWSFEP61ScanPolicy, on servers to request scanning during application installation and server startup. To learn more about annotations scanning, see the JAX-WS annotations information.

Avoid trouble: During the web services application deployment, utility jars are not scanned for annotations. Therefore, if web services are packaged in utility jars, they cannot be detected by the web services engine. In such case, if the Start components as needed option is selected in the configuration settings for the application server, web service component cannot be started after you start the application server because there is no web service detected. Use custom property com.ibm.websphere.webservices.StartWebServicesComponent to avoid this trouble.
Avoid trouble: We highly recommend packaging the Service Endpoint Interface (SEI) and implementation classes of any third party web services with the application/module. Packaging this way ensures that the SEI and implementation classes are both visible to the application's classloader and prevents the occurrence of an exception like EndpointInterfaceDescriptionImpl: cannot find super class that was specified for this class.

If the SEI and the implementation classes cannot be packaged with the application/module, we recommend packaging the jar files that contain these classes into an isolated shared library and associating this shared library with the application/module.