[Editor Update 4/22/2008: A new whitepaper from the Oracle Appliations Technology Group comparing OAF and ADF is now available. See this article for more details.]
[July 9, 2007 - see "One more thing to consider", below - Sara]
A question I've been getting recently is "Should I use OA Framework (OAF) or the Oracle Application Development Framework (ADF) to develop extensions to E-Business Suite (EBS) products? I know we are moving away from Oracle Forms, and I want to 'future-proof' my extensions as much as possible."
With all the buzz about Fusion (both the coming Fusion Applications and the current Fusion Middleware technology stack) and JDeveloper with ADF, it's hard not to get excited about using all the features of the latest versions of Fusion Middleware. So would we recommend using OAF or ADF?
My general advice is to stick with OAF so long as you are working with the E-Business Suite, and wait until you move to the Fusion Applications before moving to ADF. OAF is the development platform for the HTML EBS applications, so it makes sense to use the same development platform for custom extensions to the EBS applications. OAF provides you with automatic, seamless integration with the EBS applications in terms of EBS menus, security, look and feel, flexfields, personalization, attachments, and so on. These integrated EBS features aren't part of ADF.
Another part of the integrated OAF/EBS technology stack is Oracle Application Object Library (AOL), which provides many services to OAF, including security, messages, flexfields, and so on. Developers using OAF also use the OA Extension, which is a JDeveloper add-in bundled with JDeveloper in specific EBS development environment patches. OA Extension is an extension to JDeveloper 9.0.3 for EBS 11i, and to JDeveloper 10g (10.1.3) for EBS 12. AOL and OA Extension are not parts of the ADF technology stack for the Fusion Applications.
A terminology note: "ADF UIX" is the same UIX that is used by OAF as the HTML UI display component. Developers using OAF use ADF UIX indirectly by using OAF components. ADF UIX is not part of the "ADF" Fusion Applications technology stack that I am discussing here. "ADF Faces" is the UI component of the ADF technology stack.
Going It Alone
If you intend to build a completely standalone application that just happens to use the EBS tables, you can certainly use ADF, but you'd need to deal with things like security, look and feel, and so on yourself. You also wouldn't have the personalization, flexfields, attachments, or other infrastructure that OAF provides.
Using ADF to build integrated extensions to the E-Biz Suite is an untested combination, so you won't find much experienced help available if you take that path. Also, ADF isn't certified for use with E-Business Suite (EBS), and there are no plans for this certification. ADF is a standalone development tool and is expected to be a key part of the Fusion Applications platform. It's a very different technology stack from OAF, other than the business components. Business Components for Java (BC4J) becomes ADF Business Components (ADF BC).
Your Business Logic Moves Forward
Business logic that you create now with BC4J with the OAF technology stack will be transferable to the Fusion Applications technology stack later (possibly with minor changes). If you follow our OAF coding standards, build your pages declaratively as much as possible, and avoid putting much code into controllers if you can, you'll have a much easier time moving to Fusion later. All your business logic, validation, and so on should be in your BC4J objects.
Technology Directions
One further note: it's part of the general EBS Applications Technology and OAF direction (as part of Applications Unlimited), that we want to bring as much "Fusion technology" into the EBS applications as possible in our ongoing releases. So over time, the technology stack gap will likely get smaller, and customers will get to use some of the newer technology within the E-Biz Suite until they are ready to move to the Fusion Applications.
One example of this direction is that we now use JDeveloper 10g (10.1.3) for Release 12, instead of JDeveloper 9.0.3, which is used with Release 11.5.10. So customers can now take advantage of new JDeveloper 10g features such as a much better Java coding/editing environment. JDeveloper 10.1.3 can also dynamically recognize which files are in your path for a project. One of my correspondents thinks that feature alone is a good reason to use 10.1.3!
Happy extending!
[July 9, 2007 - One more thing to consider: how big is the project? If you are embarking on small extensions, a few pages here and there that you want to integrate into the existing applications, it's better to use the existing tool for that product line (EBS, Peoplesoft, etc.). If you are building entirely new, monolithic applications (large applications with many pages), where seamless integration with the current application pages isn't so important, you may want to use ADF (with ADF BC and ADF Faces). Then you won't need to convert your custom applications when you move to the Fusion Applications later.]
Related