Cloud-Optimized 4GL Applications

8/6/2019 Cloud-Optimized 4GL Applications

1/22

Develop and deploy: Cloud-optimized 4GLapplications

Which platform - 3GL, 4GL, or both - is optimal for yourdata-driven cloud apps

Skill Level: Intermediate

Sean Devlin ([email protected])Senior Technical EngineerServoy

Jan Aleman ([email protected])CEO and Co-founderServoy

24 Jan 2011

Explore which programming language type, 3GL or 4GL, is best suited for your cloudapplication needs and development environment. The authors who have built asuccessful, real-world application programming environment of their own take youon a journey of cloud application programming from 3GL to 4GL and back. Theydemonstrate their own invention: The anatomy of an environment that combines thebest of both worlds.

Developing and deploying applications for the cloud need not be any more difficultthan for traditional environments, especially when developers select tools whichprovide cloud-enabling functionality right out of the box.

For data-driven applications, developers usually choose between two types ofplatforms:

Fourth-generation programming languages (4GL) or

Third-generation programming languages (3GL).

Develop and deploy: Cloud-optimized 4GL applications Trademarks Copyright IBM Corporation 2011. All rights reserved. Page 1 of 22
mailto:[email protected]:[email protected]://www.ibm.com/developerworks/ibm/trademarks/http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/developerworks/ibm/trademarks/mailto:[email protected]:[email protected]


2/22

Each has its place in the technology landscape and each has enjoyed periods ofrelative popularity throughout the history of software development.

See how and why the pendulum has shifted from 3GL to 4GL and, more recently,back to 3GL. Moreover, explore the challenges and choices developers face today

with respect to developing applications for the cloud and get our own unique take onthe challenge a platform which combines the best aspects of 4GL tools and 3GLplatforms.

The pendulum swings

The 1990s saw the emergence of 4GL tools (such as FoxPro, Delphi, Progress,Oracle Forms, Informix 4GL) which gained tremendous popularity because theygreatly reduced the overall complexity of application development and maintenancewhile increasing developer productivity.

4GL tools typically automate the foundation layers common to most applications,such as data access, data binding, the assembly of native GUI components, etc.Relieved of these concerns, developers are free to focus on the user experience andspecific business logic, resulting in a faster development cycle and leaner, simplercode base. A bonus is that this also requires a smaller, less specialized team tomaintain it, making it a clear win over 3GL platforms.

However, toward the end of the 1990s, 4GLs began to show their limitations. Amidthe rise of the Internet, there was a paradigm shift which marked the departure of"fat clients," client-side processing, and native windowing interfaces in favor ofserver-side computing and a general decoupling of business logic from thepresentation layer.

Interestingly, none of the classic 4GLs presented an answer to the new paradigm ofInternet-based computing, so many developers turned once again to 3GL platforms,primarily Java and C#, to meet a growing demand for web applications.

Today, developers are faced with many new challenges as new technologies havefacilitated another paradigm shift the compelling demand for software as a service(SaaS) and cloud-based applications. A modern SaaS application requiresweb-based delivery that is secure, elastic, and fault-tolerant, combined with therobust user experience of a native application. Meeting this demand requires a new

bag of tricks. A short list includes:

Full Ajax support for interactivity

Cross-browser support

Security

developerWorks ibm.com/developerWorks

http://www.ibm.com/developerworks/ibm/trademarks/http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/developerworks/ibm/trademarks/


3/22

Multi-tenancy

Clustering and load-balancing

Automated deployment

Production life cycle (versioning)

Strong Linux support

Given these added requirements, developers face tough choices and the argumentof 3GL vs. 4GL takes on new dimensions. So let's take a closer look at each choice.

The 3GL approach to the cloud

More on 3GLThe second generation of programming languages brought logicalstructure to software; the third-generation programming language(3eGL or high-level language) refined that by making the languagesmore programmer-friendly. This included such features as improvedsupport for aggregate data types and expressing concepts in a waythat focused on the programmer and not the machine (likeeliminating the need to state the length of multi-character stringliterals in Fortran). In a 3GL, the computer handles a lot of thenon-essential details for the programmer. Most 3GLs supportstructured programming

Fortran, ALGOL, and COBOL are early (1950s) examples of 3GLs;today, the popular 3GLs are C, C++, C#, Java, Delphi, and Python.

The basic problem of 3GLs is one of productivity and maintenance. In 3GLenvironments, developers are responsible for the building and maintenance of thefoundation layers of an application. While this approach provides the granularity todeal with web-based environments, developers pay a price in lost productivity andincreased complexity.

The productivity problem is greatly compounded when building for the cloud. Theadded requirements translate into additional foundation layers to build and maintain.The code base can become so large that the majority of it deals only with theplumbing and very little deals with actual application-specific functionality.

Consider just some of the aspects of a cloud-based application from back to front:

Developers must write code to implement the data access layer, includingoptimizing SQL queries, caching results to optimize performance, withoutcompromising an application's footprint.

They must implement the presentation layer. For browser-based systems

ibm.com/developerWorks developerWorks



4/22

this involves generating markup, CSS, and client-side JavaScript.

Additionally, developers must build and maintain the Ajax layer as well,binding browser DOM events to client-side scripts which invokeserver-side business logic, all of which must be tested and debugged forevery build iteration, browser, and mobile device.

Developers must also seriously consider cloud topics such as elasticity,adding/removing capacity, clustering technologies, load-balancing, etc.

And so far we haven't even mentioned the real task at hand developingapplication-specific functionality and articulating effective user experiences.

The reality is that 3GL teams must be so specialized and focused on thesefoundation layers of the application that their ability to deliver core functionality canbe compromised.

A common solution to this problem is the use of third-party frameworks essentially

reusable code and classes which provide higher-level abstractions of specificfunctionalities. While this approach reduces the burden of development, it is notwithout its own drawbacks.

Software teams must evaluate, integrate, maintain compatible versions, train, etc.For example, to cloud-enable a modern ERP application would require some 10-30frameworks to address the foundation layers.

So given the increased burden of development and maintenance, it could bebeneficial to consider 4GLs again. Let's take a closer look at the reasons why classic4GL tools have not been well suited for cloud-based applications and what can be

done about it.

The classic 4GL approach to the cloud

More on 4GLA fourth-generation programming language (4GL) is onedesigned with a specific purpose in mind, like development ofcompute-intensive scientific or commercial business software.4GLs, roughly introduced in the 1970s, attempted to refine 3GL byoffering higher abstractions and statement power. In an attempt toeliminate some of the more error-prone, slower 3GL development

methods and provide more rapid software development, 4GLsadded higher-level methodology that could generate the equivalentof extremely complicated 3GL instructions with fewer errors. Onecomplaint of 4GLs is that they can often generate code that isinelegant in its structure and not easy to maintain.

From an architectural point of view, a 4GL is a set of pre-selected, well-orchestratedframeworks that address the foundation layers of an application. The 4GL vendor




5/22

assumes the burden of maintenance for these frameworks and the developer is freeagain to focus on the user interface and core business logic. To facilitate this, 4GLstypically provide graphical editors to visually design the GUI and proprietary scriptinglanguages and APIs to tie user-driven events to specific business logic.

The upside is simple increased productivity and reduced complexity. The pricepaid for this is flexibility. Unless 4GL vendors provide extensibility options and evensource code, developers must operate within the limits of the tool. This can befrustrating because classic 4GLs often use proprietary languages, protocols, andeven databases, making integration and extension even more difficult. However, inthe context of cloud applications, the biggest limitation is scalability.

The biggest limitation: Does it scale?

The limited scalability in classic 4GL tools is rooted in their underlying architecture.Traditional 4GLs use a two-tier design. This essentially means that native clientsconnect directly to a database. This setup is optimized for a smaller install basewhich runs on a local area network (LAN). 4GL tools cannot support a largerconcurrency because each additional client requires its own database connection;therefore, system-wide performance will degrade as more users access anapplication and burden the database with too many connections.

4GL tools cannot be run over a wide area network (WAN) for reasons of security andperformance:

Organizations cannot expose a database through a corporate firewall.

And two-tier systems perform poorly when a fat client must connect to a

database over the WAN.

The fake cloud approach

A common way of overcoming this WAN-incompatibility involves a "fake cloud"approach. This typically involves video streaming technologies, such as TerminalServices, Citrix, or VDI. A native client is run inside the LAN and its video image isprojected over the WAN to a remote client.

This approach overcomes the security problems of deploying two-tier systems overthe WAN by replicating a native client to a remote user. Moreover it is a simple

solution because there is no need to modify the existing application.

Still, the fake cloud approach does not address the scalability issues inherent in atwo-tier system. It doesn't reduce the burden of database concurrency and therequired technologies are often cost prohibitive. In short, it is a quick-and-dirtyapproach.

At the end of the day, two-tier systems cannot accommodate the requirements of




6/22

cloud applications.

This is not the triumph of browser over native, though

This is not to say that native clients are a thing of the past and that all newapplications must be browser-based. While most developers consider "cloud" toautomatically imply browser-based applications, native clients can still be deployedover the WAN using n-tier technology.

In fact, native clients are required by certain tasks for which browsers simply don'thave access, such as interacting with client-side file systems, hardware, andsoftware. But classic 4GLs do not have the proper architecture to deliver this "smartclient" technology.

So is there the possibility of having, in a single platform, both the productivity andsimplicity of a classic 4GL and the flexibility and scalability of a cloud-optimized setof 3GL frameworks?

The modern 4GL approach to the cloud

Developers have a lot to consider when selecting a new platform; let's run throughsome requirements that a modern, cloud-optimized 4GL should meet.

A next-generation 4GL platform should address the demand forserver-side computing by providing n-tier architecture. This designpattern introduces an application server in the middle tier which brokers

connections between clients and the data tier. This approach dramaticallyincreases the capacity for high concurrency because databaseconnections are pooled and shared amongst clients. Moreover, n-tierarchitecture allows for applications to be securely deployed over the WANwhile the database can remain securely behind the corporate firewall. Theapplication server layer should also be optimized for cloud deployments toinclude out-of-the-box support for security, multi-tenancy, clustering andload-balancing, automated deployment, production life cycle (versioning).

A modern 4GL platform should also provide robust options for bothnative client and browser-based deployments. If the platform canprovide these options from a single code base without the need to rewrite

anything, then development time and maintenance are again greatlyreduced.A true smart client runs over the Internet using standard protocols HTTP and SSL to avoid proxy and firewall issues. It is as responsive as alocally run application or a browser-based application. It deploys withoutinstallation to any operating system and automatically updates itself andprovides integration with local file systems, hardware, and software.




7/22

For robust browser-based deployments, a 4GL should support allmodern browsers without plug-ins or proprietary technologies:

The platform should dynamically generate the markup, CSS, andclient-side JavaScript.

The Ajax layer should be fully automated in a way that developerscan easily capture GUI events and bind them to business logic whichis executed without refreshing the page.

There should be a clean separation of business logic andpresentation. Application-specific code should not be exposed in thebrowser, thus improving security and performance and perhaps mostimportantly, providing the ability to debug a browser-based applicationas easily as a native application.

Cloud-optimized platforms should support industry standards and

remain agnostic in terms of the database vendor and operatingsystem. For example, applications may be developed and tested onWindows machines using a MSSQL database while running inproduction in the cloud on a Linux instance with a Postgresql database.Therefore, a modern 4GL platform should support any relational databaseand operating system.

The next-generation 4GL platform should provide a robust,extensible integrated development environment (IDE). Contrary toclassic 4GLs, new platforms should not introduce any proprietarylanguages or protocols. They should provide support for standard versioncontrol systems such as Subversion (SVN) and the ability to

auto-complete, document, debug, refactor, profile, and unit test all code.

We've covered a number of requirements and it has probably become clear that amodern, cloud-optimized 4GL looks quite a bit different from the classic setup. Butthe idea is the same: Provide tools to greatly enhance developer productivity whilereducing the complexity of deployment and maintenance.

Now let's take a look at a real-world platform which has reinvented 4GL to addressthese requirements.

A novel combination approach to the cloudThe approach we use that mixes 3GL and 4GL features addresses some of thelimitations of classic 4GLs, allowing you to:

Develop complex business applications in less time.




8/22

Deploy both locally and over the Internet.

Provide scalable smart client technology.

Provide a platform which is based on standards.

The platform we've developed, a development, deployment, and integration suite,offers developers a single code base from which to rapidly build and deploy fornative client and browser applications, both for the public and on-premise cloud andinternal systems (Figure 1).

Figure 1. The architecture

The remainder of this article describes this architecture and provides a simpleexample of a development environment that uses features of both 3- and 4GLs fordeploying applications into the cloud.

The n-tier deployment architecture

More on n-tier architectures

N-tier architectures(also known as multi-tier architectures) areclient-server architectures in which the presentation, the applicationprocessing, and the data management are logically separateprocesses. For example, an application that uses middleware toservice data requests between a user and a database employsmulti-tier architecture. N-tier application architecture delivers amodel for developers to use to create flexible, reusable applications;by breaking applications into tiers, developers only have to modifyor add a specific layer rather than rewrite the entire application.




9/22

The most used n-tier architecture structure is the three-tier one.

The Servoy environment employs an n-tier architecture which includescross-database support, and advanced application server, and a variety ofdeployment options in the presentation layer. Let's look at these layers in greaterdetail.

Data access layerWe provide a data access layer (bottom of Figure1) which is database agnostic. Ituses a combination of JDBC, Hibernate, and Servoy extensions to make thisdatabase independent and as such, it will run on IBM DB2, Microsoft SQLServer, Oracle, Sybase, MySQL, Postgresql, and others. Developers don't need towrite specific code in order to do this.

Application server layerThe Servoy Application Server (second layer from bottom) is an advanced

application container which manages data transactions on behalf of connectedclients. Some of its many duties include:

Deployment and life cycle management

Enforcing security

Generating HTML, CSS and client-side JavaScript

Two-way communication with the connected clients

State management

Clustering

Load balancing

Database connection pooling

Data broadcasting

Business rules layerThis layer (third from bottom) is responsible for executing all logic. This can be bothclient- or server-side.

With the web client it is always server-side: Deploying business rules to a browserexposes them to the end user, there is less control over the execution andperformance, and debugging is very complex ... this is all avoided by keeping themon the server side.

The smart client can run code both locally and server-side. By running code locallythe server is offloaded and often interactivity is increased. Expensive operations or




10/22

data-intensive operations can still be run server-side using the headless client. Abatch processor is available to schedule tasks to run server-side either on anongoing basis, a scheduled time interval, or at a certain time.

Presentation layer

This layer (shown on top) is used to visualize applications to end users. For nativeclients, they will render in the look and feel of the native operating system. Forbrowser applications, our platform generates the markup, CSS, and JavaScript, aswell as Ajax, enabling the user interfaces for a dynamic experience. The ApacheWicket framework is used for this and we've contributed heavily to this open sourceproject.

Our platform also has the capability to publish web services acting as a middlewareserver for HTTP, SOAP and REST connections.

The development environment

Servoy: Rapid deployment with a single codebaseThe Servoy platform consists of:

Servoy Developer, a powerful IDE used to design,develop, test, and debug applications.

The Servoy Application Server lets you deploy apps as azero-deployment, native smart client, or a browser-basedweb client.

The Servoy Smart Client is a small 2MB Java applicationthat uses Java WebStart technology for a

zero-deployment model.

The Servoy Web Client is a secure, scalable, pureHTML/CSS/JavaScript client that requires no plug-ins torun and supports Ajax.

The Servoy Headless Client allows you to execute yourapp's data and business logic via JSP pages, Servletsand Java applications.

All work in the Servoy platform can be done from a single codebase. This video will let you understand Servoy in less than aminute.

Our development environment includes a what-you-see-is-what-you-get (WYSIWYG) graphical form builder. This is typical of most 4GL platforms and offers a productiveedge over 3GL environments which require a lot of code to generate GUIcomponents.

The environment also provides sophisticated data modeling tools, ascripting/debugging engine, and robust APIs which like classic 4GLs are simple in


http://www.servoy.com/http://www.servoy.com/content.jsp?t=427http://www.servoy.com/content.jsp?t=429http://www.servoy.com/content.jsp?t=428http://www.servoy.com/content.jsp?t=433http://www.servoy.com/content.jsp?t=432http://www.servoy.com/content.jsp?mt=393&taxonomy_id=393http://www.ibm.com/developerworks/ibm/trademarks/http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/developerworks/ibm/trademarks/http://www.servoy.com/content.jsp?mt=393&taxonomy_id=393http://www.servoy.com/content.jsp?t=432http://www.servoy.com/content.jsp?t=433http://www.servoy.com/content.jsp?t=428http://www.servoy.com/content.jsp?t=429http://www.servoy.com/content.jsp?t=427http://www.servoy.com/


11/22

nature, but provide the sophistication needed to build modern applications. An entireapplication is stored as many simple metadata text files which are easilysynchronized with a developer's preferred version control system.

The development tool ships as a plug-in for the open-source, industry standard

Eclipse integrated IDE.

The basic unit of development in our platform is called a Solution. Solutionsencompass all forms, scripts, and data-modeling elements for a single application.However Solutions can contain other Solutions as Modules. By using a modularapproach, developers can reuse components and code across multiple applications.

Connecting to dataOur platform connects to any relational database using Java Database Connectivity(JDBC) technology. To establish a connection, one needs only the JDBC driver andthe connection parameters.

Developers can design their database from within our platform's IDE or through theDB admin tool of their choice. At runtime, the platform will manage all databasetransactions, issuing SQL queries, caching and binding results to forms and APIobjects. No prior experience with SQL is required.

Figure 2. Database connections are visually configured in a designer




12/22

Figure 3. Once a data connection is configured, the platform introspects thetable structure

Building formsDevelopers also don't need to write any code to generate GUI elements; the platformprovides a comprehensive palette of components which can be placed on a form.




13/22

This includes all standard controls (buttons, text-fields, combo boxes, radios) andspecial controls (type-ahead fields, tree-view controls, contextual pop-up menus).

Developers are also free to use image media and icons in their solutions. Allcomponents can be styled using CSS, making it easy to re-skin an entire application

by making adjustments to the style sheet. The platform also supports object-orienteddesign through form inheritance, allowing components and form-level code to beinherited and overridden.

A form is bound to a specified database table and all data controls within can beused to display and edit the table's columns without writing code or SQL. But ourform is not limited to working within a single table; a single form can display and editdata for many tables through relation objects.

Figure 4. User can specify data source, CSS, etc., in the forms wizard




14/22

Figure 5. Forms are modified through the form editor




15/22

Modeling data relationsA relation is defined between two tables by specifying key columns that link thetables, most commonly regular relations such as customer-to-orders. However, ourplatform is designed to support relations which use many keys and many operators(other than =). Relations can also use scripting variables as part of their keydefinitions, thus making a relation dynamic, such as customers-to-orders thatoccurred within seven days of a specified date.

Figure 6. Relations are configured in the Relation Designer




16/22

A relation is defined graphically without writing code and it can serve many purposesin an application:

First of all, it can be used to display/edit data on a form.

Additionally, entire forms can be shown within other forms through arelation.

In this case, the record set of the contained form will be constrained by the relation.So following our example, you can show a list of customer's recent orders within thecustomer form by adding a second, orders, form through a relation. By continuingthis process, you can build a sophisticated, fully data-driven user interface withoutwriting any code or SQL.

Figure 7. You can place an entire form within a form using a relation

Figure 8. Customer orders displayed at runtime on a browser form




17/22

Finding and filtering dataIt is possible to perform sophisticated data searches without writing SQL. Toaccomplish this, our platform provides a feature called find mode. When in find

mode, all of a form's data-bound fields can be used as search criteria. When thesearch is run, then it will generate the SQL needed to return the records. The criteriamay be entered manually by the user or programmatically. Find mode on ourplatform can accommodate logical a wide array of operators, logical operators,wildcard string searches, etc.

Figure 9. Three lines of code and no SQL for sophisticated data search




18/22

Implementing business logicOur environment uses JavaScript as its primary programming language; it exposes arobust, self-documented JavaScript API with which to accomplish most programming

tasks.

Traditionally scripting languages have always provided a great amount of flexibilityand productivity over their compiled counterparts, but due to their interpreted nature,they also have had some downsides:

difficult to debug

performance issues

weak and strong typing

code refactoring

We've addressed these issues by implementing and extending Mozilla's Rhinoproject. Rhino is a Java-based JavaScript engine. Under the hood, every JavaScriptfunction in our platform maps to an underlying Java class. This approach providesthe performance of pure Java code and the productivity and reduced complexity ofJavaScript. Moreover, developers are free to code in Java if they are comfortablewith it. This is typically useful when integrating with a third-party Java library.

One of the bigger issues encountered was debugging. To solve this, we co-foundedan Eclipse project named DLTK (dynamic language toolkit) which provides tools forthe debugging of dynamic languages. Recently this has been extended to alsosupport strong typing which with some other extensions allows for advanced coderefactoring. More information can be found in Resources.

Figure 10. This JavaSCript method is bound to the selected text field'sdesign-time, on-data-change event




19/22


20/22

The deployment environment

Once developed, an application can be easily deployed to the application server weuse. The process takes only a few seconds. A project can be exported from the

development environment and imported into the application server in a few clicks.

When the import is complete, the application is available to the world as across-platform, self-installing native client and as a cross-browser web application.Subsequent build iterations follow the same steps and the application server willmanage numerous production versions of the same application with the ability to rollback and roll forward with a single click.

Moreover, the import process will also optionally update the data model, so thatschema changes made against a development database will be pushed intoproduction automatically.

With application life cycle management greatly simplified, developers are free topursue a more aggressive build schedule and keep their users happy.

In conclusion




21/22

Developing applications for the cloud shouldn't be too different or more difficult thanwhen you develop them for a more traditional environment.

In this article, we've provided you with a glimpse at how cloud applicationdevelopment can work on a 3GL platform, on the classic and modern versions of a

4GL platform, and then we've detailed the inner workings of our own platform, onedesigned to leverage the cloud-oriented best practices of both 3- and 4GL.




22/22

Resources

Learn

Learn more about the Servoy development environment and application server.

Servoy is a co-founder of the DLTK (dynamic language toolkit) project atEclipse, tools for the debugging of dynamic languages.

In the developerWorks cloud developer resources, discover and shareknowledge and experience of application and services developers building theirprojects for cloud deployment.

The next steps: Find out how to access IBM Smart Business Development andTest on the IBM Cloud.

Get products and technologies

See the product images available on the IBM Smart Business Development andTest on the IBM Cloud.

Discuss

Join a cloud computing group on developerWorks.

Read all the great cloud blogs on developerWorks.

Join the developerWorks community, a professional network and unified set ofcommunity tools for connecting, sharing, and collaborating.

About the authors

Sean Devlin

Sean manages Cloud Services for Servoy and is a frequent speaker attechnology conferences in the United States.

Jan Aleman

Jan is a frequent speaker at SaaS and cloud computing conferencesinternationally. He is secretary of Eurocloud, a European cloudconsortium, and member of the SaaS~Cloud steering committee for theICT~Office, a trade association of IT, telecom, and Internet companiesin the Netherlands.


http://www.servoy.com/http://www.eclipse.org/dltkhttps://www.ibm.com/developerworks/cloud/index.htmlhttp://www-935.ibm.com/services/us/igs/cloud-development/technical.htmlhttp://www-935.ibm.com/services/us/igs/cloud-development/technical.htmlhttp://www.ibm.com/developerworks/cloud/devtest.htmlhttps://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?tag=cloud&page=1https://www.ibm.com/developerworks/mydeveloperworks/blogs/home/tags/cloud?lang=enhttps://www.ibm.com/developerworks/mydeveloperworks/http://www.ibm.com/developerworks/ibm/trademarks/http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/developerworks/ibm/trademarks/https://www.ibm.com/developerworks/mydeveloperworks/https://www.ibm.com/developerworks/mydeveloperworks/blogs/home/tags/cloud?lang=enhttps://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?tag=cloud&page=1http://www.ibm.com/developerworks/cloud/devtest.htmlhttp://www-935.ibm.com/services/us/igs/cloud-development/technical.htmlhttp://www-935.ibm.com/services/us/igs/cloud-development/technical.htmlhttps://www.ibm.com/developerworks/cloud/index.htmlhttp://www.eclipse.org/dltkhttp://www.servoy.com/

Documents

Cloud-Optimized 4GL Applications