[
Lists Home |
Date Index |
Thread Index
]
Hello Rick,
both have their problems.
Didier: I agree, there are pros and cons for both models.
i have always stuck to the "mainframe" model
as the fundamental model. in a shared data environment there has to be a
way of knowing a copy of the data is definitive. a single central
repository can be wrong, but it is still definitive. multiple
repositories are in general a synchronisation nightmare.
Didier:
So in that case the trick is to pick the right granularity level. Not too
much, not to few.
but if we're talking documents then not such an issue.
Didier:
As you know, when a collectionof objects are serialized in XML, it takes
adual nature: a collection of objects and a document.
so client server has several problems - performance (too much data sent
over the wire), synchronisation (who really should do the update?), and
lock out (my station has a lock, but died and forgot about the lock).
Didier:
Performance: too much data sent through the wire: not necessarily if you
package them in an XML document. Not really a decrease in performance. I
would say, on the contrary a gain in performance since you have less ping
pong between the server and the client.
Synchronization problems: Here is the real problem to be solve, not the
previous one (on the contrary you gained performance with a client-server
model compared to the mainframe centric one). I agree, synchronization is
really an issue not obvious to be resolved.
central systems can easily overcome these things.
Didier:
Yes they easily resolve the second issue: synchronization to the detriment
of the first one: performance. In reality, mainframe centric architectures
trade performance for synchronization. So, in reality they are less
efficient but not have any synchronization problem. On the other hand,
client server ones are more efficient but may lead to synchronization
problems if the granularity of the object collection transferred is too
numerous. We also forgot to mention something else, with a mainframe centric
architecture, the user have a worse experience.
many, many years ago (about the same time as rpc's) we started playing
with loosely coupled, cooperating and synchronised systems using uucp
(there wasn't any broadband back then) and found that messaging systems
could work very well. email made it easier and now soap is making it
even easier. now we need intelligent agents at the user end. our
original solution was a database agent at each distributed node, but
that doesn't work in the wide world.
Didier:
What about using XML to transfer the collection of object and then transform
them into you target language environment? Maybe you have the right
technologies now to do it, doesn't it?
xul is offering us a way forward, and presumably xaml will also (but it
will only work on ms workstations :( so it's not a general solution).
it's early days, but i see light at the end of this tunnel. java is
probably the other way forward.
Didier:
Yes indeed XUL and XAML are good solutions. There other ways but they
require more creativity and more thinking. It is possible to build a
component based system on XML+HTML+ECMAScript. Like I said, it is not so
obvious if I consider how badly the industry didn't came to a solution using
these three elements.
Cheers
Didier PH Martin
|
