Applications that must continuously check for missing data or incorrect values are well-suited to Relational Asynchronous Messaging (RAM). SQLstream's RAMMS readily supports aggregating data in multiple dimensions and checking to verify consistency of the cross sums and aggregations.

Revenue Assurance and Telecommunications

In the Telecomm world, such applications are often categorized as Revenue Assurance. Typical operations include checking that service usage totals for different time periods and geographies, across all potential delivery paths and peering partners, actually reconcile.

In Telecommunications, many service providers cooperate to enable a richer, broader, more widely connected service. They often peer with one another, meaning that they connect their services to allow subscribers to interact and interoperate with subscribers of a rival provider. The idea is that, overall, both service providers will end up generating additional incremental business.

Example: Text Messaging

A good example is Mobile Text Messaging, which only took off in the US after all key providers agreed to peer their networks. The result was that any mobile subscriber could confidently send a text message to any other subscriber, with no concern as to what provider the target subscriber was using. When all the major parties collaborated and peered, the messaging traffic took off exponentially, showing the power (and profit) of "social networking" once technological barriers are surmounted or removed.

Detecting Revenue "Leakage"

Detecting "leakage" of revenue often requires addressing many related service, cost, and regulatory issues, including the following elements:

• Totaling up service usage and service costs
• Aggregating service usage/cost components to create complete records of servicers and costs
• Rating records, which is pricing service usage based on known tariffs or price lists
• Cross-checking the findings in multiple ways until a discrepancy is found

For example, does the bill received from a peering partner match up with the service records as they have been seen and experienced? Are the callers the same? Was the correct tariff applied? Small errors can easily lead to millions of dollars, in costs or revenues, when the volume of service records is large.

RDBMS Issues and Costs

For a RDBMS, storing all the service records or individual components can be very expensive, and performing complex cross checking on all such records is not economically efficient or practical. The insertion rate is too high for sophisticated aggregation to be done concurrently with updating the database table and indexes. Instead, the usual approach is to batch up the records for a day or week and then run batch application jobs to do the checking. Unfortunately, the delay in identifying discrepancies is large, and the potential money losses due to fraud or error can be very large.

RAMMS Advantages

For SQLstream's RAMMS, however, this latency is truly minimal, because an arbitrarily large set of SQL queries can provide near real-time, continuous Revenue Assurance. SQLstream can readily instrument and capture the data sources as streams of RAM messages that feed those queries, generating immediate results as soon as all needed inputs are supplied.

Furthermore, those same messages and results can be repurposed for concurrent Fraud Detection, Compliance checking, billing, capacity planning and many other applicatons.

Thus, SQLstream's RAMMMS solution provides an effective way of both managing and reusing the services' dynamic data assets.

Using Views for Reconciliation Checking, Reporting and Error Alerting

It is natural to express reconciliation checking, reporting and error alerting as views in Relational Asynchronous Messaging (RAM). The logic required to perform such checking is naturally and declaratively expressed as relational constraints (represented as continuously executing SQL statements) over streams of data. The complexity of the logic and the constraints or checks can be broken down into as many additional views as makes sense.

These views in turn can then be re-used in other constraints or reconciliation checking rules. SQL provides excellent facilities for chopping up data streams and regrouping or aggregating along single or multiple dimensions. RAM allows for such reconciliation checking to be performed in parallel as an overlay running alongside the regular, mainline processing that is being monitored.

Alerts are easy to generate in real-time: the error stream is piped into, say, the email adapter as soon as errors are detected. Such checks can be added to safeguard the correctness of the processing or business logic against software defects, logical errors or omissions, oversights and glitches.