Conceptual Analogies

Relational Databases

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:

Concept RDBMS SQLstream
Data Stored persistently Flowing
Query StaticRe-executed frequently Live QueriesActive, continuous execution
ExecutionControl Application calls RDBMS. SQLstream calls Application.

Publish/Subscribe Message-Oriented Middleware

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:

  • Publishers INSERT INTO … the message stream through JDBC, or even through a JMS driver.
  • Subscribers *SELECT STREAM * FROM …* the view representing the logical “topic,” which can filter by tags in the message itself.
  • Unlike message-oriented middleware, SQLstream s-Server can join message streams.
  • This join capability allows SQLstream to filter content based on lookup information that is not directly contained in the message. Complex SQL can thus use multiple message attributes to create “calculated topics,” beyond any original topic list, or even create time-based “aggregated topics,” offering hourly or daily roll-ups of the published messages.

Since there is no automatic provision for storing messages if the subscriber is not connected, standard SQLstream subscriptions are non-durable in JMS terms.

Enterprise Service Bus

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.