Oracle ADF Real World Developer's Guide: Mastering essential tips and tricks for building next generation enterprise applications with Oracle ADF with this book and ebook.

The View layer contains the UI for the application ADF stack that supports the following view technologies, targeting various presentation channels such as the web browser, desktop, mobile, tablet PC, and Microsoft Excel:

The Controller layer controls the flow of the application. ADF Controller is used for the ADF Faces application, which provides an improved navigation and state management model on top of JSF. The greatest advantage of ADF Controller over the navigation model offered by core JSF is that it improves the modularity of the system by splitting a single monolithic navigation model to multiple reusable navigation cases known as task flows. Task flows are declarative solutions. Developers typically do not need to write any code for defining navigation in applications. Apart from the support for modular application design, ADF task flows also offer a declarative transaction model and state management solutions.

The Model layer binds the UI with business services, abstracting the implementation details. The model layer is functionally divided into two components—data control and data binding.

The ADF model layer plays a very vital role in the entire technology stack. It is the model layer along with JDeveloper IDE that provides a visual and declarative UI development experience for the end user, irrespective of the technology used for building business services. The glue code used for binding the UI with the data model is plumbed by the model layer at runtime based on the binding metadata definition for the page.

The Business services layer provides access to data from various sources and handles the business logic as well. ADF comes with out-of-the-box binding support for the following technologies:

You can choose any of these technologies for building the business services.

JSF is a request-driven MVC web framework, which intends to standardize the development of web-based user interface in a Java EE web applications. ADF Faces forms the view layer of a Fusion web application. This is built on top of JSF with lots of extra features, such as graphs and charts, a dialog framework, declarative components, data streaming, embeddable task flows, and rich AJAX-enabled UI components.

In a Java EE web application, it is the JSF controller that intercepts all the page requests and dispatches them to the appropriate view along with the necessary data. The JSF Controller also controls the page navigation. The ADF Controller is extended from the JSF Controller to support modular web application development by decomposing the single monolithic application into multiple reusable web modules, termed as ADF task flows. Each task flow can have its own transaction attributes, resource management, managed bean definitions, and navigation cases.

The data binding layer of ADF (also known as ADF Model) is quite unique in nature and does not have any real counterparts in the Java EE world. The ADF Model decouples the UI from the business service implementation and provides a generic binding behavior for the collection returned from the business services.

Conceptually, Context and Dependency Injection (CDI) does a similar welding job for Java EE web applications, however, feature wise there are many differences, which we will discuss in the coming chapters.

ADF Business Components simplifies the business services implementation by freeing the developer from writing infrastructural code required by enterprise applications. ADF Business Components mainly constitutes of the entity object, view object, and application module.

The ADF entity objects are similar to the Java Persistence API (JPA) entities, however functionality wise the former scores. The major advantages of the ADF entity object are out-of-the-box support for caching of data in middle tier, matured transaction management, declarative validation support, and the ability to triggerthe SOA process during the transaction post cycle.

The ADF view objects are data shaping components. The ADF view objects are similar to Java Persistence Query Language (JPQL) in the Java EE stack. Some of the advantages of ADF view objects over JPQL are the visual and declarative development experience, support for building model-driven UI, and declarative state management.

The ADF application module is the transaction component that wraps your business service—conceptually similar to a session facade built using a session bean in an EJB application. However, we need to keep in mind that these two technologies are in no way related in their underlying implementation, though at the end of the day everything boils down to Java binaries and JDBC calls.

Let us set up the environment for building applications with ADF. The development environment setup includes setting up the Integrated Development Environment (IDE), version controlling the source, picking up the right build tool, and setting up team collaboration.

The success of a development framework is well complimented by a smart development tool, which simplifies the creation of applications by using this framework. Oracle JDeveloper is the IDE that we will be using for building ADF applications. JDeveloper has better tooling support for ADF, covering an end-to-end development lifecycle. You can download and install the studio edition of the latest JDeveloper release from http://www.oracle.com/technetwork/developer-tools/jdev/downloads/index.html. The studio version of JDevloper comes packaged with Java EE and ADF libraries.

Setting up the Software Configuration Management tool

Once you have decided on tools and technologies for development, the next step may be to set up the Software Configuration Management (SCM) tool. SCM is the task of tracking and controlling changes in the source code during the application development. There are many source control tools available on the market. JDeveloper is packaged with client support for Subversion (SVN)—the most popular version control tool among Java developers. In fact, you are not limited to SVN; JDeveloper can work with most of the popular tools if you have the right extensions installed. The supported version control list includes Concurrent Version System (CVS), Perforce, Serena Dimensions, Rational ClearCase, and so on.

Oracle ADF and JDeveloper go hand in hand. JDeveloper is aimed to simplify your job as an application developer by providing visual and declarative aids for development. Let us take a quick tour of the IDE to get familiarized with the commonly used editor windows and tools.

Once the JDeveloper installation is complete, you are ready to launch it for application development. The first time JDeveloper is run, it will prompt for selecting a role that matches your requirement, as shown in the following screenshot:

JDeveloper IDE enables appropriate features to be used based on the role that you select on startup. The default role selected by the IDE is Studio Developer, which includes all the features offered by the IDE. You will use the Studio Developer role for building our first example, which we will discuss shortly. You can switch to a specific developer role if you want to restrict IDE from displaying many other features that are not relevant to the application that you are building.

JDeveloper is packaged with a variety of application templates, which may help us to set up the basic skeleton for applications leveraging well proven architectural patterns. Based on the complexity of the application, you are free to extend this basic structure by adding more projects later in the development cycle.

To create an application, perform the following steps:

Analyzing the generated metadata files

When you finish the Fusion web application generation wizard, the following files are generated in your source folder. Let us take a quick look at these metadata XML files to understand the role of each item in our application.

• adf-settings.xml: The adf-settings.xml file keeps the UI project configurations. This file is present in the < project-root >/src/META-INF folder.

• faces-config.xml: The faces-config.xml file contains the configurations for a web application built using JSF. This file allows us to configure managed beans, data convertors, and validators used in the UI, navigation cases, global resource bundles, view handlers, page lifecycle phase listeners, and custom lifecycle factory implementation for the application.

• adfc-config.xml: ADF Faces is built on top of the JSF with a lot of extra features, which are not covered by the core JSF. ADF Faces uses adfc-config.xml to keep its configurations. As a Fusion developer, you should use adfc-config.xml to configure the navigation cases and managed bean definitions. To run your Fusion web application, you may need both faces-config.xml and adfc-config.xml files—which is true even if you have not added any custom configuration entries in faces-config.xml.

• trinidad-config.xml: Apache MyFaces Trinidad forms the base for the ADF Faces component set. In fact, Trinidad components earlier were ADF Faces components, which were donated to Apache Software Foundation later in the journey. By default, the generated trinidad-config.xml file contains only the skin family name. However, trinidad-config.xml can be used to override the default configurations for accessibility settings, locale settings, state management, and so on.

• web.xml: The web.xml file acts as deployment descriptor for a Java-based web application. When you generate a Fusion web application by using JDeveloper, a default web.xml file with default settings will be created for you. The default entries include context parameters for configuring the runtime state of the system, security filters, data binding filters for web pages, and resource look up filters. The web.xml file also includes servlet context listeners for initializing the management and monitoring services for view and model layers.

• adf-config.xml: The adf-config.xml file contains application-level settings, which manage the runtime infrastructure—such as failover behavior for the application modules, global fetch limit for all the view objects, caching of resource bundles, automated refresh of page bindings, and so on—for your application.

• weblogic-application.xml: This file is the WebLogic Server-specific deployment descriptor.

The next step is to create a database connection that will be used later in the development phase to generate the data model from database objects.

You can create a database connection by right-clicking on the Connection node under the Application Resource tab and then choosing the New Connection option to connect to the database.

We will be using the HR schema in our samples. The HR schema is included with the Oracle 10g or Oracle 11g database. While you define the database connection, key in the credentials set for your local HR schema.

For building a sample application, you can also use Oracle Express Edition (Oracle Database XE) as the database. Oracle Database XE is an entry-level, small-footprint database. All the examples used in this book use Oracle Database XE as the database. To learn about Oracle Database XE, visit http://www.oracle.com/technetwork/products/express-edition/overview/index.html.

What happens when you create a database connection?

When you create a database connection, JDeveloper generates a set of metadata XML files to keep the connection information. Let us take a quick look at these files.

• connections.xml: This file contains the database connection detail that we create for development. If your application consumes web services or map viewer services, the corresponding connection uniform resource locator (URL) will also be present in this file.

• jps-config.xml: The jps-config.xml file is used to store the Oracle Platform Security configurations. The location of this file is configured in adf-config.xml. If your application is not configured to use ADF Security, this file, at a minimal level, acts as a pointer to cwallet.sso, which contains the password for the database connection details present in connections.xml.

• cwallet.sso: The cwallet.sso file follows the Oracle Platform Security Services (OPSS) specification and it is used as a credential provider in connecting to external systems, such as databases. This file is normally not edited directly.

The basic infrastructure required for building our first ADF application is in place now. First, we will start the business service implementation by generating the data access layer, followed by the business service layer exposing the services to client.

Our example uses ADF Business Components for building business services where the data access layer is formed by entity objects and view objects. The application module generates the business service layer.

What is there in your model project source now?

When you finish generating business components from the database tables by following the steps that we have discussed earlier, JDeveloper will generate metadata XML files and optionally Java classes to hold component definitions for entity objects, view objects, and application modules. Let us take a quick look at the model project source for our example generated by the wizard.

• DepartmentEO.xml: The DepartmentEO.xml file contains the name of the DEPARTMENTS table that we selected for generating the entity and attribute definitions, reflecting the properties of the columns from the DEPARTMENTS table.

• DepartmentVO.xml: The DepartmentVO xml file contains attribute definitions copied from DepartmentEO. this file also contains a query to fetch department records.

• HRServiceAppModule.xml: The HRServiceAppModule.xml file contains information about the view object instances and optional service method definitions. The view object instance used in our example is DepartmentVO1.

• bc4j.xcfg: The bc4j.xcfg file contains metadata information about the application module such as name, database connection, runtime configuration, and so on.

• Model.jpx: The <model-project-name>.jpx file is used by both ADF design-time tools and runtime components. The .jpx file contains the pointers to business component definitions in the model project, where each entry describes the package name and type of business components in the package. In more complex applications, it may also contain metadata for the shared application module, which is primarily used at runtime to share the same data between clients. This file is located in the package folder for your model project.

When you create an application module, JDeveloper IDE automatically creates a data control that contains all the functionality of the application module. You can click on the refresh icon in the Data Controls panel window to view the data control generated for the application module that you added to the model project.

The data control exposes the following:

• View object instances as named data collection

• Built-in operations on data collection and custom business methods

You can design a data bound user interface by dragging an item from the Data Controls panel and dropping it on a web page as a specific UI component.

The next step is to build the user interface for the business services. This is easy if you use ADF data binding, as we will see in this section.

To create a web page, perform the following steps:

Wow… congratulations! You are done with the implementation even without writing a single line of Java code! We can run this application either by directly a deploying to the application server integrated with JDeveloper, or generating deployable artifact from the application source and then installing to the target server.