+

Search Tips   |   Advanced Search

createWSGWProxyService command

Use the createWSGWProxyService command to set the gateway to act as a proxy for the service, then use JAX-RPC handlers to set the endpoints for incoming request messages for the service.

We can create a new proxy service configuration by using wsadmin.sh as described in this topic, or using the administrative console as described in Create a new proxy service configuration.

To run the command, use the AdminTask object of the wsadmin scripting client.

The wsadmin scripting client is run from Qshell. For more information, see Configure Qshell to run WebSphere scripts .

Command-line help is provided for service integration bus commands:

After using the command, save the changes to the master configuration using the following command:

AdminConfig.save()


Purpose

This command creates a new ProxyService object with an associated InboundService object, and a TargetService object with an associated OutboundService object.

You then use a service integration bus-enabled web services command to add any InboundPort objects associated with the InboundService object. For more information, see the worked example at the end of this topic.


Target object

ObjectName of the gateway instance within which the proxy service is created.

The command creates the proxy request destination and corresponding reply destination. The proxy request destination is configured to update the reply path to add the proxy reply destination. If a destination with the specified or default names already exists, the command fails.

If a gateway service or proxy service with the same name already exists, the command fails.

If we specify the name of the proxy request destination, the proxy service destination and port destinations are created with names derived from the proxy request destination name. Otherwise, the proxy service destination and port destinations are created with names derived from the proxy service name. The proxy service destination name is created by adding "ProxyService" to the proxy request destination or proxy service name. Each proxy port destination is then named after the proxy service destination, followed by a colon (":"), followed by the port name, followed by "Port". If a destination with any of these names already exists, the command fails.

Either specify the node and server, or specify the cluster. If there is no messaging engine defined for the specified node and server or cluster, the command fails.

The command creates an OutboundService object, with the same name as the proxy service. This new outbound service uses the created destinations, the supplied localization, and either the default proxy WSDL location for the gateway instance or (if specified) the location of the proxy WSDL file. The new outbound service is associated with the ProxyService object.

The proxy WSDL must have only a single service element. If there are multiple ports within the single service element, an outbound port object is created for each one.

The proxy WSDL should never come from UDDI, so only a web address is supported for the default and overridden proxy WSDL location.

The command uses the proxy destination to create an InboundService object with the same name as the proxy service, and uses the default or specified proxy WSDL location as the template WSDL location.


Required parameters

-name

The proxy service name.


Conditional parameters

-node

The node in which the destinations is localized.

-server

The server in which the destinations is localized.

-cluster

The cluster in which the destinations is localized.


Optional parameters

-requestDestination

The name of the proxy request destination.

-replyDestination

The name of the proxy reply destination.

-wsdlLocation

The location of the proxy WSDL file. This is a web address.


Example

The following is a minimal example of a sequence of commands to create a fully-functional proxy service with inbound and outbound SOAP over HTTP protocol attachments:

  1. Create the proxy service, where wsgw is the gateway instance:

    • Jython:

        proxyService = AdminTask.createWSGWProxyService(wsgw, ["-name", "MyProxyService", "-node", "MyNode", "-server", "server1"])

    • Jacl:
      set proxyService [$AdminTask createWSGWProxyService $wsgw {-name
       "ProxyService" -node "MyNode" -server "server1"}]

  2. Get the inbound service for the gateway service, where busName is the name of the service integration bus:

    • Jython:

        inServiceName = AdminConfig.showAttribute(proxyService, "inboundServiceName")

      inService = AdminConfig.getid("/
       SIBus:"+busName+"/SIBWSInboundService:"+inServiceName+"/")

    • Jacl:
      set inServiceName [$AdminConfig showAttribute $proxyService
       "inboundServiceName"]

        set inService [$AdminConfig getid /SIBus:$busName/SIBWSInboundService:$inServiceName/]

  3. Add a SOAP over HTTP port, where the SOAP over HTTP 1 endpoint listener is already configured:

    • Jython:

        inPort = AdminTask.addSIBWSInboundPort(inPort, ["-name", "SOAPHTTPPort", "-endpointListener", "soaphttp1", "-node", "MyNode", "-server", "server1"])

    • Jacl:
      set inPort [$AdminTask addSIBWSInboundPort $inPort {-name "SOAPHTTPPort"
       -endpointListener "soaphttp1" -node "MyNode" -server "server1"}]

  4. Complete the configuration of the inbound and outbound services and ports. For example, apply JAX-RPC handlers or WS-Security.

Ensure that all service requesters append an operationMode query string parameter to the address for the proxy service. The value of this parameter is either oneway or requestResponse, and the default is requestResponse. For example:


Related concepts

  • JAX-RPC handlers and proxy operation


    Related tasks

  • Create a new proxy service configuration

  • Modify an existing proxy service configuration


    Related information:

  • Proxy services [Settings] Reference topic