Select your language
In this post we show how to use websockets from the Modelit Webserver toolbox. This feature was recently added to the toolbox and makes it possible to have full-duplex communication between the client and the server. This means that the client as well as the server can send messages to the other, contrary to the conventional HTTP requests where the conversation is always initiated by the client. Websockets are more efficient than HTTP request because they maintain an active connection and do not require the HTTP request/response overhead for each message. This makes it suitable for realtime applications and applications with multiple clients.
In this post we show how to build an application that uses Javascript for the front-end while the back-end is implemented in Matlab. The front-end and back-end are coupled by using the Modelit Webserver toolbox. This toolbox was recently extended to support websockets which makes it possible to have two-way communication. I.e. the front-end can send messages to the back-end and vice versa.
The Modelit Webserver Toolbox for Matlab makes it possible to deploy algorithms written in Matlab code as a webservice. Central to the toolbox is a servlet that runs in Apache Tomcat and which redirects incoming web-requests to Matlab callback functions. Using Apache Tomcat has advantage that it is a proven technology with a lot of features. However it introduces an extra component which causes extra complexity and makes the use of Matlab algorithms in Docker containers overly complicated. As a solution Modelit has extended the Webserver toolbox with an embedded server, based on the Java Sun HTTP server. This server runs inside Matlab and makes it possible for Matlab to directly send and receive HTTP messages.
Background:
Matlab's webread and urlread are single threaded functions. When executing multiple download commands they are executed sequentially, while blocking the main Matlab process. For most applications in Matlab this is not a problem, normally data is downloaded once and when the data are available the main program continues its execution. But if data have to be retrieved in various separate requests, for example in the MapViewer where a number of tiles with background images have to be downloaded, it is important that the application's communication is fast and does not block the main application while downloading.
Background:
For complex applications it is useful to have a flexible logging framework. In which the logging can be sent to different destinations, for example a database, a file or the console in a format the can be configured at any time and that can filter out the desired messages depending on the environment. For example all messages in the development environment or only errors in the production environment. The Log4j framework offers all these functionalities. The previously mentioned features can be configured in a .properties file. In this way the logging can be configured without touching the source code.