Choosing the Architecture for A Rich Client Application – The InPowerSoft Story

Written by Don Young, Inpowersoft November, 2005

Introduction

InPowerSoft Corporation is in the business of creating Utility Billing Systems for large utility companies. Our first generation billing system was created under Oracle Forms 6i and later migrated to Forms 10g. About two years ago, our customers started to inquire about our technology platforms and especially the use of modern development platforms such as Java and .NET. Prospective customers who needed a multi-million dollar billing solution wanted a technology foundation that could last for another decade.

We realized that we would need to develop a new version of our product using a new technology stack. Our choices were limited but clear: build a web application like the majority of development has been done for the past 5+ years, or look for a rich-client platform that can provide the level of end-user productivity of Oracle Forms.

Today's rich-client platform has incorporated many features that originally fueled the move towards web-based development. Features such as on-demand application installation (via Webstart or similar technologies) and multi-tier deployments became part of the rich-client platform's native capabilities. These factors combined with the type of user-interface interactivity we were looking for drove us to choose to go in the rich-client direction.

Java or .NET

Having decided to use a rich-client platform as the foundation of our application development, we really had only two long-term, viable frameworks to choose from: Microsoft .NET or Java. Aside from one's preference of using open-source versus proprietary technology, both frameworks are arguably equally matched. Both are flexible and provide developers a great development environment.

However, when it comes to developing database-driven applications, a single problem plagues both the .NET and the J2EE frameworks: neither delivers the same level of development productivity as Oracle Forms. Despite what critics might say about Oracle Form's “antiquated” technology, developers can still be far quicker in delivering database-driven applications using Oracle Forms compared to Java or .NET!

What makes Oracle Forms more productive than .NET and J2EE for developing database-driven applications is that it provides a higher level of development abstraction. On the other hand, Oracle Forms does impose a rigid model for application development. Fortunately, the level of abstraction in Oracle Forms and its accompanying restrictions have been time-tested and proven to be a good trade-off considering its increased productivity.

We explored the .NET platform, which we found already has many infrastructural supports possibly sufficient to creating Oracle-Forms-like features. Our experience indicated that .NET is just as flexible as any rich-client platform, but its productivity is not comparable to Oracle Forms when it comes to developing database-driven applications. The tragedy is that Microsoft either did not realize this or chose to ignore it over all these years.

With .NET, developers still have to struggle with gluing various parts into a cohesive framework. The .NET data access layer (ADO) is reasonably matured as a straight tabular mapping tool. However, ADO lacks certain features such as automatic version checking found in most object relational (OR) mapping layers (e.g., Hibernate, JDO, and TopLink). ADO .NET is restrictively tabular in nature that maps user interface controls to tables in simplistic ways.

At this point, you probably have wondered how the entire IT industry builds their rich-client applications. Based on our research, we believe that the majority of new internal IT applications are developed using .NET or a component framework with a simplistic data access layer that ties directly to the underlying ODBC, OLE DB, or JDBC libraries. As JDBC matures overtime, a greater percentage of developers even use the more advanced data objects of JDBC 3 directly.

Make no mistake. You can develop database-driven, rich-client applications in a .NET or similar component framework, but many features found in Oracle Forms cannot be easily obtained. For example, to implement parent-child data-block navigation capabilities would require tedious and serious ad-hoc wiring efforts. Most applications instead join these parent-child tables to a singular de-normalized UI control for display. Nowhere to be found are features like automatic query mode. Developers have to hand wire a Search Dialog for each table that is mapped to a UI control. Deployment of the data access object layer to a multi-tier system is mostly non-existence. Even .NET offers no relief in many of these areas.

The ADF Business Components Advantage

While looking for a framework that will bring Oracle Forms like productivity to the world of J2EE, we naturally took a look at Oracle ADF. Oracle ADF is a J2EE framework that specifically aims to simplify the development of Java/Database applications.

The two parts of the ADF framework that piqued our interests were the ADF Business Components – a framework that manages O/R and persistence between Java objects and the database and ADF Swing (p.k.a. JClient) that provides easy binding between Swing UI components and the Model layer – ADF BC in our case.

In contrast to .Net and JDBC based DB interaction layers, Oracle's ADF Business Components (ADF BC) offers significantly more features. Oracle ADF BC includes such features as query-by-example, master-detail synchronization, transaction control and integration with J2EE application server containers. ADF BC utilizes a business-object layer on top of a tabular model that provides the ability to perform data validations at the business-tier level. Applications built on ADF BC can choose to be deployed in a multi-tier environment transparent to the front-end developers. In addition, ADF BC objects are meant to be UI presentation neutral such that the same set of business objects can be reused by a JSP or a rich-client form. Not surprisingly, ADF BC offers a data access object model very close to Oracle Forms. Here are some of the key differences we found between the .NET and the ADF BC approach:

1. Both .NET and JDeveloper have similar processes to using wizards to create data binding objects. The resulting data binding objects are stored in Java or C# source code or some intermediate XML or meta data files. However, the resulting data binding objects created are very different. ADF's generated business objects that are more than binding tables in a straight sense. These business objects can execute and validate business logic in addition to communicating with the database tables. The concept of entities and views shared across the entire application retain a single runtime representation: any UI control causes an entity to change its attribute will reflect to all other controls which depend on the same entity.
2. ADF business layers can be deployed to J2EE application servers without modifying the front-end application. In comparison, ADO .NET objects can probably be configurable as distributed COM objects to achieve some level of remote communication with another machine that acts as an application server. But we do not find support in .NET's built-in wizardry that generates the application we built.
3. .NET requires ODBC or data source provider to be installed on the client machine which the application will be deployed to. In contrast, when using Java's WebStart, Java application using JDBC libraries can be installed automatically and on-demand. Arguably, various desktop application installation management tools can provide relief to lessen the pain of the tediousness deployment of Windows applications.
4. Even after going through the steps of creating a master-detail form in .NET, it is hardly production quality. A developer still has to wire the toolbar, status bar and a whole variety of plumbing in order to make the application comparable to Oracle Forms.
5. Ostensibly absence from the .NET platform is the ability to enter query mode automatically without requiring more coding. We have known other companies that are doing .NET developments. They have to hand wire a Search Dialog for every queryable form. In a likely scenario that a parent block usually drives multiple child blocks and even grand child blocks, hand-wiring Search Dialogs quickly becomes impractical. Worse, all of these Search Dialogs nust coordinate with the entire framework such as the toolbar, the status bar, and the current form for navigation and operation. All these wiring to form a high-level framework soon become non-trivial. It is as difficult as a developer using JDBC to implement ADF, or using ODBC API to implementADO .NET's objects.
6. One of the most convenient artifacts in Oracle Forms we found so indispensable is the List of Values (LOV). .NET developers need to wire each LOV from scratch, even in ActiveX.

Extending Oracle's ADF

We at InPowerSoft were looking for a runtime functionality that is very similar to Oracle Forms. For example, while ADF Swing works with a separate toolbar for each View object, we wanted to have a single toolbar that will control all the data views in the form we were displaying. We were also looking to get even more abstraction when building an ADF Swing application.

What we ended up doing is writing an abstraction layer on top of ADF Swing – since it aimed to provide Forms like features - and we named it InPowerForms. InPowerForms extends ADF Swing and raises its level of abstraction and usefulness. This allows our developers to quickly define a Swing-based form on top of ADF BC with a few lines of code. Based on the success of this approach, we are now offering our built in framework to other customers. You can find more information about InPowerForms on our Web site at: http://inpowersoft.com/inpowerforms/index.htm

Summary

Today we have a product that answers the demand of our customers for a rich and interactive user-interface, which we developed using ADF BC, ADF Swing and our own extensions. We find that our developers are even more productive with this framework then they were with Oracle Forms. Our customers get a new system, based on a standard platform, with extended functionality.