Joty is a project born from the challenge to find a way to convert a standalone desktop application in to a web application with the minimum effort and cost.

Neither a layered structure of the destination application is the goal of the project nor particular abstraction strategies were searched. Instead, in a very primitive approach, a way was searched to let every context of data access performed by the original desktop application in the same place along the execution flow and with unchanged responsibility.

An immediate way to achieve this goal, is to deliver any statement through the http protocol to a listener ( a server ) that would perform the access to the database server and that would return the result back to the client; however this rises the problem to deal with the typical database transaction that the original desktop application typically performs: http protocol is stateless but a database transaction is not.

The idea to perform a mirrored state of the desktop transaction on the server side is completely impracticable because the mirroring can be broken by any interruption of network that makes the completion of the transaction to fail and thoughts of any sort of recovery could lead to unreasonably complex technologies and possibly poor in robustness.

The problem becomes harder since, during a transaction, new data may be created (like new entity IDs) that not only need to be returned to the caller but that must be used in the rest of the transaction (typical header-details scenario).

Not to give up to this difficulties I let coming into play an idea that I named “Delayed Desktop Transaction”; the inherent approach is as follows:

I used the word “delayed” because, in relation to the execution flow that composes the whole transaction, the actual interaction with the database server is performed at the end of the composition (see the sequence diagram), no interaction with the database server is performed before, conversely of what happens in a classic desktop application database transaction. Note that this approach recovers the strength of the transaction support of the dbms, in fact the whole transaction and its result are exchanged in a single Http Request/response interaction.

This scenario leads to the following features:

  • the logical implementation of the business rules is left unchanged and, above all, the application database remains unmodified (meaning both the type of the dbms and the schema instance)

  • the maintenance of the new application is at most costly as the old desktop application (typically the maintenance cost is even lower for the use of the Joty api)

The project has come to its 2.0 version that has been drastically improved and extended in respect of the version 1.0 released in 2013 and the last stage has been accomplished keeping unchanged the original mission.

One of the point of drastic improvement is the splitting of the framework in three part: Core, Workstation and Mobile. The Workstation part, relying on the Core, inherits the responsibilities of the previous version to let the developer to build desktop or web reach application running on PCs, but now hosting Linux, Windows or Mac OS.

The Mobile part is a completely new part that, by relying itself also on the Core, allows the developer to build web apps for the Android Os, based on the communication with the Joty Server and typically strictly related with the workstation applications, to give them the usability on the handset devices.

The framework is accompanied by a pair of sample applications one of which has a medium degree of complexity: in 2005-2007 I published on the Internet a desktop application for the Windows platform; which could be a better way to give the reader the feeling of concreteness about Joty project, than making the conversion of such an application in the Joty technology ? Furthermore, this application has been made available online (click here) to provide a trial experience without the need of a server installation.

More details about the Joty project can be found here.