Creating a Federation Configuration File

To configure the UDDI federation, you need to supply the following details:

You can configure these details in an XML configuration file. A template of the XML configuration file is available in <CentraSiteInstallDir>/Federation/config/federationConfiguration.xml. You can copy this file and edit it to suit your needs.

After configuring these details, you can start the federation.

Here is a sample configuration file:

The source registry details are provided in the sourceRegistryDetail element.

The target registry details are provided in the targetRegistryDetail element. When the CentraSite registry is the target registry, the port number is by default 53307.

The securityUrl and inquiryUrl elements provide the location of the Security and Inquiry APIs that are required for accessing the UDDI registries. The publishUrl element for the target registry provides the location of the Publish API that is required for publishing the UDDI objects.

The securityUrl, inquiryUrl and publishUrl are optional for CentraSite target registries since these are the default settings.

If the configuration file does not contain the user and password details for the source and target registries, you will be prompted to supply these values when you initialize the federation.

The target registry has another configuration:

This option is to configure the default business Entity (Organization) in the target registry. All business services will be associated with a particular business entity in the source registry as shown here:

The business key refers to a business entity in the source registry. When you try to publish this service to some other registry, it could be the case that the business entity to which this service is associated with may be already available in the target, in which case this service can be published as is in the target registry. If the target does not have the business entity to which the service is associated, you might still want to publish the service separately from the entity. The defaultBusinessEntity element provides the option to provide the default organization in the target registry to which the service must be associated when it is published. If the business key is present in the target, then the service is published without changes, and if the business key is not present, then the business key of the organization referred to in the XML file is associated with the service and it is published. In the example here, the Default Organization refers to the organization (business entity) in CentraSite.

Use the inquiryParams element in the configuration file to specify the objects that you want to select for federation.

Within this element, you can specify the following child elements:

These are the UDDIv3 Inquiry API calls. Their syntax must adhere to the UDDIv3 standard.

Not all of these child elements need to be supplied, so for example if you want to federate only business entities, it is sufficient to provide the find_business element.

The name element within the find_business, find_service or find_tModel element specifies the name of the object or objects to be searched for. You can use wildcards in the name element to search for multiple objects; these are the standard wildcards as described in the UDDI specification. For find_business and find_service you can supply more than one name element.

You can restrict the set of selected objects by using a filter, specified in a findQualifier element. The filter modifies the way in which the value in the name element is interpreted. The available filters are the findQualifiers as described in the UDDI specification. The example above illustrates how to use the findQualifiers to use case sensitivity/insensitivity, and exact/approximate match.

The sourceBasicAuthentication and the targetBasicAuthentication elements define whether the authentication to the UDDI registry should be via authTokens or through HTTP Basic Authentication. They take Boolean values of either true or false.

Authentication to a UDDI registry usually works through the Security API of the UDDI standard through authTokens. The messages to UDDI are sent as SOAP messages over HTTP. Some UDDI registries provide an option to authenticate via HTTP Basic Authentication. CentraSite and jUDDI, for example, provide authentication via authTokens whereas SAP registry provides authentication via HTTP Basic authentication.

So the sourceBasicAuthentication element specifies this option for the source registry. If set to true, it means that the source will be authenticated via HTTP basic authentication and if set to false, the source will be authenticated via authTokens. The targetBasicAuthentication element configures the authentication method for the target registry. If set to true, authentication is done via HTTP Basic authentication and if set to false, the authentication is done via authTokens.

You can control whether the UDDI objects found by the inquiry calls should be sent individually to the target or as a batch containing all of the found objects. If you set batchEventEmission to true, the objects will be sent as a batch. If you set the value to false, the objects will be sent individually.

For example, if the inquiry calls return 10 UDDI objects for federation (these 10 objects could be businesses, services, tModels or mixture of all), and batchEventEmission is true, all 10 UDDI objects are emitted as one single XML event. If batchEventEmission is false, each of the 10 UDDI objects will be emitted individually.

This configuration defines how the UDDI objects should be published. This is in alignment with the behavior of the UDDI Publish API.

If batchPublish is set to true, then events that were batched due to the setting of batchEventEmission will also be published on the target machine as a batch. If an error occurs while publishing one of the batch's objects, this object will not be published and all of the remaining objects in the batch will be ignored. This is the standard behavior of the UDDI Publish API.

If batchPublish is set to false, then events that were batched due to the setting of batchEventEmission will nevertheless be published individually on the target machine. If an error occurs while publishing one of the batch's objects, this object will not be published, but the processing of the remaining objects in the batch will continue.

Details of the publish operation will be provided in a log file.

This is an optimization configuration. During a federation operation, it can happen that an object being federated is already present in the target machine due to a previous federation operation. The following situations can occur:

Before an object is published is the target machine, CentraSite checks if the object already exists on the target machine. If the object already exists, but the timestamps are different, then the object is updated in the target registry. If the object to be published is identical to the object already present, the object is not updated. This results in performance optimization, thereby reducing the number of publish operations to the target registry.

If timestampBasedUpdate is set to true, then CentraSite performs the comparison and updates the target object if needed. If timestampBasedUpdate is set to false, the comparison is not performed and the object is published, regardless of whether the objects are updated objects or not.