Re: The Registry Approach

Richard,

While I agree with your observation that it's helpful if registry owners 
take steps to ensure that the information in their registries is reliable, 
this is a policy consideration that is up to the owners, and I would not 
want to suggest that it would be a safe programming practice to 
assume  that such information is reliable.  I've tried to add mention of 
your concern accordingly.  We're working on the document this week in our 
face-to-face meeting.


At 12:47 PM 1/20/2004 -0800, Richard Katz wrote:
>Hi Paul,
>
>Regarding
>
>
>1. Authoritative - I have a problem with this. I think a registry may not 
>be authoritative. Maybe some registries are authoritative, and some not. A 
>registry may have a mix of authoritative and non-authoritative info. This 
>can get into a deep discussion of how to identify whether some information 
>is or is not authoritative. Note that DNS has this concept, but I'm not 
>sure how "trust" is handled. Just because a DNS server says its 
>"authoritative" does not necessarily mean it is (unless you trust the DNS 
>server).
>
>Software errors will result if registrars fail to take 
>responsibility.  There is a problem today in that DNS registrars are not 
>bound and not necessarily authoritive. This has serious negative 
>consequences for Web services software design and development.
>
>There need to be both verification and certification rules.  Verification 
>simply identifies the owner of the Web service within the registry and 
>this rule can be applied by the registrar.
>
>1. The registrar should be required to remove information that is not 
>accurate. Verification and certification procedures are required to be run 
>on all information published.
>
>2. The registrant is responsible to the registrar for providing accurate 
>information.
>
>3. The industry needs to agrees to ethical standards, sets and publishes 
>such standards about requiring accurate information by the registrar and 
>by the registrant.
>
>These rules are required to ensure ethical behavior at acceptable levels. 
>Otherwise, software errors abound.
>
>Software quality costs are too high if there are registrars who are not 
>bound by such rules. It violates a particular rule of design called the 
>Law of Demeter (LoD).  The Web service as an object can not be responsible 
>for objects belonging to another object owned by the registrar.  The 
>registrar has administrative rights and privledges to the registry and has 
>all methods of control.
>
>Yet a Web service must rely on the registrar for accurate information to 
>function correctly.  But according to the Law of Demeter the Web Service 
>can not successfully perform methods such as verification on objects it 
>does not directly own because it does not have complete knowledge of them, 
>their structure, or what mechanism is used to do verification on them.
>
>The registrar has a contract with the registrant and can apply terms of 
>service. The registrar therefore must be able to have all the knowledge 
>necessary for verification.  There needs to be a standards body that 
>manages registrars and rules.  There is simply no way an external Web 
>Service can compensate. It is important not to  exposes the Web Service to 
>such risks.
>
>  A description of the LoD is as follows:
>
>The "Law of Demeter" (or LoD) as it is commonly called, is really more 
>precisely the "Law of Demeter for Functions/Methods" (LoD-F). It is a 
>design-style rule for object-oriented programs. Its essence is the 
>"principle of least knowledge" regarding the object instances used within 
>a method. The idea is to assume as little as possible about the structure 
>and properties of instances and their subparts. Thus, it is okay for me to 
>request a service of an objects instance, but if I reach into that object 
>to access another sub-object and request a service of that sub-object, I 
>am assuming knowledge of the deeper structure of the original object that 
>was made available to me.
>
>The Law of Demeter says that if I need to request a service of an objects 
>sub-part, I should instead make the request of the object itself and let 
>it propagate this request to all relevant sub-parts, thus the object is 
>responsible for knowing its internal make-up instead of the method that 
>uses it. Stated more formally, the Law of Demeter for functions says that:
>
>A method "M" of an object "O" should invoke only the the methods of the 
>following kinds of objects:
>
>1. itself
>
>2. its parameters
>
>3. any objects it creates/instantiates
>
>4. its direct component objects
>
>The basic idea is to avoid invoking methods of a member object that is 
>returned by another method. When you do this, you make structural 
>assumptions about the container object that may be likely to change.
>
><http://www.cmcrossroads.com/bradapp/docs/demeter-intro.html>http://www.cmcrossroads.com/bradapp/docs/demeter-intro.html
>HTH.
>
>Regards,
>
>Rich
>
>-----Original Message-----
>From: Paul Denning
>Sent: Jan 20, 2004 9:35 AM
>To: www-ws-arch@w3.org
>Subject: The Registry Approach
>
><existing>
>3.2.2.1 The Registry Approach
>
>A registry is an authoritative, centrally controlled store of information.
>
>Publishing a service description requires an active step by the provider 
>entity: it must explicitly place the information into the registry before 
>that information is available to others. In the case of a registry:
>
>The registry owner decides who has authority to place information into, or 
>update, the registry. Although the owner of registry R may delegate 
>permission to approved provider entities that wish to publish their own 
>service descriptions, an arbitrary third party could not publish a 
>description of someone else's service in registry R. This means, for 
>example, that company X would not be able to register a functional 
>description of company Y's service, even if that description would be 
>valuable to others and may be superior in some ways to Y's own description.
>
>The registry owner decides what information is placed in the registry. 
>Others cannot independently augment that information.
>UDDI is often seen as an example of the registry approach. However, as 
>noted below, it depends on how it is used.
></existing>
>
>Discussion:
>
>1.  Authoritative - I have a problem with this.  I think a registry may 
>not be authoritative.  Maybe some registries are authoritative, and some 
>not.  A registry may have a mix of authoritative and non-authoritative 
>info.  This can get into a deep discussion of how to identify whether some 
>information is or is not authoritative.  Note that DNS has this concept, 
>but I'm not sure how "trust" is handled.  Just because a DNS server says 
>its "authoritative" does not necessarily mean it is (unless you trust the 
>DNS server).
>
>2.  Service descriptions - If WSDL is a service description, and UDDI is a 
>Registry, then the service description (WSDL) is not published to the 
>registry (UDDI).  The metadata published to UDDI about a service may be 
>considered part of a "service description".  The UDDI entry may supplement 
>the WSDL (e.g., by adding a categoryBag), and in many cases points to a 
>WSDL document external to the registry.  A registry is not necessarily a 
>repository for service descriptions (WSDL).
>
>3.  3rd Party Publishing - One scenario is that the service provider 
>user/organization publishes the entry to the registry.  However, another 
>scenario would be for 3rd parties to publish to a registry.  There is a 
>concept of a registrar, which may be viewed as authoritative if the 
>service provider has delegated responsibility for publishing to the 
>registrar.  An arbitrary 3rd party with no relationship to the provider 
>may publish to a registry (depending on the registry's policy, see below).
>
>4.  Registry Policy - Whether or not an arbitrary 3rd party can publish a 
>description of someone else's service is a matter of policy.
>
>5.  UDDI is a registry - Providing a UDDI inquiry without the UDDI publish 
>would not be a registry.  An index may provide a UDDI inquiry web service 
>API, but without the publish API, it would not be a registry.  Note I am 
>not just talking about the Public UDDI Business Registry (UBR).
>
>Therefore, to address my concerns I propose the following changes
>
><proposal>
>3.2.2.1 The Registry Approach
>
>A registry is a centrally controlled store of information.
>
>Publishing to a registry requires an active step by a publisher: it must 
>explicitly place the information into the registry before that information 
>is available to others.
>
>A registry owner establishes policies about publishing and accessing 
>information in the registry.
>
>Depending on policy and its enforcement, a registry may or may not contain 
>authoritative information.  For example, a registry may permit arbitrary 
>third parties to publish information about someone else's service without 
>their permission.  Other registries may prohibit arbitrary third parties 
>from publishing.
>
>A registry may support techniques, such as, digital signatures, to help 
>users determine whether or not registry information is authoritative.
>
>A registry may allow publishing by service requesters that want to express 
>their interest or ability to engage specific types of services.  A 
>registry is not limited to information about service providers.
>
>UDDI is often seen as an example of the registry approach.
>
></proposal>
>
>
>Paul
>
>
>
>

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Tuesday, 27 January 2004 16:59:40 UTC