Publish to UDDI Settings

The Publish to UDDI Settings dialog is used to publish information to a UDDI registry. You can do the following:
gateway90
The Publish to UDDI Settings dialog is used to publish information to a UDDI registry. You can do the following:
  • Publish a
    API Gateway
    WSDL to a UDDI registry
  • Publish a
    API Gateway
     endpoint as a BindingTemplate in a Business Service in the UDDI Registry
  • Overwrite an existing Business Service in the UDDI registry with corresponding WSDL information from the 
    API Gateway
 
(1) If any 
API Gateway
 endpoint information (for example, cluster hostname or port settings) is changed after the 
API Gateway
 has published to UDDI, the 
API Gateway
will automatically update UDDI so that it contains the correct
API Gateway
endpoint URLs. You can control this behaviour using the uddi.auto_republish cluster property. By default, this property is "true" enables auto update. Set it to "false" to disable the automatic update. (2) If service entity ID resolution is disabled in the Service Resolution Settings dialog, then any service URLs published to UDDI by the 
API Gateway
 will not resolve if consumed.
 
To configure settings for publishing to UDDI
:
  • Do either of the following:
    • Right-click a web service under the Services and Policies list and then select Publish to UDDI.
    • Select [
      File
      ] >
      Publish to UDDI
      from the Main Menu.
The Publish to UDDI Settings dialog appears. This dialog organizes the settings across these tabs: Service, WS-Policy, and Metrics.
The various configuration tabs are as follows.
Configuring the [Service] tab
Publish_UDDI_Settings_Services.png
The [
Service
] tab lets you publish the
API Gateway
WSDL as a 'proxy binding Template' Business Service to a UDDI registry. You can also use it to update an existing Business Service with a new proxy bindingTemplate with a valid keyReference attached for a
API Gateway
 endpoint. The options that are available depend on whether the published service was created from a UDDI registry.
Publishing establishes a link between the
API Gateway
 and the UDDI registry. Once a publish action has been performed, you cannot perform another publish unless you use the [
Don't Publish
] option to reverse the publish action. However, you can still update the
API Gateway
 endpoint, which is the proxy bindingTemplate in the service, by using the [
Manage Meta Data
] option.
If any meta data is added to a BusinessService or bindingTemplate published by the
API Gateway
, that meta data will be preserved should the
API Gateway
y need to update the UDDI.
Setting
Description
Publish Business Services
This option publishes the WSDL from the
API Gateway
as Business Services in a UDDI. Only SOAP with HTTP endpoints from the
API Gateway
WSDL are published to UDDI.
If the
API Gateway
WSDL contains more than one wsdl:service, then more than one UDDI Business Service will be created. The wsdl:service maps 1:1 to a UDDI Business Service.
Complete the following:
  • UDDI Registry
    : From the drop-down list, select the UDDI registry to publish to. The registry must be configured in the Managing UDDI Registries task to appear in this list.
  • Business Entity
    : Click [
    Select
    ] and search for the destination Business Entity. For more information, see Search the UDDI Registry.
  • Update when Gateway WSDL changes
    : Select this check box to have the
    API Gateway
    update the UDDI when the Gateway WSDL changes. These changes may arise from manual user edits, from refreshing the WSDL, or from a UDDI notification causing the WSDL to be redownloaded.
This setting may be changed later, after publishing has occurred.
After publishing, all the URLs in this Business Service in the UDDI will point to the
API Gateway
.
Publish Gateway endpoint as BindingTemplate
 
Available only when the
API Gateway
has a record of the 'original' service in UDDI and the published service is not under UDDI control:
Service Properties
-> [
UDDI
] tab -> uncheck [
WSDL under UDDI control
]
Once this publishing action is performed, the WSDL under UDDI control check box will be disabled; it will be re-enabled only when the [
Don't Publish
] action is taken.
Publishing a
API Gateway
Endpoint
You can indicate whether existing bindings should be removed during publishing.
Remove_Existing_Bindings.png
  • Remove existing bindings
    : Select this check box to have the Policy Manager remove all bindings contained in the original Business Service.
GIF PublishingPublish_Gateway_Endpoints.png
 
  •  
    Publish using GIF
    : When the original service is from a Systinet UDDI, you can choose to publish the
    API Gateway
    endpoint according to the GIF (Governance Interoperability Framework) specification. This option is available only when the WSDL is not under UDDI control.
    Endpoints previously published without using this option are not GIF compliant. To make them compliant, you must first unpublish the endpoint (using the "Don't Publish" option), then re-publish.
  • Endpoint Type
    : If more than one endpoint type is available, select which one to use when publishing using GIF.
