Published Service Properties

In the Policy Manager, all your web services and XML applications are listed under the list of Services and Properties. A different icon is used for each to help you quickly identify each:
In the Policy Manager, all your web services and XML applications are listed under the list of Services and Properties. A different icon is used for each to help you quickly identify each:
Gear_icon.png icon = Web service
XMLObject16.gif icon = XML application
For the first instance, the Web Start Policy Manager takes more time to open the Service Properties window of a SOAP service.
Access the properties of a service to do the following tasks:
  • Disable or enable a service
  • Changing the service name
  • Set a resolution URI
  • Specifying the allowed HTTP methods
  • View or reset the service WSDL
The Policy Manager differentiates between SOAP web services and XML or non-SOAP applications. Collectively referred to as "services", each requires a different publication wizard:
The term
includes both users and groups; user can represent an individual human or machine; service includes both web services and XML applications.
Both web services and XML applications appear in the Services and Policies List list upon publication. Security policies for the services are configured in the policy development window.
Supporting JMS Requests
If a service supports JMS requests, ensure that the WSDL for the service specifies unique values for the following attributes: 
SOAP payload namespace URI (i.e., child elements of SOAP:Body)
Note that an empty string "" is considered a value.
As messages received over JMS cannot be resolved using an HTTP resolution URI, they rely on a unique combination of payload namespace URI and SOAPAction. In practice, this means the Gateway cannot resolve JMS messages if multiple services have been published using identical WSDL documents.
In rare instances, similar but not identical WSDL documents may prevent JMS messages from being resolved. Specifically, the Gateway allows two services to be published using WSDLs that have the same SOAP payload namespace URI, but with different SOAPAction values. In this scenario, JMS requests do not resolve to any service unless the following conditions are met:
  • The inbound JMS queues are configured with a SOAPAction attribute. Do this by setting the “Use JMS message property as SOAPAction in service resolution” setting in Manage JMS Destinations.
  • The inbound JMS requests contain valid values in that attribute
To access the properties for a service:
  • Do either of the following:
    • Right-click the web service or XML application under the Services and Policies list and then select
    • Select [
      ] >
      Service Properties
      from the Main Menu.
      The Published Service Properties are displayed. This dialog organizes the service properties of these tabs: General, HTTP/FTP, WSDL, and UDDI.
      All controls in the Published Service Properties are disabled if any of the following applies:
      - You do not have permission to edit service properties ("Manage [name] Service" role), OR
      - If the policy for the service is currently being edited and there are unsaved changes. This is indicated by the message "Service has unsaved policy changes" next to the [OK] button in the properties dialog).
