Errors "Load tModels into the registry" option & publishing proxy services

Question

Hi,
I'm making a study with BEA Aqualogic Service Bus and BEA Aqualogic Service Registry.
Reading official documentation (Console Help), I added with the BEA ALSB Console two registries. But during the configuration it doesn't allow me to set the *"Load tModels into the registry"* option, in fact when I click "Save" I get this error:
*"Permission to generate key uddi:bea.com:servicebus:servicetype denied".*
However I added two registries without setting this option.
Now, when I want to publish a proxy service (in any registry), following the official procedure, I get this error:
*"The publish completed with error. One or more services can't be published correctly, please see the detailed error messages in the summary table".*
*"CannotCreate The key uddi:bea.com:servicebus:properties does not represent a valid taxonomy!"*
I don't think it's all right! :)
Someone can help me?

Answer 1

Thank you for your help (even though you didn't know you were helping). I am also studying ALSB and ALSR, and I had the same problem when I tried to publish a proxy service ("... does not represent a valid taxonomy"). Based on your experience, I updated my registry in ALSB and checked "Load tModels". This was successful. I then published my proxy service and this too was successful.
So the help you've given me was to suggest that publishing proxy services cannot be done unless the BEA tModels are first loaded into the registry.
This means that your real problem is that you can't load the tModels. To do this, I suggest that the user ID you give when you're setting up the registry in ALSB must be an administrative user. When you installed the ALSR, an administrative account was created. Try giving this account information to the ALSB.
If you don't want to give the administrative ID and password, you must set up an account in ALSR that has the ability to create tModels. In the ALSR's console page (probably at http://localhost:7001/registry/uddi/web), look at the administrative account's permissions (you'll find it on the "Manage" tab, under "Permissions"--you won't see the "Manage" tab unless you log in as an administrator). In my system, the administrator account has four permissions; I would guess that the one you need is "org.systinet.uddi.security.permission.ConfigurationManagerPermission".