Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer web services - Bus enabled web services > Enable web services through the service integration bus > Configure web services for a service integration bus > Work with the web services gateway


Migrate a v5.1 Web services gateway configuration

In WAS v5.1, the web services gateway was a separable component with its own user interface. In later versions of the product, the gateway is integrated into service integration bus-enabled web services, and re-implemented as a mechanism for extending and linking inbound and outbound services. You use a wsadmin command script to migrate an existing gateway configuration from a v5.1 application server to an application server or cluster on a later version.

Consider whether we have to migrate your existing gateways:

See Coexistence: Preserve or migrate a v5.1 gateway.

You can migrate a v5.1 gateway that is in production use without stopping the gateway; requester applications can then switch over to using the new gateway configuration while the existing v5.1 gateway continues to run.

The migration process takes a v5.1 gateway application whose configuration has been exported to an XML file and uses the exported XML file to configure the same gateway functions on a single application server or cluster on the later version.

To do this you export the v5.1 gateway configuration, then run a script to migrate the exported configuration into a new gateway instance in an existing application server or cluster on the later version.

The v5.1 configuration is migrated as follows:

To migrate an existing gateway configuration from a v5.1 application server to the gateway capability on an application server or cluster on a later version...


Procedure

  1. Remove any filters from your v5.1 gateway.

    You can migrate a gateway that contains filters. However filters do not work in later versions, so you might prefer to remove them from the configuration before migration...

    1. Check whether your v5.1 gateway uses filters. See the WAS v5.1 topic: Listing and managing gateway-deployed filters.
    2. Remove any filters. See the WAS v5.1 topic: Removing filters from the web services gateway.

    After migration, you can recreate your filter functions by using a combination of JAX-RPC handlers and service integration bus mediations. If you migrate a web services gateway that includes a routing filter, you can recreate the filter functions as described in Choosing a target service and port through a routing mediation.

  2. Choose a target server or cluster that is a single server or cluster on the later version, and is part of a network deployment cell.

  3. Configure the target server or cluster as a member of a service integration bus. See Configure the members of a bus.
  4. Configure a Service Data Objects (SDO) repository at cell scope for the target server or cluster.

  5. If you are migrating any EJB bindings, and you want them to continue to use an RPC-encoded binding or any binding other than document literal, add a binding of the correct type to the EJB binding WSDL. This step is necessary because the v5.1 gateway default binding is RPC-encoded, whereas in later versions the default binding is document literal.
  6. Ensure that the source (Version 5.1) application server is running, then use the v5.1 gateway user interface to back up the gateway configuration from the v5.1 application server as a private configuration. For more information, see the WAS v5.1 topic: Backing up a gateway configuration.

  7. Optional: Stop the v5.1 application server.

    If you are migrating a gateway that is in production use, keep the v5.1 gateway running until the gateway configuration on the later version is complete, then switch the requester applications over to using the new gateway configuration while the existing v5.1 gateway continues to run. However both versions of the gateway do not have to be running at the same time, and you might have to stop the v5.1 server before you start the server or cluster on the later version (for example if you are installing the server or cluster on the later version as a direct replacement for the v5.1 server, on the same machine and using the same port numbers).

  8. Start the target application server or cluster on the later version and, for a single server or cluster within a managed cell, the dmgr for the target cell.
  9. Check that all the WSDL documents that were used to define the target services on the v5.1 application server are available at their given locations. If the WSDL location is a UDDI reference, check that the referenced UDDI registry is available.

  10. Optional: If the gateway being migrated uses JAX-RPC handlers and handler lists, ensure that the underlying handler classes are available at run time.

  11. To migrate the exported configuration into a new gateway instance in the application server or cluster on the later version, complete the following steps:

    1. Open a command prompt, then change to the WAS_HOME/util directory.
    2. Run the following command: 
      migratewsgw.ext -C=cell_name [-S=server_name 
       -N=node_name]
                    [-X=cluster_name] -B=bus_name
                     -G=v5_gateway_configuration_file_name
                    [-H=administration_hostname] [-A=administration_port]
                    [-U=gateway_instance_name] [-P=object_prefix]
                    [-username=WAS_user_ID -password=WAS_password]
      where:

      • .ext is the file extension .bat for a Windows system, or .sh for a Unix or Linux system.
      • Square brackets ("[ ]") indicate that a parameter or set of parameters is optional in some circumstances.
      • Either server_name

        and node_name together (for a single server), or cluster_name (for a cluster), defines the server or cluster to which the gateway configuration is migrated.

      • cell_name, server_name

        and node_name (or cluster_name), administration_hostname and administration_port together define the connection to the application server (or cluster) on the later version. server_name

        or cluster_name specifies the name of the target application server or cluster at which endpoint listeners and outbound port destinations are created. If you are migrating to a server or cluster that is part of a managed cell, then administration_hostname and administration_port define the host name and the SOAP administration port number of the dmgr. If you are migrating to a server that is not part of a managed cell, then administration_hostname and administration_port define the host name and port number of the stand-alone server, and are optional. If they are omitted, the command assumes that the intended values are localhost:8880 (that is, the WAS default values for a stand-alone server).

      • v5_gateway_configuration_file_name is the full path and file name for the exported v5.1 private gateway XML configuration file.
      • bus_name and gateway_instance_name together define the gateway instance that you are creating within this bus. The gateway_instance_name is only required if you want to create more than one gateway instance within this bus. If you omit this optional parameter, then a default name is assigned.
      • object_prefix is a string used to prefix the names of the objects defined by the migration process. If omitted, the namespace URI (default value urn:ibmwsgw) for the migrated services is used instead.
      • WAS_user_ID and WAS_password are required if the target application server or cluster is password-protected.

    Optional. If the external web addresses for the migrated services are changed by the migration process, modify the endpoint listener configuration to update these addresses. We must do this if the external web addresses point to the gateway machine rather than to a web server, and we have migrated the gateway to a different machine or to a different port on the same machine.


What to do next

+

Search Tips   |   Advanced Search