Oracle Application Development Tools
Building Complex Java Applications with
Oracle 9i JDeveloper
Dr. Paul Dorsey, Dulcian, Inc.
JDeveloper is now demonstrably Oracle’s flagship development product. More resources have been committed to JDeveloper than all other Oracle development products combined with very impressive results. The tool is evolving rapidly with many new features in each release. JDeveloper now stands as a leading tool in the Java 2 Platform, Enterprise Edition (J2EE) development environment, supporting all of the latest structures including UIX, Struts and Web Services.
Where does JDeveloper Stand in the Application Development Community?
JDeveloper has evolved from being a reasonable Java development tool to an extraordinarily rich Java development tool. With the inclusion of Business Components for Java (BC4J), it set a new standard for how Java and web applications can interact with a database. JDeveloper’s scope has also expanded to support full object-oriented model driven systems development. The main focus in recent releases has been on improving the quality of J2EE application development. In this area, great progress has been made. The current release (possibly 9.0.4 – called 10G by publication date) is adequate to support full J2EE applications, although it requires a knowledgeable developer.
J2EE development will be significantly easier in the 9.0.5 release (probably 10G, release 2 in the first or second quarter of 2004). Currently in testing, this release will represent a large step forward in ease and efficiency of J2EE application development. It will also include Oracle’s new Application Development Framework (ADF) architecture, which should not only improve J2EE application development efficiency but also make these applications more accessible to developers with less experience with JavaServer Pages (JSPs).
JDeveloper has finally grown into a mature, fully featured Java development tool. Oracle Developer users who have been reluctant to use the J2EE technology because of its complexity should now be able to move more easily into the J2EE development space. Organizations that fail to embrace this new technology run the risk of falling behind the application development curve. The organizations that choose to make this leap will find no better product than JDeveloper.
Despite all of these improvements, JDeveloper seems to be fighting an uphill battle for acceptance within the Java development community as well as the Oracle development community. The reasons for this reluctance to embrace the tool are different within each group. For the Java developers, Oracle must overcome its long-standing reputation of not creating solid development tools which began with the premature release of Forms 4.0 and Reports 2.0. Even though the Java community barely existed back then, the reputation persisted. Although Developer and Designer continually improved throughout the 1990’s, recent years have seen few changes to impress the development community. Another reason why Java developers have been slow to adopt JDeveloper is due to the fact that the tool is trying to straddle the fence between a 3GL and 4GL product. Behind the scenes, JDeveloper is largely a 3GL code generator. Major portions of the product including the entire BC4J architecture are high-level enough to demonstrate Oracle’s skill with 4GL thinking. Many in the Java development community have the “rugged individualist” philosophy and are loathe to give up control of the low level code.
For Oracle Developers, the reasons for not jumping on the JDeveloper bandwagon are quite different. Leading Oracle development shops that are effectively using Designer and Developer are arguably the most efficient in the world. The capabilities of these tools supported by high-quality templates and rigorous development standards provide an extraordinarily efficient development environment producing high-quality applications.
In JDeveloper, current Oracle developers are forced to move backwards in the quality of applications that can be created while simultaneously advancing to a much more flexible platform. Clearly, the development philosophy implied by JDeveloper is more architecturally sound than that of the Forms/Designer environment. Additionally, not only is the JDeveloper learning curve daunting, but development in this new environment is less efficient, particularly for JClient applications. Oracle is making strides in improving the J2EE environment to enhance efficiency but significant limitations in that environment still exist. Oracle is then left with the unenviable task of moving forward into this new environment while acknowledging the fact that it will take longer to build lower-quality applications.
Eventually all of these problems will be solved. In the next 1-2 years, JDeveloper will emerge as a sophisticated data modeling tool and the J2EE environment will mature, allowing us to build applications of approximately the same quality as is currently possible but which can be deployed over the Web. The J2EE environment itself will require additional maturation so that developers will be able to design and build highly sophisticated, graphically oriented applications such as are currently possible only in the JClient environment of JDeveloper.
As we move into the J2EE environment, it is important to recognize its complexity. An Oracle Forms developer needed to know SQL, PL/SQL, Forms and possibly Toad. In the J2EE architecture, developers must be familiar with Java, a little XML, JDBC, SQL-J, HTML and JavaScript. Building applications in this new environment will require more highly skilled developers.
JDeveloper History
In 1997, Oracle licensed Java-based tools from Borland International. At the time, Borland's JBuilder was a strong Java development tool. By purchasing the rights to the JBuilder source code Oracle was able to speed up its entry into the Java development environment. The initial release in 1998 called “AppBuilder for Java” was similar to its JBuilder foundation. The product was renamed JDeveloper later in 1998 and there was a second release (2.0) in 1999. Through these early versions, the product was slowly maturing in order to function effectively in the Java environment. Meanwhile, behind the scenes, Oracle was working on solving the nagging problem of Java programs connecting to relational database objects.
Since Oracle9i JDeveloper is built upon J2EE, it sits on a stronger foundation than any other product in Oracle's history. Many earlier products had to make compromises because of the limitations of existing technologies and accommodations to backward compatibility. JDeveloper is based upon a relatively new technology that has vast support from other vendors and the backing of recognized standards.
Oracle9i JDeveloper provides a solid Java development environment. A web search for articles mentioning JDeveloper yields many positive reviews from the Java community. For writing Java to interact with an Oracle database, JDeveloper is a clear winner because of the BC4J layer.
Short Term and Long Term Vision
The redesign of the 9i release did not change the basic ways in which developers work with the tool. However, the new interface is more intuitive, often faster, and more consistent than previous releases. For those accustomed to working with earlier releases, this release requires some changes in the operations used. The 9i release offers more consistency in the IDE work areas.
In the short term, Oracle is justifiably satisfied with the core architecture of the product. Now they are working to improve the product’s application development efficiency. Future JDeveloper improvements may eventually deliver improved wizards to help automate many of the tasks currently required to develop applications and to help close the gap between JDeveloper and Forms Developer for intra-company application development.
A second short-term improvement will focus on JDeveloper as a modeling and design tool. The current Class Modeler reflects Oracle’s interest in using UML to design databases. By 2004, JDeveloper may be competing with Designer as a data modeling tool. Other parts of the UML will also be incorporated into JDeveloper to support more of the software development lifecycle.
Over the long term, JDeveloper should become a completely integrated design and development environment including full UML integration and improved JSP development capability.
Business Components For Java (BC4J)
One of the key areas of the JDeveloper product that sets it apart form other tools is the BC4J architecture. BC4J greatly simplifies building applications that connect to a relational database.
By interacting almost exclusively through wizards, developers can generate sophisticated structures that allow classes and JSP tags to easily interact with a relational database. A detailed description of BC4J is beyond the scope of this paper but can be found in the Oracle 9i JDeveloper Handbook (Koletzke, Dorsey & Faderman, Oracle Press, 2002).
It is surprising that many developers currently using JDeveloper are reluctant to take advantage of what the BC4J layer has to offer. There is some learning curve associated with its architecture but the hesitance to use BC4J seems as incomprehensible as C programmers not using the ProC compiler because they want to write their own OCI calls.
BC4J has rapidly evolved into a surprisingly mature and virtually bug-free environment that not only increases development speed, but also helps developers intelligently architect their code. The author has encountered a number of systems where developers rejected using BC4J and ended up with structures that were unmaintainable if they worked at all.
With the 9i release, BC4J now works with the J2EE framework. This includes new functionality including:
· Support for J2EE security standards
· ExplainPlan for View Objects and View Links
· Audit history attribute types
· Easier debugging for EJB session beans
At its roots, BC4J is supported by a programming protocol or standard that describes how to build classes that will interact with a relational database. JDeveloper uses BC4J as the primary way of handling database DML operations (queries, inserts, updates, and deletes).
Application Development
JDeveloper can be used to create a number of different types of applications. For novice users, unlike Oracle Form Builder, there is no clear development bias. JDeveloper competes with Visual Café and JBuilder, providing an open development framework. Consequently, JDeveloper supports JClient application development with Swing components, JavaServer Pages (JSPs), UIX/Struts (currently only to a limited extent but soon to be improved in upcoming releases), Enterprise JavaBeans (EJBs) and Web Services. This can be a confusing environment for novice developers. To some extent, this will significantly change with the next major release in 2004 currently called JDeveloper 10G, second release (or 9.0.5) This release will include the Oracle Application Development Framework (ADF) which is currently the way that Oracle is building their Applications product. JDeveloper 9.0.5 will demonstrate a clear bias encouraging developers to adopt the ADF philosophy.
Oracle should be applauded for their efforts to create the ADF. For too long, the JDeveloper product has been simply reactive to the demands of the marketplace. Clearly, JDeveloper has achieved its mission of being able to compete effectively with any Java tool on the market, but has failed to emerge with any clear vision of how application development should work. When the 9.0.5 version is released, the ADF must be evaluated to determine whether or not this direction should be wholeheartedly embraced by the development community.
JClient vs. J2EE Development
Using JDeveloper, the two main development directions are JClient and J2EE web-compliant application types. Each will be discussed separately.
JClient
JClient development entails a fairly straightforward Java approach. Sun Microsystems has created a large number of Swing components to support many standard user interface structures such as text boxes, radio groups, poplists, etc. JClient applications provide the greatest flexibility from a development standpoint.
Applications of virtually any quality and complexity can be created using this architecture. The JDeveloper product itself is a very large JClient application, including sophisticated code editors, UML drawing tools and re-entrant Wizards.
Why aren’t JClient applications being built for deployment over the Web? The deployment of JClient applications can be accomplished using applets through a browser. These applications often experience significant performance and security (firewall) problems, making them an inadequate choice for web application development.
J2EE
Describing web applications within a J2EE environment is a more challenging task because they are continually changing as J2EE continues to evolve. In general, J2EE applications involve some type of markup language (HTML, XML) which then interacts with Java servlets. JavaServer Pages (JSPs) are a flavor of HTML that wrap Java calls. Until recently, JSPs were considered state-of-the-art for web application development. However, they have limited capabilities and barely adequate performance. Many JSPs require retransmitting and repainting the entire page when information is changed or updated. This is a slow and expensive process. As a result, JDeveloper is moving towards more UIX-based screen design. These designs are effectively a special type of JSP including more sophisticated tags. Unlike JSPs, UIX allows partial screen repainting resulting in better performance. J2EE web applications have less flexibility than their JClient counterparts but are easily deployed over the Web and are secure enough to handle most existing firewalls.
JavaServer Faces
The evolution of this technology in the J2EE environment continues with a new standard called JavaServer Faces (JSF) which will probably be released in the near future. Once JSF is released, the JDeveloper team will evaluate and support this technology as appropriate. JSF will probably not be integrated into future releases of JDeveloper until late 2004 at the earliest.
Model-View-Controller (MVC) Architecture
When building applications now, we are not completely without an underlying framework. Behind the scenes is the 3-tier Model-View-Controller (MVC) architecture which drives most of the Java community. Each tier will be discussed separately in the context of JClient and J2EE-compliant web applications.
Model
The model layer connects the user interface to the database (or other persistent data store). In the JDeveloper environment, this is handled by BC4J and is what BC4J was designed to do. In a relational database system, this is typically the most complex portion of the system for which to write code. Using BC4J makes this task much easier. If BC4J’s sophisticated caching and business rule storage capabilities are not used, applications can be connected to a database using Toplink. Toplink is a recent Oracle acquisition providing a simple way of connecting applications to the database.
The model layer for both JClient and J2EE applications is the same whether you are building EJBs, or BC4J elements. The entire Model layer can be created without even deciding which type of application will be supported. There are few differences in the steps needed to build for either application type.