The Vision for the Formspider Framework

Defining the Problem

With the demise of Oracle Forms as a credible development environment, PL/SQL developers are deprived of their ability to build modern applications that meet the current needs of their organizations. Unfortunately, the available alternatives are hard to learn, less productive, less capable, and require far more hardware than Oracle Forms. None of them empower PL/SQL developers the way Oracle Forms did. All of the available solutions presented as alternatives to Oracle Forms suffered from one or more of the following shortcomings:

  1. Different programming languages for different layers of development
  2. Different notations for user interface design for different platforms
  3. No true cross-browser compatibility
  4. Platform-dependent applications
  5. Unproductive, low quality, development environment
  6. Poor user experience
  7. Huge effort/cost to achieve acceptable performance
  8. Difficult to make applications secure

Building world class applications to meet the current needs of businesses requires a flexible and robust framework that makes the technology transparent to developers. The framework should largely get out of the developer’s way and make it a straightforward exercise to implement business requirements. In order to achieve this goal, an application development framework should do the following:

  • Utilize a single programming language across all development areas
  • Use a single notation for user interface (UI) design across platforms
  • Provide true cross-browser compatibility
  • Enable building platform-independent applications
  • Improve productivity with a high quality IDE
  • Support applications that provide an excellent user experience
  • Support developers in producing scalable applications with good performance
  • Support developers in building secure applications

Formspider includes all of these features, thus enabling PL/SQL developers to build world-class applications now and in the future.

Architecture of a Formspider Application

The Formspider runtime engine enables PL/SQL developers to build applications around the simple Event-Condition-Action (ECA) Architecture.

Wikipedia explains ECA architecture as follows:

“Event Condition Action (ECA) is a shortcut for referring to the structure of active rules in event driven architecture and active database systems.
Such a rule traditionally consisted of three parts:

  • The event part specifies the signal that triggers the invocation of the rule
  • The condition part is a logical test that, if satisfied or evaluates to true, causes the action to be carried out
  • The action part consists of updates or invocations on the local data”

In Formspider, the event corresponds to the interaction of a user with the application.

The action is the PL/SQL code that modifies the data and the user interface based on the input received from the user.

The condition is any conditional logic that the developer places in the action.

To achieve this, the Formspider engine is split into two parts:

  1. Server-side engine: The server-side engine receives notification of user activity, determines how the screen should be changed on the user machine, and transmits that information to the user’s device. The engine handles everything except updating the user’s screen. The server-side includes the core framework code, sessions, application data, transactions management, capabilities, etc. This is also the place where the custom code written by the PL/SQL developer resides.
  2. Client-side renderer: The client-side renderer transmits user activity to the engine and responds to engine requests to update the screen. The renderer is composed of a code library used to draw the screens, apply the UI changes received from the server, and listen to the user interaction with the application UI which it then transmits to the engine. The client-side renderer changes depending upon the client platform on which the application needs to be executed. For web applications, the renderer could be a JavaScript library. A custom Java library would be used if the choice were to run on a PC without a browser. To run on a tablet or smart phone, the renderer would have to be written in a language supported by the device.

The ECA framework completely isolates the developer from the deployment platform. As long as renderers exist for the different platforms, a developer can code in Formspider and deploy to any supported platform with absolutely no changes needed to the code.

Figure 1 shows how this architecture works in a standard web environment.

Figure 1: Formspider ECA implementation

  • The process starts with a user request (1), which includes any changed data since the last request plus a notification of what event took place that triggered the request.
  • The application server simply passes the request to the engine that resides in the database (2).
  • The engine in the database processes the request and determines what UI changes need to be made to the user’s screen (3).
  • The engine passes that request as an XML file to the application server (4) which then passes it to the client (5)
  • The client renderer processes the XML and makes the appropriate changes to the UI (6).

This communication model provides a simple and intuitive Event Condition Action (ECA) architecture with which PL/SQL developers can build applications. The web complexities are hidden behind the communication model and handled by the framework.

Note the following advantages:

  1. There is never more than a single round trip from the client to the application server or from the application server to the database. The communication between any of the two layers is optimized by the design.
  2. All interaction between the code and the data occurs in the database, making it very fast.
  3. The application server is doing very little work, and thus has a very small load.
  4. Only the changes to the screen since the last user request are transmitted from the client and only the changes to the screen are transmitted back, so the amount of network traffic between the client and the application server is very small.

The ECA architecture enables PL/SQL developers to develop applications for any platform including iPhones, iPads, laptops, or desktop computers.

Benefits of the Formspider Framework

The Formspider framework provides a number of important advantages.

1. Simple Development Environment

Creating an application should not be any more complex or expensive than it used to be using client-server technology.

With a simple development environment, developers can focus on solving business rather than technical problems.

