[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Why XML for Messaging?
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|