ProLinga System Builder
What is ProLinga?
ProLinga System Builder is a 4GL / Web Services composite environment for the development and deployment of software applications.
Introduction
Open Source technology has been widely accepted and is being used in back office server environments for many years now. Many companies are running at least one GNU/Linux server using packages as Apache Web Server, sendmail, FTP Server etc. We now see a new development emerging, where Open Source platforms are starting to get used more and more on the Desktop PC and various (hand held) devices. Quality applications as Open Office, Evolution mail and GIMP graphical editor for instance demonstrate that an Open Source desktop solution can be a superior alternative for just a fraction of the costs.
For many specific tasks on the desktop, standard Open Source packages as a Word Processor can be used. However, there will always be a need for organizations to have some tailor made solution. A membership application, a manufacturing application, order & stock application to name a few. At the moment these types of software need to be written in languages like C/C++ for these new platforms. While very powerful computer languages, which we use in many of our own projects, it often takes too long and becomes too complex for many companies to use and maintain applications in these environments. What they really need is a higher level programming and run-time environment.
ProLinga System Builder solves this problem. ProLinga System Builder is a 4GL run-time and deployment environment linking many available quality and reliable Open Source projects together, using XML where possible.
ProLinga System Builder
ProLinga System Builder is a 4GL / Web Services composite environment for the development and deployment of software applications. The product focuses primarily on the GNU/Linux (GNOME) desktop system for the User Interface and any modern GNU/Linux or Unix distributions for the Web Services. 4GL applications developed with ProLinga System Builder for the Internet browser interface, are available on a wide range of platforms. Current data interfaces include interfaces to RDBMS as MySQL, PostgreSQL, Sybase and Oracle. The application repository is a native XML database and the application data is available using an interface built around Berkeley-DBXML. Additional data interfaces as well as non-browser UI interfaces to other modern desktop systems, will become available as the project progresses.
Below a schema of the various ProLinga components and how they are linked together.
The Web Services are daemons running on a server waiting for an XML request. As soon as this request arrives, it is processed and an XML response is generated and sent back to the caller. The Web Services can run on 1 server, but they can also run on separate servers running different O/S systems from all corners of the globe. For sending and receiving requests and responses, a SOAP protocol is used, running over TCP/IP connections. The various Web Services are explained in more detail below.
This schema shows the two different user interfaces, a web browser and non-web browser based UI.
When using the browser interface, a user connects, using a URL, to the Prolinga-Web application, which is installed as a CGI application on the Web Server (ie Apache). ProLinga-Web translates the URL of the user to an XML Request (Web Command) and sends this on to the ProLinga-Run Daemon. This daemon is a 4GL language interpreter which processes the command. After processing the response is sent back to ProLinga-Web. The response as envelope is XML, but can contain data formats as XML, WML, HTML, TEXT etc. In the case of a browser being the client, the format is HTML. ProLinga-Web unpacks the response and sends the HTML portion back to the browser. To split data from mark-up, ProLinga-Web contains a built-in XSLT processor, allowing data to be generated in XML format by ProLinga-Run and then transformed using an XSLT style sheet on the web server to HTML. Security sensible information can also be parsed by ProLinga-Run itself. Please note, I differentiate this channel with the term browser-interface, the client can also be a non browser like a 3rd party application which can send out a URL and receive/process returning data.
The non-browser interface is an implementation of the GTK+ user interface for the GNOME desktop. When using the browser interface, user interfaces must be generated on the fly (using HTML for instance), by using the non-browser interface, 4GL logic commands are implemented for the control of the User Interface. This explains why the ProLinga-Run application connects to the various Web Services directly, while the ProLinga-Web interface only connects to a single Web Service. An extra layer can be implemented, to make some Web Services more private, than public, as it is now. This gives it a more one entry-point portal approach as the latest development network model demonstrates.
The type of this connection is neither a 'fat' nor a 'thin' client. 4GL interpretation is performed locally: part of processing (like validate) is done remotely and remote resources are used. From an end user point of view, only prolingarun is needed, together with a configuration file containing the IP addresses/hostnames and ports of the Web Services needed and all will work. This is where new technologies as WSDL UDDI will start to fill in all the gaps.
Main advantage of using a structure like this, is that it is very easy to maintain, add, remove, rewrite Web Services and modules without breaking the whole system. Also the background of a Web Service does not matter. One Web Service can be programmed in C++ while another is written in Java. Many libraries and sub products are written and maintained by the open source community. They have proved their stability, and minimal effort is needed to "just" support the product. Updates of the free sub product leads to a new release of the end product.
All Web Services include a C++ API as well, so all the various services can be compiled in a single stand-alone application if desired.
Please have a look at some screenshots of the product.
ProLinga Components in more Detail
The various components of the ProLinga Network Model are listed here, with links to their separate project pages.
ProLinga-Repository is built around the native XML database developed by Berkeley-DB and holds the application repository as a collection of XML documents in a database. Since all ProLinga application component definitions are managed as XML documents, it makes sense to store them as XML as well to eliminate the need for mapping the data back and forth.
This is a Web Service which uses the latest libgda technologies to provide access to the data providers MySQL, PostgreSQL, Oracle, Sybase, ODBC data sources, mSQL, IBM DB2, FireBird/Interbase, FreeTDS, SQLite, LDAP, MS SQL Server, MDB (MS Access), Berkeley-DB and xBase (dBase, Clipper, FoxPro) files.
ProLinga 4GL commands as typed in by the (developer) user can not be efficiently processed by an interpreter in its raw form. ProLinga-Validate will validate and transform 4GL code into an XML document containing control information. The user sends out a request to validate. The validate service will then send out a request to the repository service, receives the logic, transforms and validates this (or generates error code), sends transformed and validated results back to the repository and responds to the caller.
ProLinga-Web is a (Fast) CGI application which generates requests based on a received URL. More than likely this URL will come from an Internet browser, but applications can be programmed to send out URLs and receive/process results. Currently built in content types are XML, WML, HTML and TEXT. Also a built-in XSLT processor can transform XML responses into virtually every other format. This makes it very easy to split mark-up from data.
ProLinga-Run is the 4GL run-time environment. Currently there are two flavours. The prolingarund binary which runs as a daemon and is used by the web component, and the prolingarun binary which will run on a user desktop machine. In both cases, they contain the 4GL interpreter, while the desktop version also contains bindings to the user interface. With the run-time environment, I also refer to the development environment, since it runs in the run-time environment itself.
Not visible in the schema is the ProLinga-Soap project. This is a set of soap 1.2 libraries which enables the various ProLinga components to send out and receive XML documents using the libxml2 format.
Not visible in the schema is the ProLinga-Calc project. This is a library which, after implementing, enables any application to make C expression type calculations. Those expression are bind to 4GL math commands. If required, the library can be implemented as a Web Service as well.
ProLinga-Doc
Not visible in the schema is the ProLinga-Doc project. This project focuses on the development of documentation as the ProLinga 4GL Reference Manual, ProLinga User Guide and a ProLinga Introductory Tutorial as well as sets the documentation standards and layouts used by all project specific documentation.
Not visible in the schema yet is the new ProLinga-UI project. The ProLinga-UIproject focuses on the development of a User Interfaces for the ProLinga-Run (4GL Interpreter) project. Main purpose for the creation of this project, is to provide an easy way to unlink the 4GL interpreter (ProLinga-Run) from user interface calls to provide a base for a user interface independent platform.
Search
