[
Lists Home |
Date Index |
Thread Index
]
- From: uche.ogbuji@fourthought.com
- To: "Borden, Jonathan" <jborden@mediaone.net>
- Date: Tue, 09 Feb 1999 20:54:13 -0700
> > > > 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 hope you're not pointing out the above as a contradiction. If so, context
should have made it clear that when I do use DOM, it is never as a basis of
the core business-object model, but as a UI or serialization interface.
> 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.
I am aware of DO network latency issues, but for the scale in which I have
worked, a few basic optimizations minimize the ORB requests.
And your post does make me mind the fact that I should be careful when
discussing such matters here. Paul has spoken of needing to manage terabytes
of data for his clients, and I don't know what size/structure DBs you usually
work with, but I do not have experience deploying solutions invloving more
than 20GB or so of data. It is possible that what to me is a minor and
unnoticeable dilation would scale to unusability in a large-enterprise
application.
--
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com (970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com http://OpenTechnology.org
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)
|