|
 |
| e-docs > WebLogic Server > Programming WebLogic Web Services > Web Service Ant Tasks and Command-Line Utilities |
|
Programming WebLogic Web Services
|
Web Service Ant Tasks and Command-Line Utilities
The following sections describe WebLogic Web service Ant tasks and the command-line utilities based on these Ant tasks:
Overview of WebLogic Web Services Ant Tasks and Command-Line Utilities
Ant is a Java-based build tool, similar to the make command but much more powerful. Ant uses XML-based configuration files (called build.xml by default) to execute tasks written in Java.
BEA provides a number of Ant tasks that help you generate important parts of a Web service (such as the serialization class, a client JAR file, and the web-services.xml file) and to package all the pieces of a WebLogic Web service into a deployable EAR file.
The Apache Web site provides other useful Ant tasks for packaging EAR, WAR, and EJB JAR files. For more information, see http://jakarta.apache.org/ant/manual/.
You can also run some of the Ant tasks as a command-line utility, using flags rather than attributes to specify how the utility works. The description of the flags is exactly the same as the description of its corresponding attribute.
Warning: Not all the attributes of the Ant tasks are available as flags to the equivalent command-line utility. See the sections that describe each Ant task for a list of the supported flags when using the command-line equivalent.
For further examples and explanations of using these Ant tasks, see Assembling WebLogic Web Services Using Ant Tasks.
List of Web Services Ant Tasks and Command-Line Utilities
The following table provides an overview of the Web service Ant tasks provided by BEA and the name of the corresponding command-line utility.
Using the Web Services Ant Tasks
To use the Ant tasks, follow these steps:
The following example shows a simple build.xml file (with details of the Web services Ant tasks servicegen and clientgen omitted for clarity):
<project name="buildWebservice" default="build-ear">
<target name="build-ear">
<servicegen attributes go here...>
...
</servicegen>
</target>
<target name="build-client" depends="build-ear">
<clientgen attributes go here .../>
</target>
<target name="clean">
<delete>
<fileset dir="."
includes="example.ear,client.jar" />
</delete>
</target>
</project>
Later sections provide examples of specifying the Ant task in the build.xml file.
On Windows NT, execute the setWLSEnv.cmd command, located in the directory WL_HOME\server\bin, where WL_HOME is the top-level directory of your WebLogic Platform installation.
On UNIX, execute the setWLSEnv.sh command, located in the directory WL_HOME/server/bin, where WL_HOME is the top-level directory of your WebLogic Platform installation.
prompt> ant
Setting the Classpath for the WebLogic Ant Tasks
Each WebLogic Ant task accepts a classpath attribute or element so that you can add new directories or JAR files to your current CLASSPATH environment variable.
The following example shows how to use the classpath attribute of the servicegen Ant task to add to the CLASSPATH variable:
<servicegen destEar="myEJB.ear"
classpath="${java.class.path};d:\my_fab_directory"
...
</servicegen>
The following example shows how to add to the CLASSPATH by using the <classpath> element:
<servicegen ...>
<classpath>
<pathelement path="${java.class.path}" />
<pathelement path="d:\my_fab_directory" />
</classpath>
...
</servicegen>
The following example shows how you can build your CLASSPATH variable outside of the WebLogic Web service Ant task declarations, then specify the variable from within the task using the <classpath> element:
<path id="myid">
<pathelement path="${java.class.path}"/>
<pathelement path="${additional.path1}"/>
<pathelement path="${additional.path2}"/>
</path>
<servicegen ....>
<classpath refid="myid" />
...
</servicegen>
Note: The Java Ant utility included in WebLogic Server uses the ant (UNIX) or ant.bat (Windows) configuration files in the WL_HOME\server\bin directory when setting the ANTCLASSPATH variable, where WL_HOME is the top-level directory of your WebLogic Platform installation If you need to update the ANTCLASSPATH variable, make the relevant changes to the appropriate file for your operating system.
Differences in Operating System Case Sensitivity When Manipulating WSDL and XML Schema Files
Many of the WebLogic Web Service Ant tasks have attributes that you can use to specify an operating system file, such as a WSDL or an XML Schema file. For example, you can use the wsdl attribute of the clientgen Ant task to create the Web Services-specific client JAR file from an existing WSDL file that describes a Web Service.
The Ant tasks process these files in a case-sensitive way. This means that if, for example, the XML Schema file specifies two complex types whose names differ only in their capilatization (for example, MyReturnType and MYRETURNTYPE), the clientgen Ant task correctly generates two separate sets of Java source files for the Java represenation of the complex data type: MyReturnType.java and MYRETURNTYPE.java.
However, compiling these source files into their respective class files might cause a problem if you are running the Ant task on Microsoft Windows, because Windows is a case insensitive operating system. This means that Windows considers the files MyReturnType.java and MYRETURNTYPE.java to have the same name. So when you compile the files on Windows, the second class file overwrites the first, and you end up with only one class file. The Ant tasks, however, expect that two classes were compiled, thus resulting in an error similar to the following:
c:\src\com\bea\order\MyReturnType.java:14:
class MYRETURNTYPE is public, should be declared in a file named MYRETURNTYPE.java
public class MYRETURNTYPE
^
To work around this problem rewrite the XML Schema so that this type of naming conflict does not occur, or if that is not possible, run the Ant task on a case sensitive operating system, such as Unix.
Using the Web Services Command-Line Utilities
To use the command-line utility equivalents of the Ant tasks, follow these steps:
On Windows NT, execute the setWLSEnv.cmd command, located in the directory WL_HOME\server\bin, where WL_HOME is the top-level directory of your WebLogic Platform installation.
On UNIX, execute the setWLSEnv.sh command, located in the directory WL_HOME/server/bin, where WL_HOME is the top-level directory of your WebLogic Platform installation.
prompt> java weblogic.webservice.clientgen \
-ear c:\myapps\myapp.ear \
-serviceName myService \
-packageName myservice.client \
-clientJar c:/myapps/myService_client.jar
The autotype Ant task generates the following components for non-built-in data types that used as parameters or return values of your Web service operation:
For the list of non-built-in data types for which autotype can generate data type components, see Non-Built-In Data Types Supported by servicegen and autotype Ant Tasks.
You can specify one of the following types of input to the autotype Ant task:
Use the destDir attribute to specify the name of a directory that contains the generated components. The generated XML Schema and data type mapping information are generated in a file called types.xml. You can use this file to manually update an existing web-services.xml file with non-built-in data type mapping information, or use it in conjunction with the typeMappingFile attribute of the servicegen or clientgen Ant tasks, or the typesInfo attribute of the source2wsdd Ant task.
Warning: The serializer class and Java and XML representations generated by the autotype, servicegen, and clientgen Ant tasks cannot be round-tripped. For more information, see Non-Roundtripping of Generated Data Type Components.
Note: The fully qualified name for the autotype Ant task is weblogic.ant.taskdefs.webservices.javaschema.JavaSchema.
The following example shows how to create non-built-in data type components for the Java class mypackage.MyType:
<autotype javaTypes="mypackage.MyType"
targetNamespace="http://www.foobar.com/autotyper"
packageName="a.package.name"
destDir="d:\output" />
The following example is similar to the preceding one, except it creates non-built-in data type components for an array of mypackage.MyType Java data types:
<autotype javaTypes="[Lmypackage.MyType;"
targetNamespace="http://www.foobar.com/autotyper"
packageName="a.package.name"
destDir="d:\output" />
Note: The [Lclassname; syntax follows the Java class naming conventions as outlined in the java.lang.Class.getName() method documentation.
The following example shows how to use the autotype Ant task against a WSDL file:
<autotype wsdl="file:\wsdls\myWSDL"
targetNamespace="http://www.foobar.com/autotyper"
packageName="a.package.name"
destDir="d:\output" />
The following table describes the attributes of the autotype Ant task.
|
Name of a file that contains the XML Schema representation of your non-built-in data types. |
You must specify one, and only one, of the following attributes: schemaFile, wsdl, javaTypes, or javaComponents. |
|
|
Full path name or URI of the WSDL that contains the XML Schema description of your non-built-in data type. |
You must specify one, and only one, of the following attributes: schemaFile, wsdl, javaTypes, or javaComponents. |
|
|
Comma-separated list of Java class names that represent your non-built-in data types. The Java classes must be compiled and in your CLASSPATH. javaTypes="my.class1,my.class2" Note: Use the syntax [Lclassname; to specify an array of the Java data type. For an example, see Example. |
You must specify one, and only one, of the following attributes: schemaFile, wsdl, javaTypes, or javaComponents. |
|
|
Comma-separated list of Java class names that implement the Web service operation. The Java classes must be compiled and in your CLASSPATH. javaComponents="my.class1,my.class2" The autotype Ant task introspects the Java classes to automatically generate the components for all non-built-in data types it finds. |
You must specify one, and only one, of the following attributes: schemaFile, wsdl, javaTypes, or javaComponents. |
|
|
Full pathname of the directory that will contain the generated components. The generated XML Schema and data type mapping information are generated in a file called types.xml. |
||
|
File that contains data type mapping information for non-built-in data types for which have already generated needed components. The format of the information is the same as the data type mapping information in the <type-mapping> element of the web-services.xml file. The autotype Ant task does not generate non-built-in data type components for any data types listed in this file. |
||
|
Base package name of the generated Java classes for any non-built-in data types used as a return value or parameter in a Web service. This means that each generated Java class will be part of the same package name, although the autotype Ant task generates its own specific name for each Java class which it appends to the specified package base name. If you do not specify this attribute, the autotype Ant task generates a base package name for you. Note: BEA recommends you not use this attribute, but rather, specify the full package name using the packageName attribute. The packageBase attribute is available for JAX-RPC compliance. |
If you specify this attribute, you cannot also specify packageName. |
|
|
Full package name of the generated Java classes for any non-built-in data types used as a return value or parameter in a Web service. If you do not specify this attribute, the autotype Ant task generates a package name for you. Note: Although not required, BEA recommends you specify this attribute in most cases.
|
If you specify this attribute, you cannot also specify packageBase. |
|
The clientgen Ant task generates a Web service-specific client JAR file that client applications can use to invoke both WebLogic and non-WebLogic Web services. Typically, you use the clientgen Ant task to generate a client JAR file from an existing WSDL file; you can also use it with an EAR file that contains the implementation of a WebLogic Web service.
The contents of the client JAR file includes:
You can use the clientgen Ant task to generate a client JAR file from the WSDL file of an existing Web service (not necessarily running on WebLogic Server) or from an EAR file that contains a Weblogic Web service implementation.
The WebLogic Server distribution includes a client runtime JAR file that contains the client side classes needed to support the WebLogic Web services runtime component. For more information, see Getting the Java Client JAR Files.
Warning: The serializer class and Java and XML representations generated by the autotype, servicegen, and clientgen Ant tasks cannot be round-tripped. For more information, see Non-Roundtripping of Generated Data Type Components.
Warning: The clientgen Ant task does not support solicit-response or notification WSDL operations. This means that if you attempt to create a client JAR file from a WSDL file that contains these types of operations, the Ant task ignores the operations.
Note: The fully qualified name of the clientgen Ant task is weblogic.ant.taskdefs.webservices.clientgen.ClientGenTask.
<clientgen wsdl="http://example.com/myapp/myservice.wsdl"
packageName="myapp.myservice.client"
clientJar="c:/myapps/myService_client.jar"
/>
The following table describes the attributes of the clientgen Ant task.
|
Full path name or URL of the WSDL that describes a Web service (either WebLogic or non-WebLogic) for which a client JAR file should be generated. The generated stub factory classes in the client JAR file use the value of this attribute in the default constructor. |
||
|
Name of an EAR file or exploded directory that contains the WebLogic Web service implementation for which a client JAR file should be generated. Note: If the saveWSDL attribute of clientgen is set to True (the default value), the clientgen Ant task generates a WSDL file from the information in the EAR file, and stores it in the generated client JAR file. Because clientgen does not know the host name or port number of the WebLogic Server instance which will host the Web service, clientgen uses the following endpoint address in the generated WSDL: http://localhost:7001/contextURI/serviceURI
|
||
|
You can specify this attribute only in combination with the ear attribute. |
||
|
Web service name for which a corresponding client JAR file should be generated. If you specify the wsdl attribute, the Web service name corresponds to the <service> elements in the WSDL file. If you specify the ear attribute, the Web service name corresponds to the <web-service> element in the web-services.xml deployment descriptor file. If you do not specify the serviceName attribute, the clientgen task generates client classes for the first service name found in the WSDL or web-services.xml file. |
||
|
File that contains data type mapping information, used by the clientgen task when generating the JAX-RPC stubs. The format of the information is the same as the data type mapping information in the <type-mapping> element of the web-services.xml file. If you specified the ear attribute, the information in this file overrides the data type mapping information found in the web-services.xml file. |
||
|
Package name into which the generated JAX-RPC client interfaces and stub files should be packaged. |
||
|
Specifies whether the clientgen task should generate and include in the client JAR file the serialization class for any non-built-in data types used as parameters or return values to the Web service operations. |
||
|
Name of a JAR file or exploded directory into which the clientgen task puts the generated client interface classes, stub classes, optional serialization class, and so on. To create or update a JAR file, use a.jar suffix when specifying the JAR file, such as myclientjar.jar. If the attribute value does not have a.jar suffix, then the clientgen task assumes you are referring to a directory name. If you specify a JAR file or directory that does not exist, the clientgen task creates a new JAR file or directory. |
||
|
Specifies where the clientgen task gets the implementation of any non-built-in Java data types used in a Web service: either the task generates the Java code or the task gets it from the EAR file that contains the full implementation of the Web service. Valid values are True (use the Java code in the EAR file) and False. Default value is False. For the list of non-built-in data types for which clientgen can generate data type components, see Non-Built-In Data Types Supported by servicegen and autotype Ant Tasks. |
||
|
When set to True, specifies that the WSDL of the Web service be saved in the generated client JAR file. This means that client applications do not need to download the WSDL every time they create a stub to the Web service, possibly improving performance of the client because of reduced network usage. |
||
|
Specifies whether the clientgen Ant task should create a J2ME/CDC-compliant client JAR file. |
||
|
When set to true, specifies that the method names in the generated stubs have a lower-case first character. Otherwise, all method names will the same as the operation names in the WSDL file. |
||
|
Specifies the full package name of the generated Java class for any non-built-in data types used as a return value or parameter in a Web service. If you specify this attribute, you cannot also specify typePackageBase. If you do not specify this attribute and the XML Schema in the WSDL file defines a target namespace, then the clientgen Ant task generates a package name for you based on the target namespace. This means that if your XML Schema does not define a target namespace, then you must specify either the typePackageName (preferred) or typePackageBase attributes of the clientgen Ant task. Note: Although not required, BEA recommends you specify this attribute. |
Required only if you specified the wsdl attribute and the XML Schema in the WSDL file does not define a target namespace. |
|
|
Specifies the base package name of the generated Java class for any non-built-in data types used as a return value or parameter in a Web service. This means that each generated Java class will be part of the same package name, although the clientgen Ant task generates its own specific name for each Java class which it appends to the specified package base name. If you specify this attribute, you cannot also specify typePackageName. If you do not specify this attribute and the XML Schema in the WSDL file defines a target namespace, then the clientgen Ant task generates a package name for you based on the target namespace. This means that if your XML Schema does not define a target namespace, then you must specify either the typePackageName (preferred) or typePackageBase attributes of the clientgen Ant task. Note: Rather than using this attribute, BEA recommends that you specify the full package name with the typePackageName attribute. The typePackageBase attribute is available for JAX-RPC compliance. |
Required only if you specified the wsdl attribute and the XML Schema in the WSDL file does not define a target namespace. |
|
|
Specifies where the clientgen Ant task should get the names of the operations when generating a client from a WSDL file. If this value is set to true, then operations take the name specified by the name attribute of the <port> element in the WSDL file (where <port> is the child element of the <service> element). If usePortNameAsMethodName is set to false, then operations take the name specified by the name attribute of the <portType> element in the WSDL file (where <portType> is the child element of the <definitions> element). |
Equivalent Command-Line Utility
The equivalent command-line utility of the clientgen Ant task is called weblogic.webservice.clientgen. The description of the flags of the utility is the same as the description of the Ant task attributes, described in the preceding section.
The weblogic.webservice.clientgen utility supports the following flags (see the equivalent attribute for a description of the flag):
The servicegen Ant task takes as input an EJB JAR file or list of Java classes, and creates all the needed Web service components and packages them into a deployable EAR file.
In particular, the servicegen Ant task:
Warning: The serializer class and Java and XML representations generated by the autotype, servicegen, and clientgen Ant tasks cannot be round-tripped. For more information, see Non-Roundtripping of Generated Data Type Components.
Note: The fully qualified name of the servicegen Ant task is weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask.
<servicegen
destEar="c:\myWebService.ear"
warName="myWAR.war"
contextURI="web_services" >
<service
ejbJar="c:\myEJB.jar"
targetNamespace="http://www.bea.com/examples/Trader"
serviceName="TraderService"
serviceURI="/TraderService"
generateTypes="True"
expandMethods="True" >
</service>
</servicegen>
The servicegen Ant task has four attributes and one child element (<service>) for each Web service you want to define in a single EAR file. You must specify at least one <service> element.
The <service> element has one optional <client> element.
The following graphic describes the hierarchy of the servicegen Ant task.
The servicegen Ant task is the main task for automatically generating and assembling all the parts of a Web service and packaging it into a deployable EAR file.
The following table describes the attributes of the servicegen Ant task.
The <service> element describes a single Web service implemented with either a stateless session EJB or a Java class.
The following table describes the attributes of the <service> element of the servicegen Ant task. Include one <service> element for every Web service you want to package in a single EAR file.
|
JAR file or exploded directory that contains the EJBs that implement the backend component of a Web service operation. The servicegen Ant task introspects the EJBs to automatically generate all the components. |
You must specify either the ejbJar, javaClassComponents, or JMS* attribute. |
|
|
Comma-separated list of Java class names that implement the Web service operation. The Java classes must be compiled and in your CLASSPATH. javaClassComponents="my.FirstClass,my.SecondClass" Note: Do not include the .class extension when specifying the class names. The servicegen Ant task introspects the Java classes to automatically generate all the needed components. |
You must specify either the ejbJar, javaClassComponents, or JMS* attribute. |
|
|
Specifies that the Web Service ignore the Authorization HTTP header in the SOAP request. Note: Be careful using this attribute. If you set the value of this attribute to True, WebLogic Server never authenticates a client application that is attempting to invoke a Web Service, even if access control security constraints have been defined for the EJB, Web Application, or Enterprise Application that make up the Web Service. Or in other words, a client application that does not provide athentication credentials is still allowed to invoke a Web Service that has security constraints defined on it. |
||
|
Comma-separated list of EJB names for which non-built-in data type components should be generated. If you specify this attribute, the servicegen task processes only those EJBs on the list. The EJB names correspond to the <ejb-name> element in the ejb-jar.xml deployment descriptor in the EJB JAR file (specified with the ejbJar attribute). |
||
|
Comma-separated list of EJB names for which non-built-in data type components should not be generated. If you specify this attribute, the servicegen task processes all EJBs except those on the list. The EJB names correspond to the <ejb-name> element in the ejb-jar.xml deployment descriptor in the EJB JAR file (specified with the ejbJar attribute). |
||
|
Name of the Web service which will be published in the WSDL. Note: If you specify more than one <service> element in your build.xml file that calls servicegen, and set the serviceName attribute for each element to the same value, servicegen attempts to merge the multiple <service> elements into a single Web service. |
||
|
Web service URI portion of the URL used by client applications to invoke the Web service. Note: Be sure to specify the leading "/", such as /TraderService. The full URL to invoke the Web service will be: |
||
|
Specifies whether the servicegen task, when generating the web-services.xml file, should create a separate <operation> element for each method of the EJB or Java class, or whether the task should implicitly refer to all methods by specifying only one <operation> element that contains a method="*" attribute. |
||
|
Specifies whether the servicegen task should generate the serialization class and Java representations for non-built-in data types used as parameters or return values. Valid values are True and False. Default value is True. For the list of non-built-in data types for which servicegen can generate data type components, see Non-Built-In Data Types Supported by servicegen and autotype Ant Tasks. |
||
|
File that contains additional XML data type mapping information. The format of the information is the same as the data type mapping information in a web-services.xml. Use this attribute if you want to include extra XML data type information in the <type-mapping> element of the web-services.xml file, in addition to the required XML descriptions of data types used by the EJB or Java class that implements an operation. The servicegen task adds the extra information in the specified file to a generated web-services.xml file. |
||
|
Specifies whether the servicegen Ant task should generate RPC-oriented or document-oriented Web service operations. RPC-oriented WebLogic Web service operations use SOAP encoding. Document-oriented WebLogic Web service operations use literal encoding. If you specify document for this attribute, the methods that implement the operations of the generated Web service must have only one parameter. If servicegen encounters methods that have more than one parameter, servicegen ignores the method and does not generate a corresponding Web service operation for it. Valid values for this attribute are rpc and document. Default value is rpc. Note: Because the style attribute applies to an entire Web service, all operations in a single WebLogic Web service must be either RPC-oriented or documented-oriented; WebLogic Server does not support mixing the two styles within the same Web service. |
||
|
Specifies whether the client application that invokes this JMS-implemented Web service sends or receives messages to or from the JMS destination. Valid values are send or receive. Specify send if the client sends messages to the JMS destination and receive if the client receives messages from the JMS destination. |
||
|
JNDI name of the ConnectionFactory used to create a connection to the JMS destination. |
||
|
Name of the operation in the generated WSDL file. Default value is either send or receive, depending on the value of the JMSAction attribute. |
||
|
Data type of the single parameter to the send or receive operation. Default value is java.lang.String. If you use this attribute to specify a non-built-in data type, and set the generateTypes attribute to True, be sure the Java represenation of this non-built-in data type is in your CLASSPATH. |
The optional <client> element describes how to create the client JAR file that client applications use to invoke the Web service. Specify this element only if you want the servicegen Ant task to create a client JAR file.
Note: You do not have to create the client JAR file when you assemble your Web service. You can later use the clientgen Ant task to generate the JAR file.
The following table describes the attributes of the <client> element.
|
Name of the generated client JAR file. When the servicegen task packages the Web service, it puts the client JAR file in the top-level directory of the Web service WAR file of the EAR file. Default name is serviceName_client.jar, where serviceName refers to the name of the Web service (the serviceName attribute) Note: If you want a link to the client JAR file to automatically appear in the Web service Home Page, you should not change its default name. |
||
|
Package name into which the generated client interfaces and stub files are packaged. |
||
|
Specifies where the servicegen task gets the implementation of any non-built-in Java data types used in a Web service: either the task generates the Java code or the task gets it from the EAR file that contains the full implementation of the Web service. Valid values are True (use the Java code in the EAR file) and False. Default value is False. For the list of non-built-in data types for which servicegen can generate data type components, see Non-Built-In Data Types Supported by servicegen and autotype Ant Tasks. |
||
|
When set to True, saves the WSDL file of the Web service in the generated client JAR file. This means that client applications do not need to download the WSDL file every time they create a stub to the Web service, possibly improving performance of the client because of reduced network usage. |
Equivalent Command-Line Utility
The equivalent command-line utility of the servicegen Ant task is called weblogic.webservice.servicegen. The description of the flags of the utility is the same as the description of the Ant task attributes, described in the preceding sections.
Warning: If you use the weblogic.webservice.servicegen command-line utility to automatically assemble a Web service, you can create only one Web service in the web-services.xml file.
The weblogic.webservice.servicegen utility supports the following flags (see the equivalent attribute for a description of the flag):
The source2wsdd Ant task generates a web-services.xml deployment descriptor file from the Java source file for a Java class-implemented WebLogic Web service.
The source2wsdd Ant task does not generate data type mapping information for any non-built-in data types used as parameters or return values of the methods of your Java class If your Java class uses non-built-in data types, you must first run the autotype Ant task to generate the needed components, then point the typesInfo attribute of the source2wsdd Ant task to the types.xml file generated by the autotype Ant task.
If your Java class refers to other Java class files, be sure to set the sourcePath attribute to the directory that contains them.
Note: The fully qualified name of the source2wsdd Ant task is weblogic.ant.taskdefs.webservices.autotype.JavaSource2DD.
<source2wsdd
javaSource="c:\source\MyService.java"
typesInfo="c:\autotype\types.xml"
ddFile="c:\ddfiles\web-services.xml"
serviceURI="/MyService"
/>
The following table describes the attributes of the source2wsdd Ant task.
The wsdl2Service Ant task takes as input an existing WSDL file, and generates the following WebLogic Web service components:
The Java source file contains a template for the full Java class-implemented WebLogic Web service. The template includes full method signatures that correspond to the operations in the WSDL file. You write the actual code for these methods so that they function as you want.
The wsdl2Service Ant task generates a partial implementation for only one service in a WSDL file (specified by the <service> element.) Use the serviceName attribute to specify a particular service; if you do not specify this attribute, the wsdl2Service Ant task generates a partial implementation for the first <service> element in the WSDL.
The wsdl2Service Ant task does not generate data type mapping information for any non-built-in data types used as parameters or return values of the operations in the WSDL file. If the WSDL uses non-built-in data types, you must first run the autotype Ant task to generate the data type mapping information, then point the typeMappingFile attribute of the wsdl2Service Ant task to the types.xml file generated by the autotype Ant task.
Note: The fully qualified name of the wsdl2Service Ant task is weblogic.ant.taskdefs.webservices.wsdl2service.WSDL2Service.
<wsdl2service
wsdl="c:\wsdls\myService.wsdl"
destDir="c:\myService\implementation"
typeMappingFile="c:\autotype\types.xml"
packageName="example.ws2j.service"
/>
The following table describes the attributes of the wsdl2Service Ant task.
The wspackage Ant task packages the various components of a WebLogic Web service into a deployable EAR file. It is assumed that you have already generated these components, which can include:
Typically you use other Ant tasks, such as clientgen, autotype, source2wsdd, and wsdl2Service, to generate the preceding components.
Note: The fully qualified name of the wspackage Ant task is weblogic.ant.taskdefs.webservices.wspackage.WSPackage.
<wspackage
output="c:\myWebService.ear"
contextURI="web_services"
codecDir="c:\autotype"
webAppClasses="example.ws2j.service.SimpleTest"
ddFile="c:\ddfiles\web-services.xml"
/>
The following table describes the attributes of the wspackage Ant task.
The wsgen Ant task upgrades a Version 6.1 WebLogic Web service to Version 7.0. In particular, it:
The task takes as input the same build.xml file you used in Version 6.1 to create a Web service. You can optionally add two new attributes, as described in "Additional Attributes" on page B-37. The task also takes as input the same archive file or exploded directory that you used to create the 6.1 Web service.
Warning: Do not use this Ant task for assembling a new 7.0 Web service. Instead, use the servicegen Ant task. Because the wsgen Ant task is used only for upgrading Web services from Version 6.1 to 7.0, the task is deprecated in this version of WebLogic Server.
Note: The fully qualified name of the wsgen Ant task is weblogic.ant.taskdefs.webservices.wsgen.WSGenTask.
The following build.xml excerpt is taken from the 6.1 RPC-style Web services example. It includes a new attribute targetNameSpace.
<wsgen
destpath="weather.ear"
context="/weather">
<rpcservices path="weather.jar">
<rpcservice bean="statelessSession"
uri="/weatheruri"
targetNameSpace="http://www.bea.com/examples"/>
</rpcservices>
</wsgen>
Because you use the 6.1 build.xml file when using wsgen to upgrade your 6.1 Web service to Version 7.0, the attributes and elements of the build.xml file are those documented in the 6.1 version of the Programming WebLogic Web Services guide. For details, see build.xml Attributes and Elements.
You can, however, add the two attributes listed in the following table to your 6.1 build.xml file and wsgen will add the appropriate information to the new web-services.xml deployment descriptor file.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
