There are many similarities between the SQLstream s-Server and a relational database (RDBMS). Most importantly, both use the industry-standard Structured Query Language (SQL).
The main differences can be summarized in this table:
|Query||StaticRe-executed frequently||Live QueriesActive, continuous execution|
|ExecutionControl||Application calls RDBMS.||SQLstream calls Application.|
Publish/subscribe (“pub/sub”) systems — such as Tibco RendezvousTM or the pub/sub domain of most JMS message-oriented middleware (MOM) — are typically organized into a hierarchy of topics. The topics in that hierarchy offer a moderate amount of flexibility for content-based subscription. That is, the fields and metadata within each message can be used to determine which messages a subscriber will receive, based on a simple SQL, XPath or regular expression using that message content. Content-based subscriptions for different MOMs are implemented differently, rather than using a standard adhered to by all.
These pub/sub systems are not as flexible as the predicate-based filtering and routing offered by a relational SQL-based system. SQLstream’s streaming queries provide a more powerful subscription capability, as follows:
By starting with a top-level message stream, that is, the first in a cascade, a cascading network of SQL views in SQLstream can create the equivalent of a dynamic publish/subscribe topic tree:
Since there is no automatic provision for storing messages if the subscriber is not connected, standard SQLstream subscriptions are non-durable in JMS terms.
An “enterprise service bus” (ESB) is typically designed around routing and delivery features. Messages sent on an ESB are usually received in the format in which they were sent, not unlike sending a package with Federal Express. You expect the package to arrive unchanged at its destination. In some cases, ESBs can perform a one-time transformation of the message content either as it is sent, or as it is delivered.
In contrast, a SQLstream application can transform messages as well as routing and delivering them. It accomplishes this through the pipeline of streams and views. The additional power of SQL views enables SQLstream to transform messages “on the wire” to match the needs of each receiver. In other words, the same message published by system A can be received by systems B and C in two different formats. At the same time, a compliance view can be “watching” the same message traffic and logging audit data or sending alerts. It’s as if the single package you send with FedEx can be received in distinct variations by multiple recipients using different carriers, and you get a log of all the deliveries.