Oracle Application Development Framework: Past, Present and Future
Oracle Application Development Framework is an extensive enterprise application framework deeply integrated into the Oracle Fusion Middleware stack. Its metadata-driven architecture and focus on the Oracle technology ecosystem set it apart.
- The full value of Oracle Application Development Framework (ADF) will remain tightly tied to Oracle Fusion Middleware (OFM) and the Oracle JDeveloper environment.
- Oracle will remain committed to ADF as its central framework over open-source alternatives.
- Oracle-centric IT organizations that heavily depend upon OFM will find value in investing in ADF as a key part of their Java technology portfolio.
- The use of ADF is a practical necessity when customizing Oracle Fusion Applications. Organizations deploying these applications should invest in ADF skills.
- Consider the combination of the JDeveloper integrated development environment (IDE) and ADF when deploying applications on OFM to maximize the synergy between the runtime stack and developer workbench.
- The use of ADF with Eclipse is becoming increasingly viable but do not expect integration between them to reach parity with JDeveloper. Consider this scenario when other factors strongly influence the use of Eclipse, and ADF usage is minor to moderate overall.
- IT organizations deploying Java applications on platforms other than the OFM stack should consider alternatives to ADF — primarily for cost rather than technical restrictions.
- ADF serves as a productivity wrapper that extends numerous standard Java blueprint design practices. IT organizations should plan for and invest in training efforts specific to this framework.
- Avoid ADF when seeking to sidestep long-term proprietary lock-in.
ADF is a comprehensive Java development framework based on a service-oriented architecture (SOA) and Model-View-Controller (MVC) design pattern. It supports multichannel applications that access a variety of data sources and business services, and includes both design-time and runtime features (see Figure 1).
Source: Oracle (June 2012)
ADF is architected as a four-layer framework:
- The business services layer encapsulates application business logic, provides access to services and data from external services (e.g., legacy systems and Web services), and handles data persistence (via Oracle's EclipseLink object request model).
- The model layer (ADF binding) creates abstractions over the business services layer, providing a decoupled and abstracted programming interface for a multichannel user interface (view and controller) channels.
- The controller layer provides control of the "flow" of the application user interface (UI). ADF supports a standard JavaServer Faces (JSF) controller, an extended ADF controller that adds advanced page flow and a legacy controller based on Apache Struts.
- The view layer supports multiple channels of application interfaces, including Web-based interfaces (ADF Faces), mobile, and desktop applications (Microsoft Excel) by insulating developers from changes and differences in underlying UI rendering technologies. To a potentially significant degree, we believe ADF's focus on an "adaptive view" layer will assist developers in future-proofing their application logic from unforeseen changes in UI requirements.
ADF's support for Oracle Metadata Services (MDS) is one of the key features that differentiate it from most competing frameworks. MDS is a customization and personalization engine/framework integrated across the OFM stack (in particular, across business processes, business intelligence, and application services). It allows users to rebrand, personalize, and customize the look and feel of OFM-based applications using XML (even at runtime) instead of requiring changes to underlying Java code.
MDS-enabled applications are made up from a base application and one or more customization layers that handle user-specific rebranding, personalization and customization tasks at runtime. This customization layer is defined by a set of metadata documents and a Java class that determines when to apply the changes. The metadata documents may be stored in a metadata store on the file system or the MDS database repository. Oracle MDS insulates users from a variety of look-and-feel related updates, localization, and patches; it is heavily used inside Oracle Fusion Applications but can also be leveraged by IT developers directly for their own custom application efforts.
Similar to its JDeveloper IDE, Oracle tightly synchronizes the release schedules for ADF with updates to its OFM software stack. The first release of the current (11g) version was in 2007 and has been followed by five updates, occurring about once per year. An additional release train typically branches and moves ahead of the OFM release and includes additional performance and defect patches, support for emerging Java APIs, etc. These parallel efforts give users dependent upon OFM a stable and tightly linked toolset, but also provide developers with an option for more frequent updates and newer features as well. These two release trains will merge at the next OFM update cycle and the pattern repeats for the next year.
Java developers have consistently rejected vendor attempts to introduce proprietary frameworks and libraries that extend or replace the core Java standards. These developers (overall) prefer technologies that extend the Java Development Kit (JDK) but also avoid long term vendor lock-in. As a result, open source frameworks and libraries such as Spring, Hibernate and others overwhelmingly dominate the Java framework market today. In fact, today only two vendors have had reasonable success introducing their own proprietary frameworks: SAP has its NetWeaver toolset and Oracle has ADF. The size of each vendor's native developer base is one reason for this success: they both have sufficiently large captive audiences that depend on their technology stacks, whether Java-based or not. But both vendors also have a valid technical need to adopt their own proprietary frameworks driven by their enterprise application suites. This differentiates them from IBM, for example, which does not have a unified enterprise application component.
Oracle depends on ADF rather than alternatives such as Spring mainly because it must maintain control over the foundational framework of its Oracle Fusion Applications — keeping the features of ADF closely tied to the demand of these applications and the releases tightly synchronized as well. ADF's support for MDS is one clear example of this synergy. Oracle Fusion Applications depends on MDS for customization efforts. Oracle builds its own applications upon ADF and enables its customers to build their own applications on this foundation as well.
ADF has a wide range of features. Most, if not all, could be realized by mixing and matching open source alternatives, typically starting with the open-source Spring framework. However, Gartner is unaware of any alternative that matches the feature-set functionality of ADF directly out of the box. The downside to this bundled approach is a proprietary lock-in to the OFM stack. It is currently not cost-effective to deploy ADF solutions to non-Oracle middleware. This may change in part for some elements of ADF, but overall the full value of ADF will remain tied tightly to the OFM stack and the JDeveloper environment.
Pairing ADF with JDeveloper realizes the competitive edge of JDeveloper over competing toolsets, such as Eclipse. As a result, Gartner estimates that at least 90% of JDeveloper programmers use it exclusively in conjunction with ADF. While there is no absolute requirement to use ADF with JDeveloper — it works well as a general-purpose Java development environment — in reality, the two are used hand-in-hand within most scenarios.
In addition to its JDeveloper environment, Oracle added support for some elements of ADF in the Oracle Enterprise Pack for Eclipse (OEPE). This integration focused on:
- Enabling and configuring ADF runtime services with Eclipse and Oracle's WebLogic Java Application Server
- Adding design time tools for ADF Faces
- Supporting ADF controller layer, ADF task flows and ADF life cycle debugger in the 12.1.1 release
This level of integration between Oracle ADF and Eclipse should be considered moderate. But we believe that Oracle customers will increasingly demand tighter integration between these tools. For example, the next release of ADF will add support for the ADF model layer and various types of data controls. We expect Oracle to continually expand its support for ADF within its OEPE over time. However, we do not expect the combination of ADF and Eclipse to rival the level of integration between ADF and JDeveloper because of technical compatibility issues and Oracle's product focus, among other reasons.
Oracle previewed a new version of ADF Mobile supporting on-device mobile applications at Oracle's 2011 OpenWorld conference. This version will provide native device services integration such as cameras and GPS, and it will support a combination of browser-based HTML, HTML installed on local devices, and native UI technologies. It will also integrate into Oracle security and identity management services within its OFM stack. We expect this release to be coordinated with the release of OFM 12c. When ADF Mobile ships, OFM will use the technology for mobile applications rather than implementing platform-specific native applications, as it currently does. We expect that ADF Mobile will initially support Apple's iOS, with other mobile platforms to follow.
Community Edition: Gartner believes Oracle will also release a "community edition" of some subset of ADF functionality. It is unknown whether this edition will be a fully open-sourced release or simply — and unlike ADF today — "free to use" on non-OFM infrastructures. We expect a number of features to be included in this release but the major focus will be on ADF Faces.
More Support for ADF in Eclipse: Given the growing popularity of ADF among its customers, Oracle recently expanded support for a number of ADF features beyond JDeveloper and into its OEPE toolset. While the largest segment of the ADF developer community will continue to use it in combination with JDeveloper, we expect a growing number of developers to use the framework with Eclipse in coming years as well — this will be particularly true if the ADF community edition gains popularity once released.
Since the introduction of OFM version 12c, Oracle has addressed many performance and quality issues associated with its tools and development frameworks. Today, most of the reports related to quality issues have disappeared, although we continue to get occasional reports of quality and stability issues. Overall, these complaints are minor and infrequent. Today, most Gartner client inquiry feedback is of a strong overall experience tempered with some uncertainty over the implications of long-term strategic commitment to a Java toolset from a single vendor. Among highly Oracle-centric IT organizations, this is of little consequence. Investments in Oracle's middleware or applications create a predisposition toward ADF in one way or another. While Oracle may expand support for its OFM stack in its other Java tools over time, Gartner believes the combination of JDeveloper and ADF will remain the sole toolset that fully embraces and supports these technologies.
Oracle is increasingly encouraging clients to adopt some modules of Oracle Fusion Applications under its augmentation strategy (see "Weighing the Decision to Become an Early Adopter of Oracle Fusion Applications"). As a result, interest in JDeveloper, together with ADF, has grown considerably among third-party technology providers. Gartner found that before the release of OFM version 11g, many external system integrators and consultants pushed clients away from both JDeveloper and ADF and toward tools and frameworks with which they were more accustomed (Eclipse, Spring, Hibernate, etc.).
In conclusion, we can summarize the strengths and challenges of Oracle's ADF as follows:
- Robust enterprise-class Java framework with support for advanced, metadata-driven application design
- Strong integration into Oracle's JDeveloper environment to optimize developer productivity
- Growing support for the industry-standard Eclipse environment to better support development organizations with mixed deployment environments
- In the past, ADF suffered from minor to moderate quality issues (e.g., frequent crashes). Most, but not all, of these issues have been addressed in more recent versions.
- By design, ADF is targeted at a specific niche (albeit a deep one) of development efforts focused around the OFM stack or its Oracle Fusion Applications. This should not be interpreted as a weakness but rather a natural limitation, especially for development organizations with mixed Java middleware investments (e.g., Tomcat, JBoss, Spring, Hibernate, etc.).
Oracle Fusion Applications is built upon a foundation of JDeveloper and ADF. Consequently, IT organizations leveraging Oracle Fusion Applications should consider the combination of JDeveloper and ADF to be a virtual necessity. This is particularly true for application customization efforts that go beyond the metadata layers of Oracle Fusion Applications. In these scenarios, we believe there are no practical alternatives to ADF.
Development organizations deploying general purpose enterprise Java applications on Oracle's Fusion middleware suite will find ADF's deep integration with this suite to be a significant advantage. This is particularly true among applications that rely on elements of the stack that go beyond the core WebLogic server. Most notably, development efforts leveraging a combination of JDeveloper, ADF, and OFM will yield measurably higher developer productivity rates than alternative Java technologies.
Given its strong focus on the Oracle technology stack, IT leaders seeking to avoid long-term proprietary lock-in should look to other solutions in more generic Java Enterprise Edition (JEE) development efforts.
ADF competes well against the features and functionality of alternative frameworks but, when leveraged within projects strictly targeting the core Java-standard APIs, its unique value is significantly diminished. In such situations, IT leaders should prefer vendor-independent, open-source solutions.