- From: David Booth <dbooth@w3.org>
- Date: Tue, 27 Jan 2004 07:03:23 -0500
- To: Richard Katz <richkatz@acm.org>,
- Cc: Paul Denning <pauld@mitre.org>, www-ws-arch@w3.org
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