einhverfr's Journal: LedgerSMB 1.3.0 -- Why it's cool

LedgerSMB 1.3.0 was released today after several years of development (perhaps nearly joining the ranks of Perl 6 and Duke Nukem Forever). The release offers a number of compelling features, such as separation of duties, far improved payment handling, better cash reconciliation and the like. But what makes LedgerSMB 1.3.0 cool is how we are pushing the envelope technically and attempting to provide a framework for quickly building new programs which re-use our application's functionality.

Simply put, the cool approach we are taking is in making stored procedures discoverable, much like web services. This is done by assigning semantic meaning to argument names, and then using a mapping function to pull argument names from the system catalogs, mapping these to object properties. This offers many of the benefits of web services, such as offering a looser coupling between database and application layers than is traditional, and it facilitates the development of add-ons or even other applications which re-use LedgerSMB functionality.

One key element to making this work is the principle that the database in such an environment should be the centerpiece of the computing environment rather than the bottom tier of a multi-tier architecture. Thus every application user is a database user, the database itself enforces permissions, and can act not only as a data store but also a message queue, possibly routing data to other applications (via queue tables and PostgreSQL's LISTEN/NOTIFY framework). In essence the database does everything that could be done with set functions.

Of course the database doesn't do everything. We don't hand it raw http query strings, or have it output HTML documents assembled from data inside the database. This is the job of the application layer, which is to manage the interaction with the human component. Separating this role off, then allows for more diversity in usage in the future. We are thus no longer tied to a web interface for the long-run, and could allow other client apps to be built on our software in the mean time, all sharing a common security and data logic framework.

In this regard, PostgreSQL takes on traditional middleware roles in LedgerSMB from 1.3 onward. This isn't to say it is an application server in the classical sense, but rather that it takes on many roles of application servers. We've found this approach to be quite scalable because hand-tuned SQL generally performs better (and is easier to troubleshoot) than ORM-generated SQL statements, and yet of course much business logic is not in the db server at all but rather in the application which provides the interface between the db server and the user interface, whatever that may be.

Work has already begun on 1.4 to take this approach to an even higher level, as we re-engineer the financial logic to make use of this approach.