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.
View
The View layers in JClient and J2EE-compliant web applications are completely different. This layer builds the user interface.
JClient uses mostly Swing components. For graphics programming in JClient, 2D and 3D graphics libraries can also be used to dynamically draw lines and text on the screen at runtime. The JClient support within JDeveloper is quite strong. Drag and drop WYSISWYG (“What you see is sort-of what you get”) capabilities allow you to build in an almost 4GL environment. However, for sophisticated applications, much hand coding will still be necessary.
For J2EE web applications, some marking language (HTML, servlets, JSP, XML) with tags is used. Application capabilities are limited by the functionality of these tags. Generating custom tags is doable but is often beyond the talents of novice J2EE development teams.
JDeveloper support for JSPs is one of the most rapidly evolving areas of the tool. Currently, an elegant context-sensitive tag library aids selection of the appropriate tags. The 9.0.5 release promises a graphical WYSISWIG screen editor. Even then, JDeveloper is not an even competitor with highly graphical screen painters such as DreamWeaver and FrontPage. For putting the final touches on web applications, other products such as these are still likely to be used in addition to JDeveloper.
Controller
The Controller layer connects the Model and View layers. Business rules, navigation and content population controls are placed here. This layer is also similar in both JClient and J2EE environments since there is direct interaction with the different user interface components. It is not possible to build the entire Controller layer independent of the View layer. However, the Controller layer handles the business rules which can be stored in the BC4J layer. The entire Controller layer idea is less conceptually clean than the Model and View layers. BC4J spans both Model and Controller layers. BC4J includes Java classes generated explicitly to enforce complex business rules demonstrating the intent to span the Model and Controller layers.
The question of where to store the business rules must be addressed when creating the Controller layer. Oracle professionals are familiar with enforcing business rules in the database using constraints, triggers and stored program units. JDeveloper encourages the placement of business rules in the BC4J layer entity objects so that applications can be database-independent.
Business rules can also be stored in the application logic. With J2EE-compliant web applications, it is possible to enforce the business rules in the client’s JSP view layer.
Where should the Controller function in an application be placed? There is no easy answer. Controller functionality can be found anywhere from down in the database itself up to the View layer. It is up to the designer to decide where this functionality will be implemented.
Building
Complex Applications: Getting Started
Building the first few applications in this new environment is difficult. Manipulating the JDeveloper workspaces, projects and their deployment for the first time is a daunting task. The suggested approach is covered in the Oracle 9i JDeveloper Handbook. As a first step, you should build simple applications using the high-level wizards. Point them at the database tables and allow JDeveloper to build the entire (but not very usable) application. Next, look at the code generated by the high-level wizards. Then use a combination of the low-level wizards and hand coding to build the same applications with the desired refinements.
Keep in mind that JDeveloper is not a repository-based product. It is a code generator. All of the wizards write code into files. They do not place elements in a repository. The JDeveloper wizards have gotten smarter in creating code that can be modified by re-entering the wizards. These wizards work by reading code files and reverse-engineering the appropriate properties which can be manipulated using the Property Inspector. In past releases, it was relatively easy to confuse the wizards causing unpredictable results in the code. Although this is less common now, JDeveloper users must understand what underlying code is being generated and how it works. If you cannot re-enter the wizard generating the source code and understand its meaning, you will not be able to effectively develop applications.
It is strongly suggested that you build a simple JClient and JSP application as well as a simple UIX/Struts structure using both the high-level JDeveloper Wizards and the low-level wizards with some hand coding.
References
The library of books required to support application development using JDeveloper is larger that what was needed for Oracle Forms development. The following is a list of suggested references:
·
Oracle 9i JDeveloper Handbook, Koletzke, Dorsey
& Faderman, (Oracle Press, 2002) ISBN: 0072223847
·
Oracle 9iAS: Building J2EE Applications,
Morrisseau-Leroy (Oracle Press, 2002) ISBN: 0072226145
·
Oracle 9i Application Server Portal
Handbook, Vandivier & Cox (Oracle Press, 2001) ISBN: 0072222492
·
Oracle 9i JDBC Programming, Jason Price,
(Oracle Press, 2002) ISBN: 0072222549 (not needed if
you use BC4J)
·
Java2: The Complete Reference
(5th Edition), Herbert Schildt, (McGraw-Hill, 2002) ISBN: 0072224207
·
Struts Kick Start, Turner & Bedell,
(SAMS, 2002) ISBN: 0672324725
·
Oracle9i XML Handbook, Chang, Scardina
& Kiritzov, (Oracle Press, 2001) ISBN: 007213495X
·
Refactoring: Improving the Design of
Existing Code, Martin Fowler (Addison-Wesley, 1999) ISBN: 0201485672
·
Oracle 9i Web Development, Bradley D.
Brown (Oracle Press, 2001) ISBN: 0072193883
·
The
Java Class Libraries – Volumes 1, 2, 3, Chan & Lee,
(Addison-Wesley)
· The Java Tutorial (series), Campione, et. al (Addison-Wesley)
A Larger
Development Community
For the first time, Oracle developers are not alone. Thousands of other developers are working in Java and other web development environments doing work that may be of use to all developers. Oracle developers need to be aware of and integrate ideas from this larger community. If you are trying to create a tag to do what you want, there is a good chance that someone else has already done it and it may very well be freely available or available for purchase at a modest cost. Look for third party resources prior to building any internal widgets. For example, to embed a chart in an application, there are many basic chart objects not native to either Swing or J2EE tag libraries that are available by simply typing “Java chart” in any popular web search engine. Don’t reinvent the wheel.
A New
Software Development Life Cycle (SDLC)
There are two obvious SDLC candidates for building object-oriented, relational systems. The traditional relational systems development life cycle as implemented in an Oracle environment is well established and reasonably successful. However, this approach has never been contemplated in the context of an OO environment. The other alternative is the traditional OO SDLC which, similarly, has been reasonably successful in building OO-based systems but had paid little attention to solid relational database design. In our new environment, we want to have OO software sitting on top of a relational database. How can this be accomplished?
Most Java programmers pay little attention to the data structure. They want to create class diagrams that correspond to the Java classes and are satisfied as long as Oracle tables provide storage for persistent copies of objects. The core of the design rests within the application rather than the database.
Database architects focus on a well-designed data structure before writing any code, only making denormalizations and modifications to the database as necessary to make the applications perform adequately.
In the traditional relational SDLC, transitions are made from the ERD to table design which, in turn, generates the relational database. There is no awareness of OO analysis or design in the relatively limited ERD vocabulary. The OO SDLC provides a very rich analysis and design environment with a myriad of modelers and diagrammers. However, this process produces a sub-optimal database design.
Using UML class diagram syntax to create activity and sequence diagrams, it is possible to capture the structure of a system. Class diagrams show objects of interest and business processes can be represented by activity and sequence diagrams. Armed with these tools, and JDeveloper, what can be accomplished? The answer is not so simple. The reason is that there is no clear path from OO analysis and design to creating a working production system based on a relational database.
Using an SDLC where everything flows from the analysis and design phases is conceptually the right approach. Any approach with multiple generation steps where tables, entity objects, view objects and Java classes are sequentially generated moves farther away from the original design and gathered business rules. Ultimately, the best approach is to start with a complete representation of the business rules, allowing the entire system to be generated from the specified rules repository. The real promise of merging the object-oriented SDLC and the Java development environment will result in a fully object-oriented model driven SDLC where the entire system can be generated from various UML diagrams. (for more information see “The Object Oriented SDLC” on the Dulcian website at http://www.dulcian.com/)
Conclusions
In the Oracle environment, JDeveloper has numerous strengths and a few weaknesses. Its main advantages over other development products include:
·
A good integrated development environment
(IDE)
·
Easy-to-use interfaces including wizards,
property inspectors, toolbars, code generators.
·
Excellent Oracle database
connectivity
· Support for all Java development
Oracle9i JDeveloper is built upon Java 2 Platform, Enterprise Edition, which is a stronger foundation than any other product in Oracle's history. In the past, with Oracle's earlier products, compromises had to be made based upon existing technologies, as well as backward compatibility, and internal Oracle politics. JDeveloper is based upon a technology that has vast support from other vendors in addition to well recognized standards.
Complex application development is possible within the JDeveloper environment. JClient applications of any level of complexity can be built but not deployed over the Web. Applications of limited complexity can be built in J2EE-compliant form and easily deployed over the Web. With current technology, in neither case will development teams be able to match the efficiency they were accustomed to in the Forms/Designer environment. However, this lower efficiency is offset by the greater flexibility of JClient and ease of web deployment of J2EE. Furthermore, the inefficiencies, particularly in J2EE, are rapidly diminishing. The J2EE environment itself continues to close the capability gap with traditional client/server development within the next year. It is likely that this environment will have matured sufficiently in that time frame to allow us to comfortably create traditional client/server-style applications and deploy them over the web. As JDeveloper includes more and more capabilities, the ability to design and develop complex applications more efficiently will improve.
About the
Author
Dr.
Paul is the co-author of six Oracle Press books that have been translated into nine languages:
· Oracle9i JDeveloper Handbook
·
Oracle JDeveloper 3 Handbook
·
Oracle
Designer Handbook (2 editions)
·
Oracle
Developer: Advanced Forms and Reports
· Oracle8 Design Using UML Object Modeling – (the first book about UML data modeling – published 1999)
Paul won the ODTUG 2003 Volunteer of the Year award, the
Chris Woolridge Outstanding Volunteer Award at