[
Lists Home |
Date Index |
Thread Index
]
[Thanks to everyone for their input. As always, I am deeply impressed
by the incredible brainpower on this list.]
I have carefully read all your comments and have attempted to
incorporate them into a more compelling argument.
Here are the (revised) key points to my argument:
1. Defining characteristics of the Web:
- extreme scalability
- highly decentralized, distributed
2. My client's current approach is to create an ebXML-based Registry
containing information about all the services it supports. The registry
is a centralized, heavyweight data pool where users go to find the who,
what, and where of services. [Note that UDDI has the same centralized,
heavyweight mentality.]
3. A centralized, heavyweight Registry suffers from several problems:
- Non-scalable: as new services are added the Registry grows, the
number of users also grows, and the load on the
Registy correspondingly increases
- Single point of failure (unreliable): if the Registy fails then
all users are impacted.
4. A centralized Registry is a double-edged sword in terms of security:
- there is a single point of attack, so intruders can focus their
efforts on the one system
- there is a single point to secure, so efforts to secure the
system can be focused
There is an alternative to a centralized, heavyweight Registry ...
5. RDDL (Resource Directory Description Language) is a lightweight,
distributed mechanism for storing information about a namespace. The key
notion of RDDL is to use namespaces in a dual role - both as an
identifier, and as a pointer to a RDDL document. The RDDL document is a
directory for the namespace. That is, it contains pointers to documents
that you wish to associate with the namespace. Such documents include
schemas, stylesheets, dictionary, spec (all the things that my client
wants associated with each service in his registry).
6. I propose that each client service be associated with a different
namespace, and each namespace point to a RDDL document. Thus, the set
of client metadata is distributed across all the RDDL documents. This
yields a lightweight, distributed metadata mechanism.
7. A decentralized, lightweight RDDL-based registy has the benefits of:
- Scalable: new RDDL directories can be deployed without impact
to the performance of the system as a whole
- Reliable: even if one RDDL directory fails the other parts
remain active
- Local control of local resources (independent, evolutionary):
maintainers of each RDDL collection has authority over
their work, and can evolve it indedendently of others
This approach is consistent with the Web architecture.
8. A decentralized Registry is a double-edged sword in terms of
security:
- there is no single point to attack, so intruders are forced to
disperse their efforts over many systems
- each RDDL system must devise their own security mechanisms
9. In a RDDL-based, distributed architecture services are located using
a search engine. An interesting aspect of RDDL is that a RDDL document
has both a machine interface as well as a human (eyeball) interface.
Consequently, the searching can be done using either a browser or a
robot.
10. I believe that the benefits of a decentralized, RDDL-base Registry
require us to explore this as a viable alternative to centralized,
heavyweight UDDI- or ebXML-based Registries.
|
