Escolar Documentos
Profissional Documentos
Cultura Documentos
applications
Which platform - 3GL, 4GL, or both - is optimal for your
data-driven cloud apps
24 Jan 2011
Explore which programming language type, 3GL or 4GL, is best suited for your cloud
application needs and development environment. The authors — who have built a
successful, real-world application programming environment of their own — take you
on a journey of cloud application programming from 3GL to 4GL and back. They
demonstrate their own invention: The anatomy of an environment that combines the
best of both worlds.
Developing and deploying applications for the cloud need not be any more difficult
than for traditional environments, especially when developers select tools which
provide cloud-enabling functionality right out of the box.
Each has its place in the technology landscape and each has enjoyed periods of
relative 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 on
the challenge — a platform which combines the best aspects of 4GL tools and 3GL
platforms.
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 and
specific business logic, resulting in a faster development cycle and leaner, simpler
code base. A bonus is that this also requires a smaller, less specialized team to
maintain it, making it a clear win over 3GL platforms.
However, toward the end of the 1990s, 4GLs began to show their limitations. Amid
the 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 of
server-side computing and a general decoupling of business logic from the
presentation layer.
Interestingly, none of the classic 4GLs presented an answer to the new paradigm of
Internet-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 have
facilitated another paradigm shift — the compelling demand for software as a service
(SaaS) and cloud-based applications. A modern SaaS application requires
web-based delivery that is secure, elastic, and fault-tolerant, combined with the
robust user experience of a native application. Meeting this demand requires a new
bag of tricks. A short list includes:
• 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 argument
of 3GL vs. 4GL takes on new dimensions. So let's take a closer look at each choice.
The productivity problem is greatly compounded when building for the cloud. The
added 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 the
plumbing 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, including
optimizing SQL queries, caching results to optimize performance, without
compromising an application's footprint.
• They must implement the presentation layer. For browser-based systems
The reality is that 3GL teams must be so specialized and focused on these
foundation layers of the application that their ability to deliver core functionality can
be compromised.
Software teams must evaluate, integrate, maintain compatible versions, train, etc.
For example, to cloud-enable a modern ERP application would require some 10-30
frameworks to address the foundation layers.
assumes the burden of maintenance for these frameworks and the developer is free
again to focus on the user interface and core business logic. To facilitate this, 4GLs
typically provide graphical editors to visually design the GUI and proprietary scripting
languages and APIs to tie user-driven events to specific business logic.
The upside is simple — increased productivity and reduced complexity. The price
paid for this is flexibility. Unless 4GL vendors provide extensibility options and even
source code, developers must operate within the limits of the tool. This can be
frustrating because classic 4GLs often use proprietary languages, protocols, and
even databases, making integration and extension even more difficult. However, in
the context of cloud applications, the biggest limitation is scalability.
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 clients
connect directly to a database. This setup is optimized for a smaller install base
which runs on a local area network (LAN). 4GL tools cannot support a larger
concurrency because each additional client requires its own database connection;
therefore, system-wide performance will degrade as more users access an
application and burden the database with too many connections.
4GL tools cannot be run over a wide area network (WAN) for reasons of security and
performance:
This approach overcomes the security problems of deploying two-tier systems over
the 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 a
two-tier system. It doesn't reduce the burden of database concurrency and the
required technologies are often cost prohibitive. In short, it is a quick-and-dirty
approach.
At the end of the day, two-tier systems cannot accommodate the requirements of
cloud applications.
This is not to say that native clients are a thing of the past and that all new
applications must be browser-based. While most developers consider "cloud" to
automatically imply browser-based applications, native clients can still be deployed
over the WAN using n-tier technology.
In fact, native clients are required by certain tasks for which browsers simply don't
have access, such as interacting with client-side file systems, hardware, and
software. But classic 4GLs do not have the proper architecture to deliver this "smart
client" technology.
So is there the possibility of having, in a single platform, both the productivity and
simplicity of a classic 4GL and the flexibility and scalability of a cloud-optimized set
of 3GL frameworks?
Now let's take a look at a real-world platform which has reinvented 4GL to address
these requirements.
The remainder of this article describes this architecture and provides a simple
example of a development environment that uses features of both 3- and 4GLs for
deploying applications into the cloud.
With the web client it is always server-side: Deploying business rules to a browser
exposes them to the end user, there is less control over the execution and
performance, and debugging is very complex ... this is all avoided by keeping them
on the server side.
The smart client can run code both locally and server-side. By running code locally
the server is offloaded and often interactivity is increased. Expensive operations or
data-intensive operations can still be run server-side using the headless client. A
batch processor is available to schedule tasks to run server-side either on an
ongoing 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 native
clients, they will render in the look and feel of the native operating system. For
browser applications, our platform generates the markup, CSS, and JavaScript, as
well as Ajax, enabling the user interfaces for a dynamic experience. The Apache
Wicket framework is used for this and we've contributed heavily to this open source
project.
Our platform also has the capability to publish web services acting as a middleware
server for HTTP, SOAP and REST connections.
All work in the Servoy platform can be done from a single code
base. This video will let you understand Servoy in less than a
minute.
nature, but provide the sophistication needed to build modern applications. An entire
application is stored as many simple metadata text files which are easily
synchronized 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.
Connecting to data
Our platform connects to any relational database using Java Database Connectivity
(JDBC) technology. To establish a connection, one needs only the JDBC driver and
the connection parameters.
Developers can design their database from within our platform's IDE or through the
DB admin tool of their choice. At runtime, the platform will manage all database
transactions, issuing SQL queries, caching and binding results to forms and API
objects. No prior experience with SQL is required.
Building forms
Developers also don't need to write any code to generate GUI elements; the platform
provides a comprehensive palette of components which can be placed on a form.
This includes all standard controls (buttons, text-fields, combo boxes, radios) and
special controls (type-ahead fields, tree-view controls, contextual pop-up menus).
Developers are also free to use image media and icons in their solutions. All
components 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-oriented
design through form inheritance, allowing components and form-level code to be
inherited and overridden.
A form is bound to a specified database table and all data controls within can be
used to display and edit the table's columns without writing code or SQL. But our
form is not limited to working within a single table; a single form can display and edit
data for many tables through relation objects.
Figure 4. User can specify data source, CSS, etc., in the forms wizard
A relation is defined graphically without writing code and it can serve many purposes
in an application:
Figure 7. You can place an entire form within a form using a relation
Figure 9. Three lines of code and no SQL for sophisticated data search
• difficult to debug
• performance issues
• weak and strong typing
• code refactoring
We've addressed these issues by implementing and extending Mozilla's Rhino
project. Rhino is a Java-based JavaScript engine. Under the hood, every JavaScript
function in our platform maps to an underlying Java class. This approach provides
the performance of pure Java code and the productivity and reduced complexity of
JavaScript. Moreover, developers are free to code in Java if they are comfortable
with 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-founded
an Eclipse project named DLTK (dynamic language toolkit) which provides tools for
the debugging of dynamic languages. Recently this has been extended to also
support strong typing which with some other extensions allows for advanced code
refactoring. More information can be found in Resources.
Figure 10. This JavaSCript method is bound to the selected text field's
design-time, on-data-change event
Figure 11. The JavaScript code that handles the on-data-change event
Figure 12. At runtime, the JavaScript method is executed when the field's data
changes
Moreover, the import process will also optionally update the data model, so that
schema changes made against a development database will be pushed into
production automatically.
With application life cycle management greatly simplified, developers are free to
pursue a more aggressive build schedule and keep their users happy.
In conclusion
Developing applications for the cloud shouldn't be too different or more difficult than
when you develop them for a more traditional environment.
In this article, we've provided you with a glimpse at how cloud application
development 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, one
designed to leverage the cloud-oriented best practices of both 3- and 4GL.
Resources
Learn
• Learn more about the Servoy development environment and application server.
• Servoy is a co-founder of the DLTK (dynamic language toolkit) project at
Eclipse, tools for the debugging of dynamic languages.
• In the developerWorks cloud developer resources, discover and share
knowledge and experience of application and services developers building their
projects for cloud deployment.
• The next steps: Find out how to access IBM Smart Business Development and
Test on the IBM Cloud.
Get products and technologies
• See the product images available on the IBM Smart Business Development and
Test 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 of
community tools for connecting, sharing, and collaborating.
Jan Aleman
Jan is a frequent speaker at SaaS and cloud computing conferences
internationally. He is secretary of Eurocloud, a European cloud
consortium, and member of the SaaS~Cloud steering committee for the
ICT~Office, a trade association of IT, telecom, and Internet companies
in the Netherlands.