The following sections describe the iterative development process for WebLogic Web Services:
WARNING: | Although both JAX-RPC 1.1 and JAX-WS 2.0 are supported in this release of WebLogic Server, this document concentrates almost exclusively on describing how to create JAX-RPC style Web Services. This is because, in this release, all the WS-* specifications (such as WS-Security and WS-ReliableMessaging) and WebLogic value-added features (such as asynchronous request-response and callbacks) work only with JAX-RPC style Web Services. Therefore, unless otherwise stated, you should assume that all descriptions and examples are for JAX-RPC Web Services. |
Note: | For specific information about creating JAX-WS Web Services, see Implementing a JAX-WS 2.0 Web Service. |
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 both the standard annotations defined by the Web Services Metadata for the Java Platform specification (JSR-181), as well as additional WebLogic-specific ones. For additional detailed information about this programming model, see “Anatomy of a WebLogic Web Service” on page 2-3.
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.
After you have created a WebLogic Server domain, you can use the Configuration Wizard to update the domain, using a Web Services-specific extension template, so that the resources required by certain WebLogic Web Services features are automatically configured. Although use of this extension template is not required, it makes the configuration of JMS and JDBC resources much easier.
The Web Services extension template automatically configures the resources required for the following features:
To update your domain so that it is automatically configured for these Web Services features:
WL_HOME
/common/templates/applications/wls_webservice.jar
where WL_HOME
refers to the main WebLogic Server directory, such as /bea_home/wlserver_10.0
.
For detailed instructions about using the Configuration Wizard to create and update WebLogic Server domains, see Creating WebLogic Domains Using the Configuration Wizard.
This section describes the general procedure for iteratively developing WebLogic Web Services starting from Java, if effect, coding the JWS file from scratch and later generating the WSDL file that describes the service. See Chapter 3, “Common Web Services Use Cases and Examples,” for specific examples of this process. The following procedure is just a recommendation; if you have already set up your own development environment, you can use this procedure as a guide for updating your existing environment to develop WebLogic Web Services.
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” on page 4-21 for details.
To iteratively develop a WebLogic Web Service starting from Java, follow these steps:
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 BEA products and domainName
is the name of your domain.build.xml
file. You can name this directory anything you want.See Chapter 5, “Programming the JWS File.”
See “Programming the User-Defined Java Data Type” on page 5-19.
build.xml
. See “Creating the Basic Ant build.xml File” on page 4-7.
jwsc
Ant task against the JWS file to generate 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” on page 4-7.
See “Deploying and Undeploying WebLogic Web Services” on page 4-15.
See “Browsing to the WSDL of the Web Service” on page 4-17.
See “Testing the Web Service” on page 4-20.
jwsc
Ant task.See Chapter 7, “Invoking Web Services,” for information on writing client applications that invoke a Web Service.
This section describes the general procedure for iteratively developing WebLogic Web Services based on an existing WSDL file. See Chapter 3, “Common Web Services Use Cases and Examples,” for a specific example of this process. The procedure is just a recommendation; if you have already set up your own development environment, you can use this procedure as a guide for updating your existing environment to develop WebLogic Web Services.
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” on page 4-21 for details.
It is assumed in this procedure that you already have an existing WSDL file.
To iteratively develop a WebLogic Web Service starting from WSDL, follow these steps.
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 BEA products and domainName
is the name of your domain.build.xml
file. You can name this directory anything you want.build.xml
. See “Creating the Basic Ant build.xml File” on page 4-7.
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.wsdlc
Ant task against the WSDL file to generate the JWS interface, 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” on page 4-11.
wsdlc
Ant task, adding the business code to make the Web Service work as you want. See “Updating the Stubbed-Out JWS Implementation Class File Generated By wsdlc” on page 4-13.
jwsc
Ant task, specifying 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” on page 4-7.
See “Deploying and Undeploying WebLogic Web Services” on page 4-15.
The URL used to invoke the WSDL of the deployed Web Service is essentially the same as the value of the location
attribute of the <address>
element in the original WSDL (except for the host and port values which now correspond to the host and port of the WebLogic Server instance to which you deployed the service.) This is because the wsdlc
Ant task generated values for the contextPath
and serviceURI
of the @WLHttpTransport
annotation in the JWS implementation file so that together they create the same URI as the endpoint address specified in the original WSDL.
See either the original WSDL or “Browsing to the WSDL of the Web Service” on page 4-17 for information about invoking the deployed WSDL.
See “Testing the Web Service” on page 4-20.
jwsc
Ant task.See Chapter 7, “Invoking Web Services,” for information on writing client applications that invoke a Web Service.
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 -->
</target>
</project>
The jwsc
Ant task takes as input a JWS file that contains both standard (JSR-181) and WebLogic-specific 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:
webservices.xml
and JAX-RPC mapping files, the jwsc
Ant task also generates the WebLogic-specific Web Services deployment descriptor (weblogic-wesbservices.xml
), the web.xml
and weblogic.xml
files for Java class-implemented Web Services and the ejb-jar.xml
and weblogic-ejb-jar.xml
files for EJB-implemented Web Services.
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" />
</jwsc>
</target>
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
Ant task that contains the JWS interface file 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 “Iterative Development of WebLogic Web Services Starting From a WSDL File: Main Steps” on page 4-5. |
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 for more information.
The following build.xml
excerpt shows an 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" />
</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
.
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" />
</jwsc>
</target>
In the preceding example, the TemperaturePortTypeImpl.java
file is the stubbed-out JWS file that you previously updated to include the business logic to make your service work as you want. 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
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:
@WLXXXTransport
annotations.
See
“jwsc” on page A-17 for complete documentation and examples about the jwsc
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 interface file 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
" />
</target>
WSDL_file
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 interface 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 sub-directory hierarchy corresponding to its package name.
The name of the generated JWS file is PortType
Impl.java
, where PortType
refers to the name
attribute of the <portType>
element in the WSDL file for which you are generating a Web Service. For example, if the port type name is MyServicePortType
, then the JWS implementation file is called MyServicePortTypeImpl.java
.
Package_name
refers to the package into which the generated JWS interface 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.
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 also generate the stubbed-out JWS file to make your programming easier. BEA also 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" />
</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 interface 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 port type name in the WSDL file is TemperaturePortType
, then the name of the JWS implementation file is TemperaturePortTypeImpl.java
.
To actually run this task, type the following at the command line:
prompt> ant generate-from-wsdl
See
“wsdlc” on page A-52 for additional attributes of the wsdlc
Ant task.
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 PortType
Impl.java
, where 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 in the methods that implement the operations.
The JWS class implements the JWS Web Service endpoint interface that corresponds to the WSDL file; the JWS interface 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
and @WLHttpTransport
annotations in the JWS implementation class; the values of the attributes correspond to equivalent values 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; the contextPath
and serviceUri
attributes of @WLHttpTransport
together make up the endpoint address specified by the location
attribute of the <address>
element in the WSDL.
When you update the JWS file, you add Java code to the methods so that the corresponding Web Service operations works as you want. Typically, the generated JWS file contains comments where you should add code, such as:
//replace with your impl here
You can also add additional JWS annotations to the file, with the following restrictions:
javax.jws.*
package) you can include in the JWS implementation file are @WebService
, @HandlerChain
, @SOAPMessageHandler
, and @SOAPMessageHandlers
. If you specify any other standard JWS annotations, the jwsc
Ant task returns error when you try to compile the JWS file into a Web Service.serviceName
and endpointInterface
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 interface generated by the wsdlc
Ant task.
After you have updated the JWS file, BEA recommends that you move it to an official source location, rather than leaving it in the wsdlc
output location.
The following example shows the wsdlc
-generated JWS implementation file from the WSDL shown in
“Sample WSDL File” on page 3-19; 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;
import weblogic.jws.*;
/**
* TemperaturePortTypeImpl class implements web service endpoint interface
* TemperaturePortType */
@WebService(
serviceName="TemperatureService",
endpointInterface="examples.webservices.wsdlc.TemperaturePortType")
@WLHttpTransport(
contextPath="temp",
serviceUri="TemperatureService",
portName="TemperaturePort")
public class TemperaturePortTypeImpl implements TemperaturePortType {
public TemperaturePortTypeImpl() {
}
public float getTemp(java.lang.String zipcode)
{
//replace with your impl here
return 0;
}
}
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 WebLogic Server Applications.
This guide, because of its development nature, discusses just two ways of deploying Web Services:
The easiest way to quickly deploy a Web Service as part of the iterative development process is to add a target that executes the wldeploy
WebLogic Ant task to your 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>
jwsc
Ant task generates an exploded Enterprise Application directory.t3://localhost:7001
.
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.
To use the Administration Console to deploy the Web Service, first invoke it in your browser using the following URL:
http://[host]:[port]/console
Then use the deployment assistants to help you deploy the Enterprise application. For more information on the Administration Console, see the Online Help.
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
7001
).contextPath
attribute of the @WLHttpTransport
annotation, the <WLHttpTransport>
, <module>
, or<jws>
element of jwsc
) and certain methods take precedence over others. See
“How to Determine the Final Context Root of a WebLogic Web Service” on page A-19 for a complete explanation.serviceUri
attribute of the @WLHttpTransport
JWS annotation of the JWS file that implements your Web Service or <WLHttpTransport>
child element of the jwsc Ant task; the second takes precedence over the first.
For example, assume you used the following @WLHttpTransport
annotation in the JWS file that implements your Web Service
...
@WLHttpTransport(contextPath="complex",
serviceUri="ComplexService",
portName="ComplexServicePort")
/**
* This JWS file forms the basis of a WebLogic Web Service.
*
*/
public class ComplexServiceImpl {
...
Further assume that you do not override the contextPath
or serviceURI
values by setting equivalent attributes for the <WLHttpTransport>
element of the jwsc
Ant task. 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
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 WL
XXX
Transport
annotations or jwsc
elements, as described in
“Browsing to the WSDL of the Web Service” on page 4-17. 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
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. See Configure HTTP Settings for a Cluster.
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.Web Service is not a callback service and can be invoked using JMS Transport
Cluster Address
is set, then WebLogic Server uses this value in the server address of the dynamic WSDL.Listen Address
of the server to which the Web Service is deployed is set, then WebLogic Server uses this value in the server address.Web Service is a callback service
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. See Configure HTTP Settings for a Cluster.
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.Cluster Address
is set, then WebLogic Server uses this value in the server address.Listen Address
of the server to which the callback service is deployed is set, then WebLogic Server uses this value in the server address.Web Service is invoked using a proxy server.
Although not required, BEA 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.
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 previous call to view the results.
To test a deployed Web Service using the Administration Console, follow these steps:
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 already 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 and the splitdir/helloWorldEar
example installed with WebLogic Server, located in the BEA_HOME
/wlserver_10.0/samples/server/examples/src/examples
directory, where BEA_HOME
refers to the main installation directory for BEA products, such as c:/bea
.
For example, if your main project directory is called /src/helloWorldEar
, then create a directory called /src/helloWorldEar/helloWebService
:
prompt> mkdir /src/helloWorldEar/helloWebService
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
/src/helloWorldEar/helloWebService/examples/splitdir/hello
in this example.) 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” on page 4-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" />
</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.
build.xml
file to call the Web Service-related targets:<!-- Builds the entire helloWorldEar application -->
<target name="build"
description="Compiles helloWorldEar application and runs appc"
depends="build-helloWebService,compile,appc" />
WARNING: | 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. |
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>
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>
Caution: | 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” on page 4-17.