It’s been a while since the last installment of ADF BC Tuning, but it’s time to start it up again. I’ve already posted tips for tuning entity objects, associations, view objects (in three parts), and view links, so now, let’s turn our attention to the last of the major business components: application modules.
Last week, I introduced the ADF development methodology I’m proposing, “Extreme Reusability,” articulated its goals, and discussed the techniques of “Generalize, Push up, and Customize” and “Think Globally, Deploy Locally” that are critical to the methodology. I didn’t, however, describe the actual…well, methodology, meaning the development cycle prescribed by Extreme Reusability.
Notice I didn’t say the application development lifecycle. That’s because developing under Extreme Reusability, like developing under SOA, isn’t primarily about the creation of standalone applications. You should think of the development cycle for extreme reusability as part of an enterprise-wide effort.
Development under Extreme Reusability involves developing along three separate but interacting (and communicating–communication is absolutely vital under this system) tracks: framework development, service development, and application development. These tracks are assigned to different individuals on the team, in (at a guess–remember this is a proposed methodology) somewhere around a 20-60-20 division for a typical organization’s needs.
As promised, I’m posting of the presentation I’d been hoping to give at the OOW Unconference Methodology Symposium last week, expanded slightly for the more forgiving medium of a blog. As it turns out, it’s expanded substantially more than I thought, so I’m going to divide it into two parts. This week, I’ll talk about the basics of the methodology, its goals, and the two techniques it relies heavily upon. Next week, I’ll talk about the actual development process it specifies.
“Extreme Reusability” (the name is not mine, but rather Chris Muir’s; however, I decided I like it) is an idea for an ADF development methodology for mid-sized teams (generally around 4-20 developers) that I’ve been recently expanding on. Continue reading Extreme Reusability, Part I
In my very first post on this blog, I talked about service-oriented architecture (SOA), and how, while I thought it was extremely appropriate for a certain range of cases, the overhead involved in web service invocation made it very inappropriate for an equally wide, if not wider, range of cases.
Today, I want to talk a bit about an ADF 11g alternative to SOA that still gives you many of its benefits without the web service invocation overhead: reusable applications. (Next week, I’ll talk about another SOA-in-spirit mechanism that ADF 11g provides: Shared application module instances.) Continue reading SOA Without the S, Part I: Reusable Applications