[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 functions. 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. Regards, Daniel -----Original Message----- From: Alan Wu [mailto:firstname.lastname@example.org] Sent: Wednesday, March 09, 2005 7:43 PM To: email@example.com Subject: [uddi-spec] is it a good practice to define an unchecked taxonomy for access points, overview doc url etc.? Hi, 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 purpose. Any comments? Thanks, Zhe Oracle --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.com