OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [uddi-spec] is it a good practice to define an unchecked taxonomy for access points, overview doc url etc.?

Hi Zhe,

One scenario that comes to mind which can leverage such category system is
locating a new access point for a previously known one, when no other
service information is available.  The old access point can become
invalidated through whatever operational changes.  The new access point URL
would be contained in the bindingTemplate's accessPoint, whereas all
obsolete access points can be placed inside a categoryBag.  bindingTemplate
versioning would be another way of dealing with the details of this
solution, but the key aspect of it is that access point URL needs to be
available for inquiry.  This seems to imply that the URL be available as a
categorization.  Although this seems like an appealing quick-fix solution, I
think it would be quite messy and potentially unmanageable in the long term,
particularly if you consider all the different configuration-driven (and
therefore potentially short-lived) equivalents or slight alternates a single
URL may have in an enterprise (e.g. due to different transports, addressing
schemes, interceptors, buses, etc).

If the service consumer in question had relied on the bindingKey (or another
UDDI artifact, including another type of keyValue) instead of endpoint URL,
then such problem could be avoided in the first place.  The registry's
logical service model provides the indirection that is an important
motivation to have a registry in the first place.  By hard coding all your
endpoints you sacrifice one of the registry's most compelling enterprise

IMHO, if you have an endpoint URL, then you should probably use the same
medium you used to acquire it to pass the data you then want to obtain from
the registry (in which case you do not need a registry for this particular
use case, although it could be the original source of the data you receive
along with the URL) or to pass at least some kind of uddiKey or keyValue,
which can then be used by service consumer to query the registry.  For
example, if you get service URL via WS-Addressing, then whatever else you
need (whether it's the ultimate metadata or UDDI bootstrap parameter(s)) can
be encapsulated inside an EPR.

I would have to know more about your scenario to comment further.


-----Original Message-----
From: Alan Wu [mailto:alan.wu@oracle.com] 
Sent: Wednesday, March 09, 2005 7:43 PM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] is it a good practice to define an unchecked taxonomy
for access points, overview doc url etc.?


In this unchecked taxonomy, keyValues will be URLs.
The goal is to make the URLs searchable. As an example, you can categorize a
service with all the access point URLs.
Then you ask a UDDI registry a question like "hey, I know a service entry
point, is there an existing service registered with that entry point?"

The upside of this idea is obvious.

The downside is that there are some redundancy introduced.
Also there is this question that can URLs be used to classify services or
interfaces? I don't see any reason that URLs cannot be used for that

Any comments?



To unsubscribe, e-mail: uddi-spec-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: uddi-spec-help@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]