Re: Xquery might have some things right

"Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:52a2c.37$zW4.263_at_news.oracle.com...
> "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message
> news:rU82c.30429$6e7.1801_at_bignews1.bellsouth.net...
> > What if we're talking
> > about an entire network of "clients" that need to be notified. Would
> you send
> > them some sort of notification and then allow every one of them to
> then perform
> > a remote query on your servers local database? Doesn't sound like a
> very scalable
> > solution to me? I think the slight amount of overhead introduced by
> using a wordy
> > protocol like XML, when combined with a UDP broadcast, is far superior
> to
> > the "pull" type system that you are suggesting.
>
> Sorry, but no, there is no logical redundancy in my approach. Every client
> queries only the info they want to know. It is extremely rare when client
> wants the whole database. Usually, client query filters most of the data out
> according to some criteria. The other common case is aggregated report,
> where the output is small as well. In both cases extra information is
> quickly discarded on server and would never cross the network boundary.
> Whereas in your broadcasting proposal you flood the network with spam that
> clients rarely care about.

    Sorry, you're wrong again. I described a publish and subscribe mechanism     that broadcasts information only to those clients that have "subscribed" to     that particular publication. In your solution, every client interested in a particular     piece of information would have to query the server, essentially at the same     time, to retrieve it. Unless you can think of some way of throttling your clients,     I don't see how your solution would ever scale.

    Allowing clients to directly query the server via SQL makes your design     too fragile for real world application. Server side schema or application     changes will immediately break every client in your system. Your solution     requires that clients have intimate knowledge of the servers table structures     in order to properly formulate a "query" that would allow the client to pull     the information that they're interested in.

    Interfaces between systems must form an abstraction layer between the     server and the client in order to insulate one from the other and to allow     for application flexibility. Not to mention, I don't know of too many application     owners that are going to allow untrusted clients to have direct database access     to their systems. Even if the access is in a read-only mode, there may be information     stored on the server that is considered sensitive and cannot be shared with other systems.     For instance let's say your bank account numbers or social security number was stored along     with your stock information. Would you want external clients to be able to randomly     query for such information?

    An AAIS is the only real world solution, and the AAIS has to be agreed upon     by both parties. The message protocol used between the server and client needs     to be robust enough to allow the server to be able to service multiple clients with     the same message protocol. This means that the messaging layer needs to be wordy     enough for the clients to be able to distinguish between the the parts of the message     that is meant for them specifically and what is part of the message is really only meant     for another client. XML fits that need fairly well.

    Long before XML became an industry buzz word, we used an XML like language     called G2 to solve intersystem communcation problems between large disparate systems     at a really big phone company. Some of the systems that we needed to connect together     were built before 1969. Some were based on Unix solutions, others later on were based     on Windows solutions. They all had to talk together, which meant that we had to have     a language and machine neutral message protocol. G2 fit that bill. Now XML can fill     that exact same need. It's not perfect, I'm not saying that it is. But what I am saying is     that it fits a particular class of computing problem very nicely and should not be discredited     simply because it can't be queried as nicely as a relational model.

    regards
    --Corey Received on Sat Mar 06 2004 - 16:32:42 CET