ANNOUNCEMENT:

jLina is Released! Download the binaries from SourceForge (v1.1)

Home | Features | FAQ | Project members | Examples | Links

Main features

  • Multi-threaded
  • Zlib inflation/deflation of packets
  • Sacrifices processor power over bandwidth
  • Bridge between any database server (that supports the ODBC interface) and other systems
  • Programmed and optimized for speed
  • Low executable file size (thanks to UPX)

The application sacrifices the server processor speed (zlib inflation/deflation of the packets) for bandwidth (no XML, WSDL, etc. just small compressed packets).

jLina is designed to work with the Microsoft Windows operating system, targeting: Windows 2000, Windows XP, Windows Vista, Windows 7.

The available services are defined in a "operations" file which is specified in the default config file jlina.conf, along with other parameters.

The format for the services definition is "X Y", where the first parameter is one word - the service name, while the second parameter is the actual database query where '?' is parsed as an input parameter and '??' as the actual question mark.

The client would then define his packet "[DELIMITER]service_name p1 p2", connect to the jLina server and send it in deflated form. The server then inflates the packet, parses it, queries the database server, and then sends back the results as an inflated message to the client. Each client session is a separate thread on the server.

However, if X in the service definition "X Y" starts with '!' (e.g. "!Test"), then Y is actually treated as an application on the server. The application Y[0] is started along with command line params Y[1]...Y[n]. Then a pipe is created, and the output of Y[0] is sent to the client.

[DELIMITER] is a non-alpha, non-digit and a non '!' single character, which is optional. But if it is specified, e.g. to ';', then the call would be ";service_name;p1;p2". This allows us to have spaces in the query parameters.

Multiple instances of jLina can be run on the same machine on different ports, therefore allowing the administrator to define different services scope.

Home | Features | FAQ | Project members | Examples | Links