xml-dev - RE: Distributed DOM implementations

["Ingo Elfering" <elfering@medicaldataservice.de>]

We have such a system working (if I understand your question right).

It´s a DCOM (!) object that is used from a client via a browser to manage
patient healthcare data. The DCOM objects handles all logic like access
permissions, where to the other side it uses the IE 5 Beta2 DOM/XML/XSL
object to handle XML data. It runs under MTS and actually stores the data in
a SQL DB. The system is in pilot installations running. The client sees
pre-parsed data, partly as properties, partly as a XML stream. Caching is
handled via a client side COM object that uses this data DCOM obj. Run's
fine ! Not too difficult too build... Anything I can answer ?

Mit freundlichem Gruß/Best Regards
Ingo Elfering
www.MedicalDataService.de

>-----Original Message-----
>From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
>Eddie Sheffield
>Sent: Donnerstag, 28. Januar 1999 16:22
>To: XML-DEV
>Subject: Re: Distributed DOM implementations
>
>
>Hello,
>
>I've been considering the possibilities of such a system myself.
>One approach
>might be to use intelligent stubs on the client side ("stubs"
>being the client
>side objects that you interact with that in turn forward calls to
>the actual
>server-side objects) that provide some caching and prefetching
>support. This
>would require a lot more work, including probably hand-mangling
>the generated
>classes, but could be a useful compromise. For example, when you
>first get a
>reference to the root of the DOM tree, the stub goes ahead and
>fetches all the
>root's attributes and direct childen. If you then refer to one of
>those child
>nodes it's already available locally and so no server call is
>necessary. There
>would need to be some kind of policy in place for dumping cached
>objects and
>selecting which objects to cache to prevent the entire DOM from
>ultimately being
>present in the client (might be a huge document and client
>resources might be
>tight).
>
>Any ideas? I'm tempted to take this notion to the CORBA lists as
>it's more a
>distributed processing problem than XML.
>
>Eddie Sheffield
>
>"Ingargiola, Tito" wrote:
>
>> Hi,
>>
>> Given that the DOM has an IDL mapping, writing distributed
>implementations
>> of it should be easy.  Due to some of the choices made in that mapping,
>> however, it's a little less clean than one might hope.  Specifically, the
>> IDL and Java mappings are incompatible.  I had brought this up before in
>> both this and the DOM mailing lists.  Stephen McConnell from the OSM
>> (http://www.osm.net) was kind enough to explain why this was the case and
>> what was being done to address it.
>>
>> In the meanwhile, out of curiosity, I wrote a set of adapters
>that provide a
>> "bridge" between these inconsistencies in the Java & IDL mappings.  I've
>> used these adapters to remotely manipulate DOM objects using the
>> stripped-down CORBA implementation that comes with JDK1.2.  My
>experience is
>> that you're not likely to be too pleased with the performance
>> characteristics of such an effort, but it's pretty interesting
>to play with,
>> and for some uses the performance characteristics may be acceptable.
>>
>> If anyone is interested, I'll be happy to send them a copy of these
>> (extremely rough!) adapters.  Regards,
>>
>>         Tito.


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/
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)