The Business Rules Engine

CodaServer Architecture

CodaServer is a Java-based server application. It listens on a port (normally 3407) for incoming HTTP POST requests in the Hessian Binary Web Service protocol. For the most part these requests consist of a session key and a command in the Coda language.

Internally, CodaServer functions as a SQL rewrite engine to convert Coda-encoded business rules and data structures into SQL tables and data. CodaServer can connect to any SQL database engine that has CodaServer drivers, currently HSQLDB and MySQL. If you are interested in getting CodaServer running on a different database, simply implement the org.codalang.codaserver.database.CodaDatabase and org.codalang.codaserver.database.CodaConnection interfaces for your database server of choice, and put those files and the database's JDBC driver in the CLASSPATH.

There are two different types of databases used by CodaServer:

  • System Databases: Each CodaServer has one and only one of these, and theoretically multiple CodaServers can share one once clustering is implemented.
  • Application Databases: Each application hosted by a CodaServer has at least one of these, and up to three. It one is present, it is used for the application's DEV database, if two, DEV and TEST, and if three DEV, TEST, and PROD.

The architecture looks something like this:

network diagram

There is no requirement that any of these databases use the same physical database server or even the same CodaServer driver, although it is very likely that each application will only use one CodaServer driver for each of its (up to three) connections. It wouldn't make sense to have TEST on an Oracle box and PROD on a MySQL box, for instance. It would be perfectly normal for the application PAYROLL to use MySQL and the application ECOMMERCE to use Oracle.

But What is an Application?

CodaServer attempts to create a separation of responsibilities in enterprise software development; the data which is most logically shared between different applications is available to all, and data that is more specific to an individual application is local to that application. This is how it breaks down:

Server-wide Data and Responsibilities

  • Users
  • Groups
  • Application Metadata
  • Server Permissions
  • Application Permissions
  • Types
  • Coda Language Transactions
  • Session Management
  • Datasource Management

Application Data and Responsibilities

  • Tables
  • Forms and Form Statuses
  • Procedires
  • Triggers
  • Indexes
  • Crons
  • Roles
  • Table, Form, Procedure, and User-Defined Permissions

In addition, all application DDL (and some DML) statements are cataloged and versioned in the server's transaction history, so that different revisions of the application can be pushed to the TEST and PROD environments as needed.

So, to finally answer that original question, an application is a versioned package of tables, procedures, and other objects that provide a useful set of functionality. Whew.

What Next?

If all of this is a little confusing, worry not. We have a tutorial that will guide you through writing your very first CodaServer application from the ground up.