Programming Advanced Features of WebLogic Web Services Using JAX-RPC

Using Web Services Reliable Messaging

The following sections describe how to use Web Services Reliable Messaging:

Overview of Web Service Reliable Messaging

Web Service reliable messaging is a framework that enables an application running on one application server to reliably invoke a Web Service running on another application server, assuming that both servers implement the WS-ReliableMessaging specification. Reliable is defined as the ability to guarantee message delivery between the two Web Services.

WebLogic Web Services conform to the WS-ReliableMessaging specification (June 2007), which describes how two Web Services running on different application servers can communicate reliably in the presence of failures in software components, systems, or networks. In particular, the specification describes an interoperable protocol in which a message sent from a source endpoint (or client Web Service) to a destination endpoint (or Web Service whose operations can be invoked reliably) is guaranteed either to be delivered, according to one or more delivery assurances, or to raise an error.

A reliable WebLogic Web Service provides the following delivery assurances.

This document describes how to create the reliable and client Web Services and how to configure the two WebLogic Server instances to which the Web Services are deployed. See the WS-ReliableMessaging specification for detailed documentation about the architecture of Web Service reliable messaging.

Using WS-Policy to Specify Reliable Messaging Policy Assertions

WebLogic Web Services use WS-Policy files to enable a destination endpoint to describe and advertise its Web Service reliable messaging capabilities and requirements. The WS-Policy files are XML files that describe features such as the version of the supported WS-ReliableMessaging specification and quality of service requirements. The WS-Policy specification provides a general purpose model and syntax to describe and communicate the policies of a Web Service.

WebLogic Server includes pre-packaged WS-Policy files that contain typical reliable messaging assertions, as described in Pre-Packaged WS-Policy Files for Reliable Messaging. If the pre-packaged WS-Policy files do not suit your needs, you must create your own WS-Policy file. See Creating the Web Service Reliable Messaging WS-Policy File for details. See “Web Service Reliable Messaging Policy Assertion Reference” in the WebLogic Web Service Reference for reference information about the reliable messaging policy assertions.

Managing the Life Cycle of the Reliable Message Sequence

The following figure shows a one-way reliable message exchange.

A reliable message sequence is used to track the progress of a set of messages that are exchanged reliably between an RM source and RM destination. A sequence can be used to send zero or more messages, and is identified by a string identifier. This identifier is used to reference the sequence when using reliable messaging.

The Web Service client application sends a message for reliable delivery which is transmitted by the RM source to the RM destination. The RM destination acknowledges that the reliable message has been received and delivers it to the Web Service application. The message may be retransmitted by the RM source until the acknowledgement is received.

A Web Service client sends messages to a target Web Service by invoking methods on a JAX-RPC stub. The stub is associated with the port type of the reliable Web Service and represents a programmatic interface to that service. WebLogic stores the identifier for the reliable message sequence within this stub. This causes the reliable message sequence to be connected to a single JAX-RPC stub. All messages that are sent using a given stub will use the same reliable messaging sequence, regardless of the number of messages that are sent using the stub. The JAX-RPC stub is created by the <clientgen> child element of the jwsc Ant task.

Because WebLogic Server retains resources associated with the reliable sequence, it is recommended that you take steps to release these resources in a timely fashion. WebLogic Server provides a utility class, weblogic.wsee.reliability.WsrmUtils, for use with the Web Service reliable messaging. Use this class to perform common tasks such as set configuration options, get the sequence id, and terminate a reliable sequence.

Under normal circumstances, a reliable sequence should be retained until all messages have been sent and acknowledged by the RM destination. To facilitate the timely and proper termination of a sequence, it is recommended that you identify the final message in a reliable message sequence. Doing so indicates you are done sending messages to the RM destination and that WebLogic Server can begin looking for the final acknowledgement before automatically terminating the reliable sequence. Indicate the final message using the weblogic.wsee.reliability.WsrmUtils.setFinalMessage() method, passing the JAX-RPC stub being used to send messages to the RM destination.

