If you have not yet read about the DivConq design, please do so. Be sure to check out the Roadmap to see the status of any feature, because this page lists many features not yet completed.

[under construction - links to examples and documentation will be added as available]

dcSchema

Use dcSchema to define how structured data is moved around within DivConq – be that between servers, between Java and dcScript, via web services or to stored procedure calls. In the end DivConq treats all data as JSON-like structures. These structures can be validated before they are allowed to be passed to other services, scripts, procedures, etc.

dcDB

The DivConq Java code connects to the MUMPS database via an SSH connection. This keeps the data secure while in transit and is very easy to setup when used with GT.M, the typical MUMPS implementation used with DivConq Framework.

dcDB supports asynchronous calls to the database from within Java. Every update or query must first be assembled into a request and then be submitted to the Java database interface along with a callback object. dcDB will queue the requests and process them when the connection is available. Once a result is loaded the callback is triggered and the result may be processed.

Values to be stored in a database may be encrypted or hashed before being submitted to dcDB. dcDB supports your cryptography needs by supplying a utility that assembles its key from data stored in the database, in the configuration file and from within the application code. This means that a hacker would need the database, the config file for the Java application and the source code to assemble the keys before they could decode encrypted data.

DivConq believes in the power of MUMPS code. Our number one database feature, as simple as it is, is the stored procedure call. DivConq provides the features needed to make it possible to send JSON like data structures as parameters to MUMPS routines during a stored procedure call. Also, DivConq makes it easy to return JSON like data structures from a stored procedure. In addition there is a validation layer so that you may validate parameters before the procedure call is processed and you may validate the return value before the application code accepts the result.

[Stored Procedure Overview: Download Power Point or View on SlideShare]

Beyond stored procedure calls, DivConq also supports dcSimple – a basic multi-key + value storage feature. Provide between 1 to 5 keys, as well as a value, and dcSimple will store that value under those keys. Queries in dcSimple may retrieve one or more keys based on filters. dcSimple is schemaless like many other noSQL databases. dcSimple is replication compatible and will result in eventual data consistency across multiple active databases.

For your relational (table) needs DivConq also provides dcTables. dcTables does have a schema and, although not SQL compliant, it supports many familiar features such as Insert, Update and Select. dcTables does not promote Delete but instead supports Retiring and Reviving records (rows). There are a number of other features in dcTables, such as time-oriented values (data changes over time, but you don’t want to lose the old values). dcTables, like dcSimple, is replication compatible and will result in eventual data consistency across multiple active databases.

By supporting noSQL data and table like data, along with replication (eventual data consistency) across multiple active databases, dcDB dramatically reduces the complexity of database deployment. All-in-one data persistence makes development and support much easier, and replication leap-frogs most SQL engines available where even configuring mirrored database servers is a pain.

The one caution is that stored procedures which update the database must be carefully coded to support replication. But then again, you’d want use dcSimple and dcTables most of the time. For the exceptions you just have to be careful.

DivConq will support many other helpful features such as live database backups, import and export tools, and even replication from dcTables to a relational (read-only) database.

dcServiceBus

With DivConq we promote putting most application (business) logic into a service. DivConq provides the features needed to make it possible to send JSON like data structures as parameters to Services during a service call. Also, DivConq makes it easy to return JSON like data structures from a service. In addition there is a validation layer so that you may validate parameters before the service call is made and you may validate the return value before the calling code accepts the result. Just like stored procedures.

Services are Java classes or scripts (dcScript) and are published in the schema file (dcSchema). When multiple servers are deployed, services may be isolated (and load balanced) to particular servers via the fabric file.

External applications may (with the correct credentials) make “native like” calls to the DivConq service bus by passing in JSON to the web service. JSON is returned from the service call result.

dcScript

A simple, resource light and secure scripting language for use within DivConq applications. DivConq provides the features needed to make it possible to send JSON like data structures as parameters to scripts during a call. Also, DivConq makes it easy to return JSON like data structures from a script. In addition there is a validation layer so that you may validate parameters before the script call is made and you may validate the return value before the calling code accepts the result. Just like stored procedures.

