Getting Started With WebLogic Web Services Using JAX-WS

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Developing WebLogic Web Services

The following sections describe the iterative development process for WebLogic 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), and include standard annotations defined by the Web Services Metadata for the Java Platform specification (JSR-181), the JAX-WS specification (JSR-224), 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 additional detailed information about this programming model, see “Anatomy of a WebLogic Web Service” in Introducing WebLogic Web Services.

The following sections describe the high-level steps for iteratively developing a Web Service, either starting from Java or starting from an existing WSDL file:

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.

 


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 Use Cases and Examples 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-1 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 BEA_HOME/user_projects/domains/domainName, where BEA_HOME is the top-level installation directory of the Oracle products 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.
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.
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.
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.
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 Invoking Web Services 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 Developing WebLogic 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-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 BEA_HOME/user_projects/domains/domainName, where BEA_HOME is the top-level installation directory of the Oracle products 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.
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.
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.
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 Invoking Web Services 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>

 


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:

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.

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:

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 WebLogic Web Services Reference for more information.

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 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

Advanced Uses of jwsc

This section described two very simple examples of using the jwsc Ant task. The task, however, includes additional attributes and child elements that make the tool very powerful and useful. For example, you can use the tool to:

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

 


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:

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="WSDL_file"
destJwsDir="JWS_interface_directory"
destImplDir="JWS_implementation_directory"
packageName="Package_name"
type="WebService_type"/>
</target>

where:

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:

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

  prompt> ant generate-from-wsdl

See “wsdlc” in WebLogic Web Services Reference for more information.

 


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 portType 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:

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 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 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:

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 Administration Console to deploy the Web Service, first invoke it in your browser using the following URL:

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

where:

Then use the deployment assistants to help you deploy the Enterprise application. For more information on the Administration Console, see the 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:

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

  1. If the Web Service is deployed to a cluster, and the cluster Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port are set, then WebLogic Server uses these values in the server address of the dynamic WSDL.
  2. See “Configure HTTP Settings for a Cluster” in the Administration Console Online Help.

  3. If the preceding cluster values are not set, but the Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port values are set for the individual server to which the Web Service is deployed, then WebLogic Server uses these values in the server address.
  4. See “Configure HTTP Protocol” in the Administration Console Online Help.

  5. If these values are not set for the cluster or individual server, then WebLogic Server uses the server address of the WSDL request in the dynamic WSDL.

Web Service is a callback service

  1. If the callback service is deployed to a cluster, and the cluster Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port are set, then WebLogic Server uses these values in the server address of the dynamic WSDL.
  2. See “Configure HTTP Settings for a Cluster’ in the Administration Console Online Help.

  3. If the callback service is deployed to either a cluster or a standalone server, and the preceding cluster values are not set, but the Frontend Host, Frontend HTTP Port, and Frontend HTTPS Port values are set for the individual server to which the callback service is deployed, then WebLogic Server uses these values in the server address.
  4. See “Configure HTTP Protocol” in the Administration Console Online Help.

  5. If the callback service is deployed to a cluster, but none of the preceding values are set, but the Cluster Address is set, then WebLogic Server uses this value in the server address.
  6. See “Configure Clusters” in the Administration Console Online Help.

  7. 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.
  8. See “Configure Listen Addresses” in the 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 the Administration Console Online Help.

 


Testing the Web Service

After you have deployed a WebLogic Web Service, you can use the Web Services Test Client, included in the WebLogic Administration Console, to test your service without writing code. You can quickly and easily test any Web Service, including those with complex types and those using advanced features of WebLogic Server such as conversations. The test client automatically maintains a full log of requests allowing you to return to the previous call to view the results.

To test a deployed Web Service using the Administration Console, follow these steps:

  1. Invoke the Administration Console in your browser using the following URL:
  2. 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).
  3. Follow the procedure described in “Test a Web Service” in the Administration Console Online Help.

 


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) Version 5 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 for an Application” in Developing Applications With WebLogic Server and the splitdir/helloWorldEar example installed with WebLogic Server, located in the WL_HOME/samples/server/examples/src/examples directory, where WL_HOME is the top-level directory of your WebLogic Server installation.

  1. In the main project directory, create a directory that will contain the JWS file that implements your Web Service.
  2. For example, if your main project directory is called /src/helloWorldEar, then create a directory called /src/helloWorldEar/helloWebService:

    prompt> mkdir /src/helloWorldEar/helloWebService
  3. Create a directory hierarchy under the helloWebService directory that corresponds to the package name of your JWS file.
  4. 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
  5. 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.)
  6. 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.
  7. 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.

  8. Update the main build target of the build.xml file to call the Web Service-related targets:
  9.   <!-- Builds the entire helloWorldEar application -->
      <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.
  10. 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:
  11. <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>
  12. 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.
  13. 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 your JWS file explicitly implements javax.ejb.SessionBean. 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.


  Back to Top       Previous  Next