When you identify a final message, after all messages up to and including the final message are acknowledged, the reliable message sequence is terminated, and all resources are released. Otherwise, the sequence is terminated automatically after the configured sequence expiration period is reached.

Although not recommended, you can terminate the sequence reliable message sequence regardless of whether all messages have been acknowledged using the terminateSequence() method. Once issued, no further reliable messages can be sent on this stub.

For more information about the WsrmUtils utility class, see the weblogic.wsee.reliability.WsrmUtils Javadocs.

Using Web Service Reliable Messaging: Main Steps

Configuring reliable messaging for a WebLogic Web Service requires standard JMS tasks such as creating JMS servers and Store and Forward (SAF) agents, as well as Web Service-specific tasks, such as adding additional JWS annotations to your JWS file. Optionally, you create WS-Policy files that describe the reliable messaging capabilities of the reliable Web Service if you do not use the pre-packaged ones.

If you are using the WebLogic client APIs to invoke a reliable Web Service, the client application must run on WebLogic Server. Thus, configuration tasks must be performed on both the source WebLogic Server instance on which the Web Service that includes client code to invoke the reliable Web Service reliably is deployed, as well as the destination WebLogic Server instance on which the reliable Web Service itself is deployed.

The following table summarizes the steps to create a reliable Web Service, as well as a client Web Service that invokes an operation of the reliable Web Service. The procedure describes how to create the JWS files that implement the two Web Services from scratch; if you want to update existing JWS files, use this procedure as a guide. The procedure also describes how to configure the source and destination WebLogic Server instances.

Each of these steps is described in more detail in the following sections.

In addition, the following advanced topics are discussed:

Prerequisites

It is assumed that you have completed the following tasks:

For more information, see “Developing WebLogic Web Services” in Getting Started With WebLogic Web Servers Using JAX-RPC.

Configuring the Destination WebLogic Server Instance

To configure the WebLogic Server instance on which the reliable Web Service is deployed, configure the JMS and store and forward (SAF) resources.

You can configure these resources manually or you can use the Configuration Wizard to extend the WebLogic Server domain using a Web Services-specific extension template. Using the Configuration Wizard greatly simplifies the required configuration steps; for details, see “Configuring Your Domain For Web Services Features” in Getting Started With WebLogic Web Services Using JAX-RPC.

If you prefer to configure the resources manually, perform the following steps.

Configuring the Source WebLogic Server Instance

Configuring the WebLogic Server instance on which the client Web Service is deployed involves configuring JMS and store and forward (SAF) resources.

You can configure these resources manually or you can use the Configuration Wizard to extend the WebLogic Server domain using a Web Services-specific extension template. Using the Configuration Wizard greatly simplifies the required configuration steps; for details, see “Configuring Your Domain For Web Services Features” in Getting Started With WebLogic Web Services Using JAX-RPC.

If you prefer to configure the resources manually, perform the following steps.

Creating the Web Service Reliable Messaging WS-Policy File

A WS-Policy file is an XML file that contains policy assertions that comply with the WS-Policy specification. In this case, the WS-Policy file contains Web Service reliable messaging policy assertions.

WebLogic Server includes pre-packaged WS-Policy files that contain typical reliable messaging assertions that you can use if you do not want to create your own WS-Policy file. The pre-packaged WS-Policy files are listed in the following table.

You can use one of the pre-packaged reliable messaging WS-Policy files included in WebLogic Server; these files are adequate for most use cases. You cannot modify the pre-packaged files. If the values do not suit your needs, you must create a custom WS-Policy file. The following sections describe how to create a custom WS-Policy file.

Creating a Custom WS-Policy File Using WS-ReliableMessaging Policy Assertions Version 1.1

This section describes how to create a custom WS-Policy file that contains Web Service reliable messaging assertions that are based on WS Reliable Messaging Policy Assertion Version 1.1. In the current release, many of the reliable messaging policy assertions are managed through JWS annotations or configuration.

The root element of the WS-Policy file is <Policy> and it should include the following namespace declaration:

<wsp:Policy
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

You wrap all Web Service reliable messaging policy assertions inside of a <wsrmp:RMAssertion> element. This element should include the following namespace declaration for using Web Service reliable messaging policy assertions:

<wsrmp:RMAssertion
   xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"> 

The following table lists the Web Service reliable messaging assertions that you can specify in the WS-Policy file. The order in which the assertions appear is important. You can specify the following assertions; the order they appear in the following list is the order in which they should appear in your WS-Policy file:

The following example shows a simple Web Service reliable messaging WS-Policy file:

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <wsrmp:RMAssertion
         xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
    <wsrmp:SequenceTransportSecurity/>
    <wsrmp:DeliveryAssurance>
      <wsp:Policy>
        <wsrmp:ExactlyOnce/>
      </wsp:Policy>
    </wsrmp:DeliveryAssurance>
  </wsrmp:RMAssertion>
</wsp:Policy>

For more information about Reliable Messaging policy assertions in the WS-Policy file, see “Web Service Reliable Messaging Policy Assertion Reference” in WebLogic Web Services Reference.

Creating a Custom WS-Policy File Using WS-ReliableMessaging Policy Assertions Version 1.0 (Deprecated)

This section describes how to create a custom WS-Policy file that contains Web Service reliable messaging assertions that are based on WS Reliable Messaging Policy Assertion Version 1.0.

The root element of the WS-Policy file is <Policy> and it should include the following namespace declarations for using Web Service reliable messaging policy assertions:

<wsp:Policy
   xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:beapolicy="http://www.bea.com/wsrm/policy">

You wrap all Web Service reliable messaging policy assertions inside of a <wsrm:RMAssertion> element. The assertions that use the wsrm: namespace are standard ones defined by the WS-ReliableMessaging specification. The assertions that use the beapolicy: namespace are WebLogic-specific. See “Web Service Reliable Messaging Policy Assertion Reference” in the WebLogic Web Services Reference for details.

The following table lists the Web Service reliable messaging assertions that you can specify in the WS-Policy file. All Web Service reliable messaging assertions are optional, so only set those whose default values are not adequate. The order in which the assertions appear is important. You can specify the following assertions; the order they appear in the following list is the order in which they should appear in your WS-Policy file,

The following example shows a simple Web Service reliable messaging WS-Policy file:

<?xml version="1.0"?>

<wsp:Policy
   xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:beapolicy="http://www.bea.com/wsrm/policy"
  >

 <wsrm:RMAssertion>

   <wsrm:InactivityTimeout
      Milliseconds="600000" />
   <wsrm:BaseRetransmissionInterval
      Milliseconds="500" />
   <wsrm:ExponentialBackoff />
   <wsrm:AcknowledgementInterval
      Milliseconds="2000" />

 </wsrm:RMAssertion>

</wsp:Policy>

For more information about Reliable Messaging policy assertions in the WS-Policy file, see “Web Service Reliable Messaging Policy Assertion Reference” in WebLogic Web Services Reference.

Using Multiple Policy Alternatives

You can configure multiple policy alternatives—also referred to as smart policy alternatives—for a single Web Service by creating a custom policy file. At runtime, WebLogic Server selects which of the configured policies to apply. It excludes policies that are not supported or have conflicting assertions and selects the appropriate policy, based on your configured preferences, to verify incoming messages and build the response messages.

The following example provides an example of a security policy that supports both 1.1 and 1.0 WS-Reliable Messaging. Each policy alternative is enclosed in a <wsp:All> element.

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <wsrmp10:RMAssertion
       xmlns:wsrmp10="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
        <wsrmp10:InactivityTimeout Milliseconds="1200000"/>
        <wsrmp10:BaseRetransmissionInterval Milliseconds="60000"/>
        <wsrmp10:ExponentialBackoff/>
        <wsrmp10:AcknowledgementInterval Milliseconds="800"/>
      </wsrmp10:RMAssertion>
    </wsp:All>
    <wsp:All>
      <wsrmp:RMAssertion
           xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
        <wsrmp:SequenceSTR/>
        <wsrmp:DeliveryAssurance>
          <wsp:Policy>
            <wsrmp:AtMostOnce/>
          </wsp:Policy>
        </wsrmp:DeliveryAssurance>
      </wsrmp:RMAssertion>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

For more information about multiple policy alternatives, see “Smart Policy Selection” in “Configuring Message-Level Security” in Securing WebLogic Web Services.

Programming Guidelines for the Reliable JWS File

This section describes how to create the JWS file that implements the reliable Web Service.

The following JWS annotations are used in the JWS file that implements a reliable Web Service.

The following example shows a simple JWS file that implements a reliable Web Service; see the explanation after the example for coding guidelines that correspond to the Java code in bold.

package examples.webservices.reliable;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway;

import weblogic.jws.WLHttpTransport;

import weblogic.jws.ReliabilityBuffer;
import weblogic.jws.BufferQueue;
import weblogic.jws.Policy;

/**
 * Simple reliable Web Service.
 */

@WebService(name="ReliableHelloWorldPortType",
              serviceName="ReliableHelloWorldService")

@WLHttpTransport(contextPath="ReliableHelloWorld",
      serviceUri="ReliableHelloWorld",
      portName="ReliableHelloWorldServicePort")

@Policy(uri="ReliableHelloWorldPolicy.xml",
          direction=Policy.Direction.both,
          attachToWsdl=true)

@BufferQueue(name="webservices.reliable.queue")

public class ReliableHelloWorldImpl {

  @WebMethod()
  @Oneway()
  @ReliabilityBuffer(retryCount=10, retryDelay="10 seconds")

  public void helloWorld(String input) {
    System.out.println(" Hello World " + input);

  }
}

In the example, the ReliableHelloWorldPolicy.xml file is attached to the Web Service at the class level, which means that the policy file is applied to all public operations of the Web Service. The policy file is applied only to the request Web Service message (as required by the reliable messaging feature) and it is attached to the WSDL file.

The JMS queue that WebLogic Server uses internally to enable the Web Service reliable messaging has a JNDI name of webservices.reliable.queue, as specified by the @BufferQueue annotation.

The helloWorld() method has been marked with both the @WebMethod and @Oneway JWS annotations, which means it is a public operation called helloWorld. Because of the @Policy annotation, the operation can be invoked reliably. The Web Services runtime attempts to deliver reliable messages to the service a maximum of 10 times, at 10-second intervals, as described by the @ReliabilityBuffer annotation. The message may require re-delivery if, for example, the transaction is rolled back or otherwise does not commit.

Using the @Policy Annotation

Use the @Policy annotation in your JWS file to specify that the Web Service has a WS-Policy file attached to it that contains reliable messaging assertions. WebLogic Server delivers a set of pre-packaged WS-Policy files, as described in Pre-Packaged WS-Policy Files for Reliable Messaging.

Follow the following guidelines when using the @Policy annotation for Web Service reliable messaging:

For more information about the @Policy annotation, see “weblogic.jws.Policy” in WebLogic Web Services Reference.

Using the @Oneway Annotation

If you plan on invoking the reliable Web Service operation synchronously (or in other words, not using the asynchronous request-response feature), then you must annotate the implementing method with the @Oneway annotation to specify that the method is one-way. This means that the method cannot return a value, but rather, must explicitly return void.

Conversely, if the method is not annotated with the @Oneway annotation, then you must invoke it using the asynchronous request-response feature. If you are unsure how the operation is going to be invoked, consider creating two flavors of the operation: synchronous and asynchronous.

See Invoking a Web Service Using Asynchronous Request-Response, and Using the Asynchronous Features Together.

Using the @BufferQueue Annotation

Use the @BufferQueue annotation to specify the JNDI name of the JMS queue which WebLogic Server uses to store reliable messages internally. The JNDI name is the one you configured when creating a JMS queue in step 4 in Configuring the Destination WebLogic Server Instance.

The @BufferQueue annotation is optional; if you do not specify it in your JWS file then WebLogic Server uses a queue with a JNDI name of weblogic.wsee.DefaultQueue. You must, however, still explicitly create a JMS queue with this JNDI name using the Administration Console.

For more information about the @BufferQueue annotation, see “weblogic.jws.BufferQueue” in WebLogic Web Services Reference.

Using the @ReliabilityBuffer Annotation

Use the @ReliabilityBuffer annotation to specify the number of times WebLogic Server should attempt to deliver the message from the JMS queue to the Web Service implementation and the amount of time that the server should wait in between retries.

Use the retryCount attribute to specify the number of retries and the retryDelay attribute to specify the wait time. The format of the retryDelay attribute is a number and then one of the following strings:

For example, to specify a retry count of 20 and a retry delay of two days, use the following syntax:

@ReliabilityBuffer(retryCount=20, retryDelay="2 days")

The retry count and delay default to 3 and 5 seconds, respectively.

For more information about the @ReliabilityBuffer annotation, see “weblogic.jws.ReliabilityBuffer” in WebLogic Web Services Reference.

Configuring Reliable Messaging for a Reliable Web Service

If necessary, you can edit the reliable message configuration options for a reliable Web Service that are stored in the weblogic-webservices.xml descriptor by updating the application deployment plan. The deployment plan associates new values with specific locations in the descriptors for your application. At deployment time, a deployment plan is merged with the descriptors in the application by applying the values in its variable assignments to the locations in the application descriptors to which the variables are linked.

The following table summarizes the reliable messaging options that can be configured for the reliable Web Service. For more information, see “Web Service Reliable Messaging” in the Administration Console Online Help.

You can set the reliable messaging configuration options using the Administration Console or WLST, as described in the following sections.

Using the WebLogic Server Administration Console

To use the Administration Console to update an application’s deployment plan and configure reliable messaging, access the reliable messaging configuration options for a reliable Web Service in the Deployments table under the Configuration > Port Components tabs. For information about invoking the Administration Console and accessing the Web Service deployments, see “Invoking the Administration Console” in Getting Started With WebLogic Web Services Using JAX-RPC.

Using WLST

For a complete description and example of using WLST to update an application’s deployment plan to configure reliable messaging, see “Updating a Deployment Plan” in WebLogic Scripting Tool.

For your reference, the following table summarizes the XPath values for the WS-RM configuration options.

Programming Guidelines for the JWS File That Invokes a Reliable Web Service

If you are using the WebLogic client APIs, you must invoke a reliable Web Service from within a Web Service; you cannot invoke a reliable Web Service from a stand-alone client application.

The following example shows a simple JWS file for a Web Service that invokes a reliable operation from the service described in Programming Guidelines for the Reliable JWS File.

package examples.webservices.reliable;

import java.rmi.RemoteException;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.xml.rpc.Stub;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient;
import weblogic.jws.ReliabilityErrorHandler;

import examples.webservices.reliable.ReliableHelloWorldPortType;

import weblogic.wsee.reliability.ReliabilityErrorContext;
import weblogic.wsee.reliability.ReliableDeliveryException;
import weblogic.wsee.reliability.WsrmUtils;

@WebService(name="ReliableClientPortType",
            serviceName="ReliableClientService")

@WLHttpTransport(contextPath="ReliableClient",
                 serviceUri="ReliableClient",
                 portName="ReliableClientServicePort")

public class ReliableClientImpl
{

  @ServiceClient(
     serviceName="ReliableHelloWorldService",
     portName="ReliableHelloWorldServicePort")

  private ReliableHelloWorldPortType port;

  @WebMethod
  public void callHelloWorld(String input, String serviceUrl)
     throws RemoteException {

    ((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, serviceUrl);

    WsrmUtils.setFinalMessage((Stub)port);
    port.helloWorld(input);

    System.out.println(" Invoked the ReliableHelloWorld.helloWorld operation reliably." );

  }

  @ReliabilityErrorHandler(target="port")
  public void onReliableMessageDeliveryError(ReliabilityErrorContext ctx) {

    ReliableDeliveryException fault = ctx.getFault();
    String message = null;
    if (fault != null) {
      message = ctx.getFault().getMessage();
    }
    String operation = ctx.getOperationName();
    System.out.println("Reliable operation " + operation + " may have not invoked. The error message is " + message);
  }

}

As illustrated in the previous examples (in bold text), follow these guidelines when programming the JWS file that invokes a reliable Web Service:

When programming the client Web Service:

Updating the build.xml File for a Client of a Reliable Web Service

To update a build.xml file to generate the JWS file that invokes the operation of a reliable Web Service, add taskdefs and a build-reliable-client targets similar to the following:

<taskdef name="jwsc"
    classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-reliable-client">

    <jwsc
        enableAsyncService="true"
        srcdir="src"
        destdir="${client-ear-dir}" >

        <jws file="examples/webservices/reliable/ReliableClientImpl.java">

          <clientgen
            wsdl="http://${wls.destination.host}:${wls.destination.port}/ReliableHelloWorld/ReliableHelloWorld?WSDL"
            packageName="examples.webservices.reliable"/>

        </jws>

    </jwsc>

</target>

Use the taskdef Ant task to define the full classname of the jwsc Ant tasks.

Update the jwsc Ant task that compiles the client Web Service to include a <clientgen> child element of the <jws> element so as to generate and compile the JAX-RPC stubs for the deployed ReliableHelloWorld Web Service. The jwsc Ant task automatically packages them in the generated WAR file so that the client Web Service can immediately access the stubs. You do this because the ReliableClientImpl JWS file imports and uses one of the generated classes.

Using Reliable Messaging With MTOM

The following example shows a simple JWS file that implements a reliable Web Service and uses MTOM/XOP to optimize the transmission of XML data of type xs:base64Binary in SOAP messages; see the explanation after the example for coding guidelines that correspond to the Java code in bold. This example builds on the example provided in Programming Guidelines for the JWS File That Invokes a Reliable Web Service.

package examples.webservices.reliable;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway;

import weblogic.jws.WLHttpTransport;

import weblogic.jws.ReliabilityBuffer;
import weblogic.jws.BufferQueue;
import weblogic.jws.Policy;
import weblogic.jws.Policies;

/**
 * Simple reliable Web Service.
 */

@WebService(name="ReliableHelloWorldPortType",
              serviceName="ReliableHelloWorldService")

@WLHttpTransport(contextPath="ReliableHelloWorld",
      serviceUri="ReliableHelloWorld",
      portName="ReliableHelloWorldServicePort")

@Policies({@Policy(uri="ReliableHelloWorldPolicy.xml",
           direction=Policy.Direction.both,
           attachToWsdl=true),
           @Policy(uri = "policy:Mtom.xml")})

@BufferQueue(name="webservices.reliable.queue")

public class ReliableHelloWorldImpl {

  @WebMethod()
  @Oneway()
  @ReliabilityBuffer(retryCount=10, retryDelay="10 seconds")

  public void helloWorld(String input) {
    System.out.println(" Hello World " + input);

  }

  @WebMethod

  public byte[] echoBinary(byte[] bytes) {
    return bytes;
  }
}

As illustrated in the previous example (in bold text), follow these guidelines when programming the JWS file that invokes a reliable Web Service with MTOM:

Client Considerations When Redeploying a Reliable Web Service

WebLogic Server supports production redeployment, which means that you can deploy a new version of an updated reliable 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 reliable Web Service, its work is considered complete when the existing reliable message sequence is explicitly ended by the client or as a result of a timeout.

For additional information about production redployment and Web Service clients, see “Client Considerations When Redeploying a Web Service” in Getting Started With WebLogic Web Services Using JAX-RPC.

Using Reliable Messaging With a Proxy Server

Client applications that invoke reliable Web Services might not invoke the operation directly, but rather, use a proxy server. Reasons for using a proxy include the presence of a firewall or the deployment of the invoked Web Service to a cluster.

In this case, the WebLogic Server instance that hosts the invoked Web Service must be configured with the address and port of the proxy server. If your Web Service is deployed to a cluster, you must configure every server in the cluster.

This procedure describes how to create a network channel, the primary configurable WebLogic Server resource for managing network connection. Network channels enable you to provide a consistent way to access the front-end address of a cluster. For more information about network channels, see “Understanding Network Channels” in Configuring Server Environments.

For each server instance: