Explicit permission gives (positive permission), or revokes (negative permission), access rights to a party to process an action on a specified entity.

Explicit permissions are saved with the entity as special keyedReferences in the categoryBag. For more information, please see Setting ACLs on UDDI v3 Structures and Setting ACLs on UDDI v1 and v2 Structures below.

When no explicit permission is set for the find/get action on an entity, everyone can find/get it. When no explicit permission is set for the save/delete action on an entity, only owner of the entity can save/delete it. This is a standard UDDI access control. When an explicit Permission is set for an action, a completely different access control is used which is defined by the following rules:

Example:

User U1 owns a businessEntity BE. The user U1 defines the explicit get allowed permission to user group G1. Everyone can find the BE, because there is no explicit permission for find and therefore the standard UDDI access control is used. On the other hand, only user U1 (as the owner) and all users from group G1 can get the BE.

BusinessService BS can be moved from one businessEntity BE1 to other businessEntity BE2. By performing the save_service operation on BS, where BS has updated businessKey to point to the BE2. To perform this action, the party must have permission to save BE1, BE2, and BS, because all these entities are changed.

Similarly bindingTemplate BT can be moved from businessService BS1 to businessService BS2. The party who moves it must have save permission on BS1, BS2 and BT.

BusinessService BS hosted in businessEntity BE1 can be projected into businessEntity BE2. The party who projects BS must have save permission on BE2.

ACL logic considers some special pre-published abstract groups during permission evaluation. These abstract groups allow a publisher to give a permission to a specific set of BEA AquaLogic Service Registry users.

ACL permissions are represented as tModels as detailed below:

In UDDI v3, explicit ACL permission is saved in a special keyedReferenceGroup having the tModelKey uddi:systinet.com:acl. This keyedReferenceGroup can contain only keyedReferences to ACL tModels. Only the terms "user" and "group" are allowed in the included keyName, and the keyValue must contain the name of the user or group (according to keyName value).

For example, user demo_john can save (update) following businessEntity even if he is not the owner:

<businessEntity xmlns="urn:uddi-org:api_v3">
  ...
  <categoryBag>
    ...
    <keyedReferenceGroup tModelKey="uddi:systinet.com:acl">
      <keyedReference tModelKey="uddi:systinet.com:acl:save-allowed" 
      keyName="user" keyValue="demo_john"/>
      ...
    </keyedReferenceGroup>
  </categoryBag>
</businessEntity>
  

Under versions 1 and 2 of UDDI, explicit ACL permission is saved as a special keyedReference in the categoryBag. This keyedReference refers to one of the tModels representing ACL permissions. Only the terms "user" and "group" are allowed in the included keyName and the keyValue must contain the name of the user or group (according to the keyName value).

For example, user demo_john can save (update) following businessEntity even if he is not the owner:

<businessEntity ...>
  ...
  <categoryBag>
    <keyedReference tModelKey="uuid:19885bd0-dcf6-11d5-b239-cbbeaea0a8d4" 
                                         keyName="user" keyValue="demo_john"/>
    ...
  </categoryBag>
</businessEntity>
        

	Note
	ACL permissions cannot be set on the bindingTemplate structure because this structure has no categoryBag in UDDI v1/v2.

The key generator tModel is a tModel with a key in the form domain:keygenerator. This tModel permits its owner to save structures with keys in the form domain:string. For example, the tModel uddi:systinet.com:uddiRegistry:demo:keygenerator allows its owner to publish structures with keys like:

These are derived keys of the uddi:systinet.com:uddiRegistry:demo domain.

With one exception, the key generator tModel does not allow the user to save keys from subdomains such as uddi:systinet.com:uddiRegistry:demo:businessService:exchangeRate, that is, derived keys of uddi:systinet.com:uddiRegistry:demo:businessService.

The key generator tModel, however, permits the user to save the key generator for each direct subdomain. For example, the user can save uddi:systinet.com:uddiRegistry:demo:businessService:keygenerator. After creating this second key generator, the user is permitted to save structures with keys of the uddi:systinet.com:uddiRegistry:demo:businessService domain, such as uddi:systinet.com:uddiRegistry:demo:businessService:exchangeRate.

	Important
	To generate keys for a domain, the user must own the domain's key generator tModel. Only the administrator can save structures with assigned keys without having the key generator tModel. To enable this process for other users, the administrator must save the domain's tModel and then change its ownership to the user via custody transfer. For more information, please see Publish Custody Transfer.

The rules above ensure that two users can not create structures with the same key. A complicated situation arises when one user wants to copy UDDI structures from one registry to another while preserving the keys of those structures. There are two problems:

The Affiliated registries mechanism solves both problems. An affiliation is a relationship between two registries. The first registry gives up generation of keys for a certain domain and transfers this privilege to the second registry. This ensures that keys from both registries are unique.

Note

In the examples below we name the two registries 'master' and 'slave'. Moreover there are three people: The person 1 is an administrator of the master registry, this account is called master-admin. The person 2 is an administrator of the slave registry (account slave-admin) and a common user on the master registry (account master-user2). The person 3 is a common user on slave registry (account slave-user3) and a common user on master registry (account master-user3).

The following examples demonstrate the usage of range queries. Suppose that the keyedReferences are placed in the category bag of the find_business request.

greaterThan Only business entities that have a keyedReference with tModelKey equal to tmKey, and a keyValue that is greater than kv, in their categoryBags are returned.

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>greaterThan</findQualifier>
   </findQualifiers>
</keyedReference>            
        

greaterThan and lesserThan Only business entities that have keyedReference with tModelKey that is equal to tmKey, and a keyValue not equal to kv, in their categoryBags are returned.

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>greaterThan</findQualifier>
      <findQualifier>lesserThan</findQualifier>
   </findQualifiers>
</keyedReference>            
        

notExists Only business entities that do not have a keyedReference with a tModelKey equal to tmKey, and a keyValue equal to kv, in their categoryBags are returned.

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>notExists</findQualifier>
   </findQualifiers>
</keyedReference>

notExists and greaterThan Only business entities that do not have a keyedReference with a tModelKey equal to tmKey, and a keyValue greater than kv, in their categoryBags are returned.

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>notExists</findQualifier>
      <findQualifier>greaterThan</findQualifier>
   </findQualifiers>
</keyedReference>

notExists, greaterThan, equal Only business entities that do not have a keyedReference with a tModelKey equal to tmKey, and a keyValue greater than or equal to kv, in their categoryBags are returned.

<keyedReference tModelKey="tmKey" keyValue="kv" keyName="kn">
   <findQualifiers>
      <findQualifier>notExists</findQualifier>
      <findQualifier>greaterThan</findQualifier>
      <findQualifier>equal</findQualifier>
   </findQualifiers>
</keyedReference>

See also Demos, Advanced Inquiry - Range Queries.

A taxonomy, or value set in the terminology of the UDDI specifications, is a tModel which can be used in categoryBags, identifier bags, or Publisher Assertions. This tModel must be in a specific form, so that BEA AquaLogic Service Registry can recognize it as a taxonomy. The tModel must be categorized with the type of taxonomy and, optionally, with information concerning whether and how to validate the values in keyedReferences.

The UDDI specification distinguishes four types of taxonomies: categorizations, categorizationGroups, identifiers, and relationships.

The publisher of a taxonomy can decide whether the values in keyedReferences within the taxonomy will be checked or not.

The creator of the taxonomy must specify types of keyValues by assigning the appropriate comparator reference (comparator tModel) of the systinet-com:isOrderedBy taxonomy to the categorization taxonomy you want to use to categorize a UDDI entity. The following types of key values types are supported:

For example, the tModel of the categorization taxonomy with numeric key values must have the following keyedReference in its category bag:

<keyedReference tModelKey="uddi:systinet.com:isOrderedBy"
   keyValue="uddi:systinet.com:comparator:numeric"/>  
        

Figure 42. Example of Numeric Categorization

Figure 42 shows how the demo:location:floor taxonomy from Demo data can be assigned numeric key values.

Important

If you change type of keyValues of the taxonomy and there are entities in the BEA AquaLogic Service Registry that were already categorized with the taxonomy, the BEA AquaLogic Service Registry administrator must execute the task Transform keyed references. The button for executing this task is located in the Registry Console under the Manage tab, Registry Management link. See Administrator's Guide, Access Registry Management

Custom Ordinal Types  ^Locate

You can define your custom ordinal types. To demonstrate possible extensions, BEA AquaLogic Service Registry contains two demo comparators:

• systinet-com:comparator:date

• systinet-com:comparator:stringToLowerCase

Let's assume you want to create a taxonomy with date values in keyValues. You must mark the taxonomy tModel (that is, add the following keyedReference into its categoryBag) by <keyedReference tModelKey="uddi:systinet.com:isOrderedBy" keyValue="uddi:systinet.com:comparator:date"/>. It is quite easy because there is a demo comparator for date in the registry. Imagine the date comparator is not present. Take the following steps to create it in the registry:

1. Create a transformer service that transforms the date value into a string or numeric value. The transformer service must implement TransformerKeyedReferenceApi and add this class to the BEA AquaLogic Service Registry class path.

2. Create a new comparator tModel for date. The tModel must be categorized as a comparator using the systinet-com:comparator taxonomy. The comparator must refer to the transformer service. This reference is specified by the taxonomy IsTransformedBy (where "uddi:cba104c0-fb5c-11d8-8761-eb2505508761" is the key of the bindingTemplate with the specification of the transformer service.

Important

If you change implementation of the of the transformer service of the taxonomy and there are entities in the BEA AquaLogic Service Registry that were already categorized with the taxonomy, the BEA AquaLogic Service Registry administrator must execute the task Transform keyed references. The button for executing this task is located in the Registry Console under the Manage tab, Registry Management link. See Administrator's Guide, Access Registry Management

Figure 43 shows the tModel references for date categorization ordering. It describes a purchase order document that has been mapped to BEA AquaLogic Service Registry via XML-to-UDDI functionality, and then categorized by the acceptancedate taxonomy. The categorization taxonomy must refer to the comparator tModel uddi:systinet.com:comparator:date that references a bindingTemplate with the location of the date transformation service.

Figure 43. Example of Custom Categorization (date)

The transformer service is called whenever the appropriate keyedReference is processed. If any entity contains the keyedReference with a taxonomy tModel whose type is custom then the transformer service is called to discover the correct (that is, transformed) keyValue of the keyedReference. Such transformed values are stored into the database. If you want to find entities by this keyedReference (the keyedReference with the same taxonomy tModel), the service is called again to get the transformed value. Transformed values are used for the saving and searching of keyedReferences.

See Administrator's Guide , Editing Taxonomies how to edit taxonomy type.

This section demonstrates the basics of taxonomy API and taxonomy persistence format. A comprehensive description of the Taxonomy API can be found in the Developer's Guide, Taxonomy.

	Note
	For clarity, we use an XML representation, but you can achieve the same results with Java objects.

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0" 
        xmlns:uddi="urn:uddi-org:api_v3"
         check="false">
    <tModel tModelKey="uddi:systinet.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
</taxonomy>
  

Each taxonomy, in order to be saved, requires a valid tModel. While it must contain a tModelKey and a name, you do not need to set the content of the categoryBag.

Let's enhance the previous example and convert the taxonomy from unchecked to checked. Checked taxonomies must contain Validation. In this example, the taxonomy is checked by the Custom Validation Web service located at http://www.foo.com/MyValidationService.wsdl.

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0" 
        xmlns:uddi="urn:uddi-org:api_v3"
         check="true">
    <tModel tModelKey="uddi:foo.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
    <validation>
        <bindingTemplate bindingKey="" serviceKey="" xmlns="urn:uddi-org:api_v3">
            <accessPoint useType="endPoint">
               http://www.foo.com/MyValidationService.wsdl
            </accessPoint>
            <tModelInstanceDetails>
                <tModelInstanceInfo 
                        tModelKey="uddi:uddi.org:v3_valueSetValidation"/>
                <tModelInstanceInfo 
                        tModelKey="uddi:systinet.com:demo:myTaxonomy"/>
            </tModelInstanceDetails>
        </bindingTemplate>
    </validation>
</taxonomy>
  

The validation element must hold the bindingTemplate identifying the validation Web service or categories structures. In this example we chose bindingTemplate. It must contain complete accessPoint and tModelInstanceDetails must hold the Valueset_validation API and tModelKey of the saved taxonomy. If the serviceKey is specified and if the businessService already exists, it must be part of the Operational Business Entity.

	Important
	Be aware that the service will be replaced during the save_taxonomy process.

If you can provide a list of allowed values, you do not need to implement your own validation Web service. Just provide the allowed values inside the categories structure (as shown below) and the Internal Validation Service will be responsible for validation of the keyedReferences.

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0" 
        xmlns:uddi="urn:uddi-org:api_v3"
         check="true">
    <tModel tModelKey="uddi:foo.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
    <validation>
        <categories>
            <category keyName="Value A" keyValue="A"/>
            <category keyName="Value B" keyValue="B">
                <category keyName="Value B1" keyValue="B1"/>
                <category keyName="Value B3" keyValue="B3" disabled="true" />
            </category>
            <category keyName="Value C" keyValue="C"/>
        </categories>
    </validation>
</taxonomy>
  

As you can see, you can arrange your values hierarchically. This is useful for the Registry Console that implements the drill-down pattern. If you really need, you can even specify bindingTemplate along with the categories structure, but its accessPoint must point to the Internal Validation Service.

BEA AquaLogic Service Registry comes with the following predeployed taxonomies:

Registry Console is comprised of the following objects:

A: Main Menu Tabs 

B: Menu Bar Sub menu options are located here.

Figure 47. Registry Console Overview

C: History path (breadcrumbs) This area displays the log of your recent actions. You can return to any of these previous actions by clicking on the hyperlinks.

D: User Actions This area contains several control elements that enable a user to:

E: Tree Display Area A tree of available objects displays whenever applicable. It is displayed when viewing a business entity and its child objects and when the user may want a hierarchical overview of the UDDI workspace (such as when publishing).

F: Main Display Area Information chosen from the tabs and the tree display is made available in the Main Display Area.

G: Display Tabs These tabs allow the user to control the main area's display based on information type. A plain listing of all business properties would be very long and very difficult to read. Dividing the properties into tabs reduces the amount of information and improves page readability. The displayed information changes with the context.

H: Action Buttons The action buttons allow you to perform operations on the contents of the main display.

I: Resizing Bar This feature includes several enhancements to common web-based GUIs. If the content is too wide, you can drag and resize the tree window to fit all contents. The scrolling logic also applies to the main display area and makes it possible to keep all control elements of the interface on screen in any situation.

J: Action Icons There are two icons in this area. The first one allows you to refresh the page content, second one will open the product documentation page.

K: Action Icons  Icons from this area allow you to switch on/off display tabs and open the current page in the printer friendly mode.

L: Context Menu The context menu displayed in Figure 48 is available by right mouse click on a node's icon in the tree display area.

Figure 48. Context Menu

For more information, please see Figure 47.

You can manage your user account, user groups, and favorite taxonomies under the Profile menu tab.

Figure 49. Profile Menu Tab

To update your account properties, select My account and click the Edit Account button

Figure 50. View Account

Field descriptions (self-explanatory fields are omitted):

To maintain user groups, click the Groups link. From the Groups screen, you can:

Figure 51. View User Groups

favorite Taxonomies  ^Locate

You can manage your favorite taxonomies under the Profile tab. You can define which taxonomies will be present in the list of your favorite taxonomies. Favorite taxonomies help you to search and categorize UDDI entities.

To manage your list of favorite taxonomies:

1. Click on the Profile menu tab. Click on the favorite taxonomies link. This returns the list of your favorite taxonomies shown in Figure 53.

2. Click Filter to search taxonomies by name.

3. Check the boxes for all taxonomies you wish to include, and click the right-pointing arrow to copy them to the favorite taxonomies table.

4. Once taxonomies are added, click the Save button to update the registry.

Figure 53. Manage favorite Taxonomies

In this section, we will show you how to browse taxonomy structures to discover UDDI entities categorized or identified by taxonomies. You can also define a taxonomy filter and put your search criteria to a query. We present a demo data set that is installed with BEA AquaLogic Service Registry. This demonstration set is designed to help familiarize you with the registry.

To browse taxonomies and UDDI entities:

	Note
	The favorite taxonomies option appears in the drop down list only if your list of favorite taxonomies is not empty. To add a taxonomy to your favorites, follow the direction in favorite Taxonomies. The list of enterprise taxonomies is defined by an administrator. For more information, see Taxonomy Management in the Administrator's guide.

Initially, the filter contains all taxonomies except system taxonomies. Icons next to the drop down list serve to show/hide categorized entities, and show all/suppress empty categories.

Drill down through the taxonomy tree to see all taxonomy categories. Those with sub-categories can be expanded and collapsed.

When you browse internally checked taxonomies you can see their value set to see UDDI entities categorized by these key values. For unchecked or externally checked taxonomies, you can search UDDI entities by key values. We will show you how to browse an unchecked taxonomy from the demo data.

To browse the demo data using demo:location:floor taxonomy:

You can also add this search criterion to a query.

Define Filter  ^Locate

You can reduce the number of taxonomies in the taxonomy list by defining a taxonomy filter. To switch from taxonomy browsing to filter definition, click on the filter link in the lower left corner. The page shown in Figure 56 will appear.

Figure 56. Taxonomy Filter

You can filter taxonomies by name using the wild card characters % and _. You can specify taxonomy type, compatibility, and a validation type. Once you define the filter criteria, click Apply filter. This will return you to the browse taxonomy page.

Define Query  ^Locate

You can also combine search criteria in a query. To add a search criterion to a query, use the button Add to query shown in Figure 55. Then, you can expand another taxonomy and specify a new criterion. The page shown at Figure 57 presents the query displaying business entities located on the 5th floor (demo:location:floor taxonomy) having Headquarter department as the superior department (demo:hierarchy taxonomy).

Figure 57. Query

To remove a category from the query, right-click on the query and select remove from query from the context menu.

	Note
	The query definition is not persistent. Once you leave the Browse menu tab, the query will disappear.

BEA AquaLogic Service Registry search function allows you to perform the following searches:

In the Search section, we present a demonstration data set that is installed with BEA AquaLogic Service Registry. This demonstration set is designed to help familiarize you with the registry.

	Note
	BEA AquaLogic Service Registry supports the use of wildcard characters. You can use both % and _. Use % in place of any number of characters and spaces. For example, if you wish to find all business beginning with A, type A%. Use the underscore wildcard (_) in place of any single character. For example, to find Dan or Dane, type Dan_.

See Find Business by Categories how to use range queries functionality.

Find Business  ^Locate

In this section, we cover locating business entities using a number of different methods. You can locate business entities by:

• Name

• Categories

• Identifiers

• Discovery URL

• tModel

For each find method, you can specify qualifiers located on the Find Qualifiers tab of the Search panel.

Figure 58. Find Qualifiers

Find Business by Name  ^Locate

To find a business by name:

1. Under the main Search tab, click the Businesses link.

2. Click the Add Name button in the Search panel.

3. Type in the business name, such as IT from the pre-installed demo data. Then click the Find tab at the bottom right corner.

   To see all businesses, type the wildcard % and click Find.

4. The search result will appear on the Results panel. Click on the link with the business name, this opens the page shown at Figure 59.

   Figure 59. View Business Detail

   

Find Business by Categories  ^Locate

In this section we will show you how to search for business entities by categories. We will use demo data to demonstrate how to find all departments located on specific floors. Also, an example how to use range queries will be shown.

To find a business by category:

1. Under the main Search tab, click the Businesses link

2. Click the Categories tab, then click the Add category button. This returns a list of available taxonomies.

   You can switch the Show drop down list from favorite taxonomies to see all taxonomies. To manage favorite taxonomies see User Profile.

3. Click on the desired taxonomy.

   The taxonomy is shown as a tree; its sub-branches include categories.

   Select demo:location:floor from our demo data.

4. Now you can enter Key name and Key value.

   Type 1 in the box labeled Key value and then click the Add category icon.

   Figure 60. Find Business by Category

   

5. Once a category is added as your search criteria, click Find.

You will get the department with that is located on the first floor. If you want search for all departments located on higher floors you must use range queries functionality. We will continue with the previous search.

1. Click the tab Search to return to the Find business by categories page.

2. Click the Edit category icon. The page shown in Figure 61 is returned.

   Figure 61. Find Business by Range Category

   

3. From the Operator drop down list, select the > operator, and click the Update icon.

4. Click Find. You will get all departments located higher than the first floor.

Find Business by Identifier  ^Locate

In this section we will show you how to find a business entity by identifier. We will use demo data to demonstrate how to find departments by their department number identifiers.

To find a business by identifier:

1. Under the main Search tab, click the Businesses link

2. Click the Identifiers tab. Then click the Add identifier button. This returns a list of available taxonomies.

3. Click on the desired taxonomy

   The taxonomy is shown as a tree with its sub-branches including categories.

   Select demo:departmentID from the demo data.

4. Now you can enter Key name and Key value.

   Type 002 in the box labeled Key value, and click Add identifier.

   Figure 62. Find Business by Identifier

   

5. Once the Identifier is added as your search criteria, click Find.

Find Business by Discovery URL  ^Locate

To find a business entity by discovery URL:

1. Under the main Search tab, click the Businesses link.

2. Select the Discovery URLs tab.

3. Type in the discovery URL and click Find.

Direct Get  ^Locate

You can also use Direct get from the Search menu tab to retrieve data from BEA AquaLogic Service Registry when you know the key of the UDDI structure you want to retrieve. BEA AquaLogic Service Registry allows you to specify keys for both UDDI version 2 and UDDI version 3. Click the Find by v2 tab if you want to search using UDDI v2 keys.

Figure 63. Direct Get

Direct Get of XML Structures  ^Locate

You can also acquire the XML form of businesses, services, bindings, and tModels for use in automated processing by entering the key of the structure into a URI.

The form of the URI is:

http://<hostname>:<port>/uddi/web/directGetXml?<structureKey>=<key>

URI Examples Note that UDDI v3 is assumed by default.

• http://localhost:8080/uddi/web/directGetXml?businessKey=uddi:systinet.com:uddinodebusinessKey

• http://localhost:8080/uddi/web/directGetXml?serviceKey=..

• http://localhost:8080/uddi/web/directGetXml?bindingKey=..

• http://localhost:8080/uddi/web/directGetXml?tModelKey=..

Example with Login This URI includes username and password.

• https://localhost:8080/uddi/web/directGetXml?businessKey=uddi:systinet.com:uddinodebusinessKey&userName=admin&password=changeit

Example with UDDI Version Specification Use this format when getting information associated with v1 and v2 structures.

• http://localhost:8080/uddi/web/directGetXml?businessKey=8f3033d0-c22f-11d5-b84b-cc663ab09294&version=2

Find WSDL  ^Locate

You can find all WSDL documents published in BEA AquaLogic Service Registry. When you supply the WSDL location URI, you can review how artifacts of the WSDL document are published in BEA AquaLogic Service Registry. The following criteria: a WSDL document location, a tModel key, a business service key, and a binding template key can be used. To search for a WSDL document in BEA AquaLogic Service Registry:

1. Select the Search menu tab and click the WSDL link. The page shown in Figure 64 will appear.

2. Click the Find all published WSDLs button, or

   Enter WSDL location URI , then click Examine this WSDL button.

Figure 64. Find WSDL

Find XML  ^Locate

You can search for an XML document in BEA AquaLogic Service Registry according to location URI of the XML document.

To search an XML document:

1. Select the Search menu tab and click the XML link. The page shown in Figure 65 will appear.

2. Enter a location and click Find.

Figure 65. Find an XML Document

Find XSD  ^Locate

You can search for an XML Schema in BEA AquaLogic Service Registry according to location URI of the XML document.

To search an XML document:

1. Select the Search menu tab and click the XSD link. The page shown in Figure 66 will appear.

2. You can search by the location of the XML Schema document, namespaces, and by xsd:elements and xsd:types defined in the XML Schema document. Once you specify the search criteria, click Find.

Figure 66. Find XSD

Find XSLT  ^Locate

To search an XSL transformation:

1. Select the Publish menu tab and click the XML link. The page shown in Figure 67 will appear.

2. You can enter the location of the XSLT. You can also search according to input and output XML schemas Search criteria for an XML schemas can be specified by tModel key or namespace. If you click on Select XML Schema you can specify additional criteria for the XML Schema, then select an XML Schema from the XML Schema list.

3. Before you click Find, click the Update icon if you specified to be search according to an XML Schema.

Figure 67. Find XSLT

Publishing in BEA AquaLogic Service Registry has several components:

	Note
	You must be logged into BEA AquaLogic Service Registry to publish to it. There is a limitation of how many UDDI structures a user can store. See Administrator's Guide, Account Limits

The main Publish page is divided into two panels. The left panel displays UDDI data structures that belong to the logged-in user or to which this user has access permissions. The panel on the right displays details about the data structure selected in the left panel. As you can see, if no structures are selected, buttons for adding businesses and tModels are displayed.

Figure 68. Publish Page

Publishing a Business  ^Locate

This section explains how to publish a businessEntity and edit businessEntity-related structures:

• Add business name and description

• Add Contact

• Add a Discovery URL

• Add a Category

• Add an Identifier

• Add Business Services

• Add Projected Services

• Assert Business Relationships

To publish a business:

1. Click the Add Business button in the right-hand panel of the publish page, or select Add Business from the context menu that appears when you right-click the Business Entities node.

   Figure 69. Add Business

   

2. Enter the business name and a description, then click Add Business.

3. The business will appear in the left tree panel under the Business entities node

To edit a business entity:

1. Select the Publish menu tab.

2. Click the Publish link.

3. In the left tree panel, click on the business entity node you wish to edit.

   Figure 70. Edit Business

   

4. After you modified the business entity, click the Save changes button.

Adding a Contact  ^Locate

The contact structure provides you with a space where you can list the people associated with the business entity. It is comprised of six properties: name, phone, email, address, description, and use type.

It is recommended that you use the description field to give a brief explanation of how the contact should be used.

Use types can be used to indicate the expected way in which the contact should be used. For example, "New Franchises", "Sales contact", "Technical Questions".

To add a contact:

1. On the Contacts tab of the Edit business or View business page, click the Add contact button. This displays the Add contact page where you can specify the contact's name and use type, as shown in Figure 71:

   Figure 71. Add Contact

   

2. Click Add contact.

3. Build your lists of information for descriptions, phone numbers, and addresses. Each collection page, with the exception of Address collection, functions in the same manner. Click the Add button for the element you want to add. You will see two or more edit fields to be completed.

   	Important
   	Once the fields have been edited, you must click the Update icon on the right.

   For addresses, click the Addresses tab. On this tab, add, edit, or delete existing address structures by clicking through the appropriate buttons.

   When you add or edit an address, fill in the desired fields, add the data to your list, and click Update when finished.

4. Once you have updated all of the contact's information, click Save changes at the bottom of the Edit contact page. You will see the name and use type of your new contact entry in the contacts list.

Adding a Discovery URL  ^Locate

To add a Discovery URL:

1. On the Edit business page click on the Add discovery URL button at the bottom of the Discovery URLs tab.

2. Complete the Discovery URL and Use Type edit fields with the relevant data.

3. When the fields are complete, click Update on the right to add this information to the list.

4. Click Save changes

Adding a Category  ^Locate

With categories you can make your business more visible to searches by associating it with a number of accepted taxonomies. These taxonomic categories identify a business and its services by location, product or service line, and industry.

BEA AquaLogic Service Registry comes with keys for three basic checked taxonomies by default: These are the ISO 3166 geographical classification system and the NAICS and SIC industry and product classifications.

A key is also provided for Microsoft GeoWeb 2000, but as this is an unchecked taxonomy, key names and key values must be entered by hand.

To add a category to your list:

1. On the Categories tab of the Edit business page, click the Edit button. If there are already categories associated with this business entity, a list of them will be returned along with the Add category button. Otherwise, only the button will be displayed.

2. Click the Add category button beneath the Categories tab. This returns a list of available taxonomies from which you can choose categories to add to the list.

3. Click on an available taxonomy. Checked taxonomies will expand to a tree of categories valid for that model. You can type a known key name in the search box for faster retrieval. Note that larger branches are limited to ten items per page.

4. You can also search for the name of the taxonomy through the search box at the top of the taxonomy form. Use the starts with, contains, and exact match radio buttons as necessary. Like standard wild cards, these buttons search for the entered string as specified. For example, The pattern Cana, when used with the starts with button and a geographic taxonomy, returns the set {"Canada" "Canarias"}. The result set is limited to a maximum of 250 items.

   	Note
   	If you provide too broad a search pattern, the resulting list will be truncated to 100 items.

   With unchecked taxonomies (for example, Microsoft's GeoWeb taxonomy), it is possible to supply the key name and value through edit fields.

5. To add multiple categories, for example Albania and Armenia from the uddi-org:iso-ch:3166:1999 taxonomy, check the boxes to the right of those key names, and click Add category. If you would like to add categories from different pages, you must click Add category on the first page before continuing to the next page containing your selections. For example, to choose Albania and Kazakhstan:

   1. Select Albania and click Add category.

   2. Click Add category on the Find service page.

   3. Click the link for page 8 on the expanded Find service page.

   4. Check the box next to Kazakhstan and click Add category.

   Figure 72. Add Category

   

6. When you find the taxonomic classification you want, click the Add category button for checked taxonomies. For unchecked taxonomies, click Add category once the edit fields have been completed.

Adding an Identifier  ^Locate

You can also make your organization more visible by supplying any of your public or private identifiers, such as D-U-N-S, Tax, or Geographical Locator numbers to the registry. UDDI identifier structures are composed of the following elements:

tModel Key

Identifies a namespace or service in which the key name and key value have significance

keyName

The name or description of the key being used

keyValue

The value of the key

To add an identifier to your list:

1. On the Edit business page, switch to the Identifiers tab.

2. Click the Add identifier button at the bottom of the Identifiers list.

3. Choose the identifier type from the displayed list of available taxonomical tmodels. This returns a field in which you enter key names and key values.

4. When you have filled in the fields, click the Add identifier button to the right to add the new identifier to the list.

	Important
	If you use a tModel for a checked identifier, the key value must be of a recognizable form and value. For example, if you want to use a uddi-org:isReplacedBy key, you must supply the valid business entity UUID key in the keyValue field. Failure to do so will generate an error when you attempt to submit your business data to the database.

Publishing a Binding Template  ^Locate

Once you have declared and defined a business service, you must establish how current and potential business partners can access that service, a technical description of the service including where it can be found. This is accomplished through bindingTemplates.

A bindingTemplate represents a Web service instance where you obtain (among other things) the access point of an instance of the parent business service. Every bindingTemplate has a unique bindingKey for identification. (An access point contains contact information such as a URL, email address, or telephone number used to locate the service.)

The AccessPoint in a bindingTemplate structure can contain a URL of the endpoint of the web service. If there is more than one businessEntity that provides the same business service we recommend you reuse this information in a bindingTemplate. Create a bindingTemplate on the businessService that holds technical information. Other businessServices should contain bindingTemplates with accessPoints containing the key of the first technical bindingTemplate. These accessPoints should also contain useTypes with the value hostingRedirector.

	Note
	Alternatively, reference to another bindingTemplate can be stored in a hostingRedirector structure instead of in an accessPoint. However the hostingRedirector structure (not the hostingRedirector value of useType) is a relic of UDDI v2 and is deprecated in UDDI v3.

To add a bindingTemplate:

1. Select the Publish menu tab and click the Publish link

2. In the left panel, click on the service to which you want to add a binding. The right display area will show service details. Select the Bindings tab and click the Add Binding button.

   Alternatively, right-click the service node to which you want to add a binding, and select Add Binding from the context menu.

   Figure 74. Add Binding

   

Publishing a tModel  ^Locate

The tModel is a structure that takes the form of keyed metadata (data about data). In a general sense, the purpose of a tModel within BEA AquaLogic Service Registry is to provide a reference system based on abstraction. Among the roles that a tModel plays in UDDI is the ability to provide and to describe compliance with a specification or concept, to a taxonomy, for example.

To publish a tModel:

1. Select the Publish tab, and click the Publish link.

2. On the right Publish panel, click the Add tModel button.

   Alternatively, right-click on the tModels node in the left panel and select Add tModel from the context menu.

   Figure 75. Add tModel

   

3. Enter tModel name and description, and click the Add tModel button.

	Note
	If you delete an unused tModel, the tModel will be deleted from the database. The BEA AquaLogic Service Registry Administrator can change this behavior that tModels will be only marked as deleted. See Administrator's Guide, Node.

Adding a Category  ^Locate

In this section we will show you how to assign demo:location:floor taxonomy to the numeric ordering as show at Figure 42.

1. Log on as demo_john user. ( password is the same as the username).

2. Click the Publish tab in the main menu. Click on the tModel demo:location:floor item in the tree in the left part of the page. Edit tModel 'demo:location:floor' page will appear.

3. Click Add category button. A taxonomy list will appear.

4. Select the taxonomy systinet-com:isOrderedBy, enter Key value uddi:systinet.com:comparator:numeric.

5. Click the button Add category , then Save changes button.

Publishing Subscriptions  ^Locate

Subscriptions give you the ability to register interest in receiving information about changes made to BEA AquaLogic Service Registry. It allows the monitoring of new, changed, and deleted UDDI structures. Each subscription has a filter that limits the subscription scope to a subset of registry entities.

You can establish a subscription based on a specific query or set of entities in which you are interested. Query-based subscriptions notify the user if the result set changes within a given time span; entity-based subscriptions notify the user if the contents of the specified entities change.

Subscriptions enable:

• notification of the registration of new businesses or services

• monitoring of existing businesses or services

• acquiring registry information for use in a private registry

• acquiring data for use in a marketplace or portal registry

This filter should be one of the following ordinary UDDI inquiry calls:

• find_business

• find_relatedBusinesses

• find_service

• find_binding

• find_tModel

• get_businessDetail

• get_serviceDetail

• get_bindingDetail

• get_tModelDetail

Figure 77. Add Subscription

Adding Subscriptions  ^Locate

To add new subscription:

1. Click on the Subscriptions link under the Publish menu tab to display the Subscriptions page.

2. Click the Add subscription button to display the Add subscriptions page shown in Figure 77.

3. Click Change filter to specify a filter for your subscriptions. This returns the Subscription filter type page.

4. Select the filter type from the drop down list labeled Subscription filter type.

5. Click Select filter.

6. Set the filter properties in the same way you would for ordinary search calls.

7. Click the Preview results button to check filter results.

8. Click Save filter to return to the page with the filter settings shown in Figure 77.

9. Fill in the other subscription fields if needed. These are described below.

Notification Listener Types  ^Locate

Figure 78. Add Subscription - Email Notification Listener Type

• Subscription filter - Specifies on which UDDI structure change the notification will occur.

• Notification listener type - Select notification listener type

  • Email address

  • Service endpoint

  • Binding template

• Email address - Email address to which notifications will be sent

• XSLT transformer tModel - tModel that references XSLT

• Business service and Business entity - Business service and business entity to which the bindingTemplate representing the notification listener service will be saved. These drop down lists lists only business entities and business services under which you have the permission to create the binding template.

• Notification interval - Specifies how often change notifications are to be provided to a subscriber. Required only for asynchronous notifications.

• Expires after - Specifies the period of time for which the administrator would like the subscription to exist.

• Max entities - Contains the maximum number of entities in a notification returned to a subscription listener.

• Brief - Controls the level of detail returned to a subscription listener.

Figure 79. Add Subscription - Service Endpoint Listener Type

• Subscription filter - Specifies on which UDDI structure change the notification will occur.

• Notification listener type - Select notification listener type here.

  • Email address

  • Service endpoint

  • Binding template

• Notification listener endpoint - URL to which the notification will be sent

• Business service and Business entity - business service and business entity to which the bindingTemplate representing the notification listener service will be saved. These drop down lists lists only business entities and business services under which you have the permission to create the binding template.

• Notification interval - Specifies how often change notifications are to be provided to a subscriber. Required only for asynchronous notifications.

• Expires after - Specifies the period of time for which the administrator would like the subscription to exist.

• Max entities - Contains the maximum number of entities in a notification returned to a subscription listener.

• Brief - Controls the level of detail returned to a subscription listener.

Figure 80. Add Subscription - Binding Template Listener Type

• Subscription filter - Specifies on which UDDI structure change the notification will occur.

• Notification listener type - Select notification listener type here.

  • Email address

  • Service endpoint

  • Binding template

• Binding Template - The bindingTemplate representing the notification listener service.

• Notification interval - Specifies how often change notifications are to be provided to a subscriber. Required only for asynchronous notifications.

• Expires after - Specifies the period of time for which the administrator would like the subscription to exist.

• Max entities - Contains the maximum number of entities in a notification returned to a subscription listener.

• Brief - Controls the level of detail returned to a subscription listener.

Editing Subscriptions  ^Locate

To edit an existing subscription:

1. Click on the Subscriptions link under Publish menu tab to display the Subscriptions page.

2. Click the Edit button beside the subscription you want to edit. This returns the Edit subscription page. Here you can edit all subscription arguments except Subscription filter.

Deleting Subscriptions  ^Locate

To delete subscription:

1. Click on the Subscriptions link under Publish menu tab to display the Subscriptions page.

2. Check the boxes beside subscriptions you want to delete.

3. Click the Delete selected button. This returns a confirmation page.

4. The confirmation page contains a list of subscriptions marked for deletion. If it is correct, press the Yes button to delete subscriptions permanently.

Publish Custody Transfer  ^Locate

Custody transfer is a service used to transfer ownership of a selected structure (business entity, business service, binding template or tModel) from one user to another. It consists of two steps: selecting structure(s) to transfer and generating a custody transfer token. When the potential new owner receives the transfer token (by a secure transport such as encrypted email), that user may accept or reject the custody transfer.

	Important
	This token must be kept secret, as it is sufficient information to transfer custody of the structure to any user!

If you decide to cancel the request (for example the transfer token has been compromised), use the Discard transfer token button.

Requesting Custody Transfer  ^Locate

To request custody transfer:

1. Click on the Custody link under Publish menu tab to display the Custody transfer page.

2. Click the Request transfer token link. This returns a list of UDDI data structures you own.

3. Check the box next to the UDDI structure(s) you wish to transfer, and click Request transfer token.

4. The next page will generate the transfer token. Copy the text of the transfer token to a file and send this file to the user who shall become the new owner of selected structures. Keep the token secret, as anyone who knows it can use it to transfer custody of that structure. Unencrypted email, for example, is not good data transfer choice.

Accepting Custody Transfer  ^Locate

To accept custody transfer:

1. Click on the Custody link under Publish menu tab to display the Custody transfer page.

2. Click on the Transfer custody link.

3. Open the file with the transfer token, copy its contents to clipboard and paste it to the edit area on the Transfer structures page.

4. Click Transfer button.

Publishing WSDL Documents  ^Locate

BEA AquaLogic Service Registry WSDL to UDDI (WSDL2UDDI) mapping is compliant with OASIS's technical note Using WSDL in a UDDI registry Version 2.0. It enables the automatic publishing of WSDL documents into UDDI, enables precise and flexible UDDI queries based on specific WSDL artifacts and metadata, and provides a consistent mapping for UDDI v2.

Publish WSDL  ^Locate

To publish a WSDL document:

1. Click on the WSDL link under the Publish main menu tab.

2. The page shown at Figure 81 will appear.

   Figure 81. Publish WSDL

   

3. Enter the Business key of the business where services from WSDL document will be published. You can find a business key when you click on the Find business key button.

4. Enter a WSDL location. You can try the WSDL document from BEA AquaLogic Service Registry demos from REGISTRY_HOME/demos/conf/employeeList.wsdl.

5. Leave the Advanced mode check box unchecked, then click Publish button.

The WSDL document will be published to BEA AquaLogic Service Registry. You can review how WSDL artifacts of the document have been mapped to BEA AquaLogic Service Registry at Figure 82.

Figure 82. Publish WSDL Summary

Publishing WSDL Documents (Advanced Mode)  ^Locate

The advanced publishing mode allows you to specify certain details of how the WSDL document will be mapped to the UDDI registry. To publish in this mode, follow the steps from the previous section, and toggle the Advanced mode check box on. Once you click on the button Publish the Advanced Mode Publish page shown in Figure 83 will appear.

Figure 83. Publish WSDL (Advanced Mode)

In the left tree panel, you can see how artifacts of the WSDL document will be published. Click on a tree branch to edit how WSDL artifacts will be mapped to BEA AquaLogic Service Registry. Explanatory instructions in the right panel describe the mapping options. Click Preview to see how each part of the WSDL document will be mapped to the registry. From the Preview page, you can go back to adjust the WSDL mapping.

The wizard shown in Figure 83 defaults mapping according to the following rules:

• If a possible mapping of a WSDL artifact already exists in the registry, and the user owns this UDDI structure, the wizard will suggest rewriting that mapping in the registry.

• If a possible mapping of a WSDL artifact already exists in the registry, and the user does not own this UDDI structure, the wizard will suggest reusing that UDDI entity.

• If no mapping of the WSDL artifact exists in the registry, the wizard will suggest creating a new UDDI entity to represent the mapping.

BEA AquaLogic Service Registry applies these rules automatically when you publish a WSDL document without the Advanced mode option.

	Note
	Publishing of WSDL operations and WSDL messages is not implemented in this BEA AquaLogic Service Registry release.

Unpublish WSDL  ^Locate

To unpublish a WSDL definition:

1. Search for the WSDL document in the registry.

2. In the result view, click on a business service.

3. The page with business service details will appear, click the Unpublish button at the page.

4. The Unpublish WSDL document wizard will appear.

Publish XML  ^Locate

BEA AquaLogic Service Registry XML to UDDI (XML2UDDI) mapping enables the automatic publishing of XML documents into UDDI, enabling precise and flexible UDDI queries based on specific XML artifacts and metadata

If you want to unpublish an XML document, use the Find XML button, then click the Unpublish button in the search result page.

Publishing an XML Document  ^Locate

To publish an XML document:

1. Click on the XML link under the Publish main menu tab.

2. The page shown in Figure 84 will appear.

   Figure 84. Publish XML Document

   

3. Enter an XML location. To demonstrate, choose the file REGISTRY_HOME/demos/conf/employees.xml from the BEA AquaLogic Service Registry demos.

4. Leave the Advanced mode check box unchecked, and click Publish.

The XML document will be published to BEA AquaLogic Service Registry You can review how the XML document has been mapped to BEA AquaLogic Service Registry at Figure 85.

	Note
	The content of the XML document is not copied into the registry

Figure 85. Publish XML Document Summary

Publishing an XML Document - Advanced Mode  ^Locate

The advanced publishing mode allows you to specify certain details of how the XML document will be mapped to the UDDI registry. To publish in this mode, follow the steps from the previous section, check the box labeled Advanced mode, and click Publish. This returns the Advanced Mode Publish page shown in Figure 86 will appear.

Figure 86. Publish XML Document - Advanced

In the left tree panel, you can see how Namespaces of the XML document will be published. Click on a Namespace to edit how the Namespace will be mapped to BEA AquaLogic Service Registry. Explanatory instructions in the right panel describe the mapping options. Click Preview to see how the XML document and its Namespaces will be mapped to BEA AquaLogic Service Registry. From the Preview page, you can go back to edit the XML mapping.

Figure 87. Publish XML Document - Preview

Unpublish an XML Document  ^Locate

The Unpublish XML operation allows you to delete an XML mapping from BEA AquaLogic Service Registry To unpublish an XML document, you must search for the XML document first.

Publish XSD  ^Locate

BEA AquaLogic Service Registry XSD to UDDI (XSD2UDDI) mapping enables the automatic publishing of XML schema documents into UDDI, enabling precise and flexible UDDI queries based on specific XML schema artifacts and metadata.

If you want to unpublish an XML schema document, use the Find XSD button and click the Unpublish button in the search result page.

Publishing an XML Schema  ^Locate

To publish an XML Schema document:

1. Click on the XSD link under the Publish main menu tab.

2. The page shown in Figure 88 will appear.

   Figure 88. Publish XSD

   

3. Enter an XML Schema location. To demonstrate, use the file REGISTRY_HOME/demos/conf/employees.xsd from the BEA AquaLogic Service Registry demos.

4. Leave the Advanced mode check box unchecked, then click Publish.

5. The XML Schema document will be published to the registry. You can review mappings of the XML Schema document itself and its elements at Figure 89.

Figure 89. Publish XSD Summary

Publishing an XML Schema (Advanced Mode)  ^Locate

The advanced publishing mode allows you to specify certain details of how the XML Schema document will be mapped to the UDDI registry. To publish in this mode:

1. Follow the steps from the previous section, but check the Advanced mode box

2. Click Publish. This returns the Advanced Mode Publish page shown in Figure 90.

   Figure 90. Publish XSD - Advanced

   

3. In the left tree panel, you can see how the XML Schema and its possible XML Schema imports will be published. Click on an XML Schema model node to edit how the parts of the XML Schema will be mapped to the BEA AquaLogic Service Registry. The explanatory instructions in the right panel describe the mapping options.

4. Click the Preview to see how the XML Schema document will be mapped to BEA AquaLogic Service Registry. From the Preview page, you can go back to edit the XML Schema mapping.

Unpublish an XML Schema  ^Locate

The Unpublish XML operation allows you to delete the XML Schema mapping from BEA AquaLogic Service Registry. To unpublish an XML Schema document, you must search for the XML Schema document first.

Publish XSLT  ^Locate

BEA AquaLogic Service Registry XSLT to UDDI (XSLT2UDDI) mapping enables the automatic publishing of XSL Transformations into UDDI, enabling precise and flexible UDDI queries based on specific XSLT artifacts and metadata.

If you want to unpublish an XSL transformation, click the Find XSLT button, then click the Unpublish button in the search result page.

Publishing an XSL Transformation  ^Locate

To publish an XSL transformation:

1. Click on the XSLT link under the Publish main menu tab.

2. The page shown in Figure 91 will appear.

   Figure 91. Publish XSLT

   

3. Enter an XSLT location. To demonstrate, use the REGISTRY_HOME/demos/conf/employeesToDepartments.xsl file from the BEA AquaLogic Service Registry demos.

4. Leave the Advanced mode check box unchecked, then click Publish.

The XSL transformation will be published to BEA AquaLogic Service Registry. You can review how XSLT artifacts have been mapped to BEA AquaLogic Service Registry at Figure 92

Figure 92. Publish XSLT Summary

Publishing an XSL Transformation (Advanced Mode)  ^Locate

The advanced publishing mode allows you to specify certain details of how the XSL transformation will be mapped to the UDDI registry. To publish in this mode:

1. Follow the steps from the previous section, but check the Advanced mode box.

2. Click Publish. This returns the Advanced Mode Publish page shown in Figure 86.

   Figure 93. Publish XSLT- Advanced

   

   In the left tree panel, you can see how XSLT and its input and output schemas will be published.

3. Click on an XSLT node itself, its input XML Schemas, and types of XSLT output to edit how these artifacts will be mapped to BEA AquaLogic Service Registry. Explanatory instructions in the right panel describe the mapping options.

4. Click Preview to see how the XSLT will be mapped to BEA AquaLogic Service Registry. From the Preview page, you can go back to edit the mapping.

In the Signer tool's interface, the left part of the main screen consists of a tree containing all your businessEntities and tModels. If you wish to add or remove a digital signature, select the structure to sign from this tree. The Signer will fetch it from the registry. When the structure is fetched, its XML representation is displayed in the right panel. The Sign button is unblocked. If the structure has been already signed, the Remove signatures button is unblocked as well.

Figure 96. Signature Tool - Main Screen

The status bar at the bottom of the application informs the user of current action progress and results.

To sign a UDDI structure, you must set up the Java keystore. Use JDK tool keytool to generate the keystore. Please, see your JDK documentation for more information how to use keytool. The Signer tool has been tested with keystores in JKS and PKCS12 formats.

Note

To generate the certificate issue the following command keytool -genkey -keyalg RSA -storetype JKS -alias demo_john -keystore test_certificate.jks Example of the dialog: Enter keystore password: changeit What is your first and last name? [Unknown]: John Johnson What is the name of your organizational unit? [Unknown]: UDDI What is the name of your organization? [Unknown]: Myorg What is the name of your City or Locality? [Unknown]: San Diego What is the name of your State or Province? [Unknown]: California What is the two-letter country code for this unit? [Unknown]: CA Is CN=John Johnson, OU=UDDI, O=Myorg, L=San Diego, ST=California, C=CA correct? [no]: yes Enter key password for <demo_john> (RETURN if same as keystore password):

To sign a UDDI structure, you must set the Java keystore file, alias, and password as follows:

The Validate button is used to perform validity check of UDDI structures that contain XML digital signatures. The result of this operation is displayed in the status bar.

The Remove signatures button is used to remove all digital signatures from the selected UDDI structure. When this operation is complete, the XML representation of the UDDI structure is updated. If the Publish changes button had been disabled, it is enabled.

If you have signed the selected UDDI structure or removed digital signatures from it, you can select the Publish changes button to publish the changes to the registry. Its invocation uses standard UDDI publishing methods (save_tModel, etc.) to update this UDDI structure on the registry. The private key is not used during this operation.

The Signer tool automatically remembers the actual configuration such as registry endpoints or keystore location and format. The config file is saved in the user's home directory with the name signer.conf. You can change the location (and filename) by using the signer script's -c option. If you do not want this feature, use -n. The list of valid options can be obtained with -h option.