Bug 780938 (SOA-3405) - Configure Riftsaw UDDI integration to maintain backward compatibility.
Summary: Configure Riftsaw UDDI integration to maintain backward compatibility.
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-3405
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: Documentation, Build Process, jUDDI - within SOA, riftsaw
Version: 5.2.0.ER4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 5.2.0.ER5
Assignee: David Le Sage
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-22 11:01 UTC by Marek Baluch
Modified: 2011-11-09 04:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-09 04:04:06 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-3405 0 None None None Never

Description Marek Baluch 2011-09-22 11:01:59 UTC
Affects: Documentation (Ref Guide, User Guide, etc.)
Workaround: Workaround Exists
project_key: SOA

jUDDI 3.1.x allows to specify the format of entity keys which will be used to register an entity to the registry. The default format is not compatible with the format used in jUDDI 3.0.x in SOA 5.1.

The default format for jUDDI 3.1.x is the following: 

{code:title=org/apache/juddi/v3/client/config/Property.java}
public static final String DEFAULT_BUSINESS_KEY_FORMAT      = "uddi:${keyDomain}:business_${businessName}";
public static final String DEFAULT_SERVICE_KEY_FORMAT       = "uddi:${keyDomain}:service_${serviceName}";
public static final String DEFAULT_SUBSCRIPTION_KEY_FORMAT  = "uddi:${keyDomain}:service_cache_${nodeName}";
public static final String DEFAULT_BINDING_KEY_FORMAT       = "uddi:${keyDomain}:binding_${nodeName}_${serviceName}_${portName}";
{code}

Sample format in jUDDI 3.0.x:

{code:title=org/jboss/soa/bpel/uddi/UDDIRegistrationImpl.java}
public static final String DEFAULT_SERVICE_KEY_FORMAT   = "uddi:${keyDomain}:bpel-services-";
public static final String DEFAULT_BINDING_KEY_FORMAT   = "uddi:${keyDomain}:bindings-";
...
String serviceKey = TokenResolver.replaceTokens(DEFAULT_SERVICE_KEY_FORMAT + serviceName, properties);
...
String bindingKey = TokenResolver.replaceTokens(DEFAULT_BINDING_KEY_FORMAT + bindingName, properties);
...
{code}

To make the formats compatible the following properties must be defined in deploy/riftsaw.sar/bpel.properties
- bpelServiceKeyFormat
- businessKeyFormat
- bindingKeyFormat

The Riftsaw business key in file deploy/jbossesb-registry.sar/juddi_custom_install_data/riftsaw_BusinessEntity.xml must be updated according to the businessKeyFormat property.

Comment 1 Marek Baluch 2011-09-22 11:02:54 UTC
If I'm not mistaking then setting these properties in deploy/riftsaw.sar/META-INF/riftsaw.uddi.xml file should work too.

Comment 2 Len DiMaggio 2011-09-22 16:23:01 UTC
Marek,

Can you do a dump of a 5.1.0 and 5.2.0 registry - what are the differences? Is this issue unique to Riftsaw or is all of jUDDI affected? Thx!



Comment 3 Kurt Stam 2011-09-27 14:58:46 UTC
With the latest jUDDI-client RiftSaw has now more control over its own destiny (and we now have our own client config in the riftsaw.uddi.xml. I think it makes sense to take the newly formatted keys which include things like nodename so that we can handle 'clustered' environments. All your suggestions would work to go back to the old format, but what is the issue we are trying to solve here? I mean yes they are different, but it all self registers? Can't we add this to the release notes as a change? If the user really doesn't like it then they could change the format themselves as it is in the config after all?

Comment 4 Marek Baluch 2011-09-30 12:05:49 UTC
Hi Kurt. 

Web services are not registered to jUDDI upon deployment automatically. The user has to register them manually. Now because the key format has been changed Riftsaw will not be able to lookup the web-service in the registry. Not without configuration changes that is.

Having said that I agree with you that mentioning the configuration option in the release notes should be a satisfying solution. If a user wishes to use the old database records then he can change the configuration easily enough.

Comment 5 Kurt Stam 2011-09-30 12:55:51 UTC
Hi Marek,

Cool, all good then. 

Two small notes:
- You are completely right that the lookup to existing webservices would fail, since we use a lookup by Key and now the keyformat changed.. The good news is that I think with this release this is the first time all that service lookup infrastructure actually works, so not many people will be impacted. Note that the lookup is fast and accurate too, since it caches the info, and a Subscription calls back into the cache to invalidate on changes in the registry :).
- On the other hand I guess we should advertise more that self-registering of WebServices sure is possible using the UDDI annotations:
http://juddi.apache.org/docs/3.x/userguide/html/chap-UDDI_annotations.html

Cheers,

--Kurt


Comment 7 Len DiMaggio 2011-10-04 16:43:09 UTC
Affects: Added: Documentation (Ref Guide, User Guide, etc.)


Comment 8 Len DiMaggio 2011-10-04 16:43:24 UTC
Workaround: Added: Workaround Exists


Comment 9 David Le Sage 2011-10-06 05:01:37 UTC
Release Notes Docs Status: Added: Documented as Known Issue
Writer: Added: dlesage
Release Notes Text: Added: https://issues.jboss.org/browse/SOA-3405
jUDDI 3.1 allows you to specify entity keys but this is not compatible with the version from 3.0. To make the formats compatible, define the following properties in deploy/riftsaw.sar/bpel.properties: 

bpelServiceKeyFormat
businessKeyFormat
bindingKeyFormat

The Riftsaw business key in file deploy/jbossesb-registry.sar/juddi_custom_install_data/riftsaw_BusinessEntity.xml must be updated according to the businessKeyFormat property.

The Riftsaw business key in file deploy/jbossesb-registry.sar/juddi_custom_install_data/riftsaw_BusinessEntity.xml must be updated according to the businessKeyFormat property.


Comment 10 David Le Sage 2011-10-06 05:02:09 UTC
Documented for release notes.


Note You need to log in before you can comment on or make changes to this bug.