Developing JAX-WS Web Services

Overview of the WebLogic Web Service Programming Model

The WebLogic web services programming model centers around JWS files—Java files that use JWS annotations to specify the shape and behavior of the web service—and Ant tasks that execute on the JWS file. JWS annotations are based on the metadata feature, introduced in Version 5.0 of the JDK (specified by JSR-175 at http://www.jcp.org/en/jsr/detail?id=175) and include standard annotations defined by Web Services Metadata for the Java Platform specification (JSR-181), described at http://www.jcp.org/en/jsr/detail?id=181, the JAX-WS specification (JSR-224), described at http://jax-ws.java.net, as well as additional ones. For a complete list of JWS annotations that are supported, see Web Service Annotation Support in WebLogic Web Services Reference for Oracle WebLogic Server. For additional detailed information about this programming model, see The Programming Model—Metadata Annotations.

Web services can be created using two development methods: bottom-up or top-down. Bottom-up development refers to the process of developing a web service from the underlying Java implementation using SOAP. Top-development describes the development of a web service from the WSDL source.

The following sections describe the high-level steps for iteratively developing a web service, either starting from Java (bottom-up) or starting from an existing WSDL file (top-down):

Iterative development refers to setting up your development environment in such a way so that you can repeatedly code, compile, package, deploy, and test a web service until it works as you want. The WebLogic web service programming model uses Ant tasks to perform most of the steps of the iterative development process. Typically, you create a single build.xml file that contains targets for all the steps, then repeatedly run the targets, after you have updated your JWS file with new Java code, to test that the updates work as you expect.

In addition to the command-line tools described in this section, you can use an IDE, such as Oracle JDeveloper or Oracle Enterprise Pack for Eclipse (OEPE), to develop web services. For more information, see Using Oracle IDEs to Build Web Services in Understanding WebLogic Web Services for Oracle WebLogic Server.

Configuring Your Domain For Advanced Web Services Features

When creating or extending a domain, you can apply the WebLogic Advanced Web Services for JAX-WS Extension template (oracle.wls-webservice-jaxws-template.jar) to configure automatically the resources required to support the following advanced web service features:

Asynchronous messaging, as described in Developing Asynchronous Clients.
Web services reliable messaging, as described in Using Web Services Reliable Messaging.
Message buffering, as described in Configuring Message Buffering for Web Services.
Security using WS-SecureConversation, as described in Configuring Message-level Security in Securing WebLogic Web Services for Oracle WebLogic Server.

Note:

To configure your domain for SOAP over JMS transport, see Configuring the WebLogic Server Domain for JMS Transport.

Use of the WebLogic Advanced Web Services for JAX-WS Extension template is only required when you need to ensure recoverability of advanced web services. The extension template configures the following resources that support recoverability by enabling WebLogic Server to retain critical state information in the event of a server failure:

JMS queues for storing reliable messaging requests.
Default web service persistence configuration that provides a built-in, high-performance storage solution for web services.

The benefits of using the WebLogic Advanced Web Services for JAX-WS Extension template include:

Web services and clients, by default, use the reliable and high performance WebLogic storage solution.
Web services that use reliable messaging can buffer incoming asynchronous requests to increase fault tolerance and better absorb load. (This feature is enabled by default.)
Messages between web services and clients can be configured such that they are fault-tolerant and recoverable in the event of a client failure, service failure, or both.

If you do not use the WebLogic Advanced Web Services for JAX-WS Extension template, you can still develop using the advanced features, but with a reduced quality of service, as describe below:

By default, the state of an advanced web service is stored in memory; in the event of server failure, the data will be lost.
Web services will not buffer incoming asynchronous requests when using reliable messaging.
Web services and clients will not be recoverable in the event of a failure; any in-flight requests between them will be lost.

For more information, see Resources Required by Advanced Web Service Features.

Note:

If you do not apply the WebLogic Advanced Web Services for JAX-WS Extension template to support recoverability:

You must ensure that buffering is disabled for web services reliable messaging on the destination server. For more information, see Configuring a Non-buffered Destination for a Web Service.
Quality of service features that you have configured for your web service may not be in effect. In this case, a message will be logged to the sever log to indicate the feature has been disabled.

Although use of this extension template is not required, it makes the configuration of the required resources much easier. Alternatively, you can manually configure the resources required for these advanced features using the Oracle WebLogic Server Administration Console or WLST.

The following procedures describe how to configure a domain automatically for the advanced web services features. For more detailed instructions about using the Configuration Wizard to create and update WebLogic Server domains, see Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard.

Resources Required by Advanced Web Service Features

Table 3-1 lists the resources that are defined automatically when using the WebLogic Advanced Web Services for JAX-WS Extension template.

If you do not apply the extension template, you need to configure the resources manually using the Oracle WebLogic Server Administration Console or WLST. Be sure to configure JMS targeting according to best practices defined in Best Practices for JMS Beginners and Advanced Users in Administering JMS Resources for Oracle WebLogic Server. Specifically:

Configure a JMS server, Store-and-forward (SAF) service agent, and persistent store on each WebLogic Server. In a cluster, target each to a local migratable target (not the server). The host server's "default migratable target" is sufficient in most cases.
Target JMS modules to a cluster (or single server if not using a clustered environment).
Create exactly one subdeployment per module, and populate the subdeployment with the applicable JMS servers or SAF agents only, not the servers.
Target JMS destinations to the subdeployment (referred to as Advanced Targeting in the WebLogic Server Administration Console). JMS destinations must never use the default targeting option.

The following variables are used in the table:

server_designator specifies an ID that is generated automatically by the configuration framework. Typically, this ID is of the format auto_number.
uniqueID specifies unique numeric ID that is generated automatically by the configuration framework. Typically, this ID is a numeric value, such as 1234.
server_name specifies the user-specified name of the server.

Note:

At runtime, you should not change the name of resources; otherwise, you may experience runtime errors or data loss.

Table 3-1 Resources Required by Advanced Web Services Features

Resource Name	Resource Type	Description
`WseeJaxwsJmsModule`	JMS Module	Defines a JMS module that defines the JMS resources needed for advanced web services. All associated targets (JMS servers targeted to a server) on this JMS module will be used to support JAX-WS web services. All servers to which this module is targeted must have the proper web services resources configured. Oracle recommends that you target this module to all servers in the domain. Note: You must configure the JMS module as a Uniform Distributed Destination (UDD). Any queues that are used by web services on JAX-WS must be Uniform Distributed Queues. Otherwise, an exception is thrown. To configure distributed destinations manually and for more information, see Using Distributed Destination in Developing JMS Applications for Oracle WebLogic Server.
`WseeJaxwsFileStore_server_designator`	File store	Specifies the file store, or physical store, used by the WebLogic Server to handle the I/O operations to save and retrieve data from the physical storage (such as file, DBMS, and so on). A separate file store is configured on each Managed Server targeted by the `WseeJaxwsJmsModule`, as specified by `server_designator`. In a single server domain, the file store is named `WseeJaxwsFileStore`. Note: Oracle recommends targeting the file store to a migratable target. To configure the file stores manually, see Using Custom File Stores in Administering the WebLogic Persistent Store.
`WseeJaxwsJmsServer_server_designator`	JMS server	Specifies the JMS server management container. A separate JMS Server is configured on each Managed Server targeted by `WseeJaxwsJmsModule`, as specified by `server_designator`. The JMS server uses `WseeFileStore_server_designator` as the file store. When configuring the JMS server, Oracle recommends the following: Target the JMS server to a migratable target. Set realistic quotas on each JMS server. For more information, see Tuning WebLogic JMS in Tuning Performance of Oracle WebLogic Server. To configure the JMS server manually, see JMS Configuration in Administering JMS Resources for Oracle WebLogic Server.
`WseeJaxwsJmsServeruniqueID`	JMS subdeployment	Specifies the JMS subdeployment targeting the JMS servers defined on all Managed Servers in the cluster. To configure the JMS subdeployment manually, see Configure subdeployments in JMS system modules in Oracle WebLogic Server Administration Console Online Help.
`weblogic.wsee.jaxws.mdb.DispatchPolicy`	Work Manager	Enables an application to execute multiple work items concurrently within a container. One Work Manager is generated for the domain and targeted to all servers to which the `WseeJaxwsJmsModule` is targeted. Note: You should not change the name of the Work Manager resource. To configure Work Managers manually, see Description of the Work Manager API in Developing CommonJ Applications for Oracle WebLogic Server.
`ReliableWseeJaxwsSAFAgent_server_name`	SAF service agent	Provides highly available JMS message production. A separate SAF agent is configured on each Managed Server, as specified by `server_name`. The SAF agent uses `WseeFileStore_server_name` as the file store. In a single server domain, the SAF agent is named `ReliableWseeJaxwsSAFAgent`. When configuring the SAF agent, Oracle recommends that you set realistic quotas on each JMS server. For more information, see Tuning WebLogic JMS in Tuning Performance of Oracle WebLogic Server. To configure SAF service agents, see Understanding the Store-and-Forward Service in Administering the Store-and-Forward Service for Oracle WebLogic Server.
`WseeBufferedRequestQueue_server_designator`	JMS queue	Specifies the queue used for buffered requests. A separate queue is configured on each Managed Server, as specified by `server_name`. In a single server domain, the queue is named `WseeBufferedRequestQueue`. In a clustered domain, each JMS queue is prefixed by `dist_`. To configure the queues manually, see Configure queues in Oracle WebLogic Server Administration Console Online Help.
`WseeBufferedRequestErrorQueue_server_designator`	JMS queue	Specifies the error queue used for `WseeBufferedRequestQueue` for buffered requests that cannot be processed within the maximum number of retries. A separate queue is configured on each Managed Server, as specified by `server_name`. In a single server domain, the queue is named `WseeBufferedRequestErrorQueue`. In a clustered domain, each JMS queue is prefixed by `dist_`. To configure the queues manually, see Configure queues in Oracle WebLogic Server Administration Console Online Help.
`WseeBufferedResponseQueue_server_designator`	JMS queue	Specifies the queue used for buffered responses. A separate queue is configured on each Managed Server, as specified by `server_designator`. In a single server domain, the queue is named `WseeBufferedResponseQueue`. In a clustered domain, each JMS queue is prefixed by `dist_`. To configure the queues manually, see Configure queues in Oracle WebLogic Server Administration Console Online Help.
`WseeBufferedResponseErrorQueue_server_designator`	JMS queue	Specifies the error queue used for `WseeBufferedResponseQueue` for buffered responses that cannot be delivered within the maximum number of retries. A separate queue is configured on each Managed Server, as specified by `server_designator`. In a single server domain, the queue is named `WseeBufferedResponseErrorQueue`. In a clustered domain, each JMS queue is prefixed by `dist_`. To configure the queues manually, see Configure queues in Oracle WebLogic Server Administration Console Online Help.
`WseeStore`	Logical store	Defines the logical store. A separate logical store is configured on each Managed Server targeted by `WseeJaxwsJmsModule`. The logical store points to the `WseeBufferedRequestQueue` queue for its configuration and file store. To configure the logical store manually, see Configuring the Logical Store.

Configuring a Domain for Advanced Web Service Features Using the Configuration Wizard

The following sections describe how to configure a domain for advanced web service features.

Creating a Domain With the Web Services Extension Template

To create a domain that is automatically configured for the advanced web service features:

Start the Configuration Wizard.
In the Welcome window, select Create a new WebLogic domain.
Click Next.
Select Generate a domain configured automatically to support the following products and select WebLogic Advanced Web Services for JAX-WS Extension.
Click Next.
Enter the name and location of the domain and click Next.
Configure the administrator user name and password and click Next.
Configure the server start mode and JDK and click Next.
To configure additional servers and clusters:
1. On the Select Optional Configuration screen, at a minimum select Managed Servers, Clusters, and Machines to define the Managed Servers and clusters. Select any other items, as desired, and click Next.
2. Configure the Managed Servers in your environment and click Next.
3. Configure the clusters in your environment and click Next.
4. Assign the managed servers to the clusters on the Assign to Clusters screen and click Next.
5. Configure the machines in your environment and click Next.
6. Target the services defined in the environment to clusters or servers on the Target Services to Clusters or Servers screen and click Next.
  
  Note: Target the WseeJaxwsJmsModule JMS module and weblogic.wsee.jaxws.mdb.DispatchPolicy Work Manager to all servers in the cluster.
  
  Servers targeted on this screen will be fully configured for use with advanced web services.
7. Configure additional information on additional configuration screens (if selected in step 9a) and click Next.
When you reach the Configuration Summary screen, verify the domain details and click Create.

Extending a Domain With the Web Services Extension Template

To extend an existing domain so that it is automatically configured for these Web Services features:

Start the Configuration Wizard.
In the Welcome window, select Extend an Existing WebLogic Domain.
Click Next.
Select the domain to which you want to apply the extension template.
Click Next.
Select Extend my domain automatically to support the following added products and select WebLogic Advanced Web Services for JAX-WS Extension.
Click Next.
To configure additional servers and clusters:
1. On the Select Optional Configuration screen, at a minimum select Managed Servers, Clusters, and Machines to define the Managed Servers and clusters. Select any other items, as desired, and click Next.
2. Configure the Managed Servers in your environment and click Next.
3. Configure the clusters in your environment and click Next.
4. Assign the managed servers to the clusters on the Assign to Clusters screen and click Next.
5. Configure the machines in your environment and click Next.
6. Target the services defined in the environment to clusters or servers on the Target Services to Clusters or Servers screen and click Next.
  
  Note: Target the WseeJaxwsJmsModule JMS module and weblogic.wsee.jaxws.mdb.DispatchPolicy Work Manager to all servers in the cluster.
  
  Servers targeted on this screen will be fully configured for use with advanced web services.
7. Configure additional information on additional configuration screens (if selected in step 9a) and click Next.
Verify that you are extending the correct domain, then click Extend.
Click Done to exit.

Using WLST to Extend a Domain With the Web Services Extension Template

The following provides an example of how to use WLST to extend a domain using the web services extension template. Specifically, this example demonstrates how to extend a single server domain. It is assumed that you have already created a single server domain. You can add additional servers and clusters to the domain in the location noted in the example script below.

After updating the script and executing it against your domain, all resources will be configured for advanced web service features.

Review the comments provided in the sample for more information. For more information about the WLST commands described, see Understanding the WebLogic Scripting Tool.

Example 3-1 WLST Script to Extend a Domain With the Web Services Extension Template

# Read the domain. 
readDomain(single_server_domain_dir)
 
# Apply the template to the domain to configure the servers for advanced web service features.
installDir = install_directory/wlserver_10.3
templateLocation = install_directory + '/oracle_common/common/templates/wls/oracle.wls-webservice-jaxws-template.jar'
addTemplate(templateLocation)

# Save and close the domain
updateDomain()
closeDomain()

# Read the domain
readDomain(domain_dir)
 
# Optionally create any servers and clusters required in your domain environment.
# <Include create calls here . . . >
# For example: create('server1','Server') or create('cluster1','Cluster')
 
# Optionally configure the JMS module as a Uniform Distributed Destination (Recommended)
setDistDestType('WseeJaxwsJmsModule', 'UDD')

# Target WseeJaxwsJmsModule to the desired servers and clusters.
assign('JMSSystemResource', 'WseeJaxwsJmsModule', 'Target', server_or_cluster)
# Repeat assign call for other servers and clusters in the environment.

# Unassign the resource from the Administration Server.
unassign('JMSSystemResource', 'WseeJaxwsJmsModule', 'Target', Administration_Server)
 
sys.path.append(domain_dir)

applyJAXWS(globals())

# Save and close the domain
updateDomain()
closeDomain()

Updating Resources Added After Extending Your Domain

Once you have created or extended a domain using the WebLogic Advanced Web Services for JAX-WS Extension template, if you then modify the resources in your domain, you can update the configuration of those resources quickly and easily using the following WLST script.

After updating the script and executing it against your domain, all resources will be configured for advanced web service features.

Review the comments provided in the sample for more information. For more information about the WLST commands described, see Using the WebLogic Scripting Tool in Understanding the WebLogic Scripting Tool.

Example 3-2 WLST Script for Updating Resources Added After Extending Your Domain

# Read the domain.
readDomain(domain_dir)

# Optionally configure the JMS module as a Uniform Distributed Destination (Recommended)
setDistDestType('WseeJaxwsJmsModule', 'UDD')

# Target WseeJaxwsJmsModule to the desired servers and clusters.
assign('JMSSystemResource', 'WseeJaxwsJmsModule', 'Target', server_or_cluster_name)
# Repeat assign call for other servers and clusters in the environment.

# Unassign the resource from the Administration Server.
unassign('JMSSystemResource', 'WseeJaxwsJmsModule', 'Target', Administration_Server_name)

sys.path.append(domain_dir)

applyJAXWS(globals())

# Save and close the domain.
updateDomain()

Developing WebLogic Web Services Starting From Java: Main Steps

This section describes the general procedure for developing WebLogic web services starting from Java—in effect, coding the JWS file from scratch and later generating the WSDL file that describes the service. See Examples of Developing JAX-WS Web Services for specific examples of this process.

The following procedure is just a recommendation; if you have set up your own development environment, you can use this procedure as a guide for updating your existing environment to develop WebLogic web services.

Note:

This procedure does not use the WebLogic web services split development directory environment. If you are using this development environment, and would like to integrate web services development into it, see Integrating Web Services Into the WebLogic Split Development Directory Environment for details.

Table 3-2 Steps to Develop Web Services Starting From Java

#	Step	Description
1	Set up the environment.	Open a command window and execute the `setDomainEnv.cmd` (Windows) or `setDomainEnv.sh` (UNIX) command, located in the `bin` subdirectory of your domain directory. The default location of WebLogic Server domains is `ORACLE_HOME/user_projects/domains/domainName`, where `ORACLE_HOME` is the directory you specified as Oracle Home when you installed Oracle WebLogic Server and `domainName` is the name of your domain.
2	Create a project directory.	The project directory will contain the JWS file, Java source for any user-defined data types, and the Ant `build.xml` file. You can name the project directory anything you want.
3	Create the JWS file that implements the web service.	See Programming the JWS File.
4	Create user-defined data types. (Optional)	If your web service uses user-defined data types, create the JavaBeans that describes them. See Programming the User-Defined Java Data Type.
5	Create a basic Ant build file, `build.xml`.	See Creating the Basic Ant build.xml File.
6	Run the `jwsc` Ant task against the JWS file.	The `jwsc` Ant task generates source code, data binding artifacts, deployment descriptors, and so on, into an output directory. The `jwsc` Ant task generates an Enterprise application directory structure at this output directory; later you deploy this exploded directory to WebLogic Server as part of the iterative development process. See Running the jwsc WebLogic Web Services Ant Task.
7	Deploy the web service to WebLogic Server.	See Deploying and Undeploying WebLogic Web Services.
8	Browse to the WSDL of the web service.	Browse to the WSDL of the web service to ensure that it was deployed correctly. See Browsing to the WSDL of the Web Service.
9	Test the web service.	See Testing the Web Service.
10	Edit the web service. (Optional)	To make changes to the web service, update the JWS file, undeploy the web service as described in Deploying and Undeploying WebLogic Web Services, then repeat the steps starting from running the `jwsc` Ant task (Step 6).

See Developing Web Service Clients for information on writing client applications that invoke a web service.

Developing WebLogic Web Services Starting From a WSDL File: Main Steps

This section describes the general procedure for developing WebLogic web services based on an existing WSDL file. See Examples of Developing JAX-WS Web Services, for a specific example of this process.

The procedure is just a recommendation; if you have set up your own development environment, you can use this procedure as a guide for updating your existing environment to develop WebLogic web services.

It is assumed in this procedure that you already have an existing WSDL file.

Note:

This procedure does not use the WebLogic web services split development directory environment. If you are using this development environment, and would like to integrate web services development into it, see Integrating Web Services Into the WebLogic Split Development Directory Environment for details.

Table 3-3 Steps to Develop Web Services Starting From Java

#	Step	Description
1	Set up the environment.	Open a command window and execute the `setDomainEnv.cmd` (Windows) or `setDomainEnv.sh` (UNIX) command, located in the `bin` subdirectory of your domain directory. The default location of WebLogic Server domains is `ORACLE_HOME/user_projects/domains/domainName`, where `ORACLE_HOME` is the directory you specified as Oracle Home when you installed Oracle WebLogic Server and `domainName` is the name of your domain.
2	Create a project directory.	The project directory will contain the generated artifacts and the Ant `build.xml` file.
3	Create a basic Ant build file, `build.xml`.	See Creating the Basic Ant build.xml File.
4	Put your WSDL file in a directory that the `build.xml` Ant build file is able to read.	For example, you can put the WSDL file in a `wsdl_files` child directory of the project directory.
5	Run the `wsdlc` Ant task against the WSDL file.	The `wsdlc` Ant task generates the JWS service endpoint interface (SEI), the stubbed-out JWS class file, JavaBeans that represent the XML Schema data types, and so on, into output directories. See Running the wsdlc WebLogic Web Services Ant Task.
6	Update the stubbed-out JWS file generated by the `wsdlc` Ant task.	The `wsdlc` Ant task generates a stubbed-out JWS file. You need to add your business code to the web service so it behaves as you want. See Updating the Stubbed-out JWS Implementation Class File Generated By wsdlc.
7	Run the `jwsc` Ant task against the JWS file.	Specify the artifacts generated by the `wsdlc` Ant task as well as your updated JWS implementation file, to generate an Enterprise Application that implements the web service. See Running the jwsc WebLogic Web Services Ant Task.
8	Deploy the web service to WebLogic Server.	See Deploying and Undeploying WebLogic Web Services.
9	Browse to the WSDL of the web service.	Browse to the WSDL of the web service to ensure that it was deployed correctly. See Browsing to the WSDL of the Web Service.
10	Test the web service.	See Testing the Web Service.
11	Edit the web service. (Optional)	To make changes to the web service, update the JWS file, undeploy the web service as described in Deploying and Undeploying WebLogic Web Services, then repeat the steps starting from running the `jwsc` Ant task (Step 6).

See Developing Web Service Clients for information on writing client applications that invoke a web service.

Creating the Basic Ant build.xml File

Ant uses build files written in XML (default name build.xml) that contain a <project> root element and one or more targets that specify different stages in the web services development process. Each target contains one or more tasks, or pieces of code that can be executed. This section describes how to create a basic Ant build file; later sections describe how to add targets to the build file that specify how to execute various stages of the web services development process, such as running the jwsc Ant task to process a JWS file and deploying the web service to WebLogic Server.

The following skeleton build.xml file specifies a default all target that calls all other targets that will be added in later sections:

<project default="all">
  <target name="all" 
          depends="clean,build-service,deploy" />
  <target name="clean">
    <delete dir="output" />
  </target>
  <target name="build-service">
     <!--add jwsc and related tasks here -->
  </target>
  <target name="deploy">
      <!--add wldeploy task here -->
 </dftarget>
</project>

For detailed information about how to integrate and use Ant tasks in your development environment to program a web service and a client application that invokes the web service, see:

Using Oracle WebLogic Server Ant Tasks in Understanding WebLogic Web Services for Oracle WebLogic Server
Ant Task Reference in WebLogic Web Services Reference for Oracle WebLogic Server
The following sections in Developing Applications for Oracle WebLogic Server:
- Using Ant Tasks to Configure and Use a WebLogic Server Domain
- wldeploy Ant Task Reference

Running the jwsc WebLogic Web Services Ant Task

The jwsc Ant task takes as input a JWS file that contains JWS annotations and generates all the artifacts you need to create a WebLogic web service. The JWS file can be either one you coded yourself from scratch or one generated by the wsdlc Ant task.

The jwsc-generated artifacts include:

JSR-109 web service class file.
JAXB data binding artifact class file.
All required deployment descriptors, including:
- Servlet-based web service deployment descriptor file: web.xml.
- Ear deployment descriptor files: application.xml and weblogic-application.xml.
Note:

The WSDL file is generated when the service endpoint is deployed.

If you are running the jwsc Ant task against a JWS file generated by the wsdlc Ant task, the jwsc task does not generate these artifacts, because the wsdlc Ant task already generated them for you and packaged them into a JAR file. In this case, you use an attribute of the jwsc Ant task to specify this wsdlc-generated JAR file.

After generating all the required artifacts, the jwsc Ant task compiles the Java files (including your JWS file), packages the compiled classes and generated artifacts into a deployable JAR archive file, and finally creates an exploded Enterprise Application directory that contains the JAR file.

The jwsc Ant task includes attributes and child elements that enable you to:

Process multiple JWS files at once. You can choose to package each resulting web service into its own Web application WAR file, or group all of the web services into a single WAR file.
Specify the transports (HTTP/HTTPS or JMS transport) that client applications can use when invoking the web service, as described Specifying the Transport Used to Invoke the Web Service.
Update an existing Enterprise Application or Web application, rather than generate a completely new one.

To run the jwsc Ant task, add the following taskdef and build-service target to the build.xml file:

<taskdef name="jwsc"
         classname="weblogic.wsee.tools.anttasks.JwscTask" />  
<target name="build-service">
    <jwsc
      srcdir="src_directory"
      destdir="ear_directory"
      >
      <jws file="JWS_file" 
           compiledWsdl="WSDLC_Generated_JAR" 
            type="WebService_type"/>
    </jwsc>
  </target>

where:

ear_directory refers to an Enterprise Application directory that will contain all the generated artifacts.
src_directory refers to the top-level directory that contains subdirectories that correspond to the package name of your JWS file.
JWS_file refers to the full pathname of your JWS file, relative to the value of the src_directory attribute.
WSDLC_Generated_JAR refers to the JAR file generated by the wsdlc Ant task that contains the JWS SEI and data binding artifacts that correspond to an existing WSDL file.

Note:

You specify this attribute only in the "starting from WSDL" use case; this procedure is described in Developing WebLogic Web Services Starting From a WSDL File: Main Steps.
WebService_type specifies the type of web service. This value can be set to JAXWS or JAXRPC.

The required taskdef element specifies the full class name of the jwsc Ant task.

Only the srcdir and destdir attributes of the jwsc Ant task are required. This means that, by default, it is assumed that Java files referenced by the JWS file (such as JavaBeans input parameters or user-defined exceptions) are in the same package as the JWS file. If this is not the case, use the sourcepath attribute to specify the top-level directory of these other Java files.

See jwsc in the WebLogic Web Services Reference for Oracle WebLogic Server for complete documentation and examples about the jwsc Ant task.

Specifying the Transport Used to Invoke the Web Service

The <jws> child element of jwsc includes the following optional child elements for specifying the transports (HTTP/S or JMS) that are used to invoke the web service:

WLHttpTransport—Specifies the context path and service URI sections of the URL used to invoke the web service over the HTTP/S transport, as well as the name of the port in the generated WSDL. For more information, see WLHttpTransport in WebLogic Web Services Reference for Oracle WebLogic Server.
JmsTransportService—Enables and configures SOAP over JMS transport. Optionally, you can configure the destination name, destination type, delivery mode, request and response queues, and other JMS transport properties. For more information, see Developing JAX-WS Web Services.

The following guidelines describe the usage of the transport elements for the jwsc Ant task:

The transports you specify to jwsc always override any corresponding transport annotations in the JWS file. In addition, all attributes of the transport annotation are ignored, even if you have not explicitly specified the corresponding attribute for the transport element, in which case the default value of the transport element attribute is used.
You can specify both transport elements for a particular JWS file. However, you can specify only one instance of a particular transport element. For example, although you cannot specify two different <WLHttpTransport> elements for a given JWS file, you can specify one <WLHttpTransport> and one <WLJmsTransport> element.
The value of the serviceURI attribute can be the same when you specify both <WLJMSTransport> and <WLHttpTransport>.
All transports associated with a particular JWS file must specify the same contextPath attribute value.
If you specify more than one transport element for a particular JWS file, the value of the portName attribute for each element must be unique among all elements. This means that you must explicitly specify this attribute if you add more than one transport child element to <jws>, because the default value of the element will always be the same and thus cause an error when running the jwsc Ant task.
If you do not specify any transport as either one of the transport elements to the jwsc Ant task or a transport annotation in the JWS file, then the web service's default URL corresponds to the default value of the WLHttpTransport element.

Defining the Context Path of a WebLogic Web Service

There are a variety of places where the context path (also called context root) of a WebLogic web service can be specified. This section describes how to determine which is the true context path of the service based on its configuration, even if it is has been set in multiple places.

In the context of this discussion, a web service context path is the string that comes after the host:port portion of the web service URL. For example, if the deployed WSDL of a WebLogic web service is as follows:

http://hostname:7001/financial/GetQuote?WSDL

The context path for this web service is financial.

The following list describes the order of precedence, from most to least important, of all possible context path specifications:

The contextPath attribute of the <module> element and <jws> element (when used as a direct child of the jwsc Ant task.)
The contextPath attribute of the <WLHttpTransport> child elements of <jws>.
The default value of the context path, which is the name of the JWS file without any extension.

Assume that you update the build.xml file and add a <WLHttpTransport> child element to the <jws> element that specifies the JWS file and set its contextPath attribute to finance. The context path of the web service would now be finance. If, however, you then group the <jws> element (including its child <WLHttpTransport> element) under a <module> element, and set its contextPath attribute to money, then the context path of the web service would now be money.

If you do not specify any contextPath attribute in either the JWS file or the jwsc Ant task, then the context path of the web service is the default value: the name of the JWS file without its *.java extension.

If you group two or more <jws> elements under a <module> element and do not set the context path using any of the other options listed above, then you must specify the contextPath attribute of <module> to specify the common context path used by all the web services in the module. Otherwise, the default context paths for all the web services in the module are going to be different (due to different names of the implementing JWS files), which is not allowed in a single WAR file.

Examples of Using jwsc

The following build.xml excerpt shows a basic example of running the jwsc Ant task on a JWS file:

  <taskdef name="jwsc"
           classname="weblogic.wsee.tools.anttasks.JwscTask" />  
  <target name="build-service">
      <jwsc
        srcdir="src"
        destdir="output/helloWorldEar">
        <jws 
           file="examples/webservices/hello_world/HelloWorldImpl.java" 
           type="JAXWS"/>
      </jwsc>  
  </target>

In the example:

The Enterprise application will be generated, in exploded form, in output/helloWorldEar, relative to the current directory.
The JWS file is called HelloWorldImpl.java, and is located in the src/examples/webservices/hello_world directory, relative to the current directory. This implies that the JWS file is in the package examples.webservices.helloWorld.
A JAX-WS web service is generated.

The following example is similar to the preceding one, except that it uses the compiledWsdl attribute to specify the JAR file that contains wsdlc-generated artifacts (for the "starting with WSDL" use case):

  <taskdef name="jwsc"
           classname="weblogic.wsee.tools.anttasks.JwscTask" />  
  <target name="build-service">
    <jwsc
      srcdir="src"
      destdir="output/wsdlcEar">
      <jws
          file="examples/webservices/wsdlc/TemperaturePortTypeImpl.java"
          compiledWsdl="output/compiledWsdl/TemperatureService_wsdl.jar" 
          type="JAXWS"/>
    </jwsc>
  </target>

In the preceding example, the TemperaturePortTypeImpl.java file is the stubbed-out JWS file that you updated to include your business logic. Because the compiledWsdl attribute is specified and points to a JAR file, the jwsc Ant task does not regenerate the artifacts that are included in the JAR.

To actually run this task, type at the command line the following:

prompt> ant build-service

Running the wsdlc WebLogic Web Services Ant Task

The wsdlc Ant task takes as input a WSDL file and generates artifacts that together partially implement a WebLogic web service. These artifacts include:

JWS service endpoint interface (SEI) that implements the web service described by the WSDL file.
JWS implementation file that contains a partial (stubbed-out) implementation of the generated JWS SEI. This file must be customized by the developer.
JAXB data binding artifacts.
Optional Javadocs for the generated JWS SEI.

The wsdlc Ant task packages the JWS SEI and data binding artifacts together into a JAR file that you later specify to the jwsc Ant task. You never need to update this JAR file; the only file you update is the JWS implementation class.

To run the wsdlc Ant task, add the following taskdef and generate-from-wsdl targets to the build.xml file:

  <taskdef name="wsdlc"
          classname="weblogic.wsee.tools.anttasks.WsdlcTask"/>
  <target name="generate-from-wsdl">
    <wsdlc
        srcWsdl="WSDLFile"
        destJwsDir="JWS_interface_directory"
        destImplDir="JWS_implementation_directory"
        packageName="Package_name" 
        type="WebService_type"/>
  </target>

where:

WSDLFile refers to the name of the WSDL file from which you want to generate a partial implementation, including its absolute or relative pathname.
JWS_interface_directory refers to the directory into which the JAR file that contains the JWS SEI and data binding artifacts should be generated.

The name of the generated JAR file is WSDLFile_wsdl.jar, where WSDLFile refers to the root name of the WSDL file. For example, if the name of the WSDL file you specify to the file attribute is MyService.wsdl, then the generated JAR file is MyService_wsdl.jar.
JWS_implementation_directory refers to the top directory into which the stubbed-out JWS implementation file is generated. The file is generated into a subdirectory hierarchy corresponding to its package name.

The name of the generated JWS file is Service_PortTypeImpl.java, where Service and PortType refer to the name attribute of the <service> element and its inner <port> element, respectively, in the WSDL file for which you are generating a web service. For example, if the service name is MyService and the port name is MyServicePortType, then the JWS implementation file is called MyService_MyServicePortTypeImpl.java.
Package_name refers to the package into which the generated JWS SEI and implementation files should be generated. If you do not specify this attribute, the wsdlc Ant task generates a package name based on the targetNamespace of the WSDL.
WebService_type specifies the type of web service. This value can be set to JAXWS or JAXRPC.

The required taskdef element specifies the full class name of the wsdlc Ant task.

Only the srcWsdl and destJwsDir attributes of the wsdlc Ant task are required. Typically, however, you generate the stubbed-out JWS file to make your programming easier. Oracle recommends you explicitly specify the package name in case the targetNamespace of the WSDL file is not suitable to be converted into a readable package name.

The following build.xml excerpt shows an example of running the wsdlc Ant task against a WSDL file:

  <taskdef name="wsdlc"
          classname="weblogic.wsee.tools.anttasks.WsdlcTask"/>
  <target name="generate-from-wsdl">
      <wsdlc
          srcWsdl="wsdl_files/TemperatureService.wsdl"
          destJwsDir="output/compiledWsdl"
          destImplDir="impl_output"
          packageName="examples.webservices.wsdlc" 
          type="JAXWS" />
  </target>

In the example:

The existing WSDL file is called TemperatureService.wsdl and is located in the wsdl_files subdirectory of the directory that contains the build.xml file.
The JAR file that will contain the JWS SEI and data binding artifacts is generated to the output/compiledWsdl directory; the name of the JAR file is TemperatureService_wsdl.jar.
The package name of the generated JWS files is examples.webservices.wsdld.
The stubbed-out JWS file is generated into the impl_output/examples/webservices/wsdlc directory relative to the current directory.
Assuming that the service and port type names in the WSDL file are TemperatureService and TemperaturePortType, then the name of the JWS implementation file is TemperatureService_TemperaturePortTypeImpl.java.
A JAX-WS web service is generated.

To actually run this task, type the following at the command line:

prompt> ant generate-from-wsdl

For more information, see wsdlc in WebLogic Web Services Reference for Oracle WebLogic Server.

Updating the Stubbed-out JWS Implementation Class File Generated By wsdlc

The wsdlc Ant task generates the stubbed-out JWS implementation file into the directory specified by its destImplDir attribute; the name of the file is Service_PortTypeImpl.java, where Service is the name of the service and PortType is the name of the port type in the original WSDL. The class file includes everything you need to compile it into a web service, except for your own business logic.

The JWS class implements the JWS web service endpoint interface that corresponds to the WSDL file; the JWS SEI is also generated by wsdlc and is located in the JAR file that contains other artifacts, such as the Java representations of XML Schema data types in the WSDL and so on. The public methods of the JWS class correspond to the operations in the WSDL file.

The wsdlc Ant task automatically includes the @WebService annotation in the JWS implementation class; the value corresponds to the equivalent value in the WSDL. For example, the serviceName attribute of @WebService is the same as the name attribute of the <service> element in the WSDL file.

When you update the JWS file, you add Java code to the methods so that the corresponding web service operations operate as required. Typically, the generated JWS file contains comments where you should add code, such as:

  //replace with your impl here

In addition, you can add additional JWS annotations to the file, with the following restrictions:

You can include the following annotations from the standard (JSR-181) javax.jws package in the JWS implementation file: @WebService, @HandlerChain, @SOAPMessageHandler, and @SOAPMessageHandlers. If you specify any other JWS annotation from the javax.jws package, the jwsc Ant task returns error when you try to compile the JWS file into a web service. For example, if you specify the @Policy annotation in a your JWS implementation file, the jwsc Ant task throws a compilation error.
You can specify only the serviceName, endpointInterface, and targetNamespace attributes of the @WebService annotation. Use the serviceName attribute to specify a different <service> WSDL element from the one that the wsdlc Ant task used, in the rare case that the WSDL file contains more than one <service> element. Use the endpointInterface attribute to specify the JWS SEI generated by the wsdlc Ant task. Use the targetNamespace attribute to specify the namespace of a WSDL service, which can be different from the on in JWS SEI.
You can specify JAX-WS—JSR 224, JAXB (JSR 222)—or Common (JSR 250) annotations, as required. For more information about the annotations that are supported, see JWS Annotation Reference in WebLogic Web Services Reference for Oracle WebLogic Server.

After you have updated the JWS file, Oracle recommends that you move it to an official source location, rather than leaving it in the wsdlc output directory.

The following example shows the wsdlc-generated JWS implementation file from the WSDL shown in Sample WSDL File; the text in bold indicates where you would add Java code to implement the single operation (getTemp) of the web service:

package examples.webservices.wsdlc;
import javax.jws.WebService;
/**
 * TemperaturePortTypeImpl class implements web service endpoint interface 
 * TemperaturePortType */
@WebService(
  serviceName="TemperatureService",
  endpointInterface="examples.webservices.wsdlc.TemperaturePortType")
public class TemperaturePortTypeImpl implements TemperaturePortType {
  public TemperaturePortTypeImpl() {
  }
  public float getTemp(java.lang.String zipcode)
  {
    //replace with your impl here
     return 0;
  }
}

Deploying and Undeploying WebLogic Web Services

Because web services are packaged as Enterprise Applications, deploying a web service simply means deploying the corresponding EAR file or exploded directory.

There are a variety of ways to deploy WebLogic applications, from using the WebLogic Server Administration Console to using the weblogic.Deployer Java utility. There are also various issues you must consider when deploying an application to a production environment as opposed to a development environment. For a complete discussion about deployment, see Deploying Applications to Oracle WebLogic Server.

This guide, because of its development nature, discusses just two ways of deploying web services:

Using the wldeploy Ant Task to Deploy Web Services

The easiest way to deploy a web service as part of the iterative development process is to add a target that executes the wldeploy WebLogic Ant task to the same build.xml file that contains the jwsc Ant task. You can add tasks to both deploy and undeploy the web service so that as you add more Java code and regenerate the service, you can redeploy and test it iteratively.

To use the wldeploy Ant task, add the following target to your build.xml file:

  <target name="deploy">
      <wldeploy action="deploy"
        name="DeploymentName"
        source="Source" user="AdminUser"
        password="AdminPassword" 
        adminurl="AdminServerURL"
        targets="ServerName"/>
  </target>

where:

DeploymentName refers to the deployment name of the Enterprise Application, or the name that appears in the WebLogic Server Administration Console under the list of deployments.
Source refers to the name of the Enterprise Application EAR file or exploded directory that is being deployed. By default, the jwsc Ant task generates an exploded Enterprise Application directory.
AdminUser refers to administrative username.
AdminPassword refers to the administrative password.
AdminServerURL refers to the URL of the Administration Server, typically t3://localhost:7001.
ServerName refers to the name of the WebLogic Server instance to which you are deploying the web service.

For example, the following wldeploy task specifies that the Enterprise Application exploded directory, located in the output/ComplexServiceEar directory relative to the current directory, be deployed to the myServer WebLogic Server instance. Its deployed name is ComplexServiceEar.

  <target name="deploy">
    <wldeploy action="deploy"
      name="ComplexServiceEar"
      source="output/ComplexServiceEar" user="weblogic"
      password="weblogic" verbose="true"
      adminurl="t3://localhost:7001"
      targets="myserver"/>
  </target>

To actually deploy the web service, execute the deploy target at the command-line:

  prompt> ant deploy

You can also add a target to easily undeploy the web service so that you can make changes to its source code, then redeploy it:

  <target name="undeploy">
    <wldeploy action="undeploy"
      name="ComplexServiceEar"
      user="weblogic"
      password="weblogic" verbose="true"
      adminurl="t3://localhost:7001"
      targets="myserver"/>
  </target>

When undeploying a web service, you do not specify the source attribute, but rather undeploy it by its name.

Using the Administration Console to Deploy Web Services

To use the WebLogic Server Administration Console to deploy the web service, first invoke it in your browser using the following URL:

  http://[host]:[port]/console

where:

host refers to the computer on which WebLogic Server is running.
port refers to the port number on which WebLogic Server is listening (default value is 7001).

Then use the deployment assistants to help you deploy the Enterprise application. See Enterprise Applications in the Oracle WebLogic Server Administration Console Online Help.

Browsing to the WSDL of the Web Service

You can display the WSDL of the web service in your browser to ensure that it has deployed correctly.

The following URL shows how to display the web service WSDL in your browser:

http://[host]:[port]/[contextPath]/[serviceUri]?WSDL

where:

host refers to the computer on which WebLogic Server is running (for example, localhost).
port refers to the port number on which WebLogic Server is listening (default value is 7001).
contextPath refers to the context root of the web service. There are many places to set the context root (the <WLHttpTransport>, <module>, or <jws> element of jwsc) and certain methods take precedence over others. See Defining the Context Path of a WebLogic Web Service.
serviceUri refers to the value of the serviceUri attribute of the <WLHttpTransport> child element of the jwsc Ant task. If you do not specify any serviceUri attribute in the jwsc Ant task, then the serviceUri of the web service is the default value: the serviceName element of the @WebService annotation if specified; otherwise, the name of the JWS file, without its extension, followed by Service.

For example, assume that you specified the following <WLHttpTransport> child element in the jwsc task that you use to build your web service:

<target name="build-service">
  <jwsc
     srcdir="src"
     destdir="${ear-dir}"
     keepGenerated="true">
    <jws file="examples/webservices/complex/ComplexImpl.java" 
       type="JAXWS">
    <WLHttpTransport
       contextPath="complex" serviceUri="ComplexService"
       portName="ComplexServicePort"/>
    </jws>
  </jwsc>
</target>

Then the URL to view the WSDL of the web service, assuming the service is running on a host called ariel at the default port number (7001), is:

http://ariel:7001/complex/ComplexService?WSDL

Configuring the Server Address Specified in the Dynamic WSDL

The WSDL of a deployed web service (also called dynamic WSDL) includes an <address> element that assigns an address (URI) to a particular web service port. For example, assume that the following WSDL snippet partially describes a deployed WebLogic web service called ComplexService:

<definitions name="ComplexServiceDefinitions"
             targetNamespace="http://example.org">
...
  <service name="ComplexService">
    <port binding="s0:ComplexServiceSoapBinding" name="ComplexServicePort">
      <s1:address location="http://myhost:7101/complex/ComplexService"/>
    </port>
  </service>
</definitions>

The preceding example shows that the ComplexService web service includes a port called ComplexServicePort, and this port has an address of http://myhost:7101/complex/ComplexService.

WebLogic Server determines the complex/ComplexService section of this address by examining the contextPath and serviceURI attributes of the jwsc elements, as described in Browsing to the WSDL of the Web Service. However, the method WebLogic Server uses to determine the protocol and host section of the address (http://myhost:7101, in the example) is more complicated, as described below. For clarity, this section uses the term server address to refer to the protocol and host section of the address.

The server address that WebLogic Server publishes in a dynamic WSDL of a deployed web service depends on whether the web service can be invoked using HTTP/S or JMS, whether you have configured a proxy server, whether the web service is deployed to a cluster, or whether the web service is actually a callback service.

The following sections reflect these different configuration options, and provide links to procedural information about changing the configuration to suit your needs.

It is assumed in the sections that you use the WebLogic Server Administration Console to configure cluster and standalone servers.

Web service is not a callback service and can be invoked using HTTP/S

If the web service is deployed to a cluster, the following values are used in the server address of the dynamic WSDL, in order of precedence:
- Configured network channel, as described in Configuring the Identity of the Front-end SOAP Router Using Network Channels.
- Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port configured for the cluster, as described in Configure HTTP Settings for a Cluster in Oracle WebLogic Server Administration Console Online Help.
- Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port configured for the local server, as described in Configure HTTP Protocol in Oracle WebLogic Server Administration Console Online Help.
- If none of the above items are set, the Cluster Address must be set for the cluster, as described in Configure Clusters in Oracle WebLogic Server Administration Console Online Help. The server channel for the specified protocol from the request URL (for example, http) will be used to generate the cluster address that is displayed in the WSDL.
If the web service is deployed to an individual server, the Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port configured for the local server are used in the server address of the dynamic WSDL, as described in Configure HTTP Protocol in Oracle WebLogic Server Administration Console Online Help.

Web service is a callback service

If the callback service is deployed to a cluster, the following values are used in the server address of the dynamic WSDL, in order of precedence:
- Configured network channel, as described in Configuring the Identity of the Front-end SOAP Router Using Network Channels.
- Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port configured for the cluster, as described in Configure HTTP Settings for a Cluster in Oracle WebLogic Server Administration Console Online Help.
- Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port configured for the local server, as described in Configure HTTP Protocol in Oracle WebLogic Server Administration Console Online Help.
- Cluster Address for the cluster, as described in Configure Clusters in Oracle WebLogic Server Administration Console Online Help. The Cluster Address is required if no other values are set.
If the callback service is deployed to an individual server, the Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port configured for the local server are used in the server address of the dynamic WSDL, as described in Configure HTTP Protocol in Oracle WebLogic Server Administration Console Online Help.
If none of the preceding values are set, but the Listen Address of the server to which the callback service is deployed is set, then WebLogic Server uses this value in the server address.

See Configure Listen Addresses in Oracle WebLogic Server Administration Console Online Help.

Web service is invoked using a proxy server

Although not required, Oracle recommends that you explicitly set the Frontend Host, FrontEnd HTTP Port, and Frontend HTTPS Port of either the cluster or individual server to which the web service is deployed to point to the proxy server.

See Configure HTTP Settings for a Cluster or Configure HTTP Protocol in Oracle WebLogic Server Administration Console Online Help.

Testing the Web Service

After you have deployed a WebLogic web service, you can test basic and advanced features of your web service, such as security, quality of service (QoS), HTTP headers, and so on. You can also perform stress testing of the security features. For information about testing web services using the Web Services Test Client or Fusion Middleware Control Test Web Service page, see Testing Web Services in Administering Web Services.

Integrating Web Services Into the WebLogic Split Development Directory Environment

This section describes how to integrate web services development into the WebLogic split development directory environment. It is assumed that you understand this WebLogic feature and have set up this type of environment for developing standard Java Platform, Enterprise Edition (Java EE) applications and modules, such as EJBs and Web applications, and you want to update the single build.xml file to include web services development.

For detailed information about the WebLogic split development directory environment, see Creating a Split Development Directory Environment in Developing Applications for Oracle WebLogic Server and the splitdir/helloWorldEar example installed with WebLogic Server, located in the ORACLE_HOME/wlserver/samples/server/examples/src/examples directory, where ORACLE_HOME represents the directory in which you installed WebLogic Server. For more information about the WebLogic Server code examples, see Sample Applications and Code Examples in Understanding Oracle WebLogic Server.

In the main project directory, create a directory that will contain the JWS file that implements your web service.
For example, if your main project directory is called /src/helloWorldEar, then create a directory called /src/helloWorldEar/helloWebService:
```
prompt> mkdir /src/helloWorldEar/helloWebService
```
Create a directory hierarchy under the helloWebService directory that corresponds to the package name of your JWS file.
For example, if your JWS file is in the package examples.splitdir.hello package, then create a directory hierarchy examples/splitdir/hello:
```
prompt> cd /src/helloWorldEar/helloWebService
prompt> mkdir examples/splitdir/hello
```
Put your JWS file in the just-created web service subdirectory of your main project directory (/src/helloWorldEar/helloWebService/examples/splitdir/hello in this example.)
In the build.xml file that builds the Enterprise application, create a new target to build the web service, adding a call to the jwsc WebLogic web service Ant task, as described in Running the jwsc WebLogic Web Services Ant Task.
The jwsc srcdir attribute should point to the top-level directory that contains the JWS file (helloWebService in this example). The jwsc destdir attribute should point to the same destination directory you specify for wlcompile, as shown in the following example:
```
  <target name="build.helloWebService">
    <jwsc
        srcdir="helloWebService"
        destdir="destination_dir"
        keepGenerated="yes" >
        <jws file="examples/splitdir/hello/HelloWorldImpl.java" 
         type="JAXWS" />
    </jwsc>
  </target>
```
In the example, destination_dir refers to the destination directory that the other split development directory environment Ant tasks, such as wlappc and wlcompile, also use.
Update the main build target of the build.xml file to call the web service-related targets:
```
  
  <target name="build"
    description="Compiles helloWorldEar application and runs appc"
    depends="build-helloWebService,compile,appc" />
```
Note:

When you actually build your Enterprise Application, be sure you run the jwsc Ant task before you run the wlappc Ant task. This is because wlappc requires some of the artifacts generated by jwsc for it to execute successfully. In the example, this means that you should specify the build-helloWebService target before the appc target.

If you use the wlcompile and wlappc Ant tasks to compile and validate the entire Enterprise Application, be sure to exclude the web service source directory for both Ant tasks. This is because the jwsc Ant task already took care of compiling and packaging the web service. For example:

<target name="compile">
   <wlcompile srcdir="${src.dir}" destdir="${dest.dir}"
           excludes="appStartup,helloWebService">
   ...
   </wlcomplile>
...
</target>
<target name="appc">
   <wlappc source="${dest.dir}" deprecation="yes" debug="false"
           excludes="helloWebService"/>
</target>

Update the application.xml file in the META-INF project source directory, adding a <web> module and specifying the name of the WAR file generated by the jwsc Ant task.
For example, add the following to the application.xml file for the helloWorld web service:
```
<application>
...
  <module>
    <web>
      <web-uri>examples/splitdir/hello/HelloWorldImpl.war</web-uri>
      <context-root>/hello</context-root>
    </web>
  </module>
...
</application>
```
Note:

The jwsc Ant task always generates a Web Application WAR file from the JWS file that implements your web service, unless you JWS file defines an EJB via the @Stateless annotation. In that case you must add an <ejb> module element to the application.xml file instead.

Your split development directory environment is now updated to include web service development. When you rebuild and deploy the entire Enterprise Application, the web service will also be deployed as part of the EAR. You invoke the web service in the standard way described in Browsing to the WSDL of the Web Service.