The connection API discussed here is JDBC (a well known standard), the query language is SQL (an uber standard that can support joins and other complicated functions). Yes, the callnack CQ fucntionality requires a proprietary API.

With Tangosol, connection, query language and CQ call-backs are all handled via proprietary APIs, and the query langauge is more of a filtering language.

Yes, Continuous Query in Tangosol Coherence requires the use of an API designed for Continuous Query, since there is no standard API in Java to support Continuous Query. The product covered in the article requires the use of a proprietary API to use its own continuous query features, and that seems perfectly acceptable in the absence of a standard.

But, Tangosol's continuous query requires the use of a proprietary API (not as intuitive as SQL) and by no means can accomodate the complex conditions/predicates that can be modeled with a SQL based continuous query paradigm. Seems like a classic marketing/"me too" strategy from Tangosol..:-)

The client/server development model prevalent in the mid-1990's resulted in extremely easy-to-build rich GUI applications that interacted directly with a relational database. 4GL tools such as Visual Basic and PowerBuilder let even junior developers visually compose both the presentation and most of the backend data binding. While this made for impressive Rapid Application Development (RAD) productivity, the client/server architecture was severely challenged when dealing with real-time environments where the data changes rapidly and applications require visibility to the correct data at all times. As a result, client applications were forced to poll the database continuously to check for changes.

Tangosol Coherence also provided Continuous Query, including Continuous Query Caching.