Re: [regrep] http-binding and ExternalIdentifier / RIM targets

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

David RR Webber wrote:

> Farrukh,
>
> OK - some clarification - I want to use the GET syntax approach of the 
> http-binding - and use ExternalIdentifier
> as the column name instead of UUID as the id="targetvalue".

The HTTP interface of ebXML Registry does not provide a way to use an 
ExternalIdentifier in a HTTP GET to get a RegistryObject.

Personally, I do not think adding GET by ExternalIdentifier as a special 
case is a good idea. A RegistryObject has many attributes and 
ExternalIdentifier is just one of them. A more general approach that 
allows using any RegistryObject attribute value in HTTP GET starts 
infringing upon registry query interface. Our specs already support send 
any arbitrary AdhocQueryRequest as a POST request in the HTTP interface. 
This feature is optional and the freebXML Registry does not support it yet.

I think based upon your use case you should consider using one of the 
following HTTP interface features:

1. Submitter Defined URL

2. File Path URL

Both require that the submiter do something special when submitting the 
RegistryObject:

1. Submitter Defined URL requires that submitter assign a URL of their 
choice to the RegistryObject

2. File Path URL: Requires that submitter give a meaningful name and 
package containment to the RegistryObject

That said, I dont quite agree with your earlier statement quoted below:

<drrw quote>
I just went to use the http-binding GET method with the JAXR and it 
appears to be hardwired to only work with UUID instead of
the more logical ability to query against any column in the RIM, and 
specifically of course the ExternalIdentifier - which one would
expect to be the most logical place to query from a GET - because 9 
times out of 10 you could not expect to know what the
UUID is even care necessarily (it could change for updated items)."
</drrw quote>

I think that the UUID of a well known object should be well known and 
used by clients to retrieve the object. This is no different than tModel 
keys in UDDI ebing used to retrieve tModels.

Also the UUID of an object *NEVER* changes on update. On versioning the 
new version does get a new UUID but that is not the same RegistryObject.

I can see value to adding to the HTTP RPC binding the ability to access 
an object by its lid. In such a case multiple versions of the object 
could exists and they should be shown in a directory listing along with 
versionInfo and comment. This would be a minor spec change / enhancement.

>
> If the specification does not preclude this - I guess we can extend 
> the Java method to handle this  - as obviously
> this is a pretty trivial enhancement.

Above is a discussion for the ebxmlrr-tech list. Not sure what Java 
class and what method you are proposing. I welcome the input but please 
do so on ebxmlrr-tech list as JAXR is not covered by regrep TC.


-- 
Regards,
Farrukh