This section contains the following topics:
The ALRR Exchange Utility is run from a command-prompt, using the following syntax:
Table 3-1 defines the configuration options available when running the ALRR Exchange Utility.
Generates a
UDDIMappings.xml file by connecting to ALER and populating it with the t-models based on the configured Categorizations. Also, this loads the ALRR Exchange Utility configuration using the -config parameter from the default location. You can customize this file if the t-model already exists in ALSR and map an ALER categorization to a t-model.
For more information about the
UDDIMappings.xml file, see Configuring ALER Categorizations In the UDDI Mappings File.
|
||||
Publishes all the t-models configured in the
UDDIMappings.xml file to ALSR. If a t-model already exists in ALSR, it will be skipped. You need to manually delete the existing t-models if you want the ALRR Exchange Utility to populate those t-models. Also, this loads the ALRR Exchange Utility configuration using the -config parameter from the default location.
For more information about the
UDDIMappings.xml file, see Configuring ALER Categorizations In the UDDI Mappings File.
|
||||
Links a Service in ALER to a Service in ALSR together so that the ALRR Exchange Utility can treat them as the same service. This may be required when the Service in ALER and a service in ALSR are the same but was published to ALER and ALSR using different tools. For example, ALSM (AquaLogic SOA Management) could have published a service to ALSR and the SAM plug-in could have published the same service to ALER. After they are linked, they can be synchronized by the utility.
|
This section describes how metadata is synchronized when are assets exchanged between ALER and ALSR.
This section describes how metadata is synchronized when publishing assets from ALER to ALSR.
Note: | When synchronizing a service to ALSR that was previously synchronized, ALSR does not show the updated values if an ALSR browser instance is already open. Therefore, all the ALSR browser instances need to be restarted to see the updated values. For more information, see the Known Issues. |
Check if the Service asset being published has a related (by configured relation) Business Entity asset, as follows:
Check if the Service asset being published has one or more related endpoint assets, as follows:
File Info
of the endpoint asset.File Info
of the Service asset if the WSDL contains the port info.Check if Categorizations are applied to Service and Endpoint assets, as follows:
Check if Service asset being published has one or more WS-Policy assets related, as follows:
The Registration and Active Status are added to Category Bags. Figure 3-1 illustrates how Policy references appear in ALSR.
Figure 3-2 illustrates how two endpoints that are linked to a service in ALER appear in ALSR.
Figure 3-3 illustrates how the different entities and their relationship show up in the ALER Navigator.
Figure 3-4 illustrates the ALER > ALSR metadata synchronization described in this section.
This section describes how metadata is synchronized when receiving assets into the repository from ALSR.
ALRR Exchange Utility updates the endpoint asset with the performance metrics deposited by ALSM. The UDDIMappings.xml
file contains the mapping between the performance metrics t-models and the keys to ALER custom fields where these metrics are populated. You can also customize the UDDI Mapping file so that the metrics can appear on any tab mapped to any field in the tabs of any custom asset type.
Figure 3-5 illustrates how the performance metrics deposited by ALSM shows up in ALER after the endpoint is synchronized by the Exchange Utility.
Figure 3-6 illustrates how the performance metrics deposited by ALSM appear in ALSR.
Check if the Service asset being received exists and is related to a Business Entity asset, as follows:
If the Service asset is newly created, get the default Business Entity asset type for UDDI Business from the ALER configuration:
Check if an asset exists with that name and type, as follows:
Check if the Service asset being received has one or more Endpoint assets related, as follows:
Check if Categorizations are present in the Category Bag, as follows:
Check if the Service asset being received has one or more WS-Policy assets related, as follows:
Figure 3-7 illustrates the ALSR > ALER metadata synchronization described in this section.
Use the ALER Asset Editor to add the new Endpoint:Web Service
asset type so that the endpoint information can be published to ALSR.
Endpoint:Web Service
asset type.Note: | You can omit this step if the WSDL attached to the Service contains the port information. |
For more information on using the Asset Editor to manage assets, see the ALER Registrar Guide.
Use the ALER Asset Editor to add a new WS-Policy so that the endpoint information can be published to ALSR.
For more information on using the Asset Editor to manage assets, see the ALER Registrar Guide.
The ALRR Exchange Utility tags each published and received Service with information that can be used for querying, as follows:
To query published/received Service information, use the ALER More Search Options feature, as follows:
The More Search Options dialog box opens.
For more information on using the ALER search options, see the ALER User Guide.
The ALRR Exchange Utility uses log4j
for logging the detailed tasks performed. The log file is stored in the <ExhangeUtility Tool Home>
directory. The logging options can be changed by updating the file log4fl.properties
file located in the <ExhangeUtility Tool Home>
directory.
This section describes the known issues when using the ALRR Exchange Utility.
When synchronizing a Service to ALSR that was previously synchronized, there is known issue where ALSR does not show the updated values if an ALSR browser instance is already open. Therefore, all the ALSR browser instances need to be closed to see the updated values.
ALER WSDL import is not currently capable of supporting the import of an XSD into a WSDL document using the WSDL import mechanism. This is considered improper use of the WSDL import element by the industry. An example of the improper usage of the WSDL import element to import an XSD, along with an example of the correct way to import XSD into a WSDL is included. Note that ALER WSDL import does support the importing of WSDL into a WSDL document using the WSDL import element.
ALSB (AquaLogic Service Bus) currently generates WSDLs that incorrectly import XSD using the WSDL import element. This causes a problem in the AL suite due to the fact that these ALSB WSDLs can be parsed and submitted to ALER properly by the AL common Eclipse tooling; however, the ALRR Exchange Utility is not capable of parsing the WSDLs when migrating them back to ALSR (AquaLogic Service Registry).
Example of improper usage of the WSDL import element to import XSD:
<?xml version='1.0' encoding='UTF-8'?>
<definitions name='OrderProcessing'
targetNamespace='http://avitek.com/orderprocessing/definitions'
xmlns:tns='http://avitek.com/orderprocessing/definitions'
xmlns:po='urn:iwaysoftware:ibse:jul2003:createPO'
xmlns:por='urn:iwaysoftware:ibse:jul2003:createPO:response'
xmlns:pos='urn:iwaysoftware:ibse:jul2003:POStatus'
xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
xmlns='http://schemas.xmlsoap.org/wsdl/'>
<import namespace='urn:iwaysoftware:ibse:jul2003:createPO' location='bapipo.xsd'/>
<import namespace='urn:iwaysoftware:ibse:jul2003:createPO:response' location='bapipor.xsd'/>
<import namespace='urn:iwaysoftware:ibse:jul2003:POStatus' location='POStatus.xsd'/> .
Example of proper usage of the XSD import element to import XSD:
<?xml version='1.0' ?>
<wsdl:definitions targetNamespace='urn:listing2'
xmlns:tns='urn:listing2'
xmlns:listing3='urn:listing3'
xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'>
<wsdl:types>
<xsd:schema targetNamespace='urn:listing2'
xmlns:listing3='urn:listing3'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<xsd:import namespace='urn:listing3'
schemaLocation='listing3.xsd' />