XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML Feeds vs SQL Queries

Len Bullard wrote:
>> Given a choice for implementing dashboards that support near-real time
>> notifications, would you implement XML feeds or SQL queries and why?

>> MS SQL Server and the ASP design is set up to push one toward SQL providers
>> and away from using XML.  I see lots of articles for implementing either, but
>> the claim is that performance is tuned for the SQL sources not XML.

>> My intuition was that for dashboards that don't update the database, (eg,
>> read only), that decoupling and using the feed model was a better use of
>> client-server/network resources.

Not necessarily. Some middleware for SQL data access is quite mature so it deals
with issues that can affect network latency and impose a performance penalty -
for example, adapting network packet size based on the type of query.

The SQL alternative also provides a performance solution for the problem of
queries across distributed or disparate data sources. The technology for
optimizing queries across heterogeneous data sources has been refined in SQL
platforms, but it's still in the research stage in the XML world. So if you have
aggregation-type queries that pull data from disparate sources and analyze it
before presentation, you'd have to use an integration server.

If you are using only XML data feeds and your data sources are static, you can
determine how to optimize the process and embed it in application logic. On the
other hand, if the user can dynamically add or remove data sources or queries,
you need machine intelligence on your side.

Bottom line: Query optimization is not simply a solution for performance when
updating persistent data.

Len Bullard wrote:
>> I am somewhat stuck with the solutions I proposed, but for the sake of
>> learning and keeping signal high here on the big list, why is a messaging
>> system better?

Nope. Asynchronous messaging and queues are not precluded by using the SQL
approach. The high-end SQL platforms have been tightly integrated with message
queuing for several years, including Oracle Advanced Queuing. And in recent
years support was added for XML messaging, so your message queues can contain
SOAP, RSS or any class of XML-encoded message content. IBM DB2 XML Extender, for
example, was enhanced to include SQL functions and stored procedures for
MQSeries integration, such as sending messages, shredding documents in messages,
or removing messages from a queue.

Microsoft added support for queues and asynchronous messaging to its operating
systems long ago (starting with Windows NT). It's been possible to use Microsoft
Message Queuing (MSMQ) from clients such as Windows 2000 and Windows XP, and
combine that with SQL triggers to provide an event-driven solution to queue
messages from the database. More recently, SQL Server 2005 introduced a Service
Broker that supports asynchronous messaging using SQL.

So there's no reason XML or RSS content precludes using SQL queries.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS