The name that Oracle gave to the level of its ADF framework where the business logic is done is called the Application Module. It is from within this application module (and the view objects that it contains) that the database transactions and business decisions are controlled. Though the details of how ADF connects everything between the HttpSession and Application Modules are unnecessary for the purposes of these next few paragraphs, know that ADF essentially assigns an Application Module to the HttpSession when it is requested (for example, from an action class). However, it is not possible for ADF to have an infinite instances of each application module available for each user. Each user (read: HttpSession) will use only one instance of each application module that it needs (a unique identifer for this instance is kept in the SessionCookie). At the end of each HttpRequest, the application module is checked back into the 'pool'.

Given the increasing popularity of the web, it is no surprise that more and more applications are being developed for and ported to the internet.  However, as the usage of these web applications increases, so does the number of security threats and vulnerabilites that they are potentially susceptible to.  Firewalls and other traditional intrusion-detection systems are not enough to provide adequate  application security because most of these counter measures cannot distinguish between legitimate and illegitimate requests coming through a browser.  Andrew Stern, a director of security product marketing at F5 Networks expresses this sentiment by stating "If, through a Web browser, I can get my account information, I can get to your account information...those two requests look exactly the same to a traditional security system."  

Vulnerability issues therefore need to be addressed within the application itself.  Frank Nimphius, a Principal Product Manager at Oracle, in his white paper titled "J2EE Security in Oracle ADF Web Applications," suggests using J2EE security roles to secure web  applications created with Oracle's Application Development  Framework(ADF).  To do so, one must do the following in the application's deployment descriptor:

The ADF framework boasts some pretty sweet built-in functionality when it comes to user driven events. However, the table selection functionality that is currently built-in has some potential for improvement. When a user selects a specific row, there are a number of potential scenarios that I may want to code for. For example, I may want to do a combination of the following:

• Refresh one or more tables based on the user's selection.
• Update the URL of a button’s action with one or more parameters from the selected row.
• Fill out additional input components on the page.
• Perform validation on the user’s selection. For example, if the user selects a row to either delete or edit. We can perform custom validation to see if that row meets specific criteria.
• Set a value into the session.

ADF/UIX simply does not have the built-in functionality to efficiently handle a combination of these events. With this in mind, I recommend creating a custom Java event with the combination of Oracle’s Partial Page Refreshing to handle the action of a user selecting a row in a UIX table. Let’s take a look at how to do this.

Recently, Oracle made an announcement regarding the fact that Oracle was donating Oracle ADF Faces to the open-source Apache project MyFaces. 

ADF Faces is an enhancement of the xml-based ADF UIX code built on top of the JavaServer Faces (JSF) standard.  JSF's main purpose is to provide a set of APIs to represent UI components, manage their state, handle events, perform input validation and manage page navigation.  It decouples components from their presentation so they can be rendered in multiple ways.  JSF's goal is to make the development experience similar to developing a Java Swing application. 

One of the UIX view layer niceties is that you can setup your web pages to use popular AJAX-style events almost effortlessly.  And you don’t have to write a single line of JavaScript. This is because most of the common web page components; buttons, links, text input boxes, check and radio buttons, and drop-down lists are enabled to send asynchronous events to your controller class and have just about any part of the current page redrawn/updated. You don’t implement any special or extraordinary code to handle the asynchronous event; actually, it can be totally transparent to your server code. Combining this with the ADF active data model, you can really polish your Oracle web application to have that thick-client feel. Oracle calls this asynchronous event handling Partial Page Rendering, or PPR.

Oracle's Application Development Framework business Components (ADF BC ) allows for the implementation of business rules for adding default values to entity attributes, but what type of rules can we implement for the case of a sequence generated primary key?

It is standard practice within current industry to define a primary key column on all object relational database tables, which in most cases is a unique number (as opposed to a unique string of characters). This unique number can be generated by a database sequence number generator or by calculating the next available value based on what is currently realized on that column. The latter presents obvious transactional problems whereas the previous is the standard way of handling unique number-based primary keys. This presents an interesting challenge when implementing business logic, which involves inserting new record/records into a database. If we create a new Row, populate the various attributes (except for the primary key) and attempt to save the transaction we will most assuredly receive a database error, as a primary key is always unique and non- null. To prevent this type of error we can implement this logic in one of two ways: