In this article, we will provide an review of How to Deploy Web Services. We will look at the steps required to configure, package, and deploy Java EE Web services and service clients. This is part of a larger series of articles to help you prepare for the web service developer exam. You can review the first article, “Tutorial:Review of Building Web Services for the Web Service Developer Exam” in order to understand the concepts discussed here.

Package and Deployment of Pre-Java EE 5 Components

Once you had developed a J2EE component such as an EJB, servlet, JSP, or JSE, you needed to deploy it into your J2EE application server to run it. Although the deployment process was conceptually the same from one J2EE platform to the next, the tools used can differ from one vendor to another. This meant that the skills of a J2EE developer for deployment were vendor-specific.

Despite this J2EE does defined a portable mechanism for packaging J2EE components and describing their properties and runtime attributes. The mechanism for this is the Java ARchive (JAR) file format and the deployment descriptors. You would still need to use vendor specific configuration, but the JAR-based deployment process enhanced the portability of J2EE components by standardizing the way they are packaged and described. This standardization ensured that J2EE-compliant components from any source, in-house or third-party, would be recognised, easily inspected and deployed by any J2EE application server. For example, if you buy a specialized servlet from Company X and it's packaged properly, you could deploy it into your J2EE application server from Company Y immediately, using the server's deployment tools.

A JAR file consisted of class files and the XML deployment descriptor of a J2EE 5 component. This file was easily transferred or stored on a disk. Once deployed, the J2EE 5 application server's deployment tool would inspect the JAR file, read the deployment descriptor, extract the class files, properties, images, etc, and then instantiate and launch the component into the server. You could fine tune the runtime attributes of the J2EE component according to your needs during the deployment process. This fine tuning normally related to enterprise attributes like security restrictions, transactional behavior, instance pooling, and threading. The list below outlines the classic steps involved in a J2EE deployment process:
  1. A developer create Java classes and then a XML deployment descriptor for a J2EE component.
  2. The developer packages the class files and deployment descriptor(s) for the J2EE component in a JAR file.
  3. The developer makes the JAR file available to all who need it for their development.
  4. The administrator who manages the J2EE application servers receives the JAR file from the developer.
  5. The administrator adds the JAR on a local drive and loads it into the server's deployment tool.
  6. The administrator modifies runtime attributes and tunes the J2EE component for the company's production environment.
  7. The administrator restarts the J2EE component into the application server.

One would package J2EE components with either a JAR file or derivatives of JAR files. For example the JAR file containing Web components is called a Web ARchive (WAR) file nd the JAR file containing Enterprise JavaBeans is called an EJB JAR file. There is also another type of JAR file for Java EE connectors called a Resource ARchive (RAR) file. Even though J2EE connectors are not actually J2EE components, they have their own JAR file format and deployment descriptors, and follow the same general deployment process as traditional J2EE components like servlets, JSPs, and EJBs.
Finally when you have a complete J2EE application as a business solution that is comprised of Web components, EJBs, and J2EE connectors. The J2EE application can be packaged in an Enterprise ARchive (EAR) file. It contains a general XML deployment descriptor for the entire application, as well as all the J2EE components and connectors, packaged into their own EJB JAR, WAR, and RAR files.
Finally for web services, the Java Service Endpoints (JSEs) are packaged into a WAR file, since the JSE is built on top of the servlet programming model. The EJB endpoints are packaged into an EJB JAR file as an EJB endpoint is an Enterprise JavaBean that happens to process SOAP messages. We will explain how JSEs and EJB endpoints are deployed in the next section.

How to Deploy Web Services In Java EE 5

Presently in practice, you can start a Web service with a WSDL or an existing implementation. As both approaches are acceptable and used regularly, Java EE 5 Web Services embraces both. This flexibility complicates matters to a certain extent since the infrastructure for deploying Web services can start as a WSDL document, or as a JSE or an EJB endpoint.

Fortunately WS-Metadata provides a set of standard annotations that developers and administrators can use to configure how the container will deploy a Java class as a Web service. At deployment, the JWS container interprets the annotations to generate artifacts and configure itself in order to deploy the specified Web service. For example, a JWS container may construct a WSDL representation of a Web service based on the WS-Metadata annotations.

