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:
During the whole execution flow that begins and ends the transaction any statement is collected inside a package instead of being delivered to the server and
any entity ID that is expected to be created during the transaction, either because it is hosted by an auto-increment database field or because it is programmatically extracted by means of a select statement, must simply be declared as associated with the generating/extracting statement : when this condition happens, a literal is created for use as marked placeholder that will remain associated to the lack of the ID value
any reference to the ID value mentioned above, made inside all the subsequent sql statements is replaced by the marked placeholder expression (the reference, in the classic transaction code, would be otherwise resolved with the value itself, since it would be available there)
the commit command actually delivers the whole statements package to the server for execution
the rollback command makes no action (actually the need of its invocation becomes nearly null because during the building process no interaction with external systems occurs). .
The server (Joty server) scans the statements package and processes each statement in the same order in which it was collected by the client; then, for each statement:
if this is marked as a generating ID statement, forwards it to the dbms for execution and picks the generated ID up in order to return it to the client and to use it in the rest of the transaction
if it contains a marked placeholder Joty server replaces any occurrence with the lastly collected ID value, then forwards the statement to the Dbms for execution.
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.