Yes, certainly but it also some great
Firstly, X.500 was a great idea. Problem was that
it just didn't work that well and was enourmously expensive. One needed a
computer like a Wang or a Tandem or an IBM to run it. They certainly weren't
It needed really expensive people to get it
They were early pioneering days. I remember that at
that time a 2400 baud modem cost around $1000. I remember a company that I
worked for paying around $56,000 per annum for a 48k data line between two
Now a 300k DSL line can cost as little as $50 per
Then the Computer cost $300,000+. Now the same
power costs $900.
So therefore, the commercial environment in which a
Distributed Directory could exist now is entirely different than the days of
X.400/X.500 that really never were.
As an architecture, I suggest that Distributed
Directories suit the needs of Medium/Small enterprises better than centralised
directories and that the whole nature of computers is different
I'm not suggesting that X.400/X.500 should be
resurected, simply that we have a computing environment of the future is one
where all the computers will be permenantly connected to each other in much the
way that the inventors of X.500 had hoped.
As for commercial success, that's another thing. We
first need to see a few commercial releases and watch to see how they
----- Original Message -----
Sent: Friday, April 19, 2002 11:23
Subject: RE: [ebxml-dev] Distributive
Doesn't the history of X.400/X.500 give us some reason to
question the commercial success of Distributed Directories and the
administration thereof ?
Sent: Friday, April 19, 2002 1:10 AM
To: email@example.com; firstname.lastname@example.org
Subject: [ebxml-dev] Distributive Directories ?
You've raised some really good points.
Now I don't profess to be an expert in UDDI or WSDL but I've
the general philosophy behind ebXML.
Generally speaking the idea of a
registry is a good
one, it's virtually an extension of the Trading Partner
information that is kept in most of the old EDI software
Has anybody ever considered a Distributive Directory ?
This is now possible and viable with broadband and offers
small business over a centralised
The philosophy behind a Distributive Directory is that a
company joins an
Exchange and when they do their
details are broadcast (name, address,
everybody on the exchange.
The details of the new company are stored in the database of
companies that are connected.
The result is that within a city or region, everybody can have
details of everybody else and their
One could connect an entire city so that everybody could share
With broadband transmission speeds, a 2gig/hertz processor and
a 70 gig hard
drive, this seems to be readily
achievable. That btw, is the hardware that
Plumber can afford.
Surely this sort of technology is on the verge of becoming a
are some among us who have seen it in
----- Original Message -----
"Andrzej Jan Taramina" <email@example.com>
Sent: Friday, April
19, 2002 2:10 PM
Subject: Re: [ebxml-dev] RE: [EDI-L]
Article on ebXML Core Components
> > > Will the registry/repository concept for ebXML
eventually merge with
> > counterpart defined for UDDI/Web Services ?
> There are some fundamental issues
that might prevent this as well as the
> UDDI is a registry only...no
repository, where as ebXML has both. That
> may need to be) rectified by the UDDI spec
(imagine 10,000 WSDL
> pointed to by a UDDI rep.....how would you manage the storage of
in a large
corporation in a doable fashion? Put them on different web servers
company? Not likely......some form of centralized repository will
> needed to
The big issue is that UDDI has been designed to be a "global" public
> (though that does not
preclude private implementations), with support for
> and distribution of nodes
(meaning that the distributed system appears as
> global registry). Whereas ebXML
RegRep has been designed as a
> registry, to target a specific group of parties with a
common interest (a
> industry vertical, etc.) and no provision has been made for
are big chasms to cross in trying to merge the two together.
> philosophical roots.
> Best practice seems to
suggest that you use ebXML RegRep for community
> and use UDDI more globally which in
turn has a "pointer" to the specific
> Chaeron Corporation
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the
> manager: <http://lists.ebxml.org/ob/adm.pl>
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription