Thanks Matthew. > -----Original Message----- > From: Matthew J. Dovey [mailto:[EMAIL PROTECTED] > Sent: Monday, March 28, 2005 1:19 PM > To: [email protected] > Subject: RE: UDDI spec question > > At present it is regarded to be the responsibility of the WebService > container to both register WebServices when they are published and also > deregister them when they are "unpublished". >
At present web services also must be designed to react to any dead endpoints returned when issuing an inquiry. > However, one of the things which has been discussed within the context > of the next version of UDDI is some kind of lifetime mechanism to try at > clean up "dead" entries in the registry. It isn't clear that this is a > spec change per se. For instance you could define a new tModel category > which held an obsolete time/date value, ensured that your WebServices > updated the resitry to keep this category value up to date, and then ran > a cron job (or equivalent) to clean the registry. This may work. The registry could also implement this feature internally. A reaping policy could be defined using the period as perhaps one important detail (there may be others as well). Do you think that the aforementioned category would be "required"? Would they be perhaps added by the registry as part of the registration process? If not, how would we deal with registered tModels that do not conform? For those that do conform, how would we react to cases where the service is indeed alive but cannot reach the registry? In other words, how would the possibility of network partitioning (mentioned in my follow-up post) be handled? Do you think that, in this case, this problem is overly exaggerated? This would seem to be a real possibility given the frequent use of remote registries. > > Matthew Dovey > Oxford University > > > > -----Original Message----- > > From: Combs Vaughn T Civ AFRL/IFSE [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 28, 2005 5:39 PM > > To: '[email protected]' > > Subject: FW: UDDI spec question > > > > > > The UDDI spec has a subscription API (implementation > > optional) that is to be used to essentially notify clients of > > changes. > > > > Have you seen anything about potential additions to the spec > > to accommodate a leasing model between services and the > > registry (i.e. if the registry hasn't seen a lease renewal > > from a service in some time then it is dead and cleaned up > > after)? I can understand that you may want a service > > registration to persist even without a lease renewal but this > > could be specified at service registration time and subject > > to policy that is enforced on the registry side. I would > > think that the problem of an ever growing registry containing > > many dead endpoint/access point references to services would > > make this an attractive option. > > > > Many Thanks, > > > > Vaughn T. Combs > > Systems and Information Interoperability Branch > > Air Force Research Lab > > AFRL/IFSE > > > > Many Thanks, Vaughn