dcWeb

DivConq’s service bus is exposed to the world via web services – both through HTTP RPC calls and through Web Socket calls. Given the full-duplex nature of web sockets, it is possible to achieve a nearly native “dcServiceBus” feel within external applications connecting to the web socket. However, external applications are not trusted the same as internal application components are and as such only a subset of services are available to external applications.

There are two web frameworks supported within DivConq. One is “old school” in that it is not very mobile/tablet friend – but it does make it easy to assemble powerful web applications for the desktop. This first framework is called dcQoo and is based on the Qooxdoo project.

The second web framework is designed to be very light-weight, indeed possible to use no Javascript at all and to render on old browsers. Where Javascript is included, we promote the use of jQuery Mobile. This second framework, called dcLight should deploy well on mobile devices as well as desktops, but have a less rich interface that dcQoo (or take more effort to build rich interfaces).

dcRepository

In addition to the master repository described in the Design page, the developers also have a repository. The master repository contains a collapsed version of all the application components, including only the overrides where overrides are used. The developer repository on the other hand has an expanded version of all the application components. The developer may update the components they own and then compile them into the collapsed format used by the master repository.

In expanded view component overrides are kept separated. It is possible to look at any one component’s folder and find the overrides it contains. When software updates are accepted from vendors, they must first go into the developer’s repository before they can be compiled into the collapsed version. During the developer update, the update program may inform the developer of any conflicts with overrides.

dcAdmin

A web based interface via which an admin may browse, query or update the database. Also the admin may manage the developer/master repository, rollout updates, manage the fabric definitions, and use monitoring tools.

Users/Groups

In SQL databases there are often users and groups, but they often are not used within the application to manage the list of application end users. Within DivConq it is recommended to make your end users and groups relate to users in the database. The solution DivConq provides is to provide a built-in user and group table (dcTables) along with some common methods (e.g. authentication) for their use. Like any dcTable, the user and group tables may be extended by various application components.

Language Translation

DivConq has full featured language support, including support for translation within Java code, within database procedure code, within web code (dcQoo and dcLight) and within scripts (dcScript). Even RTL language support will be included, in dcLight first and eventually dcQoo.

Locale Formatting

DivConq has full featured international number and date formatting support, including support for within Java code, within database procedure code, within web code (dcQoo and dcLight) and within scripts (dcScript).

TimeZones/Chronology

Naturally DivConq also supports end users across timezones by storing all data in UTC and then formatting to the timezone of the requesting user. A step further, DivConq will also be able to support differing chronologies so that a user may see date/times in something other than the proleptic Gregorian calendar.

Since dcDB supports very old dates (up to 50 billion years ago) and also partial dates (just the year, just the year and month, etc) it is possible to track data over all known time (of the universe) – this is why the varying chronology support is important.

dcWorkpool

DivConq promotes the use of a work pool for threaded applications. Don’t create your own threads, instead allow the work (thread) pool to be tuned to handle the workload. When using the work pool the task context (user id, authorization, task id, debug and locale settings) automatically transfers to the new thread for the span of that work.

If the work pool is overloaded, adding more threads probably won’t help. Most areas of DivConq are designed to be non-blocking so when a thread is busy it probably IS busy. As such, allow the work pool to act as a natural throttling tool – work will get done ASAP, and if to much work is requested you’ll just have to wait. Spin up another server if the work load is too severe.

There is also a scheduler if you need a task to repeat at regular/calculable intervals.

Logging

A debug logger comes built-in to DivConq. Each task gets an id and that id is included in the debug log. Although the log entries are interleaved across tasks, given the task id it is easy to extract the messages specific to that task. Further, log entries are (typically) translated so when a translation file exists for your language it is possible to have a debug log in your native language. Translation codes are included in the log entry, thus making it possible to partially translate an existing log file into another language.