Picking up a new tool like JDeveloper and its Application Development Framework including ADF Business Components and ADF Faces can provide interesting and exciting times for developers. New technologies offer new opportunities, especially the chance to have a good old play with something cool. Java programming, yes! JavaServer Faces, you bet! AJAX web components, yeehaw! But in developing with a new tool it's too easy to become focused on the tool itself and ignore the greater picture of how the technology will fit in.
Duncan Mills & Peter Koletzke have an excellent book
Oracle JDeveloper 10g for Forms and PL/SQL Developers that considers the design & development methods that you may wish to follow when designing a JDeveloper application for the first time. Their recommendations come from experience and provide a good step ahead on implementing a successful new project.
From my own experience I'd like to suggest that IT organisations moving from a traditional Oracle Forms background or elsewhere, looking to go 100% JDeveloper need to expose themselves to the following concerns that aren't necessarily obvious and documented:
LDAP based security including OID - Java Enterprise Edition (JEE or what was J2EE) applications through their use of the Java JAZN/JAAS security facilities lean themselves heavily to introducing LDAP based security servers into your organisation rather than relying on database security, including JDeveloper's ADF. Software engineering suggests development should consider security as early as possible in the design cycle. JDev developers should consider a POC project to get a flavour of how security works itself into JDeveloper's ADF framework. Your DBAs need to get OID or whatever LDAP server up and running in a dev, test and prod environment to understand the complexities, as well as dictating how they want to standardise the setup of LDAP users and roles/groups and pass this onto the developers. Such thoughts don't want to be retrofitted late into the system development.
File version control system such as CVS or Subversion - a number of sites, particular Oracle Forms sites run with antiquated file version control systems (or none at all!) such as PVCS, RCS, or older MS-Visual SourceSafe versions. The Java world prefers change control systems such as CVS or SVN (Subversion) and this is true of JDev. Plug-ins for other version control systems are available but these are provided by 3rd parties, while the CVS/Subversion support is in the core product. A backed up CVS or Subversion code repository is essential, but luckily the software is also free.
CVS and SVN utilise a lazy locking model, allowing 2 developers to change the same file at the same time. The rude shock is that the developers may be required to merge their code changes on check-in unlike other hard-locking 1-developer-can-change-only systems. JDev application development can certainly be structured to avoid this to a degree, but for developers this understanding generally comes through experience rather than best practices. This problem is exasperated by the fact that new developers will build JDev applications in isolation for the first time and a little knowledge can be a dangerous thing. Later programmers code together based on a CVS/SVN code repository, are changing files here-there-and-everywhere, and suddenly a huge mess of code requiring merging exists. Wouldn't you rather avoid this with a little experimenting early on?
OC4J - a deployed ADF application will run within Oracle's OC4J container, a JEE compliant application server buried within OAS. OC4J is a sophisticated product and rightly so as it's designed to serve a scalable amount of users. On its first install it runs with default settings that prove satisfactory for your applications, but not for production purposes. Somebody needs to understand its facilities, how to configure it, what logging is required, its shareable library infrastructure (10.1.3+), failover support, load balancing support -- etc -- I said it's a sophisticated tool didn't I? A number of sites have come to grief by leaving their setup and understanding of OAS and OC4J till user acceptance testing and production deployments. There's nothing like a failing server to make your new system look poor.
Maybe the database isn't the best place for absolutely everything - a number of sites demand if they used to store absolutely everything in the database about their application, such as multilingual field names, application menu logic, user interface security rules, then the new tool should do it too. Now I'm not arguing this isn't an amicable goal and the database is the best place for data processing, but are you creating a mountain out of a mole hill for your initial development requirements? Remember picking up any tool is a difficult task, so don't make it harder than you need to straight away, otherwise your project is going to fail (read: KISS). Consider how the new tool wants to do things by default and maybe just maybe bend a little. Give consideration that tools' architects might have had bigger issues in mind than what you've considered -- so do some research why they want you to do certain things that way. Later when you're experts and you think you know better, feel free to rewrite everything to your needs. Maybe even send the original tool architects a nasty email.
Check out the wider JSF community - not really a concern but just some general advice. Oracle's ADF Faces is based on JavaServer Faces. Oracle is not the only JSF vendor out there. Take time to look further a field to understand what the rest of the community is working on. You may be pleasantly surprised to discover that the "why did Oracle do this?" will become an "ahhhhh" moment, or an "Oracle hasn't provided any examples" to an "Oracle didn't provide any examples because Sun documented it sufficiently already".
The implementation of a JDev system will certainly provide interesting times for any organisation. A bit of expended time working outside the JDev box will ensure you're not stuck in the box having no idea where to turn when project crunch time comes to the fore.
Happy JDeveloper-ing!
Mid July I'll be driving the 3430kms from Melbourne to Perth for, well, um, I'm not sure, but it'll be an interesting drive across the Nullarbor. The drive across from east to west is seen as a bit of right of passage for Australians, only being bettered by driving around the whole country.