What
You Need To Know Before Building Applications with JDeveloper 9i
Dr. Paul Dorsey, Dulcian, Inc.
Oracle 9i JDeveloper represents a leap forward towards creating a true integrated development environment (IDE). Using JDeveloper, you can design, develop, debug and deploy Java applications that can connect easily to an Oracle database. In addition, this latest release helps you better organize and encapsulate your code and includes some configuration management functionality as well.
History and
Background
JDeveloper’s roots go back to its license of Java-based tools from Borland in 1997. Using JBuilder source code as a foundation eased Oracle’s entry into the Java development environment. The JDeveloper 1.0 release (called “AppBuilder for Java”) in 1998 was still similar to its JBuilder roots. Starting in 1998, the renamed JDeveloper product’s next few releases demonstrated the tool’s maturation in the Java environment; however, they provided little support for building applications that would interact with an Oracle database. To build Oracle applications using JDeveloper required a great deal of effort, even on the part of a skilled programmer. For this reason, many of the early JDeveloper adopters were primarily Java developers looking for ways to make their applications interact with Oracle databases.
Business
Components for Java (BC4J)
Traditional Oracle developers were frustrated by the poor efficiency of building applications in early versions of JDeveloper. It was not until the 3.0 release that Oracle’s direction for building Java applications to access an Oracle database became clearer through its introduction of Business Components for Java (BC4J). BC4J hides most of the work required to make Java code interact with relational database tables from the user. Using an Oracle-supplied Java library, the JDeveloper wizards automatically generate almost all of the code necessary to allow Java applications to interact safely and efficiently with the database, solving the security, locking, and performance problems of the past. Swing components can be attached directly to BC4J objects.
JavaServer
Pages (JSPs)
JDeveloper’s JClient architecture allows developers to build Java applications or JavaServer Pages to access an Oracle database with much more confidence. A JSP produces an HTML page that is sent to the client. It is compiled into a servlet, which is a pure Java program. Though most of the business logic can be written in Java, the UI portion is usually created in HTML.
Future
Improvements
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 the end of 2003, 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.
Moving to a
Java Development Environment
Moving from a traditional client/server environment to a Java/Web environment is not a simple task. In the “good old days,” you only needed one or two products and languages to develop applications. Table 1 illustrates the tools and languages needed to develop different types of applications in a Java environment.
|
|
Oracle Developer Client/Server |
Java Applications |
Java Applets |
JavaServer Pages (JSPs) |
|
Tools |
Oracle Form Builder SQL*Server or TOAD |
JDeveloper SQL*Server or TOAD |
Oracle Form Builder SQL*Server or TOAD Apache or IAS |
Oracle Form Builder SQL*Server or TOAD Apache or IAS DreamWeaver or FrontPage |
|
Languages |
SQL PL/SQL |
SQL PL/SQL Java XML JDBC SQLJ |
SQL PL/SQL Java XML JDBC SQLJ |
SQL PL/SQL Java XML JDBC SQLJ HTML JavaScript |
|
Security Issues |
|
|
Firewalls Secure Sockets Encryption Keys |
Firewalls Secure Sockets Encryption Keys |
Table 1: Products
and Languages needed for Application Development
You can easily see that number of tools that a developer needs to master in a Java environment has increased dramatically when compared to the traditional client/server environment. For JSPs in particular, the number of tools and technologies that need to be mastered is quite daunting. JDeveloper will have to mature as a product or the underlying architecture will have to change before JSP development becomes popular in the Oracle environment. There has even been a recent surge in discussions about resurrecting the idea of client/server-style architecture for the Web. The author is currently working on a project to investigate the idea of a thick client for the web (termed “thicknet”). Anyone interested in further details is welcome to contact the author.
For current SQL and PL/SQL programmers, learning Java is more than just learning a new syntax. You need to take an object-oriented (OO) approach. Trying to use OO programming elements such as inheritance inappropriately can cause catastrophic project failures. Developers need to learn OO programming style, not just OO syntax. The author recommends the book Refactoring: Improving the Design of Existing Code by Martin Fowler et al (Addison-Wesley Pub Co., 1999) as an excellent guide to learn what it means to write good OO programs.
JDeveloper uses BC4J to handle database operations (queries, inserts, updates, and deletes). BC4J components are built using a combination of Java and the Extensible Markup Language (XML). This is a powerful combination since Java is a modular and portable language that is ideal for communicating between business applications and XML is a tag or markup language where the tags to describe the structure and content of the text or data.
Java classes contain the complex logic and application calls used by other parts of the application. XML redundantly stores the data structure of a relational database. Thus, XML is used to define the data, and Java is used to operate on the data.
In JDeveloper projects, BC4J components will have both XML and Java files associated with them. The XML file holds the metadata that defines the business component, and the Java file holds the methods that implement the business component. The .java file contains get( ) and set( ) methods, which dynamically generate insert, update, and delete statements at runtime.
BC4J
Structure
The BC4J wizards read the Oracle system views to obtain metadata representing the database structure. Using this metadata, the wizards generate XML and Java code that provides a customizable framework to which you can add data validation or other business logic.
BC4J enables Java applications to easily communicate with a relational database. By interacting with the BC4J wizards, you can generate XML files and Java classes. Application developers can then write Java code, which will interact with the BC4J-generated classes that handle communication with the database. These generated classes function because of an Oracle-supplied Java library containing all of the complex database interaction routines.
BC4J
Components
The
BC4J components allow you to conceptually divide your application into two major
parts: user interface/client logic and database interface/business logic.
The BC4J components fit into three major areas:
1. Entity objects and associations
2. View objects and view link objects
3. Data model
Entity objects are based on database tables, views, snapshots, or synonyms and include the database storage requirements. Entity objects can be generated from existing database objects, or they can be manually defined and used to create new database tables. Entity objects contain attribute (column) definitions.
An association defines the relationship between pairs of entity objects. Typically, associations represent a foreign key constraint from the database, but they may be defined for any pair of entity object attribute components. You can also specify more than one attribute on each side of the association, as long as you have the same number of attributes on each side. The association is bidirectional.
View objects use SQL queries to specify and filter data that is defined in the entity objects. Client applications can navigate, update, insert, and delete data using the view object's get()and set() methods.
View links are used to express the relationships between view objects. These relationships are only implemented in one direction. Thus, in a master-detail relationship (the master being the source and the detail being the destination), only the source objects have get/set accessor methods defined. View links provide the filtered rows for the detail table, for the current row selected in the master table.
The data model consists of a collection of views. It is the element with which the UI applications interact.
The BC4J components provide a number of benefits:
·
Logical code organization.
·
Code maintainability can be improved by moving
shared code into the BC4J layer.
·
BC4J classes are easily portable and can be
deployed on the database server, application server, or locally on the client.
·
BC4J classes can implement complex
validation.
· Development time is reduced.
· Data can be cached to improve performance.
Application
Modules
Application modules instantiate the BC4J view objects and view links with which the client applications will interact. It is possible to have multiple application modules within the same BC4J layer. It is also possible to nest application modules within other application modules. Multiple application modules may be needed to implement the business logic for a particular application screen or task, giving each logical part its own module. Typically, an application module would contain three to four view objects and links, though it might contain many more. A large application could have 20 or more application modules, each containing the appropriate view objects and view links for a given task.
BC4J
Capabilities
There are several options for placing complex validation due to BC4J. First, you can place complex validation in the database tier but this may impact performance. A second option is to place it in the middle tier (application or web server). Finally, validation can be placed locally in the client, usually leading to faster performance, easier debugging and maintenance as long as the code is not duplicated elsewhere. The factors that should be taken into account when determining the placement of the complex validation are as follows:
·
Hardware configuration
·
Deployment strategy
·
Number of and types of clients
·
Ease of debugging and maintenance
The BC4J Tester which is used to run applications as they are being created has also been improved. A simple Department/Locations application generated by JDeveloper is shown in Figure 1 in the Oracle Business Component Browser which runs locally on the client machine.
Figure 2: JDeveloper BC4J
Tester
Using
BC4J
When you create application-specific BC4J, you are building a set of Java classes that wrap the DML commands and that reference an XML document that stores the data structure definition. These Java classes extend the base BC4J library classes that make the JDBC calls to the database that take over all of the insert, update, delete, and lock functions required to make the applications run. This enables you to completely encapsulate the logic associated with database access. It also provides developers an ease of application development similar to that of basing blocks on tables in Oracle Forms Developer.
However, BC4J does more than this. Frequently, complex validation is placed in database locations such as triggers on tables, or views with INSTEAD OF triggers. INSTEAD OF trigger views are Oracle views that replace the default insert, update, and delete behavior with user-supplied triggers.
Complex data validation can also be implemented within BC4J classes. Despite this additional option, it is still difficult to set guidelines for what circumstances lead you to place data validation logic in the database as opposed to placing it in the BC4J components. In an environment that is not 100 percent Java, placing validation in BC4J components may be dangerous. Some applications will access the validation through BC4J, while other applications written in different products may be unable to access the validation logic through BC4J. If you are working in a completely Java-based environment, JDeveloper makes the creation and manipulation of BC4J components easy enough that you may choose to use BC4J over server-side validation because reduced development time means lower costs. However, this is only appropriate if you can guarantee that all data-modifying DML operations will use the BC4J components.
BC4J classes can also cache data to be shared among multiple users, providing performance benefits since no access to the database is required.
Approaches
for Using BC4J
With Oracle9i JDeveloper and J2EE, you can now build an application in many ways. System business rules may now reside in any of the following places:
·
Core database procedures and
triggers
·
Database views with INSTEAD OF
triggers
·
BC4J entity objects and associations that
interact with tables
·
BC4J view objects and view links
·
Application logic
There are several schools of thought about how to use BC4J in your applications. Business rules should not be placed in application logic or view objects. They are only listed here because it is possible to place the logic in those locations.
Some assert that the opposite is true, and that all business logic should reside in the database, with subsets used as needed for applications. Others say that virtually all business logic should be stored in the BC4J layer, with the database used as nothing more than a place to hold persistent copies of the data in the classes. The proponents of each strategy adhere to their development style with great tenacity.
This section discusses the pros and cons of these two approaches. Keep in mind that these approaches depend on JDeveloper’s ability to support them. As JDeveloper’s capabilities expand and evolve, the advantages and disadvantages may shift, and approaches that are barely workable now may become much more viable in future releases.
Database-Centric
Approach
The database-centric approach assumes that you are starting with a complete, functioning Oracle database. As you are logically designing applications, it will be evident that they can be built more easily with database views corresponding to the user interface elements. You should build these views using INSTEAD OF triggers to support insert, update, and delete functionality.
All fields to be displayed in the view objects are columns of the database views. For each program, you build a small BC4J project including entity objects and associations that have a one-to-one relationship with the tables, views, and foreign key references necessary to build that program. Next, you create a default view object and view link for each entity object and association. These are then assembled into an application module to support the front-end program.
Validation logic is added to the entity objects only for the purpose of enhancing performance, since all business logic is already validated within the database. Only rarely are additional attributes added to entity objects or view objects since these attributes are already included in the foundation views located in the database.
Each program has its own BC4J project. BC4J projects are not shared by other programs. Application modules are kept relatively small, encompassing more or less the same scope as an Oracle Forms Developer file.
Advantages of
a Database-Centric Approach
Using a database-centric approach to creating applications has the following advantages:
·
This approach is the most comfortable for
existing Oracle developers. It uses basically the same philosophy as creating
any front-end application for an Oracle database.
·
The system is not closely tied to JDeveloper and
BC4J. Most of the non-UI code resides in the database. For example, programs
that do not access the BC4J layer will still use the code in the database,
because all of the business rules reside in the database.
·
Almost all BC4J work can be supported through the
JDeveloper wizards. Little hand-coding is required. The BC4J project for an
application module can be built in a few hours or less because you are only
using one default entity object definition for each database
view.
Disadvantages
of a Database-Centric Approach
The following are some of the disadvantages of creating applications using a database-centric approach:
·
This approach ignores all of the power and
flexibility of BC4J. With entity objects and view objects, two new layers of
abstraction are sitting on top of the database that are not used by this
development strategy.
·
This
approach does not support BC4J reuse. One of the key elements of the BC4J
architecture is the ability to build and reuse BC4J projects.
·
You do not take advantage of the BC4J cache. This
is one of the main strengths of BC4J, because it offloads database activity to
another location and thus saves the CPU cycles of the database server to fulfill
its primary purpose—to manage data. The BC4J layer can cache rows and maintain
consistency with the database. This reduces the number of network messages and
the amount of database activity required to serve data that has already been
served.
·
You do not take advantage of BC4J’s support of
Web Tier and Business Tier servers. BC4J supports the J2EE notion that there is
a benefit in splitting out some of the application code to another server. If
the database is called upon to handle application code, its efficiency to
fulfill the primary directive will be compromised by having to handle complex
business logic.
·
Your application is heavily tied to the Oracle
DBMS idea of views with INSTEAD OF triggers. You cannot use this approach to
build cross-database applications unless the other database provides a structure
similar to views with INSTEAD OF triggers.
·
You need talented PL/SQL developers. If your
organization is primarily a Java shop, this approach makes little
sense.
Business-Logic
Tier Approach
The business-logic tier approach also assumes that you are starting with a complete, functioning Oracle database. The main difference with this approach is that the business logic is contained in Java class files that reside outside of the database. Carried to extremes, this approach would mean creating only one BC4J package, containing entity objects and associations, to support an entire enterprise data model. One entity object is created for each table in the database. Separate projects containing view objects, view links, and application modules can then be built to correspond to the structures that the program requires. A BC4J application module is then built for each program. Business rules are added to the entity objects, possibly backed up by redundant rules in the database for added robustness.
In the case of a large enterprise data model, it can make sense to partition the entity objects and associations created from the database into smaller subsets, to make handling them at design time easier. For example, the 300 entity objects corresponding to a 300-table system could be partitioned into approximately 10 application modules of 30 tables each. Sets of tables with many relationships between them should be placed in a single package together with associations representing those relationships. Cross-package relationships should be represented by associations in the same package as the view objects, view links, and application modules that use them. One entity project will then be shared.
As mentioned earlier, view objects are not simply default images of the entity objects, but often gather information from multiple entity objects simultaneously. In fact, view objects need not be based on entity objects at all, but can instead cache database data directly themselves. One entity object and association will then be shared by many (5–20) different packages containing extra associations, view objects, view links, and application modules. Simple programs usually have one application module for each program, but it is not uncommon for a program to have more than one application module, or for two programs that accomplish similar tasks to use the same application module.
Using this approach, validation resides in the BC4J layer, and possibly redundantly in the database.
Advantages of
the Business-Logic Tier Approach
The following advantages can be gained using this approach:
·
BC4J caching, project reuse, and independence
from the database are useful aspects of this approach.
·
This approach, if used correctly, will afford the
greatest development efficiencies because of the increased modularity of the
persistence/business logic layer.
·
You take advantage of BC4J’s ability to offload
activity from the database server as mentioned in the disadvantages of the
previous approach.
Disadvantages
of the Business-Logic Tier Approach
The following are some of the disadvantages of this approach:
It is a conceptually difficult approach because business rules
of the system may reside in different places. For example, the rules may reside
in tables, entity objects, or view objects. Standards and guidelines for the use
of the different code locations must be developed and enforced.
Organizations embracing this strategy should be careful to
formalize the rules. The rules apply to the database, entity objects, and view
objects. They need to answer questions such as “How will objects be constructed
and how will they interact?”
Without careful planning, the additional flexibility afforded
by BC4J can result in systems where bugs are difficult to track down. This is
because the logic error may reside in many places. Well-designed error messages
can assist in reducing this problem.
JDeveloper
Application Architecture
JDeveloper applications are organized into workspaces and projects. A workspace is equivalent to a directory that holds the projects (files) that make up the program. A separate connection file is required in order to connect to the database. The following diagram shows a typical JDeveloper application structure:
Workspace
BC4J Project
Entities and associations
Views and view links
Module (based on client data model)
UI Project
Class (.java files)
Items
Client data model (.cpx)
Connection (used by BC4J project)
Workspaces
Workspaces are the highest level container in JDeveloper and consist of a logical grouping of files. A workspace can include multiple projects, all of which make up an entire application. As you work with JDeveloper, more than one workspace can be open at one time. Physically, workspaces contain names and locations of other files with a (.jws) extension as shown in Figure 2.
Figure 2: JDeveloper Navigator Interface
showing Workspaces
Usually, there will be one workspace per application or logical portion of an application.
Projects
JDeveloper projects can contain a single file or many files belonging to different application tiers. Physically, projects are files (with a .jpr extension) that are pointers to other files. Projects reside in one package (directory). Many applications require at least two projects: one for the business components and one for the user interface or JSP.
Packages
JDeveloper packages are equivalent to directories. They hold all of the entities, associations, views and view links needed by the projects in a particular workspace. For example, Figure 3 shows the locdept package for a BC4J project containing location and department information.
Figure 3: JDeveloper
package
If you don’t put everything in the same package, you will need to refer to objects in other packages as package_name.object_name.
New Features
Since the release of JDeveloper 9i in the spring of 2002, Oracle has been working continuously to improve the product. The 9.0.3 Preview release includes several new features that can help make development easier and more efficient. A few are mentioned here.
JDeveloper’s Class Modeler supports the modeling of Java classes very nicely. Currently, it only supports modeling BC4J entity objects. The 9.0.3 release also allows development of Enterprise JavaBeans and interfaces in the UML class diagrams created in the Class Modeler. The Activity Modeler is also being expanded to handle process flow modeling. Much effort is being placed into improving and expanding this portion of the tool for the 9.0.4 release in 2003.
JDeveloper also includes a way to link to the Oracle Software Configuration Management (SCM) repository. Formerly knows as the Designer Repository, this feature can be used for version control and configuration management including Check-in and Check-Out, Compare and Merge functionality.
BC4J now works with the J2EE framework. This includes new functionality including:
·
Support of J2EE security standards
·
ExplainPlan for View Objects and View
Links
·
Audit history attribute types
·
Easier debugging for EJB session
beans
BC4J support for JavaServer Page technology has been enhanced. The JDeveloper wizards can generate starter JSP pages. An expanded BC4J Data Tag Library and struts support allow you to easily add tags and struts to your JSP projects. The Code Insight feature includes auto fill-in of names and arguments. A hierarchical view of the JSP and HTML is easily visible in the Structure pane as shown in Figure 3.
Figure 3: JDeveloper
package
Errors are also shown to help with debugging.
Why Use
JDeveloper?
Oracle has seemingly decided to pursue JDeveloper as its primary development platform. Oracle9i JDeveloper is built upon the Java 2 Platform, Enterprise Edition (J2EE) and therefore sits on a stronger foundation than any other product in Oracle’s history. This new technology has a great deal of support from other vendors and the backing of recognized standards.
JDeveloper is still not the complete web application development solution for a traditional Oracle developer who is used to the simple “one product development environment” of Forms Developer. Support for the visual design of the HTML page is still quite limited compared with a tool such as Microsoft FrontPage. Developers currently using Forms Developer and PL/SQL cannot simply replace those with JDeveloper and Java to create complex client/server–style applications deployed over the Web.
JDeveloper can be used very effectively for developing Java applications. JSPs require a slightly steeper learning curve but they can be well supported with JDeveloper. Is JDeveloper a replacement for Designer? Not yet; but Oracle seems to be moving in the direction of making JDeveloper its one unified development environment in the future.
More
Information
As products evolve more and more rapidly, it is particularly important to stay abreast of the changes as they occur. In addition to Oracle Support Services, the Oracle Technology Network (otn.oracle.com) products area contains lots of useful information as well as a very active JDeveloper discussion forum. The ODTUG list servs and IOUG discussion forums are also valuable resources available to help you take advantage of the experiences of others.
Two
Tips
JDeveloper is solid product, but it still has its quirks. Here are two tips that will help you to avoid hours or days of frustration.
1
Use single object (low-level wizards) for
development. Do not use the
high-level wizards that build a large part of your application in a single
step. The high-level wizards make
too many decisions at once and do not always create what you really need in your
application. It takes a little more
time to use the wizards that allow you to build a component at a time but then
you have control over each component.
The high-level wizards are fine for sales demos, but developers would do
well to avoid them.
2
Don’t rename components after they have been
created. You are working in a 3GL
environment. Renaming an object means that every reference to the renamed object
in your application must be changed. For complex programs, JDeveloper sometimes
misses one or more references that need to be changed. Sometimes the non-renamed element still
has code generated that is associated with it, so it may be weeks until you
discover that your rename operation was not totally successful. If you want to rename a component,
delete it and recreate it.
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
JDeveloper’s weaknesses include a steep learning curve and some inefficiencies for application development because of additional tools and languages required to create complete systems. The ultimate goal is a single, integrated development environment for all Oracle systems. Design, creation, and maintenance of both database and applications will all be handled using one product. JDeveloper will probably eventually include the functionality of other products such as Oracle Designer and Oracle Forms Developer as well as third-party products such as Quest Software’s TOADŇ or SQL NavigatorŇ. The realization of this vision is still a few years away. When Oracle brings this vision to fruition, Oracle professionals will have the integrated design and development environment they have dreamed of for so long.
About the
Author
Dr. Paul Dorsey
is the founder and president of Dulcian, Inc. an Oracle consulting
firm specializing in business rules and web based application development. Paul
is the co-author of five Oracle Press books on Designer, Developer, JDeveloper
and Database Design, which have been translated into six languages. He is President of the New York Oracle
Users Group and the Executive Editor of