juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Combs Vaughn T Civ AFRL/IFSE <Vaughn.Co...@rl.af.mil>
Subject RE: UDDI spec question
Date Mon, 28 Mar 2005 19:14:28 GMT

Thanks Matthew.

> -----Original Message-----
> From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk]
> Sent: Monday, March 28, 2005 1:19 PM
> To: juddi-dev@ws.apache.org
> 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:Vaughn.Combs@rl.af.mil]
> > Sent: Monday, March 28, 2005 5:39 PM
> > To: 'juddi-dev@ws.apache.org'
> > 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
> >
> >

Many Thanks,

View raw message