[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Distributed DOM implementations
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@i... [mailto:owner-xml-dev@i...]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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ 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
|