RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
Uche Ogbuji wrote: first: > > > > > I don't think it makes sense to build a business-object model > on top of DOM, > and then: > I have often ended up using DOM because I'm > working in a > distributed environment, using CORBA, and it makes it very easy > and natural to > just call DOM interfaces across the ORB I too work in a distributed environment, until the last year in DCOM but increasingly using HTTP. In the multi-tier model, the client communicates with the middleware or business-object tier using an RPC or distributed object protocol. For the sake of discussion, lets assume that the DCOM wire protocol and CORBA IIOP have roughly similar functionality as object RPC protocols. Good practices in such systems dictate that round-trips between the client and business object layers be minimized (in fact round trips between tiers in general should be minimized except that when objects exist in the same process, or memory space, an object call as efficient as other in-process calls. (e.g. in C++ this is a vtable call, the difference in Java is the difference between a normal Java method invocation and an RMI invocation). Failure to mininize round trips is often the single biggest performance drain on such systems otherwise well designed. This is a tenet of distributed object systems design. While I have advocated judicious application of the DOM interfaces in object systems, the DOM is best not employed as a business object itself (i.e. the client ought not communicate directly with a distributed DOM), for reasons outlined by Paul Prescod, as well as the fact that this use of the DOM will *maximize* client-server roundtrips. For example a when a NodeList is returned from a distributed DOM call, the client obtains a *proxy* to the NodeList, and iteration through this proxy results in a server roundtrip for each call. It is far more efficient to select a document or document fragment using a distributed call and return this as XML directly. The returned XML can be parsed and iterated on using local client calls. My studies on files as large as 100 Mb demonstrate that it is usually more efficient to download the entire file to the client for processing than it is to iterate over a file using distributed object calls. By defining a document fragment using a distributed call, and returning the document or fragment in serial fashion (i.e. XML) and locally processing, performance may increase by an order of magnitude. > > > > Yes, it makes sense to use XML as an "interchange language" between your > > business objects and your user interface. On the other hand, if that > > interface is meant to be editable the information loss associated with > > "dumbing down" to XML may not be acceptable. > Another way of saying this. Extra work to smarten up the XML interchange format is well worth it (the problem is not with XML as an interchange format). Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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