> > 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.
This will always be the case - the webservice server may have died unexpectedly, there may be network errors, the service may have been removed but its lifetime in the registry hasn't expired etc. > Would they be perhaps added by > the registry as > part of the registration process? It could be entirely internal using the modified value in operationalInfo - at least for v3 (i.e. "delete if the service has not been modified in the last month". This would require the webservice to do "null" updates to refresh the modified value. However, this would not allow a webservice container to determine different periods for the registry entry to be refreshed and the refresh cycle would have to be determined out of band. > If not, how would we deal > with registered > tModels that do not conform? If we go for a timetolive type category, interpret a default value if an entry has not such value assigned (e.g. infinity, two years) etc. > For those that do conform, how would we react to cases where > the service is > indeed alive but cannot reach the registry? One approach might be that this happens via a proxy (and in such cases the question arises how did the service get registered in the first place). Another approach would be that any service would have two bindingTemplates - one defining the WebService itself, the other defining a monitoring WebService and endpoing whose sole job is to tell you whether the real webservice is alive or not. All this is architectural design rather than UDDI per se - which is why this isn't explicitly in the UDDI spec. Matthew
