What You Need to Know Before Building Applications with JDeveloper 9i
Background
The IT world is moving in a more object-oriented direction. The slow evolution toward object-oriented development that is now overtaking the application development community also seems to be finding its way into the database community. What many of us want is to move away from client/server to more Internet- based applications where Java, because of its portability, promises to be a solid part of the solution. However, the Java environment is still in its infancy relative to other languages. The whole Internet development environment has more components and is much more complex than older environments. Internet applications are not only built in Java.
In comparison to more traditional application development environments that often require only one proprietary language, e-Commerce applications often require knowledge of at least three languages: Java, HTML, and JavaScript. In addition, some knowledge of XML may be necessary, and this makes development a daunting task for “legacy” client/server developers. In addition, system architects need knowledge of Secure Sockets Layers and firewalls to build Internet-safe systems. We are moving to a world that is much more complex, less mature, and, as of this writing, significantly less efficient.
JDeveloper 9i offers a development environment designed to help you write Java code and build an object layer that accesses the database. The wizards in JDeveloper allow you to quickly build Java applications that will easily connect to a relational database. Prior to BC4J, building Java applications for a relational database was a challenging experience. One of the strengths of JDeveloper is that it generates and manages Java code that is totally nonproprietary and portable. The 4GLwork areas of JDeveloper that make it look like Oracle Forms and Reports exist to generate this code. This means that you are working in a 3GL environment, and 3GL environments require a different level of skill and a different method of development. This is a difficult but quite important concept to grasp. If you keep in mind that JDeveloper manages 3GL code, you will be less frustrated that it does not always work like 4GL tools, with which you may already be familiar.
The advantage of working in a 3GL environment is that you have ultimate control over the behavior of your applications because you have access to all of the code. However, with this new freedom come new challenges of more low-level code to write and manage. This paper will provide an overview of the JDeveloper 9i development environment and a list of the things you will need to know prior to building applications with the tool.
Where Does JDeveloper 9i Fit?
The Java environment is much richer and more complex than the traditional development environment. With terms like web-based deployment, Java Foundation Classes, Java Server Pages, encapsulation, Java Virtual Machine, Abstract Windowing Toolkit, inheritance, Common Object Request Broker Architecture, HTML, polymorphism, XML, application servers, Java Database Connectivity, JARs, Swing, SQLJ, applets, servlets, and JavaBeans, all of the possibilities can be a bit daunting. However, the Oracle JDeveloper product can assist you in creating, debugging, and deploying Java business components and database applications for the Internet.
For those new to the tool, JDeveloper 9i represents a different way of building applications as well as a dramatic step forward for the product. There are many new areas including:
· UML Modeling
· Process Modeling
· Version Control
When you start building applications with JDeveloper 9i, there will be many things you will wish someone had told you about beforehand. This paper will give you the benefits of our experiences (both good and bad) in building production applications using JDeveloper.
Coming to an understanding of JDeveloper and Java is like trying to learn a computer word processing program and English at the same time. You should have some experience with other computer languages and application conventions before you leap into this type of effort.
JDeveloper is an Integrated Development Environment (IDE) with the following strengths and weaknesses:
Strengths:
· It has all of the benefits of an IDE.
· It’s an Oracle product.
· It is extensible through the use of wizards, property inspectors (customizers), toolbars, and code generators.
· It has excellent Oracle database connectivity.
· It supports all Java development.
Weaknesses:
· It is not the perfect IDE.
· It has no HTML layout editor.
The Multi-tier Approach to Application Development
JDeveloper is optimized to assist you in producing a multi-tier architecture for your database applications. The unique power behind JDeveloper to produce a multi-tier application is centered on Business Components for Java (BC4J). A multi-tier architecture encourages the logical separation of the following elements:
Client tier: The client tier supports the data access requirements of the end user. Complex GUIs can be supported using application code over the Internet, browser-scripting capabilities, and/or by installing application code on the client’s desktop and running it outside of the browser.
Application tier: The
application tier is where the business logic is generally enforced and data
access is coordinated. Application servers contain business logic that can be
reused across a wide variety of clients and applications, thus making it
possible to share physical and logical resources across multi-tier architectures.
The application tier can also contain specialized reporting and analysis tools
to handle complex business intelligence requirements.
Database tier: The database tier is where the data is stored and queried. This layer may also contain links to other external data sources and applications, which may be members of the overall architecture.
Building Business Components for Java (BC4J)
Business Components for Java (BC4J) are built and written using Java and XML to provide the database interaction. Using this architecture, you do not actually communicate with the database. Instead, the UI communication with the database is done in the middle-tier BC4J objects. This is not to say that the UI project cannot contain Java Database Connectivity (JDBC) code that communicates directly with the database, but the primary GUI objects (such as multi-record screen objects) will usually communicate with the database using BC4J objects.
BC4J gives JDeveloper several advantages over other development tools:
· It is the primary way of handling database DML operations.
· BC4J overcomes the hurdle of a complex database interface to handle web-based applications.
· JDeveloper builds a set of Java classes that wrap the DML commands and reference an XML document that stores the data structure.
· Classes make JDBC calls to the database to take over Insert, Update, Delete and Lock functions.
· BC4J classes can implement complex validation.
· Development time is reduced.
· You can cache data to be shared among multiple users.
· BC4J allows for tuning capabilities.
BC4J Structure
The BC4J structure allows developers to think only in terms of logical objects. You can manipulate the Java classes only where complex validation or coding is not handled by the wizards. Applications can be conceptually divided into two parts: the user interface and client logic and the database interface and business logic.
BC4J creates two types of files:
1. XML – redundantly stores data structure of relational database
2. Java classes – contain complex logic and application calls used by other parts of the application.
An Oracle provided Java library handles the JDBC generation.
How BC4J Works
The Wizards generate XML files that define data structure. This allows for a portable interface to the database. All file manipulation should be handled using the wizards. The Wizards then generate Java classes to control what happens to the data. You can add validation and business rules to the Java classes. There are several options for placement of complex validation:
· Database tier (may impact performance)
· Middle tier (application or web server)
· Locally in the client (faster performance, easier debugging and maintenance if the code is not duplicated elsewhere)
The factors to help determine where to place the validation are: hardware configuration, deployment strategy, the number of and types of clients and the ease of debugging and maintenance.
Building Applications Using BC4J
Applications can be built quickly by connecting the user interface (UI) to BC4J objects. BC4J components solve the problem of high-volume client/database traffic by providing alternative locations for client/server logic. The BC4J layer is like a virtual database adjacent to client application. Its extensible framework can do more than just act as a virtual repository.
The Java and XML files created are modular and portable which make them ideal for communicating between business applications. However, using Java you cannot exchange data effectively across different platforms and applications. Java can be used to operate on data and holds the methods to implement business components.
XML is a tag/markup language similar to HTML. You can create XML tags to describe structure and content of data
The XML holds the metadata to define business components.
Using a BC4J Development Philosophy
In JDeveloper 9i, use
the BC4J wizards to generate basic
entities, associations, views, view links, and application modules. For
testing, use the built-in Oracle Business Component Browser to verify the
appropriate definition of views and view links. In addition, BC4J should be
used to customize components, add objects and test objects again to ensure that
objects meet the
design criteria.
Sample Structure of a BC4J Project in JDeveloper
· Prepare the work area
· Create a project for business components
· Create a connection to the database
· Add entity objects
· Add association objects
· Add view objects
· Add view links
· Create application modules
In deploying BC4J projects, you should create BC4J workspaces to allow reuse of BC4J projects in different applications. For example, a JAR attached as library can be used in several applications. After deploying BC4J object, you must point at it in the Object Navigator.
Successful Deployment
The Java environment provides a three-tier architecture in which to place code. Code may reside in the database, at the application server level, or at the client. There are also a variety of products and communication protocols that enable these options. With a product such as JDeveloper, the primary goal is likely to be building e-Commerce applications. Unfortunately, this is the one type of application where you must go beyond the product to support your requirements.
There are four alternative strategies for building applications:
·
Java
application A self-contained application that is basically a
client-server deployment
·
Applet
Java that is centrally located and run using a client’s web browser
·
JSP
A type of servlet running on a Java layer that presents an HTML and JavaScript
front-end
·
Terminal
server A client-server application that runs on another server but
displays in a browser
Other options include Java in the database, HTML only, servlets, and XSQL.
Your environment will limit and guide your choice of deployment alternatives and the tool you select. Workspaces and projects in JDeveloper are like logical text files acting as pointers to physical objects. Each subdirectory created becomes a nested package inside of a Java Archive (JAR). Projects will have multiple nested packages. Many projects can point to the same package and you can deploy original objects first into a JAR.
Java Applications
A Java application looks and acts like a client/server application. The Java Virtual Machine runs on the client. You need to install java.exe on the client and set up the client CLASSPATH. Next install the data layer (BC4J objects) and application code (.class files). Set up an icon to run “java mainclass.” There is no Java server required since Java runs “locally” on the client and connects to the database “locally.”
Advantages
The benefits of deploying a Java application are as follows:
· Java technology
· True object-oriented language (benefits from design and analysis standpoint)
· Good if your staff or resources are Java experts
· Can be transitioned to applets or JSPs someday
· No application server setup required
· Good for intranet or small department solutions
· Rich GUI possibilities - all controls that are available with client/server via the AWT and Swing classes
· Very responsive on the application side
Disadvantages
The major drawback is creating a “fat client.” Other disadvantages include:
· Java applications do not run over the web and have to be maintained like any other client server application.
· Installation headaches if deployed widely
· Java is not compiled code. You are essentially distributing your source code. You can use code obfuscators to make your code hard to read but it is still source code.
Where are Java applications useful?
Java applications are indicated for intranet or small-department solutions with a small number of clients. When the number of clients grows, you will experience all of the same problems and resource drains as in client-server applications because, for each new client, a new software installation is required.
Applets
Applets have fallen out of favor recently. Relatively few developers are building them anymore.
Applets are an alternative that better leverage the strengths of web technology. With a Java applet, when the application is run, the applet is copied from the application server to the client machine and run within a browser. This gives you all of the functionality of a Java application as if you are deploying client-server but allows you to run it over the Internet. As with the Java application alternative, you are working entirely in a Java environment. This means that you can use JDeveloper exclusively to create complete applications that are deployed as applets.
Everything you can do in Java, you can deploy over the web as an applet completely transparently using JDeveloper. You will also have complete control over where the code is executed.
The client browser requests an HTML file from the web server through a standard URL. The HTML file may be static or dynamically generated from another application. This HTML file contains a special applet tag shown as in the following example:
<APPLET CODE = "empappjsp.DeptApplet"
CODEBASE =
"/applet_code/"
WIDTH = 400
HEIGHT = 400
ALIGN = middle >
</APPLET>
The applet tag signals the browser to start an applet window for the JVM session and load the application’s class file named by the code attribute. The applet tag attribute codebase specifies the location of the applet’s .class files relative to the physical location of the HTML file. If the HTML file is in the same directory, the codebase attribute is set to “.” (the same directory).
The application’s .class files download from the application server and are presented in the applet window. The class files may also be cached on the client machine, which means that the download may not be required in all cases.
Once the application has started, it runs in the JVM on the PC like a Java application. The database communication occurs between the JVM and the database as with the Java application.
Advantages
A strong advantage of the Java application is its ability to use the rich user interface components that are included with the AWT and Swing libraries. This advantage is exactly the same in the applet. An applet has the additional advantage of allowing you to use the web application server to store a common set of runtime files. The client also has to have the CODEPATH environment variable defined so that the JVM can find the required files. Although the client still needs to have the JVM runtime files installed, they are included with all popular browsers. This means that the burden of installing software on the client is greatly reduced. The main installation requirement is the client’s browser, which is standard issue these days.
Disadvantages
There are several problems with the Java applet strategy. First, Java applets can be very large. The more complex the application, the larger the applet and the longer the download time (although that can be mitigated if the applet is cached on the client machine). Internet users are an impatient lot. There is a trade-off in performance with this strategy. Once the application loads, unless there is a lot of required database access, the performance will be excellent. For e-Commerce purposes, the load time for the applet is likely to be unreasonable.
Second, the actions that the Java applet can perform on the client are restricted by the built-in security mechanisms. If those features are circumvented, Java applets can be written to perform tasks on the client machine such as writing to the file system. In many organizations, client machines reside behind a firewall that prohibits the downloading of Java applets. Therefore, the use of Java applets is an unworkable strategy for e-Commerce applications.
A restriction of the applet security mechanism is that the database and application server must be located on the same physical machine; there are workarounds for this limitation but the workarounds complicate the configuration of the server. However, this is a disadvantage that can be easily overcome.
Another disadvantage is that an applet uses an HTML browser to supply the JVM. Browsers do not universally support the Swing class libraries. AWT classes are fully supported but require much more coding to connect to the data layer. The impact on applet technology is that you must ensure that your users can access and install the Swing class plug-in offered by Sun. This requires a one-time step to download and install the plug-in. This is a factor to consider in your decision on deployment strategies.
Although one of the advantages of the applet architecture is its use of the web application server to store and serve the HTML file and applet class files, this is also one of its disadvantages. The application server requires additional configuration and maintenance, which, in turn, requires extra human resources and skills. While this requirement is manageable, it is one that must be taken into account.
Where Are Applets Useful?
Within an organization, using Java applets is a viable strategy. An applet gives you a client-server-style application without the overhead of maintaining a client-server environment. An intranet environment may also provide adequate bandwidth to reduce the load time for large Java applets. Even if the load time is significant, if users stay within a single application for some period of time, this may not be much of a hardship. Since an intranet system is a controlled environment, you will likely be operating behind the firewall, thus eliminating the problem of security.
To build e-Commerce applications you will create a BC4J project and generate JavaServer Pages (JSPs). The applications will reside on an application server such as Apache Internet Server or Oracle9i Application Server. Due to firewall issues discussed earlier, these applications cannot consist of purely Java code. They must generate JSPs, which are really simple HTML code constructed dynamically by calling Java routines on the application server.
JDeveloper has limited visual editing capabilities to work with HTML pages. To build serious e-Commerce or internal applications, a separate HTML product is highly recommended. The most popular alternatives are Microsoft FrontPage or MacroMedia Dreamweaver. Although you can gain some efficiency from these tools, any HTML editor will do. If you want additional client-side functionality (such as complex data validation) within your applications, you will need to extend your HTML pages using JavaScript.
JSPs
A JSP is an extension of servlet technology. A servlet is a program stored and run on the web application server that accepts requests from a client browser through an HTTP data stream (posted data or URL) and constructs an HTML page by querying the database and outputting the HTML tags mixed with data from the queries. The entire page is constructed dynamically by the program in a similar way to a Common Gateway Interface (CGI) program.
The advantage of servlets over CGI programs is that they only require a new thread, not an entirely new process like CGI programs. This is a significant resource savings for the application server. In addition, unlike CGI output, servlets are cached providing performance benefits such as allowing the database connections to stay open. Servlets are coded entirely in Java and are therefore portable and do not need a CGI language such as PERL.
JSPs are variations on servlet technology. They have both a dynamic and static element to them. This allows the developer to fix the parts of the application that do not change (for example, the <HTML> tag at the beginning and </HTML> tag at the end of the page). Other parts of the page that would not change would be all of the static links and boilerplate graphics and text. A servlet has to generate these each time the program is run, whereas a JSP program represents the static tag exactly as it will be output. In reality, JSPs are converted to servlets when they are run, but the cleanliness of the JSP code justifies the choice of the JSP style over the servlet style. For example, for each static tag that is built into a JSP, a println() statement would be required in a servlet. Here is an example of the default JSP code that JDeveloper creates when you select JSP from the Object Gallery:
<%@ page
contentType="text/html;charset=WINDOWS-1252"%>
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=WINDOWS-1252">
<META NAME="GENERATOR" CONTENT="Oracle JDeveloper">
<TITLE>
Hello World
</TITLE>
</HEAD>
<BODY>
<H2>The following output is from JSP code:</H2><P>
<% out.println("Hello
World"); %></P>
</BODY>
</HTML>
This sample mixes standard HTML tags (“< >“) and JSP tags (“<% %>“). The file extension .jsp indicates to the web server that the page requested is a JSP file. The web server passes the interpretation of the page to a JSP container that runs in a JVM on the server. The JSP container passes the HTML tags back as is and interprets the JSP-specific tags, some of which may create additional HTML-formatted output. The container then sends the entire page back to the browser.
The first time a JSP page is accessed, it creates a Java file and compiles that file into a bytecode in a .class file. For subsequent accesses, the .class file is cached on the server so that this compilation is not required unless the code is changed. The JSP container runs the .class file in its JVM session. The Java and class files are generated dynamically from the JSP source code file. The BC4J layer sits on the application server and communicates with the database as in the other models.
Advantages
An advantage of the JSP solution is that each page loads quickly. JSPs output plain HTML and are therefore small, compact, and universally readable in any browser. They transmit easily over the Internet. However, this ease of transfer is accompanied by limited functionality. The style of having to scroll through dozens of screens, making option selections on each one, is a familiar one for users of web applications. Simple functions such as deleting a record or changing the way information is sorted requires a reload of the page. You can increase the functionality of a JSP application dramatically by including JavaScript in the HTML page, but this solution requires that the JavaScript that you use is supported by the requirements of your users’ browsers.
The client requirement is much less than with Alternatives 1 and 2 because there is no JVM running on the client. There are no application files or Java runtime files stored or run on the client, which means that the client machine has fewer resource requirements and no special application installation. This automatically makes the JSP applications you develop compatible with a larger number of users. Since the solution is more efficient on the server side, you can support a large number of users.
The presentation look-and-feel of a page is embedded in HTML tags and cascading style sheets. Since the HTML tags are directly embedded in the JSP source file, you can split the development work. Creating the template look-and-feel for a page may be accomplished by a web graphics designer, while the dynamic JSP-specific sections would be developed by a Java programmer. Merging the work is just a matter of embedding one in the other. JDeveloper provides the tools to create and test the JSP code. The web designer would work in another tool as mentioned before.
Disadvantages
The main disadvantages of JSPs are in the added complexity of the JSP tags and architecture. In addition, there is added complexity in setting up the web server to support the servlet API and the JSP container. This extra complexity is not insurmountable but can be a daunting task for a shop that has not been involved with web technology. JDeveloper includes a wizard (the JSP Element Wizard) that helps the developer embed JSP tags into the code. This wizard helps ease the learning curve that accompanies learning the JSP tag language.
In addition, since the base language of the application is HTML, you will experience the limitations of that language when constructing a page. However, there are some complex pages on the Web now that use only HTML as their language, so this limitation is solved by employing an imaginative web designer who has a modern HTML development tool.
The HTML limitation is also eased somewhat because HTML can include embedded JavaScript. Although JavaScript does not have as many features as other programming languages such as Java, including JavaScript in an HTML page greatly extends the capabilities of the page. Therefore, developing robust JSP applications requires that the developer (or at least the development team) is skilled in Java, HTML, and JavaScript. For developers accustomed to using a single language for all coding, this will feel like a step backwards.
There is another loss in functionality because JSP-generated HTML cannot use the rich user interface features included in the AWT and Swing component libraries available for Java applications and applets. In addition, debugging is more difficult because the code is running on the server in the JSP container. JDeveloper offers remote debugging features (mentioned in Chapter 13) that assist in troubleshooting JSP applications.
Where Are JSPs Useful?
JSPs are useful anywhere you would use standard CGI-generated or static HTML pages. Whenever you need a true Internet application that has no firewall limitations or Java requirements for the client, JSPs are indicated.
Using this method can, in no way, emulate the quality of client-server applications. You will need to embrace a much more rudimentary style of development that takes into consideration the limitations of HTML applications. However, at this point in time, this is still the best alternative for deploying Internet applications, especially applications responsible for e-Commerce.
Terminal Server
This alternative falls in between the first two alternatives (Java applications and applets) in terms of effectiveness. You can build client-server applications and deploy them over the Internet using a terminal emulator tool (such as Citrix WinFrame or MetaFrame for Windows NT or Unix, respectively). Using this approach, you can create standard client-server applications and deploy them on an application server that allows each user to create his or her own operating system session.
The terminal server strategy is essentially a mainframe model. The client is a dumb terminal that presents a graphical version of the application that is actually running on the application server. Special software installed on the client emulates the runtime display. The user can interact with the application through this emulator, but there is a process running on the server that represents the actual runtime session.
This strategy is used for standard client-server applications and is available for Java applications and applets as well. It requires no special coding on the application side, so the developer would be working with JDeveloper in the same way as with a Java application.
Advantages
Users access the system through a client machine using a special piece of software. This is equivalent to having multi-user remote access software, which acts like products such as PC Anywhere. As mentioned, this strategy works, not only with Java, but with any client-server applications. For several years, many applications have used this approach to deploy Oracle Forms Developer applications over the web. The terminal software includes built-in security, making it suitable for Internet or intranet use. Using these tools, the only thing that is moving over the Internet is the information about how to change the pixels on the screen, and thus, it even works well with installations that suffer from poor data transfer rates.
This strategy provides all the benefits of client-server Java applications but does not require installation on the user’s machine. The code is centralized as it is using the web solutions, so maintenance and upgrades are easier.
Disadvantages
The disadvantage of this solution is that every user on the system effectively has a server session running, so there is a limit to the number of users that can be accommodated at any one time. In addition, the client machines must have the terminal emulation software installed and maintained. For intranet or Internet access with a small number of users, this is an adequate solution. However, this strategy would not be appropriate in an e-Commerce environment that requires support for a large number of users.
Where Is Terminal Server Useful?
Terminal server is an effective alternative if the number of users is small. It allows developers to take advantage of centralized code architecture without having a JVM installed on each user’s machine. However, the benefit of centralized code is lessened by the need to install and maintain the emulation software for each user.
What Is the Best Deployment Alternative?
Of the four alternative strategies presented, the answer to the question “which is best?” is really “all four.” The one that you use depends upon your specific environment and application requirements. The factors to be considered, as explained in the preceding discussion, are as follows:
· Complex functionality that needs to be supported
· Scalability
· Performance
· Ease of installation and maintenance
Each alternative requires some trade-offs among these factors.
If you are building applications for internal use only, that require more complex functionality, excellent performance, and scalability to any number of users, the client-server Java application alternative is best, assuming you are willing to put up with client-server development and support issues.
In terms of sophistication and performance factors, the terminal server strategy is the next best solution because it is essentially a variation on client-server. Although scalability is an issue, if the number of users is relatively small, you can deploy sophisticated applications in a poor communications environment and still achieve better performance than with client-server. This is true since all database communications occur between the application server and the database server rather than over the Internet.
Running Java applets works well in an intranet environment or where users are not concerned about page loading. This option is scalable up to thousands of users. However, the drawback of the initial class files download is worth serious consideration. This drawback is greatly mitigated by a caching scheme (available in Java 1.3) that, after the first download, keeps a copy of the applet on the client hard drive so that the download is only required if the applet code is updated.
The alternative of running the applications on an Apache or Oracle9i application server with JSPs potentially enhanced by JavaScript code provides good performance, great scalability, no security or firewall issues, but is restricted by the capabilities of HTML and JavaScript. However, currently, this is the only viable alternative for e-Commerce solutions.
Deciding Where to Put the Code
Depending upon the deployment strategy you select, you will have to make decisions about where to place the code. For example, if you settle on the client-server Java application, you have to decide whether to put the BC4J code on the client or on the server in a CORBA Server Object or Enterprise JavaBean (EJB). (You can also place the code on the server using a Remote Method Invocation (RMI) server object, but that is not currently an option in JDeveloper’s wizards and would, therefore, require some hand coding.) This particular decision is one you can make for each of the deployment strategies. The factors you will have to weigh when making this decision include the following:
· Will other applications be able to use the same data layer?
· Does any server layer offer data caching of which the business components could take advantage?
· Is it possible that the physical locations of the servers (application or database) will affect the performance of the data layer?
· How much data validation logic do you have in the application code?
The same kind of thought process is required with the database layer because the Oracle database (as of release 8.1.7) includes a JServer that you can use as an application server. Since the application server tier is always an option, this increases the number of combinations of where specific pieces of code will be placed.
There is no rule of thumb to help you make this decision. The best advice is to be aware of the options and consider them carefully. In addition, keep in touch with all of Oracle user group sources for success stories on a particular arrangement of servers and code. The good news is that the options are relatively portable, and one of your application tuning steps will be moving the code from one tier to another and testing the effect.
Note: JDeveloper support for EJB and CORBA deployment in the Oracle 8i database varies based on the release of the database and the release of JDeveloper. The JDeveloper Release Notes (available in the Help menu) contains a compatibility matrix with details about various releases of the products.
JDeveloper Code Deployment Features
Java systems contain many code files. There are class, XML, HTML, and graphics files for most types of deployment, and additional files, such as JSP files, for specific deployment strategies. The number of files for the application and BC4J code alone can be quite large. When you add these to the runtime libraries that contain the Java language and beans you are using in the application, tracking the files becomes a major effort. Fortunately, JDeveloper organizes all of the files required for the application and assists you in packaging them for distribution to whatever deployment layer you select.
The Deployment Profile Wizard is the key tool that you use to assist in this effort. This wizard creates a profile file with a .prf extension that stores details about what files will be gathered and where they will be placed. This wizard is reentrant in an edit mode, so you can adjust the settings after initially creating the profile.
File Locations
BC4J programs use Java code from many sources. Everything is a class. Buttons, fields, etc. are all stored in library classes invisible to the developer while building applications. In order to deploy successfully, you need to find and copy all of the pieces being accessed into a single deployment directory using the following steps:
1. Use Deployment Wizard Project tab to create a profile.bat in deployment directory.
2. Copy JAR files into directory
3. Modify application profile so JVM can find called JARs (JSPs require a slightly different mechanism).
Deployment Conclusions
JDeveloper is a strong Java development tool. It has excellent access to the Oracle database and serves as a good training ground for Java development work. You have more options when deploying Java code than with client/server code. The trick is to carefully analyze the environment in order to make a decision about which option to use.
Creating Naming Conventions
Consistently applied naming and coding conventions are critical for the success of any system. Given the enormous number of elements available in the Java and JDeveloper environments, it is even more important to have a clearly defined set of conventions to follow. Unlike many previous development environments that included a relatively finite set of components to name, the Java environment includes almost limitless possibilities. All of these possibilities are advantageous for development but pose special challenges for developing consistent naming standards. Using previously developed Java elements from different sources will yield a hodgepodge of naming standards because the standards of those sources may be quite diverse. In addition, even elements from the same manufacturer may not be named consistently. This paper provides some insights into what standards have been used by others as well as some recommendations for structuring your own naming and coding conventions.
Creating naming conventions for your Java applications has several benefits. First, when you review your code, you will be able to quickly grasp the meaning of a particular element simply by seeing its name. Also, by knowing how elements are named, you will be able to locate specific elements more efficiently, making your applications easier to maintain. Another benefit of using a naming convention is that it frees you from having to re-create ways to name elements. By having a naming framework, you will not have to stop and think about how to name each new element.
Ultimately, consistent naming conventions in a Java environment are even more important than they are in traditional development environments such as Oracle Developer. Not only is there a wider variety of elements from which to choose, but keep in mind that behind the scenes, you are working in a straight 3GL environment. This means that, at some point, you will be opening up large blocks of code to edit. All of your program elements will not be neatly organized into an object navigator. You want to be able to scan through the code and quickly identify the type of element you are looking at. By using distinctive naming conventions with consistent prefixes or suffixes for the elements, you can quickly and easily search all of the elements of a particular type using an automated search routine.
If you don’t use very precise naming conventions, you may end up spending time unnecessarily searching for a particular element. Consistently named elements applied throughout an organization also make it easier for developers to work on each other’s code.
Even though elements imported from other sources may not adhere to these conventions, enforcing a naming standard makes it easier to identify those elements that are imported from outside sources as well as better organizing those created internally.
The goals you strive for should follow the four Cs adapted from Oracle Developer Advanced Forms & Reports (Koletzke and Dorsey, Oracle Press, 2000) as follows:
Consistent The way you name elements should remain the same within an application and throughout all of your applications. You should create complete naming standards for everything at the same time. You cannot create database-naming standards and then later create development standards since these two standards categories interact. The standards must be set for the entire development environment and lifecycle.
Concise The names that you give elements should be short, but not so short that their meaning is not quickly understood. Short names make repeated typing easier and less prone to errors. Also, short names ease the burden on others who may need to read your code. If you use concise and consistent names, you will be able to scan through your code quickly, find the necessary elements, and determine their basic functions.
JDeveloper allows you to select class, methods, and parameters from lists that pop up automatically (or by using a keypress such as alt-ctrl-spacebar to display a package and class browser). You can save the typing necessary for long names using these features. However, it is usually faster to type a shorter name than to browse or select from a list. If you use shorter names, you can still use the automatic completion features.
Complete If you use naming conventions at all, you should use them for everything. This means that you need to adopt or develop a naming standard before any coding begins. If you leave out a particular element from your standard, when it comes to your attention you should develop a standard for that element before including it in your development effort.
Clear Select meaningful names for your variables to aid in the “self-documentation” of your programs. For example, when naming Boolean methods, use a name beginning with “is,” such as “isOpen.”
Naming conventions are an important part of an overall standards effort and, as such, should be included in your standards strategy. As with other components of your standards strategy, you have to consider how you will document your naming conventions, train developers how and why to use them, and use code reviews to enforce the naming conventions that you develop.
Types of Objects to Name
The elements being named fall into several categories. This will be new to those used to working in a single, coherent environment such as Oracle Forms. Some of the objects, you name within JDeveloper (e.g. packages) will be physically implemented as directory names in your operating system file structure.
Other objects such as class names will appear as file names within those file structure directories. Swing Components and other objects of that type will appear in the Object Navigator structure pane only and are also Java language elements.
Finally, within the Java routines themselves, you may be creating Java elements that only exist within your code. Some objects such as connections will appear in the Object Navigator but are not visible or editable in any other context.
BC4J objects (entities and views, etc.) are similarly only visible and editable through the BC4J Object Navigator and the generated XML is rarely even looked at or manipulated. Therefore, in setting naming conventions, you need some understanding of how objects are physically implemented since you may want to identify the type of object clearly in whatever context it can be viewed.
When you are creating your own naming conventions, you need to examine the names that are used for existing code and apply general rules that you create to come up with a fully defined naming convention of your own. It is useful to start your naming conventions with the ones that are generally recognized by Java programmers. This should be familiar territory if you have studied the Java language.
General Naming Convention Considerations and Guidelines
The task of defining and implementing a standard of your own can be formidable. It is easy to espouse the principle of using a naming standard, but attempting to encompass all of the possibilities can be very difficult if you try to create a list of naming methods for each element used in your development effort. Many developers attempting their first Java project have expressed their frustration when trying to apply what they have done in the past to the Java environment. Numerous projects have fallen behind schedule and exceeded their budgets with little to show in terms of completed work. In the Java environment, it is clear that you must be ready to change the way you think and work, or you may find yourself buried in so many details that you literally cease to make any headway with your overall project.
It is a good idea to learn and use the current conventions for the major items as just discussed. To complete your naming convention, you need to add some general guidelines and specific rules to the generally recognized conventions for naming all elements.
It is best to use a pre-defined, structured approach for your standard. By defining a simple naming structure that fits most situations, you will be free to add new components to your design without having to stop and think about how to name them.
The following guidelines can be used in creating naming conventions for your application development:
· Use suffixes to imply type - Using a suffix instead of a prefix is an arbitrary decision, but it follows the naming convention that JDeveloper most commonly uses when its wizards generate code. It is useful to drill into the main categories of names and apply these general guidelines to describe how you might assign specific naming conventions to these categories.
· Be aware of case sensitivity - Even though Java is case sensitive, keep in mind that Oracle is not. EMP, Emp, and emp are the same in Oracle but different in Java. When dealing with objects that will be mapped into PL/SQL elements because of function calls to database tables or columns, remember that Oracle is case insensitive. However, Oracle string comparisons are case sensitive. If you query any system tables in Oracle, the names of the Oracle elements will always be returned in upper case. For those developers experienced in the Oracle environment, this will be routine. Java developers should take special care with any elements that will be translated into Oracle elements.
· Use a dictionary of allowable words - Determine how this dictionary will be constructed either using whole words or abbreviations.
· Use abbreviations carefully - A useful abbreviation standard is to select a fixed number of characters (usually 5 or 6) as an abbreviation limit. Whenever possible, when abbreviating, always use the same number of characters only making exceptions for industry standards such as DEPT for Department. You must be somewhat careful about the abbreviations you select; otherwise you may end up with undecipherable elements in your system. Under no circumstances should you adopt a naming standard with less than five characters since it is too hard to figure out what some of these represent.
Three Things we wished we had known…
As with any new development environment, there are better ways to accomplish given tasks. You need time to create workarounds in problem areas and figure out ways to improve performance. Some areas of the tool are still buggy. The following are some pointers about JDeveloper discovered through trial and error.
1. BC4J Wizards
The JDeveloper 9i Wizards work great with the Scott/Tiger and HR schema databases. However, the Wizards did not work with some complex data structures. Sometimes, the wizards created multiple foreign keys between the same tables and overloaded tables with filters. In some cases, using the wizards meant that classes were not properly built. The best strategy was to use lower level wizards to create individual components (entities, views, associations, links) and only use higher level wizards (automatic generation) for very simple applications.
2. Communicating with the database
In order to communicate effectively with the database within an application outside of BC4J objects, you should try to run tasks in the same session. Populate any sequence-generated primary keys and run a PL/SQL procedure. If it is still difficult to pass information from the database, use “executeCommand” (Like Execute Immediate command in PL/SQL).
The syntax for the executeCommand is as follows:
Outside of BC4J -
SessionInfo1.getDBAccess().getTransaction().
executeCommand(“begin place code here; end;”);
Inside BC4J -
getTransaction().executeCommand(“begin place code here; end;”);
3. Don’t rename objects
Oracle Forms developers are used to easily renaming objects and may expect this product to handle changes in the same way. JDeveloper is not as mature a product in this area. If you rename a BC4J object, some references will be updated and some will not. JDeveloper creates two pieces of source code and two pieces of compiled code with different names. The workaround is to delete the old class and rebuild it to remove all references to it. This is just one more reason why it is so important to create and enforce formal naming conventions in this development environment.
Conclusions
You can build very complex applications with JDeveloper 9i. However, this new environment is less mature than Oracle Forms and still has some bugs. There is also a steep learning curve. You will need to know about many other tools and languages in order to use JDeveloper successfully. You still need to know HTML, JavaScript, and other editors (FrontPage, Dreamweaver).
The long-term vision for JDeveloper is quite promising. It is intended to be a complete design and development environment with full UML integration. This is the vision of what Designer and Developer never fully achieved. JDeveloper is a good tool to build Java applications and the best tool for building Oracle-based Java applications. However, the long-term vision is still far in the future.
In moving to a Java-based development environment, don’t abandon your old development environment immediately. Java is still bleeding-edge technology. Keep your first few projects simple. The transition from a traditional client/server Developer environment to JDeveloper will be worthwhile, but not easy, cheap or painless.
About the Author
Dr.