10. 10
ADF Pattern genealogy
Sum of the
Parts
Two for One
Deal
Cylinder
Monster
Fine Grained
Small
Application
Small and
Simple
Application
Source: Chris Muir, Oracle Corporation - One size doesn't fit all - Oracle ADF Architecture Fundamentals
Pillar
11. 11
Small application
• One application workspace = one deployment EAR
• Model: ADF Business Components
– Moderate amount of BC's
– One or a few Application Modules
• ViewController
–
–
–
–
One Unbounded Task Flow
Some Bounded Task Flows
Some page fragments
One or a few pages
Source: Chris Muir, Oracle Corporation - One size doesn't fit all - Oracle ADF Architecture Fundamentals
12. 12
Small application
Application Workspace
Model
View Objects
AppModule
Framework
Extensions
Entity Objects
ViewController
Bounded Task Flow
Fragments
Fragments
Bounded Task Flow
Fragments
Task Flow Template
Page Template
Declarative Components
Skin
Source: Chris Muir, Oracle Corporation - One size doesn't fit all - Oracle ADF Architecture Fundamentals
EAR
Pages
Bounded Task Flow
ViewController
Extensions
Unbounded Task Flow
13. 13
Small Application
Advantages
• Simple architecture
– Easy to build and deploy
• Suits small teams and/or
small apps
• Bounded Task Flows
– Improved business process to
design mapping
– Improved modularization but not
perfect
– Options such as transaction
features (vs root ADF BC AMs)
– Programming by contract now
possible
• Improved ability to test
modules
• Requires little development
infrastructure
Disadvantages
• Developers can still
accidentally tightly couple
code
• Bounded Task Flows aren’t
externally reusable
• Application tends to grow in
size
14. 14
Monster application
• Synonyms: uber, monolithic
• One application workspace = one deployment EAR
• Model
– Many, many BC's
– Multiple Application Modules
• ViewController
–
–
–
–
One Unbounded Task Flow
Many Bounded Task Flows
Many page fragments
Multiple Pages
Source: Chris Muir, Oracle Corporation - One size doesn't fit all - Oracle ADF Architecture Fundamentals
16. 16
Monster application
Advantages
Disadvantages
•
Relatively simple architecture
still
•
•
•
Bounded Task Flows
•
Requires little development
infrastructure
•
•
Hard to maintain
Size (# of objects)
– Difficult to understand and
oversee everything
– Dependencies
– Developer's don’t dare to
touch existing code
Build is an all or nothing affair
Bounded Task Flows
transaction options can be
complicated
Source: Chris Muir, Oracle Corporation - One size doesn't fit all - Oracle ADF Architecture Fundamentals
17. 17
Modular ADF
Architectures
Sum of the
Parts
Two for One
Deal
Cylinder
Monster
Fine Grained
Small
Application
Small and
Simple
Application
Source: Chris Muir, Oracle Corporation - One size doesn't fit all - Oracle ADF Architecture Fundamentals
Pillar
18. 18
Examples
• Shop
• Insurance application
– Policies, Customers, Cases, Claims, Commission, Financials, …
• Judicial system
• Booking system
• … Business application
• Multiple small applications with repeated functionalities
• Multi-brand application
• Multi channel
– web, desktop, mobile, services
30. 30
Organization - general
• One workspace for main
• One workspace per 'unit'
• One or more common workspaces
–
–
–
–
–
–
Framework extensions
Declarative components
Taskflow templates
Pagetemplates
Skins
Utilities
• Each 'unit' is delivered as an ADF library
31. 31
General principals
• Each workspace is able to run / tested on its own
• Full debugging must be available everywhere
– sources libraries
• Automated build, test, deliver and deploy process
32. 32
Development Issues
•
•
•
•
•
Every object must be unique, worldwide
UI (page, tf, pagedef) hot deployment is only possible within a project
Libraries cannot be hot-deployed
Taskflows must be delivered in an ADF library to be used elsewhere
Testing taskflows
– Testpages (and pagedefs) and setup
– ADF EMG Taskflow Tester
• Limited ADF library configuration
• Refactoring over projects
• Build automation (with ant) is not easy
33. 33
Single workspace nightmare
• May sound as a good idea: start small and grow bigger
• Use working sets to organize the projects within the workspace
But…
• Boundaries become fuzzy
• Running the application can be slow
• Testing is a problem
• Workspace might grow organically
• Using taskflows is confusing
• Hot deployment issues
• Fighting the framework
• Beware for the monster…
43. 43
Where to store (adf) libraries?
• ant
– project lib directory
• Maven
– local repository
• Internal Application libraries
– Build them locally and then deploy them to lib dir / local repo
– Don't submit then to scm but build them when needed
• External libraries (aka dependencies):
– Download from artifact repository
main -> HR
-> OE
44. 44
ADF library dependencies
•
•
•
•
Dependencies of ADF libraries
Included in the consuming project
Works as a charm
ADF_Library_Dependencies.library
• Multiple versions of
nl/amis/demo/hr/view/DataBindings.cpx appear in
your project run classpath
– Path is not world-wide unique
– Circular dependency: project itself is included as library
because its used by dependent project
main -> HR -> commons
45. 45
Artifact versioning
• Always provide version information
– MANIFEST.MF
•
define in deploy profile
– Filename
– WLS Deployment version
•
Manifest entry: Weblogic-Application-Version
• Remarks
–
–
–
–
–
–
–
OJDeploy failure when manifest file fails
'Internal' libraries could do without version in the file name
max # of redeployments on WLS
Update library definition
Use ojdeploy outputfile parameter for version in filename
Store version in local file to be used in ant build scripts
scm revision
47. 47
Sources and JavaDoc
• Always deliver sources and javadoc
• ant / maven tasks
• sources jar can also be generated with separate deploy profile
• Include as project library
48. 48
Organize the build
• Multiple build files
– Build project
– per application
– per project
• Split build files
– build, artifact mgt, build-info, deploy
• Fix the generated build files
• Consistent naming
– use prefixes
• Externalize properties
• Manage project ant settings
• Reuse using svn externals
• Build scripting is hard
51. 51
Summary
•
•
•
•
•
Modularization allows for better understandability and manageability
Choose the right architecture
Module autonomy
Build automation
JDeveloper doesn't always provide optimal support