Today Morfik announced officially the availability of Morfik 07, the internal version 1.0.0.7 (See press release PDF). You can download Morfik 07 from morfik.com, some new exciting features that we didn’t announce previously goes public now:
- Morfik debugger has been modified to enable it to debug Free Pascal Compiler (FPC) created applications. What this means is that FPC has now replaced Virtual Pascal Compiler (VPC) as the default backend compiler for Morfik. As of this release, VPC is no longer supported.
- Converting projects from one language to another. This feature, which is available under ‘Project Menu’, is currently being used as an in-house tool for converting all sample projects in Morfik Labs to Morfik C#, Java and Basic languages.
You can find more details concerning new Morfik features in the release notes. Morfik 07 come also with a zero-deployment-cost perpetual license, startups interested can use it now and pay later, and be sure to check the website for more details on pricing and usage by Pioneers and educational institutions also. So we thought today about giving you look inside Morfik Architecture. It will be in two parts, we will cover first the basic architecture of WebOS applications and the WebOS application programming model. Then we will see in another post the event driven nature of Morfik WebOS applications and Morfik’s design methodology for building WebOS Applications to complete the serie.
Basic architecture of WebOS applications
It’s interesting to notice that applications that are created using Morfik WebOS AppsBuilder have the same binary structure as the native executables that run on the underlying operating system. The main difference between the WebOS applications (‘XApp’) and the native applications are the way their user interfaces are implemented. Whilst native executables use the non-standard proprietary interface elements of the underlying operating system, WebOS applications implement their interfaces using the web browser and W3C standards. The implementation of the user interface in the browser is done through a combination of JavaScript, XMLHttpRequest and HTML which is also known as AJAX (Asynchronous JavaScript and XML).
WebOS applications store the AJAX code internally similar to the way that win32 resources are stored within a native executable. When WebOS applications are loaded their AJAX code is sent to the browser. The remaining part of the application will behave as a web server responding to the requests initiated from the AJAX code within the browser. The communication between these two entities is of course based on the HTTP protocol.
Compared to the native executables, WebOS applications have a few limitations due to the stateless nature of the HTTP protocol. However, their main advantage is the fact that the user interfaces can be ‘decoupled’ and sent to a remote machine to run! This decoupling of the user interface and the application on demand and at run time is the most powerful feature of WebOS applications. As a result, a WebOS application can run locally, remotely, on-line and offline. It can support both the peer-to-peer architecture as well as the classic client/server model. It can be used as a single user application or a multi-user application.
Morfik’s current implementation of a WebOS application uses the Apache server. Unlike the standard deployment of the Apache server Morfik uses the Apache server in the form of a dynamically linked library (DLL). This makes the Apache server subservient to a WebOS application. The interaction between the Apache server and the WebOS executable is based on the ISAPI model. The Apache server passes all requests to the executable. These calls to the executable carry the request through the ISAPI Extension Control Block (ECB). The ECB contains the http request information and also include internal function pointers. These function pointers allow the response to be communicated back to the Apache server for transmission back to the originator of the request.
On the browser side the execution happens within the context of a single browser page inside the browser. The Morfik AJAX engine acts in similar fashion to the Delphi’s VCL or Microsoft MFC in that it consists of wrapper objects that wrap around the underlying operating system user interface elements. In the case of win32 these objects are the windows controls whilst in the case of WebOS these controls are elements found in the browser DOM.
WebOS application programming model
The browser side and the server side code in a WebOS application are characterized by two distinct programming models. The server side code is highly concurrent while the browser side code is completely asynchronous. Whilst Morfik IDE removes many of the programming chores associated with these two types of programming an understanding of these two concepts are fundamental to efficient programming within Morfik.
The majority of desktop applications are lightly threaded and almost always synchronous. Apart from the user interface thread there might be a small number of worker threads that do a number of time consuming activities. Most small to medium size application on the desktop are run on a single thread. On the other hand the server side of a WebOS application is heavily multithreaded. Every request going to the server runs on a separate thread.
Morfik’s implementation of WebOS applications uses a completely stateless approach to the programming of the server side. This means the data within the server side code does not change during the course of execution of the program. Any data that changes is either committed to the database or will be lost. This to a large degree mitigates the onerous requirements of multithreaded programming. This approach needs to be followed by application developers. Global variables must be avoided as much as possible as they are normally not ‘thread safe’ and they would break the stateless model of Morfik WebOS applications. However if it is needed to have stateful global variables one has to use the appropriate programming techniques for thread synchronization.
The programming model for the browser side is on the other hand completely asynchronous. This would particularly feel different for those who are accustomed to traditional desktop applications that are highly synchronous. The main cause of this is the http communications between the browser side and the server side. Sophisticated activities within the browser side often require multiple calls to the server side. However every time a call is made to the server side a ‘callback’ must be set up so that the execution of the task could continue. Since the ‘state’ of the execution is not kept from the point that the call was made relative to the point where the call back function is invoked, it is the responsibility of the programmer to manage the execution state within the browser. Morfik IDE and the AJAX code hide most of these activities from the programmer. However there are situations that one may require to do the setting up of the call back functions as well as preserving the context of execution.
Another aspect of Morfik’s browser side programming that requires a mention is the way in which the AJAX code is downloaded into the browser. Upon start, the core of the AJAX engine is sent to the browser. This is enough to get the AJAX user interface up and running. Then the first time a module is being accessed within the browser, the associated JavaScript must be downloaded. This allows for a higher level of scalability but at the same time it means extra programming work before calling functions within other modules. Morfik has a number of functions that hides the code that is responsible for downloading the JavaScript.
