To configure the UDDI federation, you need to supply the following details:
The source registry details where the original data is located: host, port, username, password (needed for connecting to the registry for inquiring data).
Also the URLs of the UDDI security and inquiry APIs, to allow the UDDI Client API to connect to the registry.
The target registry details to which the data will be copied: host, port, username, password (needed for connecting to the registry for publishing data).
Also the URLs of the UDDI security, inquiry and publish APIs, to allow the UDDI Client API to connect to the registry.
The data that has to be inquired from the source registry. The types of UDDI object that can be federated are business entities, business services and tModels. Refer to the standard UDDI specification for details of these object types.
The location of the Event Type Store. This is by default <SuiteInstallDir>/common/EventTypeStore/.
The location where further internal components required for the federation are available. This is by default <SuiteInstallDir>/CentraSite/Federation.
You can configure these details in an XML configuration file. A template of the XML configuration file is available in <SuiteInstallDir>/CentraSite/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:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:federationConfiguration xmlns:ns2="http://namespaces.softwareag.com/EDA/Federation/UDDI/Configuration" xmlns:ns3="urn:uddi-org:api_v3"> <sourceRegistryDetail> <host>MyUDDIServer</host> <port>8080</port> <user>root</user> <password>root</password> <securityUrl>http://MyUDDIServer:8080/juddiv3/services/security</securityUrl> <inquiryUrl>http://MyUDDIServer:8080/juddiv3/services/inquiry</inquiryUrl> </sourceRegistryDetail> <targetRegistryDetail> <host>FedTarget</host> <port>53307</port> <user>AdminUser</user> <password>ABCXYZ123</password> <defaultBusinessEntity>Default Organization</defaultBusinessEntity> <securityUrl>http://FedTarget:53307/UddiRegistry/security</securityUrl> <inquiryUrl>http://FedTarget:53307/UddiRegistry/inquiry</inquiryUrl> <publishUrl>http://FedTarget:53307/UddiRegistry/publish</publishUrl> </targetRegistryDetail> <inquiryParams> <find_business> <ns3:findQualifiers> <ns3:findQualifier>caseInsensitiveMatch</ns3:findQualifier> <ns3:findQualifier>approximateMatch</ns3:findQualifier> </ns3:findQualifiers> <ns3:name>Custom Organization</ns3:name> </find_business> <find_service> <ns3:findQualifiers> <ns3:findQualifier>caseInsensitiveMatch</ns3:findQualifier> <ns3:findQualifier>approximateMatch</ns3:findQualifier> </ns3:findQualifiers> <ns3:name>PlainService</ns3:name> <ns3:name>TestService</ns3:name> </find_service> <find_tModel> <ns3:findQualifiers> <ns3:findQualifier>caseInsensitiveMatch</ns3:findQualifier> <ns3:findQualifier>approximateMatch</ns3:findQualifier> </ns3:findQualifiers> <ns3:name>%</ns3:name> </find_tModel> </inquiryParams> <sourceBasicAuthentication>true</sourceBasicAuthentication> <targetBasicAuthentication>false</targetBasicAuthentication> <batchEventEmission>true</batchEventEmission> <batchPublish>false</batchPublish> <timestampBasedUpdate>true</timestampBasedUpdate> </ns2:federationConfiguration>
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:
<defaultBusinessEntity> Default Organization </defaultBusinessEntity>
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:
<businessService serviceKey="uddi:juddi.apache.org:68f6379d-9063-4eaf-b35a-45199c9f0b0a" businessKey="uddi:juddi.apache.org:4375a871-b13e-46ae-b329-c79871efc3f1">
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:
find_business
: search for UDDI objects of
type "business entity".
find_service
: search for UDDI objects of
type "service".
find_tModel
: search for UDDI objects of type
"tModel".
These are the UDDIv3 Inquiry API calls. Their syntax must adhere to descriptions in the section Inquiry API Functions of 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.
Note:
Currently, the federation from an SAP source registry to a target
CentraSite registry only supports HTTP Basic Authentication on the source SAP
registry, i.e. authenticating via AuthToken on the source SAP registry is not
supported. Therefore, the value in the
<sourceBasicAuthentication>
element must be
"true". Similarly, if SAP is the target registry,
then the value in the
<targetBasicAuthentication>
element must be
"true".
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:
The object that is already available in the target registry might have been updated in the source registry and now this object has to be updated in the target registry as well.
The object that is already available in the target registry has not been updated in the source registry, so the objects are identical.
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.