xml-dev - RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)

["Borden, Jonathan" <jborden@mediaone.net>]

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@ic.ac.uk
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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)