Coincidentally,
literally just a minute or two before I saw this message, I came across the
fact that serviceInfo only contains the name(s) and not the description(s),
but I started from get_registeredInfo. The serviceInfo structure is also
returned as part of the response to find_business so there are three API calls
that would return more data than they currently do, if we made a
change.
I don’t think this is
serious enough to change V3 but it should be a small change so I would not
object to it.
-----Original
Message-----
From: Von
Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: 23 May 2003 15:20
To:
'uddi-spec@lists.oasis-open.org'
Cc: Lhermine, Thierry
Subject: [uddi-spec] Inconsistency in
find_xx return structures - second try
Sorry,
the first mail contained diagrams as embedded objects. I attached them
now.
-----Original
Message-----
From: Von
Riegen, Claus
Sent: Freitag,
23. Mai 2003 15:57
To:
Cc: Lhermine, Thierry
Subject: [uddi-spec] Inconsistency in
find_xx return structures
One of my colleagues at SAP made
the observation that the serviceList return structure, which is included in
the response message to a find_service API call, does not contain the
descriptions of businessService elements being found.
<<...OLE_Obj...>>
While this is true for all
versions of UDDI, it is inconsistent with the return structures for
find_businss (businessList) and find_tModel (tModelList). In these cases, the
description for the businessEntity or the tModel is returned within the
businessInfo or tModelInfo, respectively. (Note that there is no similarity
for bindingTemplates - they are always returned in a bindingDetail
structure).
Before actually drafting a change
request (for V3), I'd like to get an overview on your opinion: is this
inconsistency worth to change V3 as follows?
<<...OLE_Obj...>>
Pros
·
More detailed information in
serviceList return structure so that inquirers can more easily choose the
"correct" businessService
·
No change of inquiry behavior or
general structure of response structure necessary
Cons
·
UDDI servers have to be
changed
·
UDDI clients must be changed since
they don't expect the descriptions (as they did not in UDDI V1 and
V2)
Thoughts?
Claus