This chapter includes the following sections:
For definitions of unfamiliar terms found in this and other books, see the Glossary.
Oracle ADF is a commercial Java framework for building enterprise applications. It supports rapid application development based on ready-to-use design patterns, metadata-driven and visual tools.
The Oracle Application Development Framework (Oracle ADF) is an end-to-end application framework that builds on Java Platform, Enterprise Edition (Java EE) standards and open-source technologies. You can use Oracle ADF to implement enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces. Because of its declarative nature, Oracle ADF simplifies and accelerates development by allowing users to focus on the logic of application creation rather than coding details. Used in tandem, Oracle JDeveloper and Oracle ADF give you an environment that covers the full development lifecycle from design to deployment, with drag and drop data binding, visual UI design, and team development features built in.
Tip:
You can also develop ADF applications using Oracle Enterprise Pack for Eclipse (OEPE). OEPE is a set of plug-ins designed for the Eclipse IDE to support Java EE development. OEPE also includes support for ADF application development, though that support is more limited than that provided by JDeveloper. See http://www.oracle.com/technetwork/developer-tools/eclipse/overview/index.html
.
You can develop Fusion web applications, which are applications built with the full Fusion technology stack—ADF Business Components, ADF Model, ADF Controller, and JavaServer Faces pages with ADF Faces components. As a companion to this guide, you can download and view the Summit sample applications for Oracle ADF, which help to illustrate the concepts and procedures in this guide (and other Oracle Fusion Middleware developer guides). The examples in this sample application are built using the Fusion web application technology stack. Screenshots and code samples from this application are used throughout this guide to provide you with real-world examples of using the Oracle ADF technologies. For information about downloading and using the Summit ADF sample applications, see Introduction to the ADF Sample Application.
Oracle ADF architecture is based on Model-View-Controller (MVC) design pattern that consists of four layers – Model, View, Controller, and Business Services. Separating applications into these layers helps in the maintenance and reusability of components across applications.
In line with community best practices, applications you build using the Fusion web technology stack achieve a clean separation of business logic, page navigation, and user interface by adhering to a model-view-controller architecture. As shown in Figure 1-1, in an MVC architecture:
The model layer represents the data values related to the current page, along with the model-level business rules, security, and application logic used against the data values.
The view layer contains the UI pages used to view or modify that data.
The controller layer processes user input and determines page navigation.
The business service layer handles data access and encapsulates business logic.
Figure 1-1 MVC Architecture Cleanly Separates UI, Business Logic and Page Navigation
Figure 1-2 illustrates where each ADF module fits in the Fusion web application architecture. The core module in the framework is ADF Model, a data binding facility. ADF Model enables a unified approach to bind any user interface to any business service, without the need to write code. The other modules that make up a Fusion web application technology stack are:
ADF Business Components, which simplify building business services.
ADF Faces, which offers a rich library of ajax-enabled UI components for web applications built with JavaServer Faces (JSF).
ADF Controller, which integrates JSF with ADF Model. ADF Controller extends the standard JSF controller by providing additional functionality, such as reusable task flows that pass control not only between JSF pages, but also between other activities, for instance method calls or other task flows. The ADF Controller also works with the data model to ensure the proper data is used for each request or region.
Note:
In addition to ADF Faces, Oracle ADF also supports using the Java and standard JSF view technologies. For information about these technologies, see Getting Started with Developing Java Applications in Developing Applications with Oracle JDeveloper. Oracle ADF also provides support for using Microsoft Excel as a view layer for your application. See About ADF Desktop Integration with Microsoft Excel in Developing Applications with Oracle ADF Desktop Integration.
Figure 1-2 Simple Oracle ADF Architecture
For information about the Oracle ADF architecture and the individual ADF technologies, see Overview of Oracle ADF in Understanding Oracle Application Development Framework.
You can build a Fusion web application with Oracle ADF using JDeveloper. Use the step-by-step ADF application development process that minimizes the coding effort of the developer to build an application’s infrastructure and to implement complex business logic of the application.
Oracle ADF emphasizes the use of the declarative programming paradigm throughout the development process to allow users to focus on the logic of application creation without having to get into implementation details. Using JDeveloper with Oracle ADF, you benefit from a high-productivity environment that automatically manages your application's declarative metadata for data access, validation, page control and navigation, user interface design, and data binding.
At a high level, the development process for a Fusion web application usually involves the following:
Creating an application workspace: Using a wizard, JDeveloper automatically adds the libraries and configuration needed for the technologies you select, and structures your application into projects with packages and directories.
Modeling the database objects: You can create an online database or offline replica of any database, and use JDeveloper editors and diagrammers to edit definitions and update schemas.
Creating use cases: Using the UML modeler, you can create use cases for your application.
Designing application control and navigation: You use diagrammers to visually determine the flow of application control and navigation. JDeveloper creates the underlying XML for you.
Identifying shared resources: You use a resource library that allows you to view and use imported libraries by simply dragging and dropping them into your application.
Creating business components to access data: From your database tables, you create entity objects using wizards or dialogs. From those entity objects, you create the view objects used by the pages in your application. You can implement validation rules and other types of business logic using editors.
Implementing the user interface with JSF: The Data Controls panel in JDeveloper contains a representation of the view objects in your application. Creating a user interface is as simple as dragging an object onto a page and selecting the UI component you want to display the underlying data. For UI components that are not databound, you use the Components window to drag and drop components. JDeveloper creates the page code for you.
Binding UI components to data using ADF Model: When you drag an object from the Data Controls panel, JDeveloper automatically creates the bindings between the page and the data model.
Incorporating validation and error handling: Once your application is created, you use editors to add additional validation and to define error handling.
Securing the application: You use editors to create roles and populate these with users. You then use a flat file editor to define security policies for these roles and assign them to specific resources in your application.
Testing and debugging: JDeveloper includes an integrated application server that allows you to fully test your application without needing to package it up and deploy it. JDeveloper also includes the ADF Declarative Debugger, a tool that allows you to set breakpoints and examine the data.
Deploying the application: You use wizards and editors to create and edit deployment descriptors, JAR files, and application server connections.
The first step in building a new application is to assign it a name and to specify the directory where its source files will be saved. When you create an application using the application templates provided by JDeveloper, it organizes your workspace into projects and creates and organizes many of the configuration files required by the type of application you are creating.
One of these templates is the ADF Fusion Web Application template, which provides the correctly configured set of projects you need to create a web application that uses ADF Faces for the view, ADF Controller for the page flow, and ADF Business Components for business services. When you create an application workspace using this template, JDeveloper automatically creates the JSF and ADF configuration files needed for the application.
One part of the application overview is the Fusion Web Application Quick Start Checklist. This checklist provides you with the basic steps for creating a Fusion web application. Included are links to pertinent documentation, prerequisites, and the ability to keep track of status for each step in the checklist, as shown in Figure 1-3.
Figure 1-3 Fusion Web Application Quick Start Checklist
JDeveloper also creates a project named Model
that will contain all the source files related to the business services in your application, and a project named ViewController
that will contain all the source files for your ADF Faces view layer and model layer, including files for the controller.
To save you having to add the associated libraries yourself, JDeveloper automatically adds the following libraries to the data model project, once you create a business component:
ADF Model Runtime
BC4J Oracle Domains
BC4J Runtime
BC4J Security
MDS Runtime
MDS Runtime Dependencies
Oracle JDBC
JDeveloper also adds the following libraries to the view project:
JSP Runtime
JSF 2.1
JSTL 1.2
ADF Page Flow Runtime
ADF Controller Runtime
ADF Controller Schema
ADF Faces Runtime 11
ADF Common Runtime
ADF Web Runtime
MDS Runtime
MDS Runtime Dependencies
Commons Beanutils 1.6
Commons Logging 1.0.4
Commons Collections 3.1
ADF DVT Faces Runtime
ADF DVT Faces Databinding Runtime
ADF DVT Faces Databinding MDS Runtime
Once you add a JSF page, JDeveloper adds the Oracle JEWT library.
You can then use JDeveloper to create additional projects, and add the packages and files needed for your application.
Note:
If you plan to reuse artifacts in your application (for example, task flows), then you should follow the naming guidelines presented in Reusing Application Components in order to prevent naming conflicts.
Tip:
You can edit the default values used in application templates, as well as create your own templates. To do so, choose Application > Manage Templates.
Figure 1-4 shows the different projects, packages, directories, and files for the Summit ADF sample application, as displayed in the Applications window.
Figure 1-4 Summit ADF Sample Application Projects, Packages, and Directories
For more information, see the "Managing Applications and Projects" section of Developing Applications with Oracle JDeveloper.
When you work with your files, you use mostly the Applications window, editor window, the Structure window, and the Properties window, as shown in Figure 1-5. The editor window allows you to view many of your files in a WYSIWYG environment, or you can view a file in an overview editor where you can declaratively make changes, or you can view the source code for the file. The Structure window shows the structure of the currently selected file. You can select objects in this window and then edit the properties for the selection in the Properties window.
In JDeveloper, you can work with a database that is online, or, after you create your application workspace, you can copy database objects from a database schema to an offline database or project where they become available as offline database objects, saved as .xml
files. With either an online or offline database, you can then create and edit database object definitions within a project. You can also compare your offline database objects with other offline or live database schemas and generate SQL statements (including CREATE
, REPLACE
, and ALTER
).
For example, you can drag a table from a database connection that your application defines onto a database diagram and JDeveloper will give you the choice to model the database object live or offline (to create the .xml
file representation of the object). Modeling database definitions, such as tables and foreign keys, visually captures the essential information about a schema. You can use the diagram to drag and drop columns and keys to duplicate, move, and create foreign key relationships. Working in offline mode, whenever you model a node on a diagram, JDeveloper creates the underlying offline object and lists it in the Applications window. Working with a live schema, JDeveloper updates the live database object as you amend the diagram. You can create multiple diagrams from the same offline database objects and spread your offline database across multiple projects.
Using a database diagram like the one shown in Figure 1-6 you can visualize the following:
Tables and their columns
Foreign key relationships between tables
Views
Offline sequences and synonyms
In addition to using the diagram directly to create and edit database objects, you can work with specific database object editors. After you have finished working with the offline database objects, you can generate new and updated database definitions to online database schemas.
When you work with the database diagram you can customize the diagram to change the layout, change how objects are represented and grouped, add diagram annotations to specify dependencies or links (such as URLs), and change visual properties, such as color and font of diagram elements.
Figure 1-6 Database Diagram for Payments Grouping
For more information about modeling database definitions with database diagrams, see the "Creating, Editing, and Dropping Database Objects" section in Developing Applications with Oracle JDeveloper.
After creating an application workspace, you may decide to begin the development process by doing use case modeling to capture and communicate end-user requirements for the application to be built. Figure 1-7 shows a simple diagram for an HR administrator creating a new employee that you might design using the UML modeler in JDeveloper. Using diagram annotations, you can capture particular requirements about what end users might need to see on the screens that will implement the use case. For example, in this use case, it is noted that the user will choose to create a new employee while viewing a list of all employees.
Figure 1-7 Use Case Diagram for Viewing Order History
For more information about creating use case diagrams, see the "Developing Applications Using Modeling" chapter of Developing Applications with Oracle JDeveloper.
By modeling the use cases, you begin to understand the kinds of user interface pages that will be required to implement end-user requirements. At this point, you can use these diagrams as documentation tools that will help as you begin to design the flow of your application. In a Fusion web application, you use ADF task flows instead of standard JSF navigation flows. Task flows provide a more modular and transaction-aware approach to navigation and application control. Like standard JSF navigation flows, task flows contain mostly viewable pages (or page fragments). Aside from navigation, task flows can also have nonvisual activities that can be chained together to affect the page flow and application behavior. For example, these nonvisual activities can call methods on managed beans, evaluate an EL expression, or call another task flow. This facilitates reuse, as business logic can be invoked independently of the page being displayed.
Figure 1-8 shows a task flow for creating an employee. In this task flow, GeneralInfo
and Confirmation
are view activities that represent pages, while CreateInsert
is a method call activity. When the user enters this flow, the CreateInsert
activity is invoked (because it is the entry point for the flow, as denoted by the green circle) and the corresponding method is called. Because this is a call to a method, and the method itself is not included in the task flow, the method can be reused elsewhere in the application. Or, the logic in the method could be changed, without affecting the metadata for the page flow. From there, the flow continues to the GeneralInfo
page, and once the data is submitted, to the Confirmation
page.
Figure 1-8 Task Flow to Create an Employee
ADF Controller provides a mechanism to define navigation using control flow rules. The control flow rule information, along with other information regarding the flow, is saved in a configuration file. Figure 1-9 shows the Structure window for the task flow. This window shows each of the items configured in the flow, such as the control flow rules. The Properties window (by default, located at the bottom right) allows you to set values for the different elements in the flow.
Figure 1-9 Task Flow Elements in the Structure Window and Properties Window
Aside from pages, task flows can also coordinate page fragments. Page fragments are JSF documents that are rendered as content in other JSF pages. You can create page fragments and the control between them in a bounded task flow as you would create pages, and then insert the entire task flow into another page as a region. Because it is simply another task flow, the region can independently execute methods, evaluate expressions, and display content, while the remaining content on the containing page stays the same.
Regions also facilitate reuse. You can create a task flow as a region, determine the pieces of information required by a task and the pieces of information it might return, define those as parameters and return values of the region, then drop the region on any page in an application. Depending on the value of the parameter, a different view can display.
The chapters in Creating ADF Task Flows contain information about using task flows. For general information about task flows and creating them, see Getting Started with ADF Task Flows . For information about task flow activities, see Working with Task Flow Activities . If you need to pass parameters into or out of task flows, see Using Parameters in Task Flows. For more information about regions, see Using Task Flows as Regions . For information about advanced functionality that task flows can provide, such as transactional capabilities and creating mandatory sequences of pages (known as trains), see Creating Complex Task Flows . For information about using task flows to create dialogs, see Using Dialogs in Your Application.
When designing the application, you may find that some aspects of your application can be reused throughout the application. For example, you might have one developer that creates the business components, and another that creates the web interface. The business component developer can then save the project and package it as a library. The library can be sent to other developers who can add it to their resource catalog, from which they can drag and drop it onto any page where it's needed. Figure 1-10 shows a resources catalog in the Resources window of JDeveloper.
Figure 1-10 Resources Window in JDeveloper
Be sure to note all the tasks that can possibly become candidates for reuse. Reusing Application Components provides more information about the ADF artifacts that can be packaged and reused as an ADF library, along with procedures both for creating and using the libraries.
Typically, when you implement business logic as ADF Business Components, you do the following:
Create entity objects to represent tables that you expect your application to perform a transaction against. The entity objects can actually be created from an existing database schema. Add validation and business rules as needed.
Create view objects that work with the entity objects to query the database. These view objects will be used to make the data available for display at your view layer. You can also create read-only view objects, which you might use to display static lists. Like entity objects, view objects can be created from an existing database schema.
Create the application module, which is the transactional component that UI clients use to work with application data. The application module provides the interface to the business services that a consumer of those services (such as the UI layer of your application) will use. This application module contains view object instances in its data model along with any custom methods that users will interact with through the application's web pages.
If needed, publish your services as web services for remote invocation.
The chapters contained in Building Your Business Services provide information on creating each of these artifacts. The chapters in Completing Your Application provide additional information, such as extending business objects, tuning, and state management.
Once you have an understanding of the data that will be presented and manipulated in your application, if you haven't already done so, you can build your database (for more information, see the "Designing Databases Within Oracle JDeveloper" chapter of Developing Applications with Oracle JDeveloper). Once the database tables are in place, you can create a set of entity objects that represents them and simplifies modifying the data they contain. When you use entity objects to encapsulate data access and validation related to the tables, any pages you build today or in the future that work with these tables are consistently validated. Any relationships between the tables will be reflected as associations between the corresponding entity objects.
Once the entity objects are created, you can define control and attribute hints that simplify the display of the entities in the UI, and you can also add behaviors to the objects. For more information, see Creating a Business Domain Layer Using Entity Objects.
Once the reusable layer of business objects is created, you can implement the application module's data model and service methods with which a UI client can work.
The application module's data model is composed of instances of the view object components you create that encapsulate the necessary queries. View objects can join, project, filter, sort, and aggregate data into the shape required by the end-user task being represented in the user interface. When the end user needs to update the data, your view objects reference entity objects in your reusable business domain layer. View objects are reusable and can be used in multiple application modules. For more information, see Defining SQL Queries Using View Objects.
Figure 1-11 shows the oracle.summit.model.view
package, which contains many of the queries needed by the application.
Figure 1-11 View Objects in the Summit ADF Sample Application
Additionally, you may find that you need to expose functionality to external applications. You can do this by exposing this functionality through a service interface. For example, the ServiceAppModule
application module is exposed as a web service. This web service exposes the CustomersView
and OrdersView view instances, as shown in Figure 1-12. For more information, see Creating SOAP Web Services with Application Modules.
Figure 1-12 The ServiceAppModule Application Module as a Web Service
While you develop your application, you can iteratively test your business services using the Oracle ADF Model Tester. The tester allows you to test the queries, business logic, and validation of your business services without having to use or create a user interface or other client to test your services. Using the tester allows you to test out the latest queries or business rules you've added, and can save you time when you're trying to diagnose problems. For more information about developing and testing application modules, see Implementing Business Services with Application Modules.
The tester also interacts with the ADF Declarative Debugger to allow debug your business services. You can set breakpoints on any custom methods you create. For more information, see Using the Oracle ADF Model Tester for Testing and Debugging.
From the page flows you created during the planning stages, you can double-click the page icons to create the actual JSF files. When you create a JSF page for an ADF Faces application, by default, you create a Facelets XHTML file that uses the .jsf
extension. Facelets is a JSF-centric XML view definition technology that provides an alternative to using the JSP engine.
Tip:
While Facelet pages can use any well formed XML file, when you create a Facelet page in JDeveloper, it is created as an XHTML file.
ADF Faces provides a number of components that you can use to define the overall layout of the page. JDeveloper contains predefined quick start layouts that use these components to provide you with an efficient way to correctly determine the layout of your pages. You can choose from one-, two-, or three-column layouts, and then determine how you want the columns to behave. You can also choose to apply themes to the layouts, which adds color to some of the components for you. For more information see the "Using Quick Start Layouts" section of Developing Web User Interfaces with Oracle ADF Faces.
Oracle ADF also allows you to create and use your own page templates. When creating templates, you can determine the layout of the page (either using one of the quick layout templates or creating the layout manually), provide static content that must appear on all pages, and create placeholder attributes that can be replaced with valid values for each page. Each time the template is changed, for example if the layout changes, any page that uses the template will reflect the update.
The chapters in Creating a Databound Web User Interface provide information on creating different types of UI functionality, from basic forms to more complex search capabilities.
In a typical JSF application, you bind the UI component attributes to properties or methods on managed beans. The JSF runtime manages instantiating these beans on demand when any EL expression references them for the first time. However, in an application that uses ADF Model, JDeveloper automatically binds the UI component attributes to ADF Model, which uses XML configuration files that drive generic data binding features. It implements concepts that enable decoupling the user interface technology from the business service implementation: data controls and declarative bindings.
Data controls use XML configuration files to describe a service. At design time, visual tools like JDeveloper can leverage that metadata to allow you to declaratively bind UI components to any data control operation or data collection, creating bindings. For example, Figure 1-13 shows the BackOfficeAppModuleDataControl
data control as it appears in the Data Controls panel of JDeveloper.
Figure 1-13 BackOfficeAppModuleDataControl
Note that the collections that display in the panel represent the set of rows returned by the query in each view object instance contained in the BackOfficeAppModuleDataControl
application module. For example, the Countries
data collection in the Data Controls panel represents the Countries
view object instance in the BackOfficeAppModuleDataControl's
data model. The attributes available in each row of the respective data collections appear as child nodes. The data collection level Operations node contains the built-in operations that ADF Model supports on data collections, such as previous
, next
, first
, last
, and so on.
Note:
If you create other kinds of data controls for working with web services, XML data retrieved from a URL, JavaBeans, or EJBs, these would also appear in the Data Controls panel with an appropriate display. When you create one of these data controls in a project, JDeveloper creates metadata files that contain configuration information. These additional files do not need to be explicitly created when you are working with Oracle ADF application modules, because application modules are already metadata-driven components, and so contain all the information necessary to be exposed automatically as ADF Model data controls.
Using the Data Controls panel, you can drag and drop a data collection onto a page in the visual editor, and JDeveloper creates the necessary bindings for you. Figure 1-14 shows the Countries
collection being dragged from the Data Controls panel, and dropped as a form onto a JSF page.
Figure 1-14 Declaratively Creating a Form Using the Data Controls Panel
The first time you drop a databound component from the Data Controls panel on a page, JDeveloper creates an associated page definition file. This XML file describes the group of bindings supporting the UI components on a page. ADF Model uses this file at runtime to instantiate the page's bindings. These bindings are held in a request-scoped map called the binding container. Each time you add components to the page using the Data Controls panel, JDeveloper adds appropriate binding entries into this page definition file. Additionally, as you perform drag and drop data binding operations, JDeveloper creates the required tags representing the JSF UI components on the JSF page. For more information about using the Data Controls panel, see Using ADF Model in a Fusion Web Application.
Aside from forms and tables that display or update data, you can also create search forms, and databound charts and graphs. For more information about using data controls to create different types of pages, see the chapters contained in Creating a Databound Web User Interface . For more information about the Data Controls panel and how to use it to create any UI data bound component, see Using ADF Model in a Fusion Web Application. For detailed information about ADF Model, see About ADF Model in Developing Applications with Oracle ADF Data Controls.
You can add validation to your business objects declaratively using the overview editors for entity and view objects. In the case of entities, the business rules always reflect the data type constraints defined on the attributes.
Figure 1-15 shows the Business Rules page of the overview editor for the EmpEO
entity object.
Figure 1-15 Setting Validation in the Overview Editor
Along with providing the validation rules, you also set the error messages to display when validation fails. To supplement this declarative validation, you can also use Groovy-scripted expressions. For more information about creating validation at the service level, see Defining Validation and Business Rules Declaratively.
Additionally, ADF Faces input components have built-in validation capabilities. You set one or more validators on a component either by setting the required
attribute or by using the prebuilt ADF Faces validators. You can also create your own custom validators to suit your business needs. For more information, see the "Validating and Converting Input" chapter of Developing Web User Interfaces with Oracle ADF Faces.
You can create a custom error handler to report errors that occur during execution of an application. Once you create the error handler, you only need to register the handler in one of the application's configuration files.
Oracle ADF provides a security implementation that is based on Java Authentication and Authorization Service (JAAS). It enables applications to authenticate users and enforce authorization. The Oracle ADF implementation of JAAS is permission-based. You define these permissions and then grant them on application roles that you associate with users of the application. For more information about securing your application, see Enabling ADF Security in a Fusion Web Application.
Testing an Oracle ADF web application is similar to testing and debugging any other Java EE application. Most errors result from simple and easy-to-fix problems in the declarative information that the application defines or in the EL expressions that access the runtime objects of the page's ADF binding container. In many cases, examination of the declarative files and EL expressions resolve most problems.
For errors not caused by the declarative files or EL expressions, you can use the ADF Logger, which captures runtime trace messages from ADF Model API. The trace includes runtime messages that may help you to quickly identify the origin of an application error. You can also search the log output for specific errors.
JDeveloper also includes the ADF Declarative Debugger, a tool that allows you to set breakpoints on declarative aspects of Oracle ADF, such as the binding layer, taskflows and more. When a breakpoint is reached, the execution of the application is paused and you can examine the data that the ADF binding container has to work with, and compare it to what you expect the data to be. Testing and Debugging ADF Components contains useful information and tips on how to successfully debug a Fusion web application.
For testing purposes, JDeveloper provides integration with JUnit. You use a wizard to generate regression test cases. For more information, see Regression Testing with JUnit.
Using JDeveloper, you can easily rename or move the different components in your application. When you use JDeveloper to refactor the business components of your data model project, you can rename components or move them to a different package and JDeveloper will find and update all references to the refactored component. Whenever possible, you should use JDeveloper's refactoring actions to avoid error-prone manual editing of the project. For more information, see Refactoring a Fusion Web Application .
You can deploy a Fusion web application to either the integrated WebLogic server within JDeveloper or to a supported standalone instance. For more information about deployment, see Deploying Fusion Web Applications.
You can integrate your Fusion web application with any existing or new applications using service-oriented architecture (SOA) principals provided by Oracle SOA Suite. Oracle SOA Suite includes declarative development tools that allow you to easily integrate multiple applications using services, events, business rules, business process flows, and other SOA technologies.
You can build your Fusion web application so that it can easily integrate with other applications. You can publish your application modules as services. You can also create events that can be used for example, to initiate business processes. See Creating SOAP Web Services with Application Modules. Your application modules can also call other web services directly. See Calling a Web Service from an Application Module. You can also integrate your application using task flows. For example, a task flow can be used to initiate a business process flow.
For information about Oracle SOA Suite, see Introduction to Oracle SOA Suite in Developing SOA Applications with Oracle SOA Suite.
Working effectively in a team is crucial for application development. It requires effective communication, collaboration, and time management between the developers working on developing different parts of an ADF application.
Often, applications are built in a team development environment. While a team-based development process follows the development cycle outlined in Overview of Building an Application with Oracle ADF ,many times developers are creating the different parts of the application simultaneously. Working productively means team members divide the work, understand how to enforce standards, and manage source files with a source control system, in order to ensure efficient application development.
Before beginning development on any large application, a design phase is typically required to assess use cases, plan task flows and screens, and identify resources that can be shared.
The following list shows how the work for a typical Fusion web application might be broken up once an initial design is in place:
Infrastructure
An administrator creates Ant scripts (or other script files) for building and deploying the finished application. SQL scripts are developed to create the database schema used by the application.
Entity objects
In a large development environment, it may be that a separate development group builds all entity objects for the application. Because the rest of the application depends on these objects, entity objects should be one of the first steps completed in development of the application or part of the application.
Once the entity objects are finished, they can be shared with other teams using Oracle ADF libraries (see Packaging a Reusable ADF Component into an ADF Library for more information). The other teams then access the objects by adding to them to a catalog in the Resources window. In your own application development process, you may choose not to divide the work this way. In many applications, entity objects and view objects might be developed by the same team (or even one person) and would be stored within one project.
View objects
After the entity objects are created and provided either in a library or within the project itself, view objects can be created as needed to display data (in the case of building the UI) or supply service data objects (when data is needed by other applications in a SOA infrastructure).
During development, you may find that two or more view objects are providing the same functionality. In some cases, these view objects can be easily combined by altering the query in one of the objects so that it meets the needs of each developer's page or service. View criteria, in particular, enable developers to easily adapt a query to distinct usages.
Once the view objects are in place, you can create the application module, data controls, and add any needed custom methods. The process of creating view objects, reviewing for redundancy, and then adding them to the application module can be an iterative one.
User interface (UI) creation
With a UI design in place, the view objects in place and the data controls created, the UI can be built either by the team that created the view objects (as described in the previous bullet point) or by a separate team. You can also develop using a UI-first strategy, which would allow UI designers to create pages before the data controls are in place. Oracle ADF provides placeholder data controls that UI designers can use early in the development cycle. See Designing a Page Using Placeholder Data Controls .
Because numerous individuals divided into separate teams will be developing the application, you should enforce a number of standards before development begins to ensure that all components of the application will work together efficiently. The following are areas within an application where it is important to have standardization in place when working in a team environment:
Code layout style
So that more than one person can work efficiently in the code, it helps to follow specific code styles. JDeveloper allows you to choose how the built-in code editor behaves. While many of the settings affect how the user interacts with the code editor (such as display settings), others affect how the code is formatted. For example, you can select a code style that determines things like the placement of opening brackets and the size of indents. You can also import any existing code styles you may have, or you can create your own and export them for use by the team. For more information, see the "How to Set Preferences for the Source Editor" section in Developing Applications with Oracle JDeveloper.
Package naming conventions
You should determine not only how packages should be named, but also the granularity of how many and what kinds of objects will go into each package.
Pages
You can create templates to be used by all developers working on the UI, as described in Implementing the User Interface with JSF. This not only ensures that all pages will have the same look and feel, but also allows you to make a change in the template and have the change appear on all pages that use it. For more information, see Using Page Templates.
Aside from using templates, you should also devise a naming standard for pages. For example, you may want to have names reflect where the page is used in the application. To achieve this goal, you can create subdirectories to provide a further layer of organization.
Connection names: Unlike most JDeveloper and Oracle ADF objects that are created only once per project and by definition have the same name regardless of who sees or uses them, database connection names might be created by individual team members, even though they map to the same connection details. Naming discrepancies may cause unnecessary conflicts. Team members should agree in advance on common, case-sensitive connection names that should be used by every member of the team.
When working in a team environment, you will need to use a source control system. By default, JDeveloper provides support for the Subversion source control system, and others (such as CVS) are available through extensions. You can also create an extension that allows you to work with another system in JDeveloper. For information about using these systems within JDeveloper, see the "Versioning Applications with Source Control" chapter of Developing Applications with Oracle JDeveloper.
Following are suggestions for using source control with a Fusion web application:
Checking out files
Using JDeveloper, you can create a connection to the source control server and use the source control window to check out the source. When you work locally in the files, the pending changes window notifies you of any changed files. You can create a script using Apache Ant (which is integrated into JDeveloper). You can then use the script to build all application workspaces locally. This can ensure that the source files compile before you check the changed files into the source control repository. To find out how to use Apache Ant to create scripts, see the "Building with Apache Ant" section of Developing Applications with Oracle JDeveloper.
Automating builds
Consider running a continuous integration tool. Once files are checked into the source server, the tool can be used to recognize either that files have changed or to check for changed files at determined intervals. At that point, the tool can run an Ant script on the server that copies the full source (note that this should be a copy, and not a checkout), compiles those files, and if the compilation is successful, creates a zip file for consumers (not developers) of the application to use. The script should then clean up the source directory. Running a continuous integration tool will improve confidence in the quality of the code in the repository, encourage developers to update more often, and lead to smaller updates and fewer conflicts. Hudson (http://hudson-ci.org/
) is one example of a continuous integration tool.
Updating and committing files
When working with Subversion, updates and commits should be done at the Working Copy level, not on individual files. If you attempt to commit and update an individual file, there is a chance you will miss a supporting metadata file and thereby corrupt the committed copy of the application.
Resolving merge conflicts
When you add or remove business components in a data model project with ADF Business Components, JDeveloper reflects it in the project file (.jpr
). When you create (or refactor) a component into a new package, JDeveloper reflects that in the project file and in the ADF Business Components project configuration file (.jpx
). Although the XML format of these project control files has been optimized to reduce occurrences of merge conflicts, merge conflicts may still arise and you will need to resolve them in JDeveloper using the Resolve Conflicts option on the context menu of each affected file.
After resolving merge conflicts in any ADF Business Components XML component descriptor files, the project file (.jpr
) for a data model project, or the corresponding ADF Business Components project configuration file (.jpx
), close and reopen the project to ensure that you're working with latest version of the component definitions. To do this, select the project in the Applications window, choose File > Close from the JDeveloper main menu, and then expand the project again in the Applications window.
Oracle JHeadstart application generator is an additional extension for JDeveloper that offers additional productive advantage in creating web-based, JEE business applications. Using Oracle ADF’s built-in features, Oracle JHeadstart adds an additional capability to iteratively generate a fully-working web tier using ADF Faces as View layer and ADF Task Flows as Controller layer.
As you'll learn throughout the rest of this guide, JDeveloper and Oracle ADF give you a productive, visual environment for building richly functional, database-centric Java EE applications with a maximally declarative development experience. However, if you are used to working with tools like Oracle Designer that offer complete user interface generation based on a higher-level application structure definition, you may be looking for a similar facility for your Java EE development. If so, then the Oracle JHeadstart application generator may be of interest to you. It is an additional extension for JDeveloper that uses Oracle ADF's built-in features to offer complete web-tier generation for your application modules. Starting with the data model you've designed for your ADF business service, you use the integrated editors that JHeadstart adds to the JDeveloper environment to iteratively refine a higher-level application structure definition. These editors control the functionality and organization of the view objects' information in your generated web user interface. By checking boxes and choosing various options from dropdown lists, you describe a logical hierarchy of pages that can include multiple styles of search regions, list of values (LOVs) with validation, shuttle controls, nested tables, and other features. These declarative choices use terminology familiar to Oracle Forms and Designer users, further simplifying web development. Based on the application structure definition, you generate a complete web application that automatically implements the best practices described in this guide, easily leveraging the most sophisticated features that Oracle ADF and JSF have to offer.
Whenever you run the JHeadstart application generator, rather than generating code, it creates (or regenerates) all of the declarative view and controller layer artifacts of your Oracle ADF-based web application. These artifacts use ADF Model and work with your ADF application module as their business service. The generated files are the same kinds you produce when using the JDeveloper built-in visual editors. The key difference is that JHeadstart creates them in bulk, based on a higher-level definition that you can iteratively refine until the generated pages match your end users' requirements as closely as possible. The generated files include:
JSF pages with databound ADF Faces UI components
ADF Model page definition XML files describing each page's data bindings
JSF navigation rules to handle page flow
Resource files containing localizable UI strings
Once you've generated a maximal amount of your application's web user interface, you can spend your time using the productive environment of JDeveloper to tailor the results or to concentrate your effort on additional showcase pages that need special attention. Once you've modified a generated page, you can adjust a setting to avoid regenerating that page on subsequent runs of the application generator. Of course, since both the generated pages and your custom designed ones leverage the same ADF Faces UI components, all of your pages automatically inherit a consistent look and feel. For more information on how to get a fully functional trial of JHeadstart for evaluation, including details on pricing, support, and additional services, see the JHeadstart page on the Oracle Technology Network athttp://www.oracle.com/technetwork/developer-tools/jheadstart/ overview/index.html
To learn how to best use Oracle ADF in applications, you can take the help of many other resources in addition to the developers guide. Some of these resources are step-by-step tutorials, technical papers, pre-recorded sessions, books, trainings, certifications, and so forth.
In addition to this developers guide, Oracle also offers the following resources to help you learn how you can best use Oracle ADF in your applications:
Tutorials: JDeveloper cue cards provide step-by-step support for the application development process using Oracle ADF. They are designed to be used either with the included examples and a sample schema, or with your own data. The tutorials also include topics that provide more detailed background information, viewlets that demonstrate how to complete the steps in the card, and code samples. Tutorials provide a fast, easy way to become familiar with the basic features of Oracle ADF, and to work through a simple end-to-end task.
Technical papers, samples, and more on Oracle Technology Network, including ADF Insider, recorded sessions that will help you get up to speed with Oracle ADF.
Oracle Press and Packt Publishing offer a number of books on JDeveloper and Oracle ADF. See http://www.oracle.com/technetwork/developer-tools/adf/learnmore/index.html
Oracle University offers training and certification for Oracle ADF. See http://education.oracle.com
.
Other developer guides for supporting Oracle ADF technology: Oracle provides developer guides for data controls (other than for ADF Business Components), ADF Faces, and ADF Desktop Integration to name a few. For information about related guides, see Related Documents, in this book's Preface.