Understanding the architecture of ADF
Since you have decided to evaluate ADF for your enterprise application, you probably already have a pretty good idea of its architecture and capabilities. Therefore, this section will only give you a very brief overview of ADF—there are many whitepapers, tutorials, and demonstrations available at the Oracle Technology Network (OTN) website. Your starting point for ADF information is http://www.oracle.com/technetwork/developer-tools/adf/overview/index.html.
Enterprise architecture
A modern enterprise application typically consists of a frontend user-facing part and a backend business service part.
The frontend part
The frontend part is constructed from several layers. In a web-based application, these are normally arranged in the common model-view-controller (MVC) pattern, as illustrated in the following figure:
The view layer is interacting with the user, thus displaying data as well as receiving updates and user actions. The controller layer is in charge of interpreting user actions and deciding which screens are presented to the user in which order. The model layer is representing the backend business services to the view and controller layers, thus hiding the complexity of storing and retrieving data.
This architecture implements a clean separation of duties—the page doesn't have to worry about where to go next because that is the task of the controller. The controller doesn't have to worry about how to store data in the data service because that is the task of the model.
Tip
Other frontends
An enterprise application could also have a mobile application frontend or even use existing desktop applications, such as Microsoft Excel, to interact with data. In the ADF technology stack, all of these alternative frontends interact with the same model, making it easy to develop multiple frontend applications against the same data services.
The backend part
The backend part consists of a business service layer that implements the business logic and provides some way of accessing the underlying data services. Business services can be implemented as API code written in Java, PL/SQL, or other languages, using web services or a business service framework such as ADF Business Components.
Under the business services layer, there will be a data service layer actually storing persistent data. Typically, this is based on relational tables, but it could also be XML files in a filesystem or data in other systems accessed through an interface.
The ADF architecture
There are many different ways of building applications with Oracle Application Development Framework, but Oracle has chosen a modern SOA-based architecture for Oracle Fusion Applications. This brand new product has been built from the ground up as the successor to Oracle E-Business Suite, Siebel, PeopleSoft, J.D. Edwards, and many other applications Oracle has acquired over the last couple of years.
Tip
If it's good enough for Oracle Fusion Applications, arguably the biggest enterprise application development effort ever undertaken by mankind, it's probably good enough for you, too.
Oracle Fusion Applications are using the following parts of the ADF framework:
ADF Faces Rich Client (ADFv): This is a very rich set of user interface components implementing advanced functionality in a web application.
ADF Controller (ADFc): This implements the features of a normal JSF controller, but is extended with the possibility to define modular, reusable page flows. ADFc also allows you to declare transaction boundaries, so one database transaction can span across many pages.
ADF binding layer (ADFm): This implements a common backend model that different user interface layers can communicate with.
ADF Business Components (ADF-BC): This is a highly productive, declarative way of defining business services based on relational tables.
You can see all of these in the following figure:
Note
There are many ways of getting from A to B—this book is about traveling the straight and well-paved road Oracle has built for Fusion Applications. However, other routes might be appropriate in some situations; in the frontend part, you could use ADF Mobile for smartphones and tablets or ADF Desktop Integration to access your data directly from within Microsoft Excel, and in the backend, you could use business services based on Web Services, EJBs, or many other technologies and still use the ADF binding layer to connect the back and frontend parts together.
Entity objects and associations
Entity objects (EOs) take care of object-relational mapping, making your relational tables available to the application as Java objects. Entity objects form the base that view objects are normally built on, and all data modifications go through the entity object. You will normally have one entity object for every database table or database view that your application uses, and this object is responsible for producing the correct SQL statements to insert, update, or delete data in the underlying relational tables.
The entity objects help you build scalable and well-performing applications by intelligently caching database records on the application server in order to minimize the load that the application places on the database.
Like entity objects are the middle-tier representation of database tables and database views, associations are the representation of foreign key relationships between tables. An association implements a connection between two entity objects and allows ADF to connect data in one entity object with data in another. JDeveloper is normally able to create associations automatically by simply inspecting the database, but in case your database does not contain foreign keys, you can build associations manually to let ADF know about the relationships in your data.
View objects and view links
While you don't really need to make any major decisions when building the entity objects for the Proof of Concept, you do need to consider the consumers of your business services when you start building view objects—for example, what information you would display on a screen.
View objects are typically based on entity objects, and you'll mainly be using them for two purposes:
To provide data for your screens
To provide data for lists of values (LOVs)
The data handling view objects are normally specific to each screen or business service. One screen can use multiple view objects. If you have master-detail data, for example, departments containing employees, you create one view object for each master-detail level you wish to display on your screen (for example, one department and one employee view object).
One view object can pull together data from several entity objects. If you need to look up a reference value from another table, you don't need to create a separate view object for this. For example, an employee entity object might contain only the department number. If you want your view object to display the department name, you need to include the department entity object in the view object in order to retrieve it.
The LOV view objects are used for drop-down lists and other selections in your user interface. They are typically defined as read-only, and because they can be reused, you can define them once and re-use them everywhere you need a drop-down list on a specific data set.
View links are used to define the master-detail relationships between the view objects and are typically based on associations (again, they are often based on foreign keys in the database).
The following figure shows an example of two ways to display data from the familiar EMP and DEPT tables found in the SCOTT schema:
The left-hand side illustration shows a situation in which you wish to display a department with all of its employees in a master-detail screen. In this case, you create two view objects connected by a view link. The right-hand side illustration shows a situation in which you wish to display all employees together with the name of the department they work in. In this case, you only need one view object pulling together data from both the EMP and DEPT tables through the entity objects.
Application modules
Application modules encapsulate the view object instances and business service methods necessary to perform a unit of work. Each application module has its own transactional context and holds its own database connection. This means that all of the work a user performs using view objects from one application module is part of one database transaction.
Application modules can have different granularity, but typically, you will have one application module for each major subsystem in your application. However, there is no limit to the amount of functionality you can put into one application module—indeed, it is possible to build a small application using just one application module.
Tip
Application modules for Oracle Forms
If you come from an Oracle Forms background and are developing a replacement for an Oracle Forms application, your application will often have a relatively small number of complex, major forms and a larger number of simple data maintenance forms. You will often create one application module per major form and a few application modules, each of which provides data, for a number of simple forms.
If you wish, you can combine multiple application modules inside one root application module. This is called nesting and allows several application modules to participate in the transaction of the root application module. This also saves database connections because only the root application module needs a connection.
The ADF user interface
The preferred way of building the user interface in an ADF enterprise application is with JavaServer Faces (JSF). JSF is a component-based framework for building web-based user interfaces that overcome many of the limitations of earlier technologies such as JavaServer Pages (JSP).
In a JSF application, the user interface does not contain any code but is built from the configurable components of a component library instead. For your application, you'll want to use the sophisticated ADF 12c JSF component library known as the ADF Faces Rich Client.
Note
There are other JSF component libraries; for example, an earlier version of the ADF Faces components (Version 10g) has been released by Oracle as Open Source and is now part of the Apache MyFaces Trinidad project. However, for a modern enterprise application, use ADF Faces Rich Client.
ADF Task Flows
One of the great improvements that ADF 11g and 12c offer over the earlier ways of building web applications is the concept of ADF Task Flows.
It had long been clear to web developers that in a web application, you cannot just let each page decide where to go next—you need the controller from the MVC architecture. Various frameworks and technologies have implemented controllers (both the popular Struts framework and JSF have this), but the controller in ADF Task Flows was the first one capable of handling large enterprise applications.
An ADF web application has one unbounded task flow where you place all of the publicly accessible pages and define the navigation between them. This corresponds to other controller architectures such as Apache Struts. The user can enter an unbounded task flow on any page. However, ADF also has bounded task flows, which are complete, reusable mini applications that can be called from an unbounded task flow or from another bounded task flow.
A bounded task flow has a well-defined entry point, accepts input parameters, and can return an outcome back to the caller. For example, you might build a customer management task flow to handle customer data. In this way, your application can be built in a modular fashion—the developers in charge of implementing each use case can define their own bounded task flow with a well-defined interface for others to call. The team building the customer management task flow is thus free to add new pages or change the navigation flow without affecting the rest of the application.
The concepts behind ADF Task Flows have influenced the JSF 2.2 standard, where this approach is known as Faces Flows. However, ADF Task Flows have more features and a different technical implementation.
ADF pages and fragments
In bounded task flows, you can define either pages or page fragments. Pages are complete web pages that can be run on their own, while page fragments are reusable components that you can place inside regions on pages.
You can choose to build your ADF application as either a traditional web application or a Rich Internet Application (RIA). A traditional web application consists of pages—when the user interacts with the application, the whole browser window will redraw, thus showing the next page of the application. In a Rich Internet Application, on the other hand, you will have a small number of pages (possibly only one) and a larger number of page fragments. These page fragments will dynamically replace each other inside a region on an application page, so the user sees only a part of the page change. If you choose this technique, your application will seem more like a desktop application than a traditional web application.
On your pages or page fragments, you can add content using layout components, data components, and control components:
Layout components: These are containers for other components and control the screen layout. Often, multiple layout components are nested inside each other to achieve the desired layout.
Data components: These are the components that the user interacts with to create and modify data. Data components range from fairly simple components, such as an input field or a checkbox, to very sophisticated components, such as an ADF table.
Control components: These are the buttons and links used to perform actions in an ADF application.
