[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Of directories...
Shane's view:
A 'directory' is similar to DNS.. perhaps with out the
'S'.
- A directory represents
the known list of MDEs participating in a LegalXML system, and their
'address' for interaction.
We have also said
this:
- A directory expresses each MDE's type (so that
we know what general behavior we might expect from
it).
- A directory informs us as to what functions the MDE
supports (or, perhaps, what it does not
support)
However, if given an MDE's address, we could just ask
the MDE "What can you do?", then, we might not even need those last two
requirements, or maybe not BOTH of those requirements. (we'll
see.)
And, that's about it, as far as I am
concerned.
Practically speaking, the directory contents should
probably be publish-able somewhere, in some format, for all system participants
to review. But, not necessarily...
(This is where I think we have had
some debate...)
In my view, each participant should be able to retain
and maintain their own data representing a
directory.
They do not need to
dynamically refer to a centrally-defined directory, of a pre-defined
format, on an hourly/daily/weekly basis.
The way I see it, each
participant may develop and persist their own directory structure in
whatever format they desire.
They can learn of other MDE's addresses through any
number of practical means ("Dude, what's your
IP?")
However, if the system were to contain a centrally
available directory, in a format that is suitable for all participants, and
there exists a system participant/process to assure the directory's accuracy and
availability, then it is perfectly reasonable to ask all participants to
dynamically refer to that structure before interacting with an
MDE.
Either of those models are fine by
me.
Where I feel like we would be going further than
necessary, is if we were to attempt to formally define the directory data
structure, and formally define interactions with a 'directory server
MDE'.
1) I think directory contents (i.e. the addresses of
MDEs) would have to be specific to whatever profile is being implemented
for the system.
A directory for WebServices system, will look different
than a CORBA-based system, would be different than a sneaker-net based
system.
2) I believe a centrally-available and accessible
directory is only really desirable in those systems where MDEs are joining and
leaving the system on a frequent, and generally 'quiet' basis.
We only need the central list to exist so that we might
discover the MDEs that are so quietly jumping into the
system.
Now, that *might* be the case, someday... but, when I
put my 'practical cap' on, I recognize, for the foreseeable future, MDEs
are not going to enter a system without EVERYONE being very aware, and
highly prepared, for the event. As far as I can see, It will be very
unlikely that I'll need to discover MDEs,
on a daily/hourly basis, via the central directory. (for instance:
BearingPoint and LexisNexis would know about each
other's participation in the *same* system, almost immediately. Long
before a central directory might ever list
us.)
And, since it will not be needed for awhile, I say,
let's not try to define a 'directory server' at this
time.
3) As you noted Rex (as did Jim) , the concept of a
'directory' is very similar to UDDI/DNS,
etc.
I think, for all of the 'profiles' we have kicked
around, we will find that there already exists a perfectly suitable way to
express a directory, and a perfectly suitable way to publish the
directory.
I may have made a call for 'more definition'... but, I
really don't want to formally define it with much
detail. I believe our assistance, in terms of development
of a standard for 'directory', is not really needed in this
area.
Perhaps, for specific system profiles, we could offer
suggestions/examples, of existing technologies, for a publish-able
directory.
That's about as far as I would like to take
it.
- Shane Durham
LexisNexis
FileAndServe
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]