The world used to be a simpler place. In Oracle Forms, one developer with knowledge of PL/SQL and Forms could build a working application. Now systems require teams of developers using many products that all have to work together perfectly. “Successful” projects cost ten times what they did a decade ago.

The job of the application developer should be to define the application, and not to worry about how it is implemented. There is no reason why the experience of building an application to run on a handheld device should be vastly different from building one to run in a browser.

The Formspider ECA architecture is much easier to understand and work with than most other framework architectures such as JSF and Struts. Figure 2 shows the life cycle of a web application in the JSF framework.

Figure 2: JavaServer Faces framework web application life cycle

Figure 3 represents the flow of a Struts application.

Figure 3: Struts application process flow

Web developers can spend a significant amount of time studying the mechanisms shown in Figures 2 and 3 that drive the inner workings of those frameworks. They must keep these diagrams in mind and ensure that every line of code is written to the appropriate place in the flow. These frameworks are also designed to only generate web pages and therefore completely fail to deliver in platforms other than the browser.

Formspider has a simple flow that is much more intuitive. There is hardly anything to learn or keep in mind during development. The development experience in Formspider is very much like that of Oracle Forms.

Figure 4: Formspider application process flow

2. Single Programming Language

Formspider uses only PL/SQL as its scripting language.

As long as data is stored in the database, code written in the database will have a huge advantage over code written in the middle tier. In the Oracle environment, developers know PL/SQL. Therefore PL/SQL is the natural language of choice for application development.

One of the biggest handicaps of currently available frameworks is that they require extensive knowledge of several programming languages. For most JavaEE frameworks, a developer needs in-depth knowledge of Java, JavaScript and a variety of component technologies. With so much to learn, it is understandable that most Java developers resist becoming skilled database developers as well.

Becoming an expert in a single programming language takes years. Asking enterprise application developers to become experts in two or more languages is counterproductive. An enterprise application developer must understand business rules and implement them in code. A programming language is the means by which this task is accomplished. Once a developer is expert at expressing the business rules in one programming language, learning any additional languages is time consuming and may not ultimately help them become better developers. If you ask an experienced PL/SQL developer to program in Java (or the other way around), they will struggle with the nuances of the new language for years. The result of this struggle is sub-par performance, bugs, and low-quality applications.

The PL/SQL scripting used in Formspider will look familiar to Oracle Forms developers. The ability to manipulate components is similar to what Forms developers have been using for years. Because the scripting is in PL/SQL and stored in the database, developers can use any PL/SQL editor to write programs.

The following code shows the script used to create a login screen button like that shown in Figure 5 work:

Figure 5: Sample login screen

procedure doLogin is
v_loginResult_tx varchar2(10);
begin
--- this is the call to the developer’s login package
v_loginResult_tx:=myapplication.doLogin(
--- this retrieves the value from the “User name”
api_component.getvaluetx('loginPanel.user'),
--- this retrieves the value from the “Password”
api_component.getvaluetx('loginPanel.password')
);
if v_loginResult_tx=’OK’ then
api_dialog.setvisible('loginWindow','N'); -- this hides the window
else
--login failed. warn user.
end if;
end;

The actual procedure would be more complex but this example shows how application behavior can be coded. It is as simple and intuitive as in Oracle Forms.

3. Single Development Environment for all Platforms

Excluding accommodations for differing capabilities, defining the application should not be dependent upon the deployment platform.

The technology to develop the same UI changes from platform to platform. Web, mobile and desktop technologies vastly differ in the way in which they define user interfaces. If a screen is developed in Java Swing, there is no way to render the same screen in a browser. It would be easier to rewrite the screen as a JSF, JSP, or ASP page. This is extremely unproductive because when a new platform emerges for deploying applications (such as mobile native applications), the UI development experience in the old tech stack is useless. Developers must go back to square one.

With Formspider, developers can learn it once, and develop screens for any platform. Each platform may have its own special components, constraints, layouts, etc. However, the way to build the screens, create events on them, and associate programs with these events can and should be similar. A button is a button, and a button press is a button press, whether it occurs on a tablet or a PC. There is no need for multiple ways to define this element.

Virtually every existing framework locks organizations into a platform by choosing a client-side programming language: web, desktop, or mobile. Developing in one environment without needing to know its details is just as valuable as true browser compatibility because, in the end, each browser is just another platform.

Many people believed that the web eliminated the need for deploying native applications. This perception was completely overturned by the emergence of mobile operating systems. As of today, PL/SQL developers have no way of building applications for the mobile world.

