StreamDDB

Many businesses are finding out how important electronic document delivery is to support their customer self-service initiatives. Initiatives that include on-line bill presentment, on-line report distribution, on-line manual retrieval and many others.

StreamDDB is server-side middleware that facilitates electronic document retrieval and transformation that is reliable and scaleable The diagram below illustrates the StreamDDB integration.

Application Architecture

StreamDDB provides a generic interface into IDARS (Integrated Document Archive and Retrieval Systems) and Document Transformers. This “hub and spoke” architecture provides a high degree of flexibility for companies to leverage the best of breed IDARS systems and Document Transformers without coding to any specific vendor API.

The diagram below illustrates how DDBServer interfaces with IDARS systems and Document Transformers independently via connector and transformer adaptors (represented by the double arrow).

Product Features

Reduces round trips to the IDARS Systems. (Integrated Document Archival And Retrieval System) StreamDDB will reduce the number of round trips made to your document storage system. By reducing round trips to the document storage system, companies are able to reduce the demand on their system, and will ultimately use fewer vendor user licenses.

Document cache

When an application requests a document from StreamDDB, it first checks its LRU (Least Recently Used) cache. If the document is found in cache, no call is made to the Document Server. If the document is not found in cache, StreamDDB requests a connection from the connection pool and then retrieves the document and stores it in the LRU cache.

ResultSet cache

The resultset cache is similar to the document cache. In this case resultsets are cached, so that multiple requests for the same resultset do not pay the penalty for downstream calls to the document server.

Connection Pooling

Generally a round trip is required to “logon” to the Document Server another to “logoff” from the server. By initializing and pooling document server connections at system start up, StreamDDB is able to eliminate the unnecessary round trips for logons and logoffs to the document server.

Failover

StreamDDB customers can configure multiple instances of StreamDDB to handle their system demand StreamDDB leverages the Publish and Subscribe model to provide failover between the DDBClient and the DDBServer. If a DDBServer goes down, the DDBClient will automatically reroute the request to another available DDBServer instance. Likewise when a DDBServer is made available the DDBClient will automatically start routing request to the given server based upon the load balancing strategy defined in the configurations files.

Scalability

The StreamDDB architecture can scale horizontally to as many StreamDDB servers as are required to meet the demand. StreamDDB servers can be co-located on the same machine as the application or on separate machines. This horizontal approach to scaling, allows companies to distribute their load as demand increases.

Load Balancing

StreamDDB has implemented two types of load balancing: “Round Robin” and “Preferred List”. The Round Robin load balancing type will distribute load evenly to the DDBServer instances. The Preferred List will always attempt to route requests to the first available DDBServer in the list. Should the “preferred” DDBServer instance become unavailable the next available server in the list will be used. Preferred server is popular with companies who may have their application and StreamDDB server co-located on the same machine. This type of configuration can reduce network traffic between the DDBClient and the DDBServer.

Stability

The sections above that describe Failover, Scalability, and Load Balancing all contribute to the overall picture of providing a stable production environment. With failover, should one server fail the system rolls over to another active server accepting requests. With the ability to dynamically add new DDBServer instances to meet demand, the system scales horizontally very easily. By simply modifying the client configuration file, the system can balance load between DDBServer instances.