Configuring the [General] Tab
The [General] tab contains basic information about the service, including settings to disable/enable the service.
Service Display Name
The name of the service as it appears in the services and policies list and in the policy tabs. You can change this name if necessary.
Service ID
The entity ID for the published service. This value is for displayed for reference only and cannot be modified.
Policy GUID
The GUID for the policy. This value is for displayed for reference only and cannot be modified.
Perform WS-Security processing for this service
Select this check box to perform WS-Security processing for the published service. By default, this is not enabled for XML services but is enabled for all other services.
(1) The Gateway performs WS-Security processing on a request message as required by the services policy, even if [Perform WS-Security processing for this service] is not selected. This allows assertions that require WS-Security processing on request messages to run, even when WS-Security processing is disabled in a service. (2) If there are WS-Security assertions in an XML service, be sure to enable WS-Security processing, otherwise these assertions do not work.
Additional Properties
Optionally define additional properties for the service.
Your administrator can help you determine the need for additional properties.
  • To add an additional property, click [
    ] and then enter the
  • To modify a property in the list, select the row and then click [
    ]. Edit the
    as required.
  • To remove a property from the list, select the row and then click [
Select this option to enable a service that has been disabled. When enabled, the red "X" over the icon is removed and the service accepts requests. By default, all services are enabled after publication, except for those services created using the Create WSDL Wizard.
Select this option to disable a service. All requests for a disabled service are rejected. When disabled, a red "X" appears over the icon and the service refuses all requests. Disabling is a good alternative to deleting a service.
Enable policy debug tracing
Select this option to enable tracing of policy execution for the current service. This may help you debug problems in your policy. When tracing is enabled, a green "bug" icon appears over the service icon. For more information, see "Policy Debug Tracing" under Debug a Policy.
(1) Enabling debug tracing creates a debug trace policy, if one does not exist yet. Disabling debug tracing does not remove the debug trace policy. (2) You can optionally allow the trace to inspect the backing policy of an encapsulated assertion.
Only use policy debug tracing for troubleshooting purposes, as it degrades policy performance significantly.
Security Zone
Optionally choose a security zone. To remove this entity from a security zone (security role permitting), choose "No security zone".
For more information about security zones, see Understanding Security Zones.
This control is hidden if either: (a) no security zones have been defined, or (b) you do not have Read access to any security zone (regardless of whether you have Read access to entities inside the zones).
If you are updating a service, you can only choose zones to which you are permitted to update services.
Configuring the [HTTP/FTP] Tab
The [HTTP/FTP] tab contains service resolution settings for both HTTP and FTP protocols and the HTTP methods permitted.
Service Resolution
Use this section to view or change the resolution path for a service.
  • No resolution path: 
    (Applies to web services only) Select this option to set the resolution path to the default Gateway URI "/ssg/soap".
  • Custom resolution path:
    Select this option to enter a custom resolution URI for the service. A custom resolution path is mandatory for XML applications, but optional for web services. The Custom resolution path cannot begin with "/ssg".
For more information, see "About the Resolution Path" at the end of this topic.
(1) Only enter a path that completes the embedded Gateway URL into the field—make sure that it does not duplicate any other Gateway resolution paths. You may include the '*' (asterisk) wildcard in the path to allow for any incoming URL following a certain pattern to resolve to this service. For details on how the wildcards are interpreted, see Validate Against Swagger Document Assertion will be used, the service resolution URI must end with '
' (no quotes), otherwise the service cannot be resolved.
[Check for resolution conflicts]
Click this button to check whether the service is resolvable via HTTP/FTP and which other services have resolution conflicts with this service. If conflicting services are displayed, enter a different Custom resolution path and then check again.
If there are no issues with the resolution path, you see the message "No Conflicts. The service resolves successfully." 
Allowable HTTP Methods
Select which HTTP methods are permitted for incoming requests. The Gateway supports these verbs: GET, PUT, POST, DELETE, HEAD, PATCH, OPTIONS.Select Other to allow any HTTP method name not already listed above.
By default, SOAP web services accept only POST requests, while non-SOAP applications support GET, PUT, POST, DELETE. If you do not select a HTTP method, the service is not accessible through HTTP. However, it could still allow access through non-HTTP transport methods (for example, JMS, FTP, SSH, or email).
Use the "Other" option with care, as it can permit any arbitrary string in the incoming request. Be sure to validate the method name in policy, using the
context variable. You can also place the validation the service policy or in a 'message-complete' global policy fragment.
Configuring the [WSDL] Tab
The [WSDL] tab displays the WSDL document for a published web service. Scroll through the window to examine the WSDL. You can also right-click within the WSDL window to do the following:
  • Search the WSDL:
    Search a node
    from the context menu to jump to a specific node within the WSDL.
  • Copy lines from the WSDL:
    from the context menu to copy the selected lines from the WSDL. You can then paste these lines as text in another application.
The [WSDL] tab is available only for SOAP web services.
Reset WSDL
You can change the WSDL for a published web service with another WSDL document. Once reset, the existing policy becomes active for the resolution parameters extracted from the new WSDL document.
For more information, see Resetting the WSDL for a Service.
Resetting the WSDL is not possible for an internal service or if the WSDL is under UDDI control (see the [UDDI] tab).
You can modify the existing WSDL document for the service by clicking [Edit WSDL]. This opens the Edit WSDL Wizard, which leads you through the editing process. The wizard is prepopulated with the contents of the WSDL document. You can add or remove operations by following the wizard.
Editing the WSDL is not possible for an internal service or if the WSDL is under UDDI control (see the [UDDI] tab).
SOAP version
Select the SOAP version to be supported by the service:
SOAP 1.1
SOAP 1.2
Unspecified (
either SOAP version is accepted)
When a service is first published, the initial SOAP version is based on the bindings that are present in the WSDL, in the order in which they appear.
Allow requests intended for operations not supported by the WSDL
By default, the Gateway only permits SOAP requests for operations supported by the service's WSDL. If you need to override this behavior for the selected web service, select the [Allow requests intended for operations that are not supported by the WSDL] check box.
Select this check box only if you need to do any of the following:
  • Allow SOAP messages that are not explicitly supported in the WSDL.
  • Allow non-SOAP messages to be sent to a SOAP service.
  • Allow encryption of the Body element in the SOAP request to pass through the Gateway (for example, if the Gateway is unable to decrypt the contents of the Body element).
  • Bypass the SOAP version check (e.g., allows a SOAP 1.1 request to be sent to a service marked as SOAP 1.2, although warning messages continue to appear about incompatible XPath namespaces).
To learn more about how the Gateway resolves a request, see Gateway Service Resolution Process.
Specify a custom resolution path (in the [HTTP] tab) if you are enabling the "Allow requests intended for..." feature. Otherwise, a request could fail under the following conditions:
  • A service uses distinct SOAPAction values in its operations, AND
  • A request arrives with a SOAPAction value that is not supported by the service's WSDL.
A custom resolution path is optional if the WSDL for a service does not specify any SOAPAction values or uses the same SOAPAction value for all operations.
Configuring the [UDDI] Tab
The [UDDI] tab displays which Business Service and UDDI registry were used to find the WSDL used to create the service. The settings here affect the available options in the Publish to UDDI dialog.
Original UDDI Business Service
This section is the Gateway's record of how the published service was created. The information makes it possible to place the WSDL under the control of the UDDI registry, enabling the Gateway to monitor it for changes to the endpoint and WSDL.
Click [
] to associate the service with a UDDI Business Service. Do this if you wish to place an existing service under UDDI control, or to change an existing association.
Use the Search UDDI dialog to locate the Business Service to associate with. For more information, see "Searching the UDDI Registry" under Export, Import a Policy.
If there is an existing association, you must click [Clear] first to clear it before selecting another one. If you receive a message stating that the Gateway WSDL is stale, you can refresh it by using [Reset] on the [WSDL] tab of this dialog.
Click [
] to remove an association between the published service and a UDDI Business Service.
You must clear an existing association before you can use [Select] to establish a new association.
It is not possible to clear the original business service if a Gateway endpoint has been published to it or if the original service has been overwritten. In those cases, the publish must be reversed before [Clear] can be used to clear the association. To reverse the publish, use the [Don't Publish] option in the [Service] tab of the Publish to UDDI Settings dialog.
UDDI Settings
When a service was created from a WSDL found in a UDDI registry, this section is enabled and the [WSDL under UDDI control] check box is selected by default.
WSDL under UDDI control
When selected, this check box indicates that the service is associated with a UDDI Business Service and a wsdl:port (binding template). When the WSDL is under UDDI control, the following options are not available:
  • [Service] tab of the Publish to UDDI Settings dialog:
    • Publish Gateway endpoint as BindingTemplate
    • Overwrite existing BusinessService with Gateway URLs
  • [WSDL] tab of Service Properties:
    • Reset WSDL
    • Edit WSDL
If the WSDL cannot be placed under UDDI control, this check box is disabled. For example, if the existing service is overwritten, it is no longer under UDDI control. This check box is also disabled when the action [Publish Gateway endpoint as BindingTemplate] is taken in the [Service] tab of the Publish to UDDI Settings dialog.
Clear this check box if you wish to remove the WSDL manually from under UDDI control. This re-enables all the disabled controls described above.
Monitoring Enabled
This check box is enabled only when [WSDL under UDDI control] is selected. It enables monitoring at the service level. The type of monitoring is determined by the UDDI registry configuration.
When monitoring is enabled, any changes to the Business Service in the UDDI registry are detected by the Gateway and the following occurs:
  • The Gateway downloads the UDDI Business Service. The values from UDDI are validated to match the Gateway's WSDL. If they do not match, the association with the original Business Service is deleted. If they do match, the value of the accessPoint which belongs to the monitored bindingTemplate is checked. If it differs from the existing known endpoint value, the
    context variable is updated to contain the new value.
  • If the [Update WSDL] check box is selected, the Gateway updates its WSDL.
  • If the [Disable service if WSDL has changed] check box is selected, the Gateway disables the published service when the WSDL changes.
Update WSDL
Select this check box to instruct the Gateway to update its WSDL document if changes in the WSDL under UDDI control are detected. The Gateway downloads and checks the WSDL for changes.
  • If there are no changes, no further action is taken.
  • If changes have occurred, then the published service's WSDL is updated.
The Gateway logs and audits at the "Warning" level that the WSDL has changed. The Gateway then updates the
context variable with the service endpoint.
This occurs if the endpoint URL changes in the UDDI even when the WSDL itself has not changed.
Disable service if WSDL has changed
Select this check box to instruct the Gateway to disable the published service if changes in the WSDL under UDDI control are detected.
View Publish to UDDI Settings
Click this button to view the settings in the Publish to UDDI Settings dialog. The information is read only when displayed in this manner. To make changes to the settings, see Publish to UDDI Settings.
About the Resolution Path
A resolution path must be specified when a web service is published. If a custom resolution path was not specified, the default URI "/ssg/soap" is used and only requests directed to this URI are consumed. Should you attempt to republish the same web service, you must specify a different resolution path to differentiate between the two services.
When an XML application is published, specifying a custom resolution path is mandatory. Some resolution paths are reserved for internal use. If you enter a custom resolution path that conflicts with an internal one, you see a warning message.  
The custom resolution path can be entered using the Publish SOAP Web Service Wizard and can be entered, changed, or removed using the Service Properties ([HTTP/FTP] tab). It is displayed in the Services and Policies list next to the service name. For example, the name appears as "ServiceName [/customPath]" instead of simply "ServiceName".
For information on how the Gateway resolves the destination web service, see Gateway Service Resolution Process.
(1) The resolution path for published services applies to both HTTP and FTP-based transports. This allows (for example) consumption of non-SOAP traffic over FTP, multiple versions of the same service consumed over FTP. (2) Since the default service resolution process uses SOAP payload namespace URI and SOAPAction values, customizing the resolution path of a web service allows the same WSDL to be published more than once. Without a customized resolution path, duplication would result in runtime ambiguity.