[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin wrote:
>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.
>
>
not an issue with documents, but it can be a very big problem with data
where extraction may require information retrieval from houndreds,
thousands, millions, etc of records. client server simply scales very badly.
>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?
>
>
we're starting to do it, but if note the cross thread on a recent ms
patent i will probably have to go back to the drawing board on
representation.
but yes, xml transport of data (i'd rather not call them objects) is
working very well. the secret however is the message system, rather than
the syntax of the message.
>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.
>
>
and what is wrong with more creativity and more thinking? i wouldn't
expect a good solution any other way :)
rick
>Cheers
>Didier PH Martin
>
>
>
>!DSPAM:42a26911170345686112979!
>
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