By using WS-Metadata, the programming model for the development and deployment of Web Services is simplified and streamlined than if we had to configure and package the class files, deployment descriptors and other resources ourselves. We can simply have WS-Metadata use the annotations to declaratively specify the Web services a Java class provides and you no longer need to have a webservices.xml file. The flip side of this simplification is that when you use annotations to encode the definition of the Web service inside the Java class definition itself, then you will need to override those annotations with deployment descriptors if you want to deploy the same class, with different Web service representations, in another context. This is because the optional webservices.xml file continues to be supported. If you choose to use both webservices.xml and annotations, remember that the webservices.xml configuration information will override the annotations. Also the JAX-RPC mapping file that was required when using JAX-RPC in J2EE environments, is no longer required since JAX-WS uses JAXB for all its data binding requirements.

Web Service Enterprise Endpoints (WSEE) simplifies the development and deployment of Web services through the use of annotations, and by defining the proper use and packaging of WS-Metadata annotated classes. In many common deployment scenarios, no deployment descriptors are required. But in those situations where you will want to use deployment descriptors, it is important to understand how they work. Also it is important to realize that although developers are not dealing that often with deployment descriptors in JWS, the JWS container is probably generating them based on the annotations and using them behind the scenes. Therefore you need to understand how annotations and deployment descriptors interact as well as the behavior of Web Services deployment in general.

Overview of the Process of Packaging and Deployment

A Web service component that get packaged and deployed to the JWS container is referred to as a port component. It is considered an addition to the Java EE platform defined by WSEE and is similar to other deployable components such as servlets and JSPs in a Web container or EJBs in an EJB container. Like the previously mentioned components, a port component depends on the functionality provided by the Web and EJB containers. The WSEE specification does not specify how a Java EE container should implement port components. But most implementations rely heavily on servlets because it can leverages the existing investment already made in developing servlet technology.

A port component defines the programming model artifacts defined in the WSEE specification that make up a portable Web service application. A port component must include a service implementation bean. The service implementation bean (SIB) is a Java class that contains the business logic of a JAX-WS Web service and optionally can be a wrapper that invokes other classes containing the business logic. In either case, it is annotated with @WebService or @WebServiceProvider and its methods can be exposed as Web service operations. The SIB is fully defined in the WS-Metadata specification. It is the only required artifact in a port component.

A port component can also include a service endpoint interface (SEI), a WSDL document, security role references, as well as a Web Services deployment descriptor. The SEI is a Java interface that is mapped to a wsdl:portType based on the JAX-WS WSDL/Java Mapping. When you include a SEI in a port component, the container then uses that SEI and its annotations to generate the WSDL representation of the resulting Web service. Otherwise the container generates the WSDL representation directly from the SIB.

You can also provide a WSDL document as part of the port component. In such cases, the container does not generate WSDL, but uses the supplied document. When a WSDL is supplied, the existing endpoint address defined in the WSDL can be modified by the container to be consistent with the endpoint address where the resulting Web service is deployed. For example, the soap:address in the provided WSDL can be changed in the deployed WSDL to reflect the context root and path of the deployment.

Security role references are logical role names similar to those in web or ejb deployments that are declared by the port component using the deployment descriptors for the component (i.e. Web or EJB component). The Web services deployment descriptor (webservices.xml) is no longer required, as this information can be specified with annotations. But you may still use a webservices.xml descriptor if you need to deploy legacy classes that are not annotated or when overriding the value of some annotations.
You may also use other deployment artifacts such as web.xml for deploying a servlet endpoints, ejb-jar.xml for deploying an EJB endpoints and implementation-specific descriptors (e.g., a vendor specific file such as Glassfish’s sun-ejbjar.xml for specifying the context root of the endpoint URL for EJB deployment).

The port components may be packaged in a WAR file or EJB JAR file. When port components are packaged in a WAR file, they are referred to in WSEE as JAX-WS Service Endpoints. These are service implementation beans that do not have the @Stateless annotation. There is some confusion due to the term, “JAX-WS Service Endpoint” being similar to “JAX-WS service endpoint interface (SEI).” In fact, you can implement a SEI by either a JAX-WS Service Endpoint or a Stateless Session EJB in an EJB container.

Port components packaged in an EJB-JAR file must use a stateless session bean for the service implementation bean and must be annotated @Stateless. In order to clarify the packaging, I will provide details for packaging a Web service for deployment either as a WAR or an EJB-JAR.

Servlet Endpoint Packaging

The figure below shows the packaging of a SIB for deployment as a servlet endpoint using a WAR:

Tutorial:Review of How to Deploy Web Services for The Web Service Developer Exam-b15-servletendpointpackaging.jpg
Figure: Servlet Endpoint Packaging

Here we will discuss each numbered component of the package in the above figure:
  1. Service Implementation Bean - is a required artifact that is contained in the WEBINF/classes/<package-path>/, where <package-path> is determined by the class’s package name. This location is not mandatory. This class file must be annotated with @WebService or @WebServiceProvider and its methods contain the business logic that implements the Web service operations.
  2. Service endpoint interface - is an optional artifact that is contained in the WEBINF/classes/<package-path>/ where <package-path> is determined by the class’s package name. This location is not mandatory. The SEI class file can be located anywhere on the application classpath. When used, the SIB’s @WebService.endpointInterface attribute’s value must equal the complete name of this SEI.
  3. WSDL - is an optional artifact that is contained in the WEB-INF/wsdl directory. This is not a mandatory location. When used, the SIB’s @WebService.wsdlLocation attribute’s value must equal the relative location of this file. All files such as XML Schema definitions that are referenced by the WSDL must be referenced relative to the WSDL’s location. For example, if the WSDL is in the META-INF/wsdl directory and it references a schema as
  4. ../myschema.xsd then myschema.xsd should be in META-INF.
  5. web.xml - is an optional artifact that is contained in the WEB-INF/ directory.
  6. webservices.xml - is an optional artifact that is contained in the WEB-INF/ directory.
  7. jax-ws-catalog.xml - is an optional artifact that is contained in the WEB-INF/ directory. This descriptor is used in connection with OASIS XML Catalog 1.1. See OASIS XML Catalog for more information.
  8. vendor-xxx.xml - is an optional artifact that is contained in a directory specified by the Java EE 5 container vendor. In fact it will be mandatory depending on the Java EE 5 container that you use.
  9. Handler Chain File - is an optional artifact that is contained under the WEB-INF/ classes directory where it will be available as a resource on the application classpath. This file has is no standard name. The location is not a mandatory location. It can even be specified as an external URL. When used, the SIB’s @HandlerChain.file attribute’s value must equal either:
  10. Absolute java.net.URL in external form (i.e. http://rthandlers.acme.com/handlerfile.xml)
  11. Relative path from the source file or class file (e.g., retail/handlerfile.xml) specifying the location of this file
  12. Dependent Classes - these are optional artifacts that are bundled in a JAR and located under the WEB-INF/lib directory where they are available on the application classpath. These are any classes that the SIB or SEI must leverage. The location is not a mandatory location, but the dependent classes must be located somewhere on the application classpath.

The majority of Java container implementations provide development tools that include packaging utilities to create and package a servlet endpoint WAR. But you can instead you other tools for deployment and packaging such as Apache Ant or Apache Maven.

EJB Endpoint Packaging

Packaging a SIB for deployment as a stateless session bean endpoint, the EJB-JAR will be structured as shown below.

Tutorial:Review of How to Deploy Web Services for The Web Service Developer Exam-b15-ejbendpointpackaging.jpg
Figure: EJB Endpoint Packaging

Here we will discuss each numbered component of the package in the above figure:
  1. Service implementation bean - this required artifact is contained in the <package-path>/ directory where <package-path> is determined by the class’s package name. This location is not mandatory. Also the SIB can be bundled within an EAR of the same EJB-JAR and referenced in the EJB-JAR’s manifest file Class-Path attribute. The SIB could even be located in an installed library and referenced by the EJB-JAR’s manifest file Extension-List attribute. What is important is that the SIB is on the application classpath for the packaging to work. The class file must be annotated with @Stateless, and @WebService or @WebServiceProvider. The SIB’s methods hold the business logic implemented for the Web service operations.
  2. Service endpoint interface - this optional artifact is contained in the <package-path>/ where <package-path> is determined by the class’s package name. This location is not mandatory. You can locate the SEI class file anywhere on the application classpath similar to the SIB. In order to use it, the SIB’s @WebService.endpointInterface attribute’s value must equal the complete name of the SEI.
  3. WSDL - this optional artifact is contained in the META-INF/wsdl directory. The WSDL description for WAR and EJB-JAR usage is the same.
  4. ejb-jar.xml - this optional artifact is contained in the META-INF/directory.
  5. webservices.xml - this optional artifact is contained in the META-INF/directory.
  6. jax-ws-catalog.xml - this optional artifact is contained in the META-INF/ directory. This descriptor is used in connection with OASIS XML Catalog 1.1 usage
  7. vendor-ejb-xxx.xml - is an optional artifact that is contained in a directory specified by the Java EE 5 container vendor. In fact it will be mandatory depending on the Java EE 5 container as it is normally the vendor’s EJB deployment descriptor.
  8. Handler Chain File - this optional artifact is also contained under the <packagepath>/directory which is determined by the SIB class’s package name. It is available as a resource on the application classpath. The Handler Chain File description for WAR and EJB-JAR usage is the same.
  9. Dependent Classes - these optional artifacts are contained in a separate JAR file at the root of the enclosing EAR where they will be available on the application classpath. These are any classes that the SIB or SEI must leverage. The location is not a mandatory location, but the dependent classes must be located somewhere on the application classpath.

Auto-Deployment

There is an optional WS-Metadata envisions auto-deployment mechanism providing “drag and drop” functionality in some Java EE containers such as GlassFish. This is a server-side directory monitored by the container, that when it detects an WS-Metadata annotated class file, examines the annotations, builds the WSDL, and configures the run-time machinery required for dispatching.

Servlet Endpoint Deployment and Dispatching

A JWS deployable module is anything that can be deployed as a Web service by the container such as a WAR module or an EJB-JAR module. For auto-deployment, this could be a single annotated class file. The JWS container includes a deployment subsystem responsible for deployment. The subsystem can contain some components such as a command-line deployment utility that are outside of the actual container. In some cases, the actual deployment can involve an EAR containing multiple deployable modules.

In the process, the first thing that is done if for the deployment subsystem to validate the contents of the deployable module by checking that EJB Web service endpoints are deployed in EJB-JARs. The deployment subsystem may also collect some binding information from the deployer. Next the deployment subsystem deploys the components and Web services defined in the deployable module, publishes the WSDL documents for the deployed Web services, deploys any clients that use Web services, configures the server, and finally starts the application.

The deployment process is started by the deployment tool identifying the Web services using the Web service meta-data annotations or webservices.xml deployment descriptor file contained within the module. The WSEE specification states that the deployment of services occurs before resolution of service references. This is done in order to allow WSDL port addresses to be updated by deployment before the service references to them for processing. This is required as the port addresses can be determined by context root that is supplied only at deployment time. Check you vendors documentation in order to understand how the processing of annotations works in conjunction with deployment.

The processing of annotations is critical for an understanding of deployment, so we will look at how it works using what could be considered the reference implementation of the Java EE 5, GlassFish. In GlassFish V1, all of the deployment descriptors are loaded by the deployment subsystem and then annotations are processed by the annotation framework. When for example, the @WebService annotation is detected, the annotation framework calls WebServiceHandler to processes the annotation. During processing, the annotation, the framework checks whether a deployment descriptor entry is already available from webservices.xml. If there is a deployment descriptor entry, the annotation values will not override the equivalent defined in the descriptor. At the end of the annotation processing phase, all the information has been gathered that is required to generate the WSDL as well as other portable artifacts.
When the deployment is for a servlet endpoint, GlassFish generates a web.xml that directs the HTTP request containing the payload, this can be either SOAP/HTTP, or XML in the case of a RESTful service deployed with the XML/HTTP binding, to an instance of the JAXWSServlet class. This is a wrapper servlet class that dispatches requests to endpoints. Below is the detailed steps involved in the process for when you deploy a WAR with a servlet endpoint:
  1. The GlassFish container creates a web.xml to deploy an instance of JAXWSServlet that is either built up from the original web.xml contained in your WAR or strictly generated web.xml. In either case, the servlet-class is replaced with JAXWSServlet, the webservices.xml deployment descriptor is generated if it doesn’t already exist and the service-endpoint-interface references the class being deployed that was specified in your web.xml’s servlet-class. Note that webservices.xml is generated for internal use by GlassFish although it is not required by JAX-WS.
  2. Once the instance of JAXWSServlet is deployed, and initialized, this is what follows:

  • An instance of the endpoint implementation class (com.sun.enterprise.webservice.monitoring.JAXWSEnd pointImpl) is created from the port component using the definition from the deployment descriptors and annotations. The port component description is represented internally as an instance of com.sun.enterprise.deployment.WebServiceEndpoint. This JAXWSEndpointImpl instance is used to processes the MessageContext containing the SOAP request/response.
  • The deployment subsystem registers the endpoint implementation with the JAX-WS runtime. The registry is an instance of com.sun.enterprise.webservice.JAXWSRuntimeEpiRegis try. The endpoint object that is registered is an instance of com.sun.xml.ws.spi.runtime.RuntimeEndpointInfo that includes an instance of the application-defined @WebService or @WebServiceProvider annotated class implementing the endpoint, a WebServiceContext instance, an associated WSDL file that is either packaged or generated from annotations, an instance of the protocol binding (i.e., javax.xml.ws.Binding), and the handler chain.
Once the endpoint has been deployed using these steps, the servlet container registers the JAXWSServlet wrapper and it starts to listen for requests. When the JAXWSServlet instance receives a HTTPServletRequest containing a SOAP/HTTP or XML/HTTP message, it does the following:
  1. Creates the MessageContext including a reference to the ServletContext.
  2. Passes the HTTP request/response objects, along with the RuntimeEndpointInfo, to the entry point for the JAX-WS runtime system (i.e. an instance of com.sun.xml.ws.spi.runtime.Tie).
  3. The JAX-WS runtime decodes the SOAP request by applying the JAX-WS and JAXB XML/Java bindings in order to get the parameters used to invoke the endpoint implementation class.
  4. Finally the flow is reversed and a HTTP response is serialized out including the returned object.

GlassFish’s internal deployment mechanism for servlet endpoints begins with the artifacts provided in the WAR and either creates or modifies the internally used descriptors. The figure below illustrates this process:

Tutorial:Review of How to Deploy Web Services for The Web Service Developer Exam-b15-internaldescforservlet.jpg
Figure: Internal Descriptor Generation for Servlet Endpoints

The figure shows the internally generated web.xml, webservices.xml, and WSDL files. The internally generated files (e.g., web.xml) are produced in an application specific location within the directory tree rooted at $GLASSFISH_HOME/ domains/domain1/generated/xml. When you deploy a WAR, look in that directory to see the files that have been generated.
The reason for this internal descriptor generation process is partially to map the JAX-WS/WS-Metadata deployment model to the previous J2EE deployment model that requires a webservices.xml file for JAX-RPC. It is also needs to generate a web.xml for deploying the wrapper servlet (JAXWSServlet). In any event, this approach facilitates GlassFish’s support for the JAX-WS/WS-Metadata deployment approach as well as the legacy JAX-RPC approach.

Below is illustrated the numbered items showing how the generated artifacts are created either from annotations or from the web.xml supplied with the WAR if it is supplied:
  1. The servlet-name of the generated web.xml comes from the name of the class being deployed since it is associated with the servlet-link element in the generated webservices.xml. Remember that if you package a web.xml with the SIB, its servlet-name must also match the name of the SIB class.
  2. The servlet-class of the generated web.xml is the com.sun.enterprise.webservice.JAXWSServlet wrapper class.
  3. The url-pattern is the simple name of the endpoint class + “Service” which is the default value of the @WebService.serviceName attribute unless it is overridden by the servlet-pattern in a web.xml you provide. In our case, this was /MyService. The context root is a parameter provided to the deployer or a proprietary deployment descriptor.
  4. The generated wsdl:service name is specified by the @WebService.serviceName attribute
  5. The generated wsdl:service name also provides the value for the generated webservices.xml wsdl-service element. If you provide a webservices.xml, the wsdl-service element’s value would override the annotation to determine the wsdl:service name. In our case, the webservice.xml is generated.
  6. The servlet-link in the generated webservices.xml comes from the name of the class being deployed which is the same servlet-name in the generated web.xml.
  7. The generated wsdl-port in the webservices.xml comes from the @WebService.name attribute. In this case, the attribute is the default value (i.e., class name plus “Port”) since none was provided.
  8. The wsdl-port provides the wsdl:port value. This would be overridden by the @WebService.name annotation value if you had provided a webservices.xml.

Note there is an additional constraint on the mapping for the @WebServiceProvider tha comes from WSEE. It states that “For servlet based endpoints using this [@WebServiceProvider] annotation, the fully qualified name of the service implementation bean class must be used as the <servlet-link> element in the deployment descriptor to map the Port component to the actual servlet.” So when you want to use web.xml deployment descriptor along with a Provider<T> implementation, the <servlet-name> must equal the fully qualified name of the service implementation bean class. The consequence of this is that you can only deploy a Provider<T> implementation once.

EJB Endpoint Deployment and Dispatching

The deployment of stateless session bean (EJB) endpoints is similar to the case of servlet endpoints. There is a wrapper servlet class, EjbWebServiceServlet that is used to handle requests to services deployed as EJB endpoints. EjbWebServiceServlet uses an instance EjbMessageDispatcher to dispatch HTTP requests containing the payload of type SOAP/HTTP or XML in the case of a RESTful service deployed with the XML/HTTP binding to the appropriate endpoint.

Once the EJB-JAR is deployed, the Web service endpoint is registered. When the EJB Web service endpoint is registered, an instance of EjbWebServiceRegistryListener registers the endpoint’s path (i.e., the endpoint-address-uri) as an ad hoc path (i.e. servlet path) with the Web container, along with the ad hoc servlet (i.e., EjbWebServiceServlet) that is responsible for servicing any requests on this path. The servlet path for the EJBWebServiceServlet also known as the ad hoc path is not declared in the Web module’s deployment descriptor. GlassFish calls a Web module all of whose mappings are for ad hoc paths an ad hoc web module. The EjbWebServiceServlet instance receiving SOAP or XML over HTTP on behalf of an EJB endpoint is deployed in as an ad hoc Web module. Therefore, you won’t find a web.xml for this servlet or see it on the GlassFish Admin Console.
When you deploy an EJB-JAR with an EJB endpoint, the following things occur:
  1. The GlassFish container creates the deployment descriptors required for the deployment, including:
    • An ejb-jar.xml to deploy the service implementation bean. If there is already an ejb-jar.xml, the generated ejb-jar.xml is built from your original ejb-jar.xml as a starting point. In the generated ejb-jar.xml, the ejb-class references your service implementation bean, and the ejb-name is the value specified by @Stateless.name.
    • A webservices.xml where the service-endpoint-interface references the service implementation bean except in cases where the @WebService.endpointInterface annotation indicates a service endpoint interface. The port-component-name is the name of the Web service generated by the @WebService.name annotation. The webservices.xml file generated here is for internal use and is not required by JAX-WS.
    • A sun-ejb-jar.xml is created from the one supplied with your EJBJAR, if it exists. This is a GlassFish-specific descriptor. The ejb-name is the value specified by the @Stateless.name. The endpointaddress-uri specifies the endpoint path. The default deployment path of an EJB endpoint can be changed by providing a sun-ejb-jar.xml with this information in your EJB-JAR. You can also configure security by using this deployment descriptor.
  2. An instance of com.sun.enterprise.webservice.EjbContainerPreHandl er is created to handle security and is inserted first in the handler chain for the endpoint. This class performs the security authorization, before the invocation of any deployed handlers or the endpoint itself.


When the EjbWebServiceServlet instance receives a HTTPServlet Request with a SOAP/HTTP or XML/HTTP message, it does the following:
  1. Searches for the endpoint descriptor (EjbRuntimeEndpointInfo) in the EJB endpoint registry (WebServiceEjbEndpointRegistry)
  2. Performs authentication consistent with the Interoperable Services specification.
  3. Passes the HTTPServletRequest and HttpServletResponse, along with the endpoint descriptor, to the EjbMessageDispatcher for processing.

The EjbMessageDispatcher processing is similar to the dispatching performed by JAXWSServlet, and includes the following steps:
  1. Creates the MessageContext without a reference to the ServletContext.
  2. Passes the HTTP request/response objects, along with the RuntimeEndpointInfo, to the entry point for the JAX-WS runtime system (i.e. an instance of com.sun.xml.ws.spi.runtime.Tie).
  3. The JAX-WS runtime decodes the SOAP request by applying the JAX-WS and JAXB XML/Java bindings in order to get the parameters used to invoke the endpoint implementation class.
  4. Finally the flow is reversed and a HTTP response is serialized out including the returned object.

GlassFish’s internal deployment mechanism for EJB endpoints begins with the artifacts provided in the EJB-JAR and either creates or modifies the internally used descriptors. The figure below illustrates this process:

Tutorial:Review of How to Deploy Web Services for The Web Service Developer Exam-b15-internaldescejbendpoint.jpg
Figure: Internal Descriptor Generation for EJB Endpoints

The figure shows the internally generated ejb-jar.xml, webservices.xml, and WSDL files. Similar to the servlet case, these internally generated files such as ejb-jar.xml are located within the directory tree rooted at $GLASSFISH_HOME/domains/domain1/generated/xml.
Below is illustrated the numbered items showing how the generated artifacts are created:
  1. The ejb-name of the generated ejb-jar.xml is taken from the @Stateless.name. If a sun-ejb-jar.xml file is supplied in order to specify the endpoint-address-uri, the ejb-name must match the @Stateless.name. Note also that the ejb-link of the generated webservices.xml is taken from this @Stateless.name value.
  2. The ejb-class of the generated ejb-jar.xml is the full name of the class annotated with @WebService.
  3. The @WebService.name attribute’s value is the port-component-name for the generated sun-ejb-jar.xml as well as the generated webservices.xml. It is also the wsdl:portType name in the generated WSDL. This value needs to match the port-component-name in the sun-ejbjar.xml if it has been supplied in order to specify the endpoint address.
  4. If you specify the endpoint address of the Web service by in an sun-ejb-jar.xml file with the endpoint-address-uri value set to the desired endpoint path, then the WSDL soap:address location is taken from this value. Otherwise the default is composed from the serviceName / portName. This is GlassFish specific behavior. Other implementations may handle specifying the endpoint differently.
  5. The @WebService.serviceName provides the wsdl:service name for the generated WSDL file as well as corresponding to the serviceqname in the generated sun-ejb-jar.xml and the webservicedescription-name for the generated webservices.xml.
  6. The @WevService.portName specifies the service port (i.e. wsdl:port name value) in the generated WSDL. It also corresponds to the wsdl-port in the generated webservices.xml.
  7. The method name in the @WebService annotate class maps to the operation name in the generated WSDL.



Conclusion

In this article we looked at the how to package a deploy a web service. Thanks to WS-Metadata and WSEE it is possible to deploy a web service without deployment descriptors using only a service implementation bean (SIB), or using a service endpoint interface (SEI) with a SIB, and while supplying your own WSDL. This still doesn’t prevent you from using deployment descriptors in order to customize the endpoint URL where a service is deployed, or passing deployment specific environment information to the SIB or its handlers or finally for overriding the value of an annotation. Overall the process has been greatly simplified for any developers to build, package and deploy web services. In general, you should be able to complete successfully the web service developer exam as well as tackle any deployment challenges that you may have.