Publish Gateway endpoint as BindingTemplate (cont'd)
  • Manage Meta Data
    : This opens the Manage Meta Data dialog to manage the list of keyedReferences. Use it to add, edit, or remove keyed References. For more information on this dialog, see Manage Meta Data.
    It is possible to change the meta data after the endpoint has been published. Modification of the meta data will cause UDDI to be updated.
    This option cannot remove or edit the existing keyedReferences attached to the bindingTemplate in the Business Service on the UDDI registry. This is because the [
    Remove
    ] and [
    Edit
    ] options can only be used on keyedReference entries that were entered using [Add].
Overwrite existing BusinessService with Gateway URLs
 
Available only when the
API Gateway
has a record of the 'original' service in UDDI.
This option updates the entire Business Service to point to the
API Gateway
cluster hostname for all URLs. Note: This overwriting cannot be undone. If the Business Service contains any non SOAP bindings, then they are not removed. Only SOAP + HTTP bindings are removed.
The information that is published to UDDI is taken from the
API Gateway
WSDL.
  •  
    Update when Gateway WSDL changes
    : Select this check box to have the
    API Gateway
    update the UDDI when the Gateway WSDL changes.
 
Once this publishing action is performed, the WSDL under UDDI control check box in the [
UDDI
] tab of the service properties will be permanently disabled. Using the [
Don't Publish
] action will remove all the published bindings.
Don't Publish
This option reverses the publishing effects of the [
Publish Business Services and Publish Gateway endpoint as BindingTemplate
] actions. It will not reverse the overwriting made by the [
Overwrite existing BusinessService with Gateway URLs
] action, apart from deleting the published bindings.
Once the [
Don't Publish
] action has been used to reverse a publishing action, the other three actions are once again available.
Publishing Status
After a publishing action is performed, the status is shown in the [
Service
] tab, next to the action selected:
Status
Description
Published
The information has been successfully published to the UDDI registry.
Publishing
The information is actively being published or updated to the UDDI registry.
Publish failed x times. Set to retry
The publish failed. See Gateway Audit Events or Viewing Logs for details. The publish will be retried if the retry attempts is less than the uddi.wsdlpublish.maxretries cluster property.
Cannot publish. Tried x times. Please select 'Don't Publish' to retry
Unable to publish to the UDDI registry after exhausting the maximum number of times in the uddi.wsdlpublish.maxretries cluster property. To clear this status to try again, run the [
Don't Publish
] action first.
Deleting
The information is being actively deleted from the UDDI registry.
Delete failed x times. Set to retry
The delete failed. The delete will be retried if the retry attempts is less than the uddi.wsdlpublish.maxretries cluster property.
Cannot delete. Tried x times. Please select 'Dont Publish' to retry
Unable to delete from the UDDI registry after exhausting the maximum number of times in the uddi.wsdlpublish.maxretries cluster property. To clear this status to try again, run the [D
on't Publish
] action first.
Configuring the [WS-Policy] tab
Publish_UDDI_Settings_WS_Policy.png
The [
WS-Policy
] tab is used to configure publishing settings for the WS-Policy.
Setting
Description
Publish and Attach WS-Policy
Select this check box to publish the WS-Policy to the UDDI registry. The policy can be attached to the original business service or to all published business services.
The following settings are available only when the Publish and Attach WS-Policy check box is selected:
WS-Policy Attachment Business Service
From the drop-down list, select the target for the WS-Policy attachment. The options that are available depend on the [
Service
] tab and whether there is an "Original UDDI Business Service" selected:
  • If a service has a selected "Original UDDI Business Service", then "Original Business Service" is available.
  • If business services were published (first option on [
    Service
    ] tab), then "Published Business Services" is available.
  • If both of the above, then "Both Business Services" is available.
Publish URL to full policy
The policy published to the UDDI registry can be either the client view of the policy (which is sufficient to allow a client to consume the service) or the full policy (as shown when editing the policy in the Policy Manager). The full policy is only available when the policy is downloaded from a white-listed IP address.
Use the service.passthroughdownloads cluster property to configure white-listed addresses.
Inline policy includes
This check box is used to control how to handle included policy fragments in a WS-Policy registered in the UDDI. (These fragments are added using the Include Policy Fragment Assertion.) It is enabled only when [
Publish URL to full...
.] is selected.
  • Select this check box to insert all the assertions from the policy fragment into the main policy. This way you can see all the assertions from the fragment, but the hierarchy is lost.
  • Clear this check box to show just the "Include Policy Fragment" assertion in the policy. This will retain the policy structure in the fragment but you will not see the individual assertions.
Configuring the [Metrics] tab
The [
Metrics
] tab is available only for services that have been published to a CentraSite ActiveSOA UDDI registry. Ensure that a Policy Enforcement Point target type has been created in Centrasite ActiveSOA and that a target has been created.
To publish metrics to UDDI, ensure that the uddi.centrasite.activesoa.target cluster property is configured with the name of the target as configured target in CentraSite ActiveSOA.
  •  Select the Publish Service Metrics for Published Business Services check box to enable metrics.
The following metrics will be collected:
Total Count
Success Count
Failure Count
Minimum Response Time
Maximum Response Time
Average Response Time Availability
Controlling Access to the WSDL or WS-Policy
When publishing a service (WSDL) or its WS-Policy to UDDI, a remote requestor may attempt to download the published WSDL/WS-Policy from the
API Gateway
after obtaining the WSDL/WS-Policy URL from UDDI. To control who is permitted to download and the extent of what is downloaded, configure these two cluster properties:
  • service.passthroughdownloads
    : This property defines a "whitelist" of who is permitted to download WSDL and policy documents without credentials. By default, only the localhost is permitted. Tip: This cluster property allows the use of IP prefixes/masks to configure a wide range of IPv4 or IPv6 addresses for a whitelist. For example, use "10.7.32.0/24" to permit the address range 10.7.32.0 to 10.7.32.254.
  • service.wsdlDependenciesEnabled
    : This property defines whether any WSDL dependencies may be downloaded in addition to the WSDL itself. Examples of dependencies include child WSDLs or XML schemas that enable the main WSDL to be fully functional.
For more information on these cluster properties, see "Service Settings" in the Gateway Cluster Properties.