Hi cli_dc,
All UDDI implementations will try to be compatible and implement the
spec as best as they can. However sometimes the spec maybe ambiguous,
and there is no TCK testsuite for UDDI (Although we started maintaining
one as part of the jUDDI project).
In short this means that you may find slight differences. I think we
implemented it the way we did because of this sentence in the spec:
http://uddi.org/pubs/uddi_v3.htm#_Toc85908086
"In the event that no matches were located for the specified criteria,
the bindingDetail structure returned is empty (i.e., it contains no
bindingTemplate data). This signifies a zero match result. If no
arguments are passed, a zero-match result set will be returned. "
So I think it says that if no arguments are passed to the
find_businesses, a zero-match should be returned. Please read this
section also to see if you agree with us.
We should see where (client or server) and how we should fix the
incompatibility. i.e. does HP still work ok if you give it the same
query you send to make jUDDI work? It maybe that HP allows some sort of
default behavior not really specified in the spec. We could do something
similar if needed, and add config option to turn this on/off.
Cheers,
--Kurt
On 4/22/11 4:52 AM, cli_dc wrote:
We had to change our UDDI-client code a little when we switched our
UDDI server backend !!
That was a surprise to us !! Below are the details. Please suggest
what is missing -- it's puzzling, and we need to solve this puzzle.
*/Question:/*
Why client code change is necessary when we switch from HP to jUDDI
v3.0.4 ?
*/Details:/*
We switched our backend UDDI registry instance from HP to jUDDI
v3.0.4. [Note that: The HP registry is also UDDI spec v3 compliant.]
After the jUDDI instance started, we ran our existing piece of code
(as included below) and ran into
"/org.uddi.v3_service.DispositionReportFaultMessage: At least one
search criterion must be supplied/".
*/Stack Trace:/*
Caused by: org.uddi.v3_service.DispositionReportFaultMessage: At least
one search criterion must be supplied
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:141)
at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy41.findBusiness(Unknown Source)
at
org.mine.connectmgr.uddi.MyUDDIAccessor.retrieveBizInfo(MyUDDIAccessor.java:581)
*/Code that works on HP:/*
UDDIInquiryPortType oInq = getUDDIInqWebSvc();
FindBusiness oFindBiz = new FindBusiness();
oFindBiz.setMaxRows(100);
oBusinessList = oInq.findBusiness(oFindBiz);
*/Code (with additions) that works on jUDDI v3:/*
UDDIInquiryPortType oInq = getUDDIInqWebSvc();
FindBusiness oFindBiz = new FindBusiness();
Name findName = new Name(); // new code
FindQualifiers qualifiers = new FindQualifiers(); // new code
findName.setValue("%"); // new code
qualifiers.getFindQualifier().add("approximateMatch");// new code
oFindBiz.getName().add(findName); // new code
oFindBiz.setFindQualifiers(qualifiers); // new code
oFindBiz.setMaxRows(100);
oBusinessList = oInq.findBusiness(oFindBiz);
Thanks! Is the code change (// new code) necessary to get rid of
org.uddi.v3_service.DispositionReportFaultMessage ?
What are we missing ??
Please let us know at your earliest.
------------------------------------------------------------------------
View this message in context: Changes required to the client code ??
(when switched from HP to jUDDI v3.0.4)
<http://old.nabble.com/Changes-required-to-the-client-code----%28when-switched-from-HP-to-jUDDI-v3.0.4%29-tp31455105p31455105.html>
Sent from the jUDDI - User mailing list archive
<http://old.nabble.com/jUDDI---User-f240.html> at Nabble.com.
