![]() ![]() ![]() ![]() ![]() ![]() |
The following sections describe how to invoke WebLogic Web Services:
Note: | The following sections do not include information about invoking message-secured Web Services; for that topic, see the Web Services security guide, in particular Updating a Client Application to Invoke a Message-Secured Web Service. |
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 and invoking JAX-WS Web Services, see Implementing a JAX-WS 2.0 Web Service. |
Invoking a Web Service refers to the actions that a client application performs to use the Web Service. Client applications that invoke Web Services can be written using any technology: Java, Microsoft .NET, and so on.
Note: | In this context, a client application can be two types of clients: One is a stand-alone client that uses the WebLogic client classes to invoke a Web Service hosted on WebLogic Server or on other application servers. In this document, a stand-alone client is a client that has a runtime environment independent of WebLogic Server. The other type of client application that invokes a Web Service runs inside a Java Platform, Enterprise Edition (Java EE) Version 5 component deployed to WebLogic Server, such as an EJB or another Web Service. |
The sections that follow describe how to use BEA’s implementation of the JAX-RPC specification (Version 1.1) to invoke a Web Service from a Java client application. You can use this implementation to invoke Web Services running on any application server, both WebLogic and non-WebLogic. In addition, you can create a stand-alone client application or one that runs as part of a WebLogic Server.
WARNING: | You cannot use a dynamic client to invoke a Web Service operation that implements user-defined data types as parameters or return values. A dynamic client uses the JAX-RPC Call interface. Standard (static) clients use the Service and Stub JAX-RPC interfaces, which correctly invoke Web Services that implement user-defined data types. |
This section describes two different types of client applications:
Main
public class that you invoke with the java
command. It runs completely separately from WebLogic Server.The Java API for XML based RPC (JAX-RPC) is a Sun Microsystems specification that defines the APIs used to invoke a Web Service. WebLogic Server implements the JAX-RPC 1.1 specification.
The following table briefly describes the core JAX-RPC interfaces and classes.
For detailed information on JAX-RPC, see http://java.sun.com/xml/jaxrpc/index.html.
The clientgen
WebLogic Web Services Ant task generates, from an existing WSDL file, the client artifacts that client applications use to invoke both WebLogic and non-WebLogic Web Services. These artifacts include:
Stub
and Service
interface implementations for the particular Web Service you want to invoke.
For additional information about the clientgen
Ant task, such as all the available attributes, see
Ant Task Reference.
WARNING: | The fully qualified name of the clientgen Ant task supported in this release of WebLogic Server is weblogic.wsee.tools.anttasks.ClientGenTask . This is different from the clientgen Ant task supported in version 8.1 of WebLogic Server, which is weblogic.webservice.clientgen . |
WARNING: | Although the 8.1 clientgen Ant task is still provided in this release of WebLogic Server, it is deprecated. If you want to generate the client artifacts to invoke a 9.X WebLogic Web Service, be sure you use the 9.X version of clientgen and not the 8.1 version. For example, if you have upgraded an 8.1 Web Service to 10.0, but your Ant scripts explicitly call the 8.1 clientgen Ant task by specifying its fully qualified name, then you must update your Ant scripts to call the 9.X clientgen instead. |
WebLogic Server includes examples of creating and invoking WebLogic Web Services in the WL_HOME/samples/server/examples/src/examples/webservices
directory, where WL_HOME
refers to the main WebLogic Server directory.
For detailed instructions on how to build and run the examples, open the WL_HOME
/samples/server/docs/index.html
Web page in your browser and expand the WebLogic Server Examples->Examples->API->Web Services node.
In the following procedure it is assumed that you use Ant in your development environment to build your client application, compile Java files, and so on, and that you have an existing build.xml
file that you want to update with Web Services client tasks.
For general information about using Ant in your development environment, see Creating the Basic Ant build.xml File. For a full example of a build.xml
file used in this section, see Sample Ant Build File for a Stand-Alone Java Client.
To create a Java stand-alone client application that invokes a Web Service:
On Windows NT, execute the setDomainEnv.cmd
command, located in 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.
On UNIX, execute the setDomainEnv.sh
command, located in 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 to execute the clientgen
Ant task to generate the needed client-side artifacts to invoke a Web Service.See Using the clientgen Ant Task To Generate Client Artifacts.
See Getting Information About a Web Service.
See Writing the Java Client Application Code to Invoke a Web Service.
Update your build.xml
file, adding a call to the clientgen
Ant task, as shown in the following example:
<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<target name="build-client">
<clientgen
wsdl="http://${wls.hostname}:${wls.port}/complex/ComplexService?WSDL"
destDir="clientclasses"
packageName="examples.webservices.simple_client"/>
</target>
Before you can execute the clientgen
WebLogic Web Service Ant task, you must specify its full Java classname using the standard taskdef
Ant task.
You must include the wsdl
and destDir
attributes of the clientgen
Ant task to specify the WSDL file from which you want to create client-side artifacts and the directory into which these artifacts should be generated. The packageName
attribute is optional; if you do not specify it, the clientgen task uses a package name based on the targetNamespace
of the WSDL.
Note: | The clientgen Ant task also provides the destFile attribute if you want the Ant task to automatically compile the generated Java code and package all artifacts into a JAR file. For details and an example, see
clientgen. |
If the WSDL file specifies that user-defined data types are used as input parameters or return values of Web Service operations, clientgen
automatically generates a JavaBean class that is the Java representation of the XML Schema data type defined in the WSDL. The JavaBean classes are generated into the destDir
directory.
Note: | The package of the Java user-defined data type is based on the XML Schema of the data type in the WSDL, which is different from the package name of the JAX-RPC stubs. |
See Sample Ant Build File for a Stand-Alone Java Client for a full sample build.xml
file that contains additional targets from those described in this procedure, such as clean
.
To execute the clientgen
Ant task, along with the other supporting Ant tasks, specify the build-client
target at the command line:
prompt> ant build-client
See the clientclasses
directory to view the files and artifacts generated by the clientgen
Ant task.
You need to know the name of the Web Service and the signature of its operations before you write your Java client application code to invoke an operation. There are a variety of ways to find this information.
The best way to get this information is to use the clientgen
Ant task to generate the Web Service-specific JAX-RPC stubs and look at the generated *.java
files. These files are generated into the directory specified by the destDir
attribute, with subdirectories corresponding to either the value of the packageName
attribute, or, if this attribute is not specified, to a package based on the targetNamespace
of the WSDL.
ServiceName
.java
source file contains the get
PortName
()
methods for getting the Web Service port, where ServiceName
refers to the name of the Web Service and PortName
refers to the name of the port. If the Web Service was implemented with a JWS file, the name of the Web Service is the value of the serviceName
attribute of the @WebService
JWS annotation and the name of the port is the value of the portName
attribute of the @WLHttpTransport
annotation.PortType
.java
file contains the method signatures that correspond to the public operations of the Web Service, where PortType
refers to the port type of the Web Service. If the Web Service was implemented with a JWS file, the port type is the value of the name
attribute of the @WebService
JWS annotation.
You can also examine the actual WSDL of the Web Service; see Browsing to the WSDL of the Web Service for details about the WSDL of a deployed WebLogic Web Service. The name of the Web Service is contained in the <service>
element, as shown in the following excerpt of the TraderService
WSDL:
<service name="TraderService">
<port name="TraderServicePort"
binding="tns:TraderServiceSoapBinding">
...
</port>
</service>
The operations defined for this Web Service are listed under the corresponding <binding>
element. For example, the following WSDL excerpt shows that the TraderService
Web Service has two operations, buy
and sell
(for clarity, only relevant parts of the WSDL are shown):
<binding name="TraderServiceSoapBinding" ...>
...
<operation name="sell">
...
</operation>
<operation name="buy">
</operation>
</binding>
In the following code example, a stand-alone application invokes a Web Service operation.
The client application takes a single argument: the WSDL of the Web Service. The application then uses standard JAX-RPC API code and the Web Service-specific implementation of the Service
interface, generated by clientgen,
to invoke an operation of the Web Service.
The example also shows how to invoke an operation that has a user-defined data type (examples.webservices.complex.BasicStruct) as an input parameter and return value. The clientgen
Ant task automatically generates the Java code for this user-defined data type.
package examples.webservices.simple_client;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
// import the BasicStruct class, used as a param and return value of the
// echoComplexType operation. The class is generated automatically by
// the clientgen Ant task.
import examples.webservices.complex.BasicStruct;
/**
* This is a simple stand-alone client application that invokes the
* the echoComplexType operation of the ComplexService Web service.
*
* @author Copyright (c) 2005 by BEA Systems. All Rights Reserved.
*/
public class Main {
public static void main(String[] args)
throws ServiceException, RemoteException{
ComplexService service = new ComplexService_Impl (args[0] + "?WSDL");
ComplexPortType port = service.getComplexServicePort();
BasicStruct in = new BasicStruct();
in.setIntValue(999);
in.setStringValue("Hello Struct");
BasicStruct result = port.echoComplexType(in);
System.out.println("echoComplexType called. Result: " + result.getIntValue() + ", " + result.getStringValue());
}
}
ComplexPortType
stub:ComplexService service = new ComplexService_Impl (args[0] + "?WSDL");
ComplexPortType port = service.getComplexServicePort();
The ComplexService_Impl
stub factory implements the JAX-RPC Service
interface. The constructor of ComplexService_Impl
creates a stub based on the provided WSDL URI (args[0] + "?WSDL"
). The getComplexServicePort()
method is used to return an instance of the ComplexPortType
stub implementation.
echoComplexType
operation of the ComplexService
Web Service:BasicStruct result = port.echoComplexType(in);
The echoComplexType
operation returns the user-defined data type called BasicStruct.
The method of your application that invokes the Web Service operation must throw or catch java.rmi.RemoteException
and javax.xml.rpc.ServiceException
, both of which are thrown from the generated JAX-RPC stubs.
Add javac
tasks to the build-client
target in the build.xml
file to compile all the Java files (both of your client application and those generated by clientgen
) into class files, as shown by the bold text in the following example
<target name="build-client">
<clientgen
wsdl="http://${wls.hostname}:${wls.port}/complex/ComplexService?WSDL"
destDir="clientclasses"
packageName="examples.webservices.simple_client"/>
<javac
srcdir="clientclasses"
destdir="clientclasses"
includes="**/*.java"/>
<javac
srcdir="src"
destdir="clientclasses"
includes="examples/webservices/simple_client/*.java"/>
</target>
In the example, the first javac
task compiles the Java files in the clientclasses
directory that were generated by clientgen,
and the second javac
task compiles the Java files in the examples/webservices/simple_client
subdirectory of the current directory; where it is assumed your Java client application source is located.
In the preceding example, the clientgen
-generated Java source files and the resulting compiled classes end up in the same directory (clientclasses
). Although this might be adequate for proto-typing, it is often a best practice to keep source code (even generated code) in a different directory from the compiled classes. To do this, set the destdir
for both javac
tasks to a directory different from the srcdir
directory. You must also copy the following clientgen
-generated files from clientgen
’s destination directory to javac
’s destination directory, keeping the same sub-directory hierarchy in the destination:
packageName
/ServiceName
_internaldd.xmlpackageName
/ServiceName
_java_wsdl_mapping.xmlpackageName
/ServiceName
_saved_wsdl.wsdl
where packageName
refers to the subdirectory hierarchy that corresponds to the package of the generated JAX-RPC stubs and ServiceName
refers to the name of the Web Service.
To run the client application, add a run
target to the build.xml
that includes a call to the java
task, as shown below:
<path id="client.class.path">
<pathelement path="clientclasses"/>
<pathelement path="${java.class.path}"/>
</path>
<target name="run" >
<java
fork="true"
classname="examples.webServices.simple_client.Main"
failonerror="true" >
<classpath refid="client.class.path"/>
<arg line="http://${wls.hostname}:${wls.port}/complex/ComplexService" />
</java>
</target>
The path
task adds the clientclasses
directory to the CLASSPATH. The run
target invokes the Main
application, passing it the URL of the deployed Web Service as its single argument.
See Sample Ant Build File for a Stand-Alone Java Client for a full sample build.xml
file that contains additional targets from those described in this procedure, such as clean
.
Rerun the build-client
target to regenerate the artifacts and recompile into classes, then execute the run
target to invoke the echoStruct
operation:
prompt> ant build-client run
You can use the build-client
and run
targets in the build.xml
file to iteratively update, rebuild, and run the Java client application as part of your development process.
The following example shows a complete build.xml
file for generating and compiling a stand-alone Java client. See Using the clientgen Ant Task To Generate Client Artifacts and Compiling and Running the Client Application for explanations of the sections in bold.
<project name="webservices-simple_client" default="all">
<!-- set global properties for this build -->
<property name="wls.hostname" value="localhost" />
<property name="wls.port" value="7001" />
<property name="example-output" value="output" />
<property name="clientclass-dir" value="${example-output}/clientclass" />
<path id="client.class.path">
<pathelement path="${clientclass-dir}"/>
<pathelement path="${java.class.path}"/>
</path>
<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<target name="clean" >
<delete dir="${clientclass-dir}"/>
</target>
<target name="all" depends="clean,build-client,run" />
<target name="build-client">
<clientgen
wsdl="http://${wls.hostname}:${wls.port}/complex/ComplexService?WSDL"
destDir="${clientclass-dir}"
packageName="examples.webservices.simple_client"/>
<javac
srcdir="${clientclass-dir}" destdir="${clientclass-dir}"
includes="**/*.java"/>
<javac
srcdir="src" destdir="${clientclass-dir}"
includes="examples/webservices/simple_client/*.java"/>
</target>
<target name="run" >
<java fork="true"
classname="examples.webservices.simple_client.Main"
failonerror="true" >
<classpath refid="client.class.path"/>
<arg line="http://${wls.hostname}:${wls.port}/complex/ComplexService"
/>
</java>
</target>
</project>
Invoking a Web Service from within a WebLogic Web Service is similar to invoking one from a stand-alone Java application, as described in Invoking a Web Service from a Stand-alone Client: Main Steps. However, instead of using the clientgen
Ant task to generate the JAX-RPC stubs of the Web Service to be invoked, you use the <clientgen>
child element of the <jws>
element, inside the jwsc
Ant task that compiles the invoking Web Service. In the JWS file that invokes the other Web Service, however, you still use the same standard JAX-RPC APIs to get Service
and PortType
instances to invoke the Web Service operations. This section describes the differences between invoking a Web Service from a client in a Java EE component and invoking from a stand-alone client.
It is assumed that you have read and understood Invoking a Web Service from a Stand-alone Client: Main Steps. It is also assumed that you use Ant in your development environment to build your client application, compile Java files, and so on, and that you have an existing build.xml
that builds a Web Service that you want to update to invoke another Web Service.
The following list describes the changes you must make to the build.xml
file that builds your client Web Service, which will invoke another Web Service. See Sample build.xml File for a Web Service Client for the full sample build.xml
file:
<clientgen>
child element to the <jws>
element that specifies the JWS file that implements the Web Service that invokes another Web Service. Set the required wsdl
attribute to the WSDL of the Web Service to be invoked. Set the required packageName
attribute to the package into which you want the JAX-RPC client stubs to be generated.The following bullets describe the changes you must make to the JWS file that implements the client Web Service; see Sample JWS File That Invokes a Web Service for the full JWS file example.
<clientgen>
child element of the jwsc
Ant task. These include the JAX-RPC stubs of the invoked Web Service, as well as the Java representation of any user-defined data types used as parameters or return values in the operations of the invoked Web Service.Note: | The user-defined data types are generated into a package based on the XML Schema of the data type in the WSDL, not in the package specified by clientgen . The JAX-RPC stubs, however, use the package name specified by the packageName attribute of the <clientgen> element. |
java.rmi.RemoteException
and javax.xml.rpc.ServiceException
.
The following sample build.xml
file shows how to create a Web Service that itself invokes another Web Service; the relevant sections that differ from the build.xml
for building a simple Web Service that does not invoke another Web Service are shown in bold.
The build-service
target in this case is very similar to a target that builds a simple Web Service; the only difference is that the jwsc
Ant task that builds the invoking Web Service also includes a <clientgen>
child element of the <jws>
element so that jwsc
also generates the required JAX-RPC client stubs.
<project name="webservices-service_to_service" default="all">
<!-- set global properties for this build -->
<property name="wls.username" value="weblogic" />
<property name="wls.password" value="weblogic" />
<property name="wls.hostname" value="localhost" />
<property name="wls.port" value="7001" />
<property name="wls.server.name" value="myserver" />
<property name="ear.deployed.name" value="ClientServiceEar" />
<property name="example-output" value="output" />
<property name="ear-dir" value="${example-output}/ClientServiceEar" />
<property name="clientclass-dir" value="${example-output}/clientclasses" />
<path id="client.class.path">
<pathelement path="${clientclass-dir}"/>
<pathelement path="${java.class.path}"/>
</path>
<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />
<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<taskdef name="wldeploy"
classname="weblogic.ant.taskdefs.management.WLDeploy"/>
<target name="all" depends="clean,build-service,deploy,client" />
<target name="clean" depends="undeploy">
<delete dir="${example-output}"/>
</target>
<target name="build-service">
<jwsc
srcdir="src"
destdir="${ear-dir}" >
<jws
file="examples/webservices/service_to_service/ClientServiceImpl.java">
<clientgen
</jws>
wsdl="http://${wls.hostname}:${wls.port}/complex/ComplexService?WSDL"
packageName="examples.webservices.service_to_service" />
</jwsc>
</target>
<target name="deploy">
<wldeploy action="deploy" name="${ear.deployed.name}"
source="${ear-dir}" user="${wls.username}"
password="${wls.password}" verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}" />
</target>
<target name="undeploy">
<wldeploy action="undeploy" name="${ear.deployed.name}"
failonerror="false"
user="${wls.username}"
password="${wls.password}" verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}" />
</target>
<target name="client">
<clientgen
wsdl="http://${wls.hostname}:${wls.port}/ClientService/ClientService?WSDL"
destDir="${clientclass-dir}"
packageName="examples.webservices.service_to_service.client"/>
<javac
srcdir="${clientclass-dir}" destdir="${clientclass-dir}"
includes="**/*.java"/>
<javac
srcdir="src" destdir="${clientclass-dir}"
includes="examples/webservices/service_to_service/client/**/*.java"/>
</target>
<target name="run">
<java classname="examples.webservices.service_to_service.client.Main"
fork="true"
failonerror="true" >
<classpath refid="client.class.path"/>
<arg
line="http://${wls.hostname}:${wls.port}/ClientService/ClientService"/>
</java>
</target>
</project>
The following sample JWS file, called ClientServiceImpl.java
, implements a Web Service called ClientService
that has an operation that in turn invokes the echoComplexType
operation of a Web Service called ComplexService
. This operation has a user-defined data type (BasicStruct
) as both a parameter and a return value. The relevant code is shown in bold and described after the example.
package examples.webservices.service_to_service;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
import javax.jws.WebService;
import javax.jws.WebMethod;
import weblogic.jws.WLHttpTransport;
// Import the BasicStruct data type, generated by clientgen and used
// by the ComplexService Web Service
import examples.webservices.complex.BasicStruct;
// Import the JAX-RPC Stubs for invoking the ComplexService Web Service.
// Stubs generated by clientgen
import examples.webservices.service_to_service.ComplexPortType;
import examples.webservices.service_to_service.ComplexService_Impl;
import examples.webservices.service_to_service.ComplexService;
@WebService(name="ClientPortType", serviceName="ClientService",
targetNamespace="http://examples.org")
@WLHttpTransport(contextPath="ClientService", serviceUri="ClientService",
portName="ClientServicePort")
public class ClientServiceImpl {
@WebMethod()
public String callComplexService(BasicStruct input, String serviceUrl)
throws ServiceException, RemoteException
{
// Create service and port stubs to invoke ComplexService
ComplexService service = new ComplexService_Impl(serviceUrl + "?WSDL");
ComplexPortType port = service.getComplexServicePort();
// Invoke the echoComplexType operation of ComplexService
BasicStruct result = port.echoComplexType(input);
System.out.println("Invoked ComplexPortType.echoComplexType." );
return "Invoke went okay! Here's the result: '" + result.getIntValue() + ", " + result.getStringValue() + "'";
}
}
Follow these guidelines when programming the JWS file that invokes another Web Service; code snippets of the guidelines are shown in bold in the preceding example:
ComplexService
uses the BasicStruct
JavaBean:import examples.webservices.complex.BasicStruct;
ComplexService
Web Service; the stubs are generated by the <cliengen>
child element of <jws>
:import examples.webservices.service_to_service.ComplexPortType;
import examples.webservices.service_to_service.ComplexService_Impl;
import examples.webservices.service_to_service.ComplexService;
ServiceException
and RemoteException
:throws ServiceException, RemoteException
ComplexService
:ComplexService service = new
ComplexService_Impl(serviceUrl + "?WSDL");
ComplexPortType port = service.getComplexServicePort();
echoComplexType
operation of ComplexService
using the port you just instantiated:BasicStruct result = port.echoComplexType(input);
It is assumed in this document that, when you invoke a Web Service using the client-side artifacts generated by the clientgen
or wsdlc
Ant tasks, you have the entire set of WebLogic Server classes in your CLASSPATH. If, however, your computer does not have WebLogic Server installed, you can still invoke a Web Service by using the stand-alone WebLogic Web Services client JAR file, as described in this section.
The standalone client JAR file supports basic client-side functionality, such as:
The stand-alone client JAR file does not, however, support invoking Web Services that use the following advanced features:
To use the stand-alone WebLogic Web Services client JAR file with your client application, follow these steps:
WL_HOME
/server/lib/wseeclient.zip
from the computer hosting WebLogic Server to the client computer, where WL_HOME
refers to the WebLogic Server installation directory, such as /bea/wlserver_10.0
.wseeclient.zip
file into the appropriate directory. For example, you might unzip the file into a directory that contains other classes used by your client application.wseeclient.jar
file (unzipped from the wseeclient.zip
file) to your CLASSPATH. Note: | Also be sure that your CLASSPATH includes the JAR file that contains the Ant classes (ant.jar ). This JAR file is typically located in the lib directory of the Ant distribution. |
You can use a proxy server to proxy requests from a client application to an application server (either WebLogic or non-WebLogic) that hosts the invoked Web Service. You typically use a proxy server when the application server is behind a firewall. There are two ways to specify the proxy server in your client application: programmatically using the WebLogic HttpTransportInfo
API or using system properties.
For a complete example of using a proxy server when invoking a Web Service, see the example on the dev2dev Code Example site.
You can programmatically specify within the Java client application itself the details of the proxy server that will proxy the Web Service invoke by using the standard java.net.*
classes and the WebLogic-specific HttpTransportInfo
API. You use the java.net
classes to create a Proxy
object that represents the proxy server, and then use the WebLogic API and properties to set the proxy server on the JAX-RPC stub, as shown in the following sample client that invokes the echo
operation of the HttpProxySampleService
Web Service. The code in bold is described after the example:
package dev2dev.proxy.client;
import javax.xml.rpc.Stub;
import java.net.Proxy;
import java.net.InetSocketAddress;
import weblogic.wsee.connection.transport.http.HttpTransportInfo;
/**
* Sample client to invoke a service through a proxy server via
* programmatic API
*/
public class HttpProxySampleClient {
public static void main(String[] args) throws Throwable{
assert args.length == 5;
String endpoint = args[0];
String proxyHost = args[1];
String proxyPort = args[2];
String user = args[3];
String pass = args[4];
//create service and port
HttpProxySampleService service = new HttpProxySampleService_Impl();
HttpProxySamplePortType port = service.getHttpProxySamplePortTypeSoapPort();
//set endpoint address
((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, endpoint);
//set proxy server info
Proxy p = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(proxyHost, Integer.parseInt(proxyPort)));
HttpTransportInfo info = new HttpTransportInfo();
info.setProxy(p);
((Stub)port)._setProperty("weblogic.wsee.connection.transportinfo",info);
//set proxy-authentication info
((Stub)port)._setProperty("weblogic.webservice.client.proxyusername",user);
((Stub)port)._setProperty("weblogic.webservice.client.proxypassword",pass);
//invoke
String s = port.echo("Hello World!");
System.out.println("echo: " + s);
}
}
The sections of the preceding example to note are as follows:
java.net.*
classes:import java.net.Proxy;
import java.net.InetSocketAddress;
HttpTransportInfo
API:import weblogic.wsee.connection.transport.http.HttpTransportInfo;
Proxy
object that represents the proxy server:Proxy p = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(proxyHost, Integer.parseInt(proxyPort)));
The proxyHost
and proxyPort
arguments refer to the host computer and port of the proxy server.
HttpTransportInfo
object and use the setProxy() method to set the proxy server information:HttpTransportInfo info = new HttpTransportInfo();
info.setProxy(p);
weblogic.wsee.connection.transportinfo
WebLogic stub property to set the HttpTransportInfo
object on the JAX-RPC stub:((Stub)port)._setProperty("weblogic.wsee.connection.transportinfo",info);
weblogic.webservice.client.proxyusername
and weblogic.webservice.client.proxypassword
WebLogic-specific stub properties to specify the username and password of a user who is authenticated to access the proxy server:((Stub)port)._setProperty("weblogic.webservice.client.proxyusername",user);
((Stub)port)._setProperty("weblogic.webservice.client.proxypassword",pass);
Alternatively, you can use the setProxyUsername()
and setProxyPassword()
methods of the HttpTransportInfo
API to set the proxy username and password, as shown in the following example:
info.setProxyUsername("juliet".getBytes());
info.setProxyPassword("secret".getBytes());
When you use system properties to specify the proxy server, you write your client application in the standard way, and then specify the following system properties when you execute the client application:
where proxyHost
is the name of the host computer on which the proxy server is running, proxyPort
is the port to which the proxy server is listening, proxyUsername
is the authenticated proxy server user and proxyPassword
is the user’s password.
The following excerpt from an Ant build script shows an example of setting these system properties when invoking a client application called clients.InvokeMyService
:
<target name="run-client">
<java fork="true"
classname="clients.InvokeMyService"
failonerror="true">
<classpath refid="client.class.path"/>
<arg line="${http-endpoint}"/>
<jvmarg line=
"-DproxySet=true
-DproxyHost=${proxy-host}
-DproxyPort=${proxy-port}
-Dweblogic.webservice.client.proxyusername=${proxy-username}
-Dweblogic.webservice.client.proxypassword=${proxy-passwd}"
/>
</java>
</target>
WebLogic Server supports production redeployment, which means that you can deploy a new version of an updated WebLogic Web Service alongside an older version of the same Web Service.
WebLogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the Web Service during the redeployment continue to use the older version of the service until they complete their work, at which point WebLogic Server automatically retires the older Web Service. If the client is connected to a conversational or reliable Web Service, its work is considered complete when the existing conversation or reliable messaging sequence is explicitly ended by the client or because of a timeout.
You can continue using the old client application with the new version of the Web Service, as long as the following Web Service artifacts have not changed in the new version:
If any of these artifacts have changed, you must regenerate the JAX-RPC stubs used by the client application by re-running the clientgen
Ant task.
For example, if you change the signature of an operation in the new version of the Web Service, then the WSDL file that describes the new version of the Web Service will also change. In this case, you must regenerate the JAX-RPC stubs. If, however, you simply change the implementation of an operation, but do not change its public contract, then you can continue using the existing client application.
WebLogic Server provides a set of stub properties that you can set in the JAX-RPC Stub used to invoke a WebLogic Web Service. Use the Stub._setProperty() method to set the properties, as shown in the following example:
((Stub)port)._setProperty(WLStub.MARSHAL_FORCE_INCLUDE_XSI_TYPE,"true");
Most of the stub properties are defined in the WLStub
class. See weblogic.wsee.jaxrpc.WLStub for details.
The following table describes additional stub properties not defined in the WLStub
class.
Use the weblogic.wsee.jaxrpc.WLStub.CHARACTER_SET_ENCODING
WLStub property to set the character encoding of the response (outbound) SOAP message. You can set it to the following two values:
The following code snippet from a client application shows how to set the character encoding to UTF-16:
Simple port = service.getSimpleSoapPort();
((Stub) port)._setProperty(weblogic.wsee.jaxrpc.WLStub.CHARACTER_SET_ENCODING, "UTF-16");
port.invokeMethod();
See weblogic.wsee.jaxrpc.WLStub for additional WLStub properties you can set.
![]() ![]() ![]() |