Formspider provides a way to deploy native applications to platforms including mobile operating systems. The client-side library of the framework can be Java, ObjectiveC, or anything else that happens to come along. This flexibility enables organizations to deploy to different platforms using the developers’ existing PL/SQL skill set. The platform is just another target to deploy to. Each platform may have its own set of layouts or even components. For example, the constraints and requirements of a mobile application are very different from those of a web application rendered on a 27-inch monitor connected to a quad core machine with 32GB of memory. However, the notation to develop the UI and the language to script the program flow stays the same. Developers continue to be productive in an environment that is familiar to them. They can use the same APIs, IDE, debugging tools etc..

Another side effect of the current development method is that separate developers work to deliver applications to different platforms which essentially fulfill the same business needs. It becomes very difficult to synchronize these applications in behavior, look-and-feel and features made available to users. The ECA architecture makes it possible for the same PL/SQL development team to control applications running on different platforms, thus providing consistency.

4. True Cross-Browser Compatibility

With Formspider, browser compatibility is our problem, not yours.

There are many different browsers available, and each has its own way of interpreting HTML, JavaScript and CSS.

With the first line of JavaScript, HTML and CSS you write, you are in browser compatibility hell. It is absurd to expect an enterprise developer to be an expert in this field as well, in addition to having expertise in industry business rules, screen design, and multiple programming languages.

Today, browser compatibility is a task for the development teams. Most teams just give up. In environments where rigid control can be exercised, users are banned from upgrading their browsers. So much for platform independence; we end up building web applications that are browser-dependent.

Some teams seek refuge in JavaScript libraries that are compatible with the major browsers. This makes sense. The only problem is that a developer must write JavaScript to use these libraries. However, this custom JavaScript code must also be tested in every relevant brand and browser version.

Some have faint hopes that this problem will go away eventually. In reality, it only gets worse. For example, the latest version of Microsoft Internet Explorer (IE9) does not work in Windows XP and leaves millions of users behind. IE9 does not consolidate the fragmentation among IE users. Instead, it makes the fragmentation worse.

The ECA paradigm separates the client library from the server. This separation results in specialization. While enterprise developers concentrate on turning business rules into code, the framework’s JavaScript developers focus on the JavaScript library. They spend all of their time and energy on JavaScript. Their only goal is providing the best library to the enterprise developers. They know nothing of the business rules of any industry or ways of writing an efficient query. When there is a compatibility issue with a component in a browser, they fix it. When they fix it, the problem is solved for all the applications out there that use Formspider. Nobody reinvents the wheel; nobody wastes time on forums; OTN, or Stackoverflow. Nobody tries to get creative and come up with kludges. The JavaScript experts solve the problem once and for all for everybody since everyone can download the updated JavaScript library.

Since every PL/SQL developer using Formspider writes only PL/SQL and communicates with the client using the framework’s PL/SQL APIs, the framework’s JavaScript library is the only JavaScript that executes in any of the applications built with the framework. Therefore, every application benefits from any improvement in the library.

5. Productive Development Environment

It should not take any longer to build an application than it used to.

Back in the old Oracle Forms days, a developer could build a moderately complex screen in about a day. That same screen takes a week to build in a JavaEE framework and the probability of that application actually working when you get to production is much lower than the old Forms application.

The Formspider IDE was written using Formspider. The IDE was the first application developed. From the very start, we were not just the developers, but also the customers. As a result, much effort has gone into making the IDE intuitive and productive.

We built the best, the most user-friendly XML Editor for the Formspider IDE. It helps you build your screens by completing your code automatically, formatting it beautifully, and giving meaningful error messages.

Because the main layout editor is written in XML, the entire IDE only comprises about 100 screens (~20 of which you use 80% of the time). Compare that with Oracle’s Application Express (APEX) that includes over 2000 screens in the IDE.

Objects that have been logically associated (such as panels on windows) can be found as child objects in the navigation tree, so there is no need for a text search for impact analysis when you delete something.

Testing your application requires a single button press. There is no deploying or waiting for the application to compile. It runs exactly as if it were in the production environment.

Formspider includes an excellent debugger. It will even show the component you are looking at which makes finding where a change needs to happen very easy.

6. Excellent User Experience

Applications must be beautiful by design.

It is not enough anymore to build applications the way we used to in client/server days. Users want a rich UI experience with beautiful screens.

Formspider has all of the components needed to build a great looking Web 2.0 framework. Every Formspider application works as a single page web application by design, using AJAX 100% of the time to communicate with the server. Formspider applications never do full page refreshes which are reminiscent of early web days. In fact, if you open your browser full screen, it is hard to tell that you are looking at a web application.

The look-and-feel of Formspider applications is infinitely customizable with CSS. Formspider has different layout capabilities that enable you to take advantage of every pixel on the screen any way you want.

You will delight your users with the applications you can build with Formspider and turn every Java and JavaScript developer green with envy.

7. Great Performance without Great Effort

A reasonable developer should not have any trouble building an application with excellent performance.

