|
Oracle® Application Development Framework Developer's Guide
10g Release 3 (10.1.3) B25386-01 |
|
 Previous |
 Next |
|
Oracle® Application Development Framework Developer's Guide
10g Release 3 (10.1.3) B25386-01 |
|
|
Previous |
Next |
The Oracle Application Development Framework (Oracle ADF) is an end-to-end application framework that builds on J2EE standards and open-source technologies to simplify and accelerate implementing service-oriented applications. If you develop enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces, Oracle ADF can simplify your job. Used in tandem, Oracle JDeveloper 10g 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.
In line with community best practices, applications you build using Oracle ADF achieve a clean separation of concerns by adhering to a model, view, controller architecture. Figure 1-1 illustrates where each ADF module fits in this architecture. The core module in the framework is Oracle ADF Model, a declarative data binding facility that implements the JSR-227 specification. The Oracle ADF Model layer enables a unified approach to bind any user interface to any business service with no code. The other modules Oracle ADF comprises are:
Oracle ADF Controller integrates Struts and JSF with Oracle ADF Model
Oracle ADF Faces offers a library of components for web applications built with JSF
Oracle ADF Swing extends Oracle ADF Model to desktop applications built with Swing
Oracle ADF Business Components simplifies building business services for developers familiar with 4GL tools like Oracle Forms.
In the view layer of your application, where you design the web user interface, you can develop using either classic JavaServer Pages (JSP) or the latest JavaServer Faces (JSF) standard. Alternatively, you can choose the polish and interactivity of a desktop UI, and develop using any off-the-shelf Swing components or libraries to ensure just the look and feel you need. Whatever your choice, you work with WYSIWYG visual designers and drag-and-drop data binding. One compelling reason to choose JSF is the comprehensive library of nearly one hundred JSF components that the ADF Faces module provides.
ADF Faces components include sophisticated features like look and feel "skinning" and the ability to incrementally update only the bits of the page that have changed using the latest AJAX programming techniques. The component library supports multiple JSF render kits to allow targeting users with web browsers and roaming users with PDA telnet devices. In short, these components dramatically simplify building highly attractive and functional web and wireless UIs without getting your hands "dirty" with HTML and JavaScript.
In the controller layer, where handling page flow of your web applications is a key concern, Oracle ADF integrates both with the popular Apache Struts framework and the built-in page navigation functionality included in JSF. In either case, JDeveloper offers visual page flow diagrammers to design your page flow, and the ADF Controller module provides appropriate plug-ins to integrate the ADF Model data binding facility with the controller layer's page processing lifecycle.
In the model layer, Oracle ADF Model implements the JSR-227 service abstraction called the data control and provides out-of-box data control implementations for the most common business service technologies. Whichever ones you employ, JDeveloper and Oracle ADF work together to provide you a declarative, drag-and-drop data binding experience as you build your user interfaces. Supported technologies include:
Enterprise JavaBeans (EJB) Session Beans
Since most J2EE applications require transactional services, EJB session beans are a logical choice because they offer declarative transaction control. Behind the EJB session bean facade for your business service, you use plain old Java objects (POJOs) or EJB entity beans to represent your business domain objects. JDeveloper offers integrated support for creating EJB session beans, generating initial session facade implementations, and creating either Java classes or entity beans. You can also use Oracle TopLink in JDeveloper to configure the object/relational mapping of these classes.
JavaBeans
You can easily work with any Java-based service classes as well, including the ability to leverage Oracle TopLink mapping if needed.
Web Services
When the services your application requires expose standard web services interfaces, just supply Oracle ADF with the URL to the relevant Web Services Description Language (WSDL) for the service endpoints and begin building user interfaces that interact with them and present their results.
XML
If your application needs to interact with XML or comma-separated values (CSV) data that is not exposed as a web service, this is easy to accomplish, too. Just supply the provider URL and optional parameters and you can begin to work with the data.
ADF Application Modules
These service classes are a feature of the ADF Business Components module, and expose an updateable dataset of SQL query results with automatic business rules enforcement.
The remainder of this guide focuses attention on using Oracle ADF with the technologies Oracle recommends to J2EE developers building new web applications: JavaServer Faces for the view and controller layers, and the combination of an EJB session bean with mapped Java classes for the business service implementation. However, this chapter begins with a very simple Oracle ADF application built with these technologies to acquaint you with typical development process.
|
Note: If you are a developer coming to J2EE development with experience in 4GL tools like Oracle Forms, Oracle Designer, Visual Basic, PowerBuilder, and so on, Oracle recommends that you take advantage of the additional declarative development features offered by the Oracle ADF Business Components module. Oracle ADF Developer's Guide for Forms/4GL Developers covers using Oracle ADF with additional framework functionality in the business services tier using this module. You can access the developer's guide for Forms/4GL developers fromhttp://www.oracle.com/technology/documentation/jdev/B25947_01/index.html.
|
For seasoned Java developers, choosing to develop declaratively instead of coding admittedly takes some getting used to. However, most developers will acknowledge a true time-saver, and they are also likely to have some exposure to declarative techniques through their experience with frameworks like Spring or Apache Struts and tag libraries like the JSP Standard Tag Library (JSTL). JavaServer Faces incorporates similar declarative functionality and Oracle ADF complements it by adding declarative data binding to the mix.
Using the Spring Framework, developers configure the instantiation of JavaBeans through a beans XML file, declaratively specifying dependencies between them. At runtime, generic framework code reads the XML file, instantiates the beans as directed, and resolves the dependencies between beans. This design pattern is commonly known as dependency injection, and Spring provides a declaratively configured way to leverage its generic implementation to set up your application's beans.
Using the Struts struts-config.xml file, developers configure the mapping of HTTP requests to action handler classes and other page flow information. At runtime, the generic Struts front-controller servlet uses the information contained in the configuration XML file to route the requests as directed. When you use Struts, you leave the request routing to the declaratively configured Struts infrastructure, and concentrate on writing the interesting code that will handle particular requests.
Using the JSTL tag library, developers indicate the model data to iterate over and present on the page using declarative expressions, as shown in this snippet:
<c:when test="${not empty UserList}">
<c:forEach var="user" items="${UserList.selectedUsers}">
<tr>
<td><c:out value="${user.name}"/></td>
<td><c:out value="${user.email}"/>
</tr>
</c:forEach>
</c:when>
Rather than resorting to an unmaintainable mix of Java scriptlet code and tags in their page, developers embed expressions like ${not empty UserList}, ${UserList.selectedUsers}, and ${user.name} into tag attributes. At runtime a generic expression evaluator returns the boolean-, List- and String-valued results, respectively, performing work to access beans and their properties without writing code. This same declarative expression language, nicknamed "EL," that originally debuted as part of the JSTL tag library has been improved and incorporated into the current versions of the JSP and JSF standards.
JavaServer Faces simplifies building web user interfaces by introducing web UI components that have attributes, events, and a consistent runtime API. Instead of wading knee-high through tags and script, you assemble web pages from libraries of off-the-shelf, data-aware components that adhere to the JSF standard. As part of fulfilling their mission to simplify web application building, the industry experts who collaborated to design the JavaServer Faces standard incorporated numerous declarative development techniques. In fact, JSF supports all three of the facilities discussed above: instantiation and dependency injection for beans, page request handling and page navigation, and use of the standard expression language.
At runtime, the value of a JSF component is determined by its value attribute. While a component can have static text as its value, typically the value attribute will contain an EL expression that the runtime infrastructure evaluates to determine what data to display. For example, an outputText component that displays the name of the currently logged-in user might have its value attribute set to the expression #{UserInfo.name} to accomplish this. Since any attribute of a component can be assigned a value using an EL expression, it's easy to build dynamic, data-driven user interfaces. For example, you could hide a component when a collection of beans you need to display is empty by setting the component's rendered attribute to a boolean-valued EL expression like #{not empty UserList.selectedUsers}. If the list of selected users in the bean named UserList is empty, then the rendered attribute evaluates to false and the component disappears from the page.
To simplify maintenance of controller-layer application logic, JSF offers a declarative bean creation mechanism similar to the Spring Framework. To use it, you configure your beans in the JSF faces-config.xml file. They are known as "managed beans" since the JSF runtime manages instantiating them on demand when any EL expression references them for the first time. JSF also offers a declarative dependency injection feature. Managed beans can have managed properties whose runtime value is assigned by the JSF runtime based on a developer-supplied EL expression. Managed properties can depend on other beans that, in turn, also have managed properties of their own, and the JSF runtime will guarantee that the "tree" of related beans is created in the proper order.
As illustrated in Figure 1-2, JSF managed beans serve two primary roles.
Request-scoped managed beans that are tightly related to a given page are known colloquially as "backing" beans, since they support the page at runtime with properties and methods. The relationship between a UI component in the page and the backing bean properties and methods is established by EL expressions in appropriate attributes of the component like:
value="#{expr}"
References a property with data to display or modify
action="#{expr}"
References a method to handle events
binding="#{expr}"
References a property holding a corresponding instance of the UI component that you need to manipulate programmatically — show/hide, change color, and so on.
Think of managed beans that aren't playing the role of a page's backing bean simply as "application logic beans." They contain code and properties that are not specific to a single page. While not restricted to this purpose, they sometimes function as business service wrappers to cache method results in the controller layer beyond a single request and to centralize pre- or post-processing of business service methods that might be used from multiple pages.
In addition to using managed beans, you can also write application code in a so-called PhaseListener class to augment any of the standard processing phases involved in handling a request for a JSF page. These standard steps that the JSF runtime goes through for each page are known as the "lifecycle" of the page. Most real-world JSF applications will end up customizing the lifecyle by implementing a custom phase listener of some kind, typically in order to perform tasks like preparing model data for rendering when a page initially displays, among other things.
The Oracle ADF Model layer follows the same declarative patterns as other J2EE technologies, by using XML configuration files to drive generic framework facilities. The only interesting difference is that ADF Model focuses on adding value in the data binding layer. It implements the two concepts in JSR-227 that enable decoupling the user interface technology from the business service implementation: data controls and declarative bindings.
Data controls abstract the implementation technology of a business service by using standard metadata interfaces to describe its public interface. This includes information about the properties, methods, and types involved. At design time, visual tools leverage the service metadata to let you bind your UI components declaratively to any public member of a data control. At runtime, the generic Oracle ADF Model layer reads the information describing your data controls and bindings from appropriate XML files and implements the two-way "wiring" that connects your user interface to your service. This combination enables three key benefits:
You write less code, so there are fewer lines to test and debug.
You work the same way with any UI and business service technologies.
You gain useful runtime features that you don't have to code yourself.
There are three basic kinds of binding objects that automate the key aspects of data binding that all enterprise applications require:
Action bindings invoke business service methods to perform a task or retrieve data.
Iterator bindings keep track of the current row in a data collection.
Attribute bindings connect UI components to attributes in a data collection.
Typically UI components like hyperlinks or buttons use action bindings. This allows the user to click on the component to invoke a business service without code. UI components that display data use attribute bindings. Iterator bindings simplify building user interfaces that allow scrolling and paging through collections of data and drilling-down from summary to detail information.
The group of bindings supporting the UI components on a page are described in a page-specific XML file called the page definition file. Generic bean factories provided by ADF Model use this file at runtime to instantiate the page's bindings. These bindings are held in a request-scoped Map called the binding container accessible during each page request using the EL expression #{bindings}. This expression always evaluates to the binding container for the current page. Figure 1-3 shows how EL value binding expressions relate the UI components in a page to the binding objects in the binding container.
Figure 1-4 illustrates the architecture of a JSF application when leveraging ADF Model for declarative data binding. When you combine Oracle ADF Model with JavaServer Faces, it saves you from having to write a lot of the typical managed bean code that would be required for real-world applications. In fact, many pages you build won't require a "backing bean" at all, unless you perform programmatic controller logic that can't be handled by a built-in action or service method invocation (which ADF Model can do without code for you). You can also do away with any application logic beans that wrap your business service, since the ADF Model's data control implements this functionality for you. And finally, you can often avoid the need to write any custom JSF phase listeners because ADF Model offers a generic JSF phase listener that performs most of the common operations you need in a declarative way based on information in your page definition metadata.
With the fundamentals of ADF Model data binding for JSF applications described, it's time to describe the full breadth of added-value functionality that ADF Model brings to the table. The following sections give an overview of the key functional areas that further improve your development productivity.
JDeveloper's comprehensive desig- time support for ADF Model declarative data binding includes:
Quickly create a data control for EJB session beans, Java service classes, web services, XML or CSV data from a URL, and ADF application modules. When additional information is required, helpful wizards guide you step by step.
Visualize all business services that you have exposed as data controls and drag service properties, methods, method parameters, and method results to create appropriate bound user interface elements. Easily create read-only and editable forms, tables, master/detail displays, and individual bound UI components including single and multiselect lists, checkboxes, radio groups, and so on. Creating search forms, data creation pages, and parameter forms for invoking methods is just as easy. If your process involves collaboration with page designers in another team, you can drop attributes onto existing components in the page to bind them after the fact. In addition to the UI components created, appropriate declarative bindings are created and configured for you in the page definition file with robust undo support so you can experiment or evolve your user interface with confidence that your bindings and UI components will stay in sync.
Visualize page definition metadata in the Structure window and configure declarative binding properties using the appropriate editor or the Property Inspector. Create new bindings by inserting them into the structure where desired.
Edit binding metadata with context-sensitive, XML schema-driven assistance on the structure and valid values. Visualize page definition metadata in the Structure window and configure declarative binding properties using the appropriate editor or the Property Inspector.
The JSF reference implementation provides a bare-bones set of basic UI components that includes basic HTML input field types and a simple table display, but these won't take you very far when building real-world applications. The ADF Model layer implements several features that work hand-in-hand with the more sophisticated UI components in the Oracle ADF Faces library to make quick work of the rich functionality your end users crave, including:
More Sophisticated Table Model
Tables are a critical element of enterprise application UIs. By default, JSF doesn't support paging or sorting in tables. The ADF Faces table and the ADF Model table binding cooperate to display pageable, editable or read-only, tables with sorting on any column.
Key-Based Current Selection Tracking
One of the most common tasks of web user interfaces is presenting lists of information and allowing the user to scroll through them or to select one or more entries in the list. The ADF Model iterator binding simplifies tracking the selected row in a robust way, using row keys instead of relying on positional indicators that can change when data is refreshed and positions have changed. In concert with the ADF Faces table and multiselection components, it's easy to work with single or multiple selections, and build screens that navigate master/detail information.
Declarative Hierarchical Tree Components and Grids
Much of the information in enterprise applications is hierarchical, but JSF doesn't support displaying or manipulating hierarchical data out of the box. The ADF Model layer provides hierarchical bindings that you can configure declaratively and use with the ADF Faces tree or hierarchical grid components to implement interactive user interfaces that present data in the most intuitive way to your users.
More Flexible Models for Common UI Components
Even simple components like the checkbox can be improved upon. By default, JSF supports binding a checkbox only to boolean properties. ADF Model adds the ability to map the checkbox to any combination of true or valid values your data may present. List components are another area where ADF Model excels. The valid values for the list can come from any data collection in a data control and the list can perform updates or be used for row navigation, depending on your needs. The ADF Model list binding also makes null-handling easy by optionally adding a translatable "<No Selection>" choice to the list.
ADF Model can improve the reuse of several aspects of application functionality by allowing you to associate layered metadata with the data control structure definitions that can be reused by any page presenting their information. Examples of functionality that ADF Model allows you to reuse includes:
Translatable Prompts, Tooltips, and Format Masks
JSF supports a simple mechanism to reference translatable strings in resource bundles, but it has no knowledge about what the strings are used for and no way to associate the strings with specific business domain objects. With ADF Model, you can associate translatable prompts, tooltips, and format masks with any attribute of any data type used in the data control service interface so that the attribute's data is presented in a consistent, locale-sensitive way on every page where it appears.
Declarative Validation
JSF supports validators that can be associated with a UI component; however, it offers no mechanism to simplify validating the same business domain data in a consistent way on every screen where it's used. With ADF Model, you can associate an extensible set of validator objects with the data control structure definition metadata so that the validations will be enforced consistently, regardless of which page the user employs to enter or modify the object's data.
Declarative Security
JSF has no mechanism for integrating authorization information with UI components. With ADF Model, you can associate user or role authorization information with each attribute in the data control structure definition metadata so that pages can display the information consistently only to users authorized to see it.
JSF rigorously defines the page processing lifecycle, but for some very common tasks it requires you to write code in your own phase listener to implement it. What's more, until a future version of the JSF specification, phase listeners are global in nature, requiring you to write conditional code based on the current page's name when the functionality applies only to a specific page. The ADF Model and ADF Controller layers cooperate to simplify per-page control over the most common things you would typically code in a custom phase listener, including:
Declarative Method Invocation
Configure business service method invocations with EL expression-based parameter passing, and bind to method results with options to cache results until method parameters change to avoid unnecessary requerying of data. You can have methods invoked by the press of a command component like a link or button, or configure your page definition to automatically invoke the method at an appropriate phase of the JSF lifecycle
Declarative Page Lifecycle Control
Declaratively configure an iterator binding to refresh its data during a specific JSF lifecycle phase, and optionally provide a conditional EL expression for finer control over when that refresh is desired. You have the same control over when any automatic method invocation should invoke its method as well.
Centralized Error Reporting
Customize the error reporting approach for your application in a single point instead of on each page.
