-deploy: Deploy a web service or callout application

The -deploy command deploys a web service or callout application to the active configuration of the SOAP Gateway server.

Syntax

Read syntax diagramSkip visual syntax diagram iogmgmt -deploy  -w wsdl_file  -r correlator_file  -ttoken_type -ytruststore_type -ptruststore_pwd -htruststore_path

Parameters

Use the following parameters to deploy a web service to the server.
-deploy
Specifies the deployment task.
-w definition_file
Specifies which WSDL file to use for the web service or application. If the file is in the SOAP Gateway WSDL directory (install_dir/imssoap/wsdl), only the file name is required. If the file is anywhere else, you must specify the full path to the file. If the fully qualified path to the file includes spaces, enclose the entire path in quotation marks: " ".
Restriction: For the provider scenario, if the specified WSDL file imports additional XSD schema files, those files must be present in the same directory as the WSDL when it is deployed. If nested XSD references are used, all of the referenced XSD files must be in the same directory as the WSDL. Referencing XSD files using absolute paths, paths starting with a period "(.)"', or the <include> tag are not supported. Nested WSDL files are not supported.

For the provider scenario, web services can share the same XSD schema files, or XSD files of the same name but different content.

For the consumer scenario:
  • Sharing XSD schema files among web services are not supported.
  • Nested XSD import statements are not supported unless you are using Rational® Developer for System z® Version 8.5.1 or later to generate the COBOL copybook from a web service WSDL file for the synchronous callout scenario.
-r correlator_file
Specifies the correlator file to use. If the correlator file is in the SOAP Gateway XML directory (install_dir/imssoap/xml), only the file name is required. If the correlator file is anywhere else, you must specify the full path to the file. If the fully qualified path to the file includes spaces, enclose it in quotation marks (" "). The path cannot include parentheses. Soft links are not supported.
-t token_type
Specifies the type of security token to use.
The valid values for the provider scenario are:
  • SAML11Token
  • SAML11SignedTokenTrustAny
  • SAML11SignedTokenTrustOne
  • SAML20Token
  • SAML20SignedTokenTrustAny
  • SAML20SignedTokenTrustOne
  • UserNameToken

SAML11SignedTokenTrustAny or SAML20SignedTokenTrustAny indicates the signed SAML tokens are trusted regardless of the signer. SAML11SignedTokenTrustOne or SAML20SignedTokenTrustOne indicates that signature must be verified with the certificates in a specified truststore. A truststore, its password, and the absolute path to the truststore must be provided.

The valid values for the synchronous callout scenario are:
  • SAML11Token
  • SAML20Token
Specifying a value for this parameter enables WS-Security for the provider web service or synchronous callout web service. If this parameter is not used, WS-Security is disabled for the service or application being deployed.
-y truststore_type
Specifies the type of the truststore that contains the certificates to use to verify the signature in SAML tokens. The valid values are JCEKS, JKS, and PKCS12. When the token type is set to SAML11SignedTokenTrustOne or SAML20SignedTokenTrustOne, a truststore, its password, and the absolute path to the truststore must be provided.
-p truststore_pwd
Specifies the password for the truststore that contains the certificates to use to verify the signature in SAML tokens. When the token type is set to SAML11SignedTokenTrustOne or SAML20SignedTokenTrustOne, a truststore, its password, and the absolute path to the truststore must be provided.
-h truststore_path
Specifies the absolute path to the truststore that contains the certificates to use to verify the signature in SAML tokens. When the token type is set to SAML11SignedTokenTrustOne or SAML20SignedTokenTrustOne, a truststore, its password, and the absolute path to the truststore must be provided.

Example: Deploying a web service without WS-Security

The following example deploys the file MyWSDL.wsdl, which is in install_dir/imssoap/wsdl (otherwise, the fully qualified path must be specified). The correlator file for this web service is MyCorrelator.xml in install_dir/imssoap/xml directory (otherwise, the fully qualified path must be specified). WS-Security is not enabled.
iogmgmt -deploy -w MyWSDL.wsdl -r MyCorrelator.xml

Example: Deploying a web service that requires a SAML 2.0 unsigned token

The following example deploys a web service with WS-Security enabled, and the token type is SAML 2.0 unsigned token.
iogmgmt -deploy -w MyWSDL.wsdl -r MyCorrelator.xml -t SAML20Token

Example: Deploying a web service that requires a SAML 1.1 signed token

The following example deploys a web service with WS-Security enabled, and the token type is SAML 1.1 signed token. The signature in the token must be verified with the certificates in the specified truststore before the token can be trusted.
iogmgmt -deploy -w MyWSDL.wsdl -r MyCorrelator.xml -t SAML11SignedTokenTrustOne
-y JCEKS –p MyPassword –h /u/ssl/trust.jceks

Example: Deploying a callout application

The following example deploys a callout application.
iogmgmt -deploy -w myCalloutWSDL.wsdl -r myCalloutCorrelator.xml

Example: Deploying a callout application with a SAML 2.0 unsigned token

The following example deploys a callout web service that would pass the user ID information for the user that initiates the IMS callout request in a SAML 2.0 unsigned token to the external web service.
iogmgmt -deploy -w myCalloutWSDL.wsdl -r myCalloutCorrelator.xml -t SAML20Token