Back in the Oracle Forms days, the only way you could make an application perform poorly was to do something that an experienced developer could easily avoid or fix when discovered, such as write a bad query. In JavaEE environments, you must be an expert in every one of the component technologies, or applications that appear to work well in development will fail in test or production.

Large enterprise applications built with Web 2.0 technologies such as AJAX and JavaScript libraries, often create too many objects in the DOM and load too much code for the browser to perform adequately. This problem is usually detected very late in the development process and may have its roots deep in the architecture, with the result that correcting the problem in time may be an impossible task.

Development teams are expected to adhere to a certain set of rules and manage the load they are putting on the browser. This is a new problem in Web 2.0 development that did not exist in the early days, when the application was divided into many pages. Users called pages from the server as needed. Even if the actual application consisted of thousands of pages, the user accessed them one at a time. With the emergence of AJAX and JavaScript libraries, an entire application can be loaded to the browser all at once. However, this doesn’t mean that it should be. The architects are faced with the problem of web pages taking too long to load. For example, an entire finance system might need to be loaded to the user’s screen even though the only operation needed was looking up an account code.

The solution to this problem is obviously to load the necessary code and screens only when they are needed. However, there is no mechanism to do this automatically. Development teams are forced to choose between two evils. They either have to manage the deployment of the code to the browser manually, or just forward the user to a new web page. The first option causes a lot of “plumbing” for the developer to manage. Naturally, this process is very error prone. The second option sacrifices the user experience. It also divides the application into arbitrary page groups. Probably, the worst effect of the second option is that it involves server-side coding which means adding another programming language and framework to the complexity of the application.

Formspider applications run in the database and load only a small (300KB) JavaScript library to the client that has been extensively tuned. Each Formspider application uses the same library. The screens of the application are loaded to the browser only when they are accessed by the user and they are cached for the duration of his session. This provides an environment that “by design” is going to run quickly end efficiently. You have to work hard to make a Formspider application perform poorly. Any performance problems can easily be discovered by an experienced PL/SQL developer.

8. Scalability

Less hardware should required than used with client-server technology.

Scalable should not mean “you can buy a bigger database or application server to improve performance”. Scalable should mean that you do not need to buy more hardware to get good performance. In the Oracle Forms days, the main resource issue was that each user had his/her own database session. Since we are building stateless applications that use session pooling, hardware requirements should have decreased. Instead, most frameworks are so inefficient in their use of resources that hardware requirements are much greater than they were in the past.

Formspider applications scale with your Oracle Database. The entire server-side code of the Formspider framework is written in PL/SQL, so it is incredibly fast. It takes advantage of the speed of the Oracle Database in managing data. If your database is fast now, your applications will become faster with Formspider.

Formspider will also reduce your hardware costs because it puts very little weight on the middle tier. This has two benefits:

  1. It requires less processing power, memory, and storage capacity in the middle tier hardware.
  2. No sophisticated application server software is needed. Formspider can run on free Apache Tomcat or any JEE compliant application server. Even if you must run licensed software in your middle tier for various other reasons, Formspider will reduce your licensing costs because it will require less processors, memory and storage.

9. Security

Formspider has significant security capability inherent in the framework.

JavaScript is not secure. Anybody can open up a JavaScript debugger like Firebug and start changing the code. They can enable/disable fields, or change the content in hidden fields. One solution is to obfuscate the JavaScript. This only makes life harder for people with bad intentions. When JavaScript executes to hide or disable a field, the server is unaware of the change unless it is notified. This notification must come from a JavaScript execution which is not secure. Hence the notification cannot be relied upon because it can be blocked by a hacker.

Existing frameworks attempt to solve this problem in the server by creating security resources, assigning them to UI objects, and then giving these resources to different users and user groups. This is all well and good. However, enterprise developers are often expected to be security experts by assigning each secure component to a security resource and worrying about security at every step. Most frameworks are unaware of what is being sent to the client. There is no notification if a button on the screen is enabled or disabled or if a certain field is hidden.

The Formspider architecture stores a logical copy of every screen for every user. Every UI modification sent from the server is also stored in the Formspider engine. Therefore, it is very easy to validate every input received from the client to see if this event is valid for this user. The server rejects the event if it is not valid in a particular context. For example, if the developer disables a field using a PL/SQL API and a hacker attempts to set its value, the server will automatically reject this input. No additional effort is required from the developer. This feature does not eliminate the need for the implementation of user privileges and security precautions, but it adds a significant layer of protection without any effort by the developer.

Conclusions

Formspider enables PL/SQL developers build modern applications for Web 2.0 and mobile devices much more easily and inexpensively with their existing skill set.

Using Formspider, one PL/SQL team can deliver applications for different platforms such as Web and mobile operating systems. This helps organizations lower their IT costs.

Yalim K. Gerger