Already a member?
Sign in
ADF Methodology - Work in Progress
This page outlines the current ADF Methodology as a Work in Progress. Feel free to add to, modify and restructure this page with appropriate content within the guidelines of the the previous page.
As an initial brainstorm, the points below show some example issues and concepts that maybe appropriate to capture in the ADF methodology as material to assist future discussions:
Project planning & estimates
As an initial brainstorm, the points below show some example issues and concepts that maybe appropriate to capture in the ADF methodology as material to assist future discussions:
ADF pre-project adoption decision points
There are many common questions being asked all around the world about adopting ADF and JDeveloper. This section aims to capture the common questions that organisations should be asking without diving in blindly to ADF, as well as answers, or links to Internet material that considers the same issues.
Examples:
- Are open source frameworks required or are proprietary frameworks okay? (eg. ORM: Hibernate vs ADF BC, UI: MyFaces vs ADF Faces RC)
- Does the end solution require a rich desktop application, a standard web application or a rich internet application? (eg. ADF Swing vs ADF Faces RC, see for example Swing or JavaServer Faces)
-
- Skills fit of existing staff to ADF (ie. Java programmers, or PL/SQL programmers)
- Training costs?
For the remainder of the methodology ADF BC and ADF Faces RC have been selected as the technologies of choice, and the following sections only consider these.
Actual content:
- How to convince others to adopt ADF & JDeveloper
- If ADF is adopted, why and when should I pick ADF BC, Toplink, JPA or EJB's for the ORM?
-
- ADF Business Components
- ADF BC is particular suited to ex-Oracle Forms and PL/SQL programmers
- It was written with these skill sets in mind
- Structures are relationally organised, with components that map to "Tables", "Columns" and based on standard SQL to interact with the database.
- Toplink
- tba
- (CM note: ...suited to Java programmers ...?)
- JPA
- tba
- (CM note: ...suited to Java programmers ...?)
- (CM note:... this is essentially EJB 3 isn't it.... I forget....?)
- (CM note:.... where does EclipseLink fit into this?)
- EJB
- tba
- (CM note: I assume this implies older EJB choices separate to JPA....?)
- ADF Business Components
Technical system requirements
Consideration of the end technical and architectual solution. For instance one organisation may only need to support 5 users, while another 1000 users, which will require different application server architectures. Alternatively organisations may already be using MS-Active Directory for LDAP security which requires the site to think about different intergration choices from another site that uses Oracle's OID.
Examples:
- What browsers and versions must be supported?
- What level of availability does the system require? (eg. 24/7, 99.9%, or scheduled downtime is okay?)
- Which JEE application server technology and version? (eg. OAS, Weblogic, Tomcat etc)
- What level of scalability does the system require? (eg. 100 concurrent users, 500, 1000s etc)
- What type of security infrastructure is expected or must be integrated? (eg. LDAP, SSO, MS-Active Directory, Database)
- Which file version control system to use? (eg. CVS, Subversion)
User focused system requirements
Inclusive of software engineering system requirement gathering (that we all should be doing?!), as well as other user focused requirements, beyond the technical.
Examples:
- Which software engineeering methodologies fit well to ADF development (eg. Agile, Waterfall, I'll do it later etc)
- Does your system require accessibility support (eg. people with visual impairments)?
- How to design adf application adhering to AnySufer?
- Which language, or is multilingual support required?
- Are all system-defined labels (af:table multiselect en pagination), error-handling, etc. customizable?
Project planning & estimates
What, who, where, when must be considered in the project plan? Have you allocated time to create ADF Skins and Templates and organised a review with the users? Is there time in the project to test the application server load testing? Who is going to setup the version control systems?
Examples:
- Definition of naming conventions and packaging for as well modelling as view layer (what are watch-outs)?
- Who will setup database environments dev/test/prod and administer?
- Who is in charge of LDAP, SSO, OAS, etc?
- How should business rules be implemented (business rules engine? triggers? BC? faces validators?)
- How many application server environments will be needed and who will administer?
- Who will do builds and how will the build process be implemented (or automated, continuous integration)?
- How many screens to be created? How many ADF BC components? How many of these already exist in reusable format?
- What templating mechanism to use, and how to define reusable page components (header, footer, navigation bar, ...)?
- How to define and manage security, what are the options and what’s best practice?
- How to install and configure ADF applications using SSO. What are the pitfalls and best practices?
- How to enable automatic deployment through release management processes?
- How to integrate ADF applications with existing User Management Artifacts, such as Access Control Management System (Sun iPlanet LDAP) ?
Design
Given the users' requirements, what's the best approach to designing screens, data models etc?
Examples:
- Storyboarding
- User workshops and screen scraping
- Which data modelling capabilitie's does Jdeveloper have to offer and plug-ins for SQLDeveloper, when to use what.
- How to integrate existing applications and which design rules need to be decided out, e.g. security propagation, parameter passing, lifecycle handling, ...
- What's available out-of-the-box (validation framework, event handling, data binding, error handling, transaction handling) when using a specific technology, e.g; JSF or ADF Faces, ADF Security, ...
- Decompose design into identified reusable components for ADF, including ADF BC entity objects, view objects, domains, and ADF Faces RC declarative components, and page fragments.
Development
What are best practices for development, what will need to be created?
Example best practices questions:
- Define ADF BC package structures/naming conventions
- Define JSF packages structures/naming conventions + directory structures
- How to structure the application - 1 apps vs many apps + how many projects?
- Deliverables besides software (eg. documentation, screen flows, ER models)
- JSF backing beans: to inject the binding container, use ADFUtils or JSFUtils, or annotations (as per Simon Lessard's detailed discussion)
- How to define connection pooling on AM-level and container level (weblogic, oc4j)?
- Where to put the business logic, pl/sql, BC4J domain validation, BC4J impl-classes?
- Is there a need to override the existing validation framework, what are the boundaries of the ADF Framework concerning validation?
- What can and can’t be refactored when using BC4J and ADF, pageDefinition-files, implementation files, watch-outs.
Examples of standard development steps:
- Create custom ADF BC framework
- Create sub-top-level ADF BC framework objects (e.g., "StoredProcedureViewObjectImpl")
- Create reusable ADF BC entity objects
- Create reusable ADF BC view objects (eg. lookups)
- Create reusable ADF BC domains
- Create reusable ADF BC validation rules + customizers
- Create reusable ADF BC application modules (e.g., nestable app modules for common tasks)
- Define application look and feel through ADF Faces RC Templates and Skins
- Create custom ADF Faces-friendly utilities (e.g., utilities for working with EL)
- Create custom ADF Faces framework (e.g., error handling, lifecycle modifications)
- Create reusable ADF Faces RC declarative components
- Create reusable bounded task flows
- Create reusable ADF Faces RC page fragments
- Create services applicable for enterprise wide applications: export-functionality, print previews, rendering to different document formats
An alternative development process is laid out in Extreme Reusability.
Testing & deployment
What level of testing, and what should be considered in testing once the application is deployed?
Examples:
- ADF testing approaches (eg. what needs testing, load testing, stress testing)
- Performance tuning best practices
- High availability
- Load balancing
- Security
- The common JEE problem on how to minimize redeployment to the app server (or is it even possible) (as per Chris Muir's blog post)
- AD4J, what's in it for us, how to diagnose an applications' performance, session traffic, logging information and levels (verbose utility)
- Remote versus local debugging, how to configure and define logging
Support & maintenance
What should be considered to aid in the ongoing support and maintenance of an ADF application?
Examples:
- Automated regression testing?
- Future builds and releases
- What level of ongoing support from Oracle Support is required?
- Migration paths
Avrom |
Latest page update: made by Avrom
, Oct 18 2008, 2:56 PM EDT
(about this update
About This Update
Changed mini-section on Extreme Reusability to link to full page.
- Avrom
10 words added 195 words deleted view changes - complete history) |
|
Keyword tags:
adf
jdeveloper
More Info: links to this page
|
| Started By | Thread Subject | Replies | Last Post | |
|---|---|---|---|---|
| pa_ko | Why not EJBs? | 6 | Aug 5 2008, 6:59 PM EDT by chriscmuir | |
|
Thread started: Jul 12 2008, 3:48 AM EDT
Watch
I notice that ADF methodology doesn't consider EJBs as "standard" development step? While BCs, which are definitely non-standard (proprietary) technology, are considered "standard"? This is wrong. I can understand Oracle's sentimental reasons for keeping BCs a live, but the EJBs are standard and the future belongs to them (the EJB 3.1, JPA 2.0 coming this year).
2
out of
3 found this valuable.
Do you?
Keyword tags:
adf
jdeveloper
|
||||
