Slides from Oracle's ADF Architecture TV series covering the Design phase of ADF projects, considering ADF Business Components application module design.
Like to know more? Check out:
- Subscribe to the YouTube channel - http://bit.ly/adftvsub
- Design Playlist - http://www.youtube.com/playlist?list=PLJz3HAsCPVaSemIjFk4lfokNynzp5Euet
- Read the episode index on the ADF Architecture Square - http://bit.ly/adfarchsquare
#StandardsGoals for 2024: Whatâs new for BISAC - Tech Forum 2024
Â
Oracle ADF Architecture TV - Design - ADF BC Application Module Design
1. 1 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
2. 2 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Real World ADF Design & Architecture Principles
ADF BC Application Module Design
15th Feb 2013 v1.0
3. 3 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Learning Objectives
â˘âŻ At the end of this module you should be able to:
â⯠Determine if you need to create multiple root Application
Modules or can survive with one
â⯠Understand when your architecture will mean you have multiple
Application Modules regardless and how you avoid consuming
too many database connections
â⯠Technique to future proof your application module design
â⯠When and why you should use shared application modules
Image: imagerymajestic/ FreeDigitalPhotos.net
4. 4 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
â˘âŻ Root and Nested Application Modules
â˘âŻ Number of Root Application Modules
â˘âŻ Application Module Connection Sharing
â˘âŻ Future Proofing Application Module Design
â˘âŻ Shared Application Modules
5. 5 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Root Application Modules
â˘âŻ Expose View Objects to the Binding layer and indirectly the
View layer as the basis of what is displayed to the user
â˘âŻ 1 instance given to each user at runtime, unless âsharedâ
â˘âŻ Stateful
â˘âŻ Design time configure one JDBC URL/JNDI DataSource
â˘âŻ Connect to the database, by inference control database
transactions
â˘âŻ Each root AM has its own application module pool
Image: winnond/ FreeDigitalPhotos.net
6. 6 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Root vs Nested Application Modules
â˘âŻ An application can have 1 or multiple
root AMs
â⯠Each root AM has its own database connection
and therefore transaction
â⯠If you multiply this by the number of concurrent
users this can limit your scalability
â˘âŻ AMs can be ânestedâ under ârootâ AMs to
logical group VOs
â⯠But only the ârootâ AM is responsible for
connections/transactions/AM pool
â⯠Nested AMs delegate all such responsibilities to
their root AM
Image: IKunl/ FreeDigitalPhotos.net
7. 7 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
â˘âŻ Root and Nested Application Modules
â˘âŻ Number of Root Application Modules
â˘âŻ Application Module Connection Sharing
â˘âŻ Future Proofing Application Module Design
â˘âŻ Shared Application Modules
8. 8 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
How many root AMs should your app have?
â˘âŻ Reasons to have multiple
root AMs, you want:
1.⯠Separate (> 1) transactions
per user session
2.⯠Separate (> 1) data sources in
your app (rare)
3.⯠Configure different tuning
options dependent on VO
usage exposed through the
AM
4.⯠Modularization (cylinder
pattern)
9. 9 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
How many root AMs should your app have?
â˘âŻ Reasons to have multiple
root AMs, you want:
1.⯠Separate (> 1) transactions
per user session
2.⯠Separate (> 1) data sources in
your app (rare)
3.⯠Configure different AM tuning
options dependent on VO
usage exposed through the
AM
4.⯠Modularization (cylinder
pattern)
â˘âŻ Traditionally in 10g the only approach
was to create multiple root AMs
â˘âŻ In 11g the âisolatedâ data control
scope task flow option create
separate instances of the same root
AM for the same user
â˘âŻ This feature may make the need for
multiple root AMs redundant
10. 10 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
How many root AMs should your app have?
â˘âŻ Reasons to have multiple
root AMs, you want:
1.⯠Separate (> 1) transactions
per user session
2.⯠Separate (> 1) data sources in
your app (rare)
3.⯠Configure different AM tuning
options dependent on VO
usage exposed through the
AM
4.⯠Modularization (cylinder
pattern)
â˘âŻ Arguably rare (but valid) requirement
â˘âŻ Still requires separate root AMs
configured to access the different
data sources
â˘âŻ Essential to use the <No Controller
Transaction> task flow option
otherwise the other task flow
transaction options with a shared data
control scope may consolidate the
connection under the disparate AMs
â˘âŻ (More discussed soon)
11. 11 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
How many root AMs should your app have?
â˘âŻ Reasons to have multiple
root AMs, you want:
1.⯠Separate (> 1) transactions
per user session
2.⯠Separate (> 1) data sources in
your app (rare)
3.⯠Configure different AM tuning
options dependent on VO
usage exposed through the
AM
4.⯠Modularization (cylinder
pattern)
â˘âŻ Possibly taken care of by âsharedâ AMs
â˘âŻ Be aware of the âautomagicalâ nesting
of AMs and task flow transaction
options (besides <No Controller
Transaction>)
â⯠Under 11gR1 each root AM is nested under
the first task flow root AM
â⯠Under 11gR2+ (inc 12c) each root AM
maintains itself as root with separate AM
pools
â⯠http://bit.ly/automagicAMnest1
â⯠http://bit.ly/automagicAMnest2
â⯠http://bit.ly/automagicAMnest3
12. 12 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
How many root AMs should your app have?
â˘âŻ Reasons to have multiple
root AMs, you want:
1.⯠Separate (> 1) transactions
per user session
2.⯠Separate (> 1) data sources in
your app (rare)
3.⯠Configure different AM tuning
options dependent on VO
usage exposed through the
AM
4.⯠Modularization (cylinder
pattern)
â˘âŻ The cylinder pattern proposes separate
model layers for each cylinder
â˘âŻ Allows large teams/developments to
not have dependencies on each other
â˘âŻ Not actually possible to nest AMs
under a single root AM without creating
an intermediary model layer to re-
group AMs â this results in as many
connections as root AMs
â˘âŻ We can use the BTF transaction
options to solve this (next section)
13. 13 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
â˘âŻ Root and Nested Application Modules
â˘âŻ Number of Root Application Modules
â˘âŻ Application Module Connection Sharing
â˘âŻ Future Proofing Application Module Design
â˘âŻ Shared Application Modules
14. 14 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Automatic ADF BC Root AM Connection Sharing
â˘âŻ If an application contains multiple root AMs all connecting to same db
â⯠Possibly forced upon the application architecture by breaking the application into
self contained BTF workspaces
â˘âŻ A single page consuming multiple BTF workspaces will spawn a
large amount of database connections seriously limiting scalability
â˘âŻ If BTF transaction options are used (Not <No Controller
Transaction>)
â⯠ADF will automatically merge the AM connections
â⯠Throws runtime error if the root AMs donât share same JNDI
â˘âŻ Radically reduces the number of connections
15. 15 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Automatic ADF BC Root AM Connection Sharing
â˘âŻ Validate this behavior by:
â⯠(With ADF Source Code) Place breakpoint on
oracle.jbo.server.DBTransactionImpl.establishNewConnection()
â⯠Or watching connections at the db level:
SELECT * FROM v$session WHERE username = 'HR';
â⯠Be mindful the BTF âNo save point upon task flow entryâ option when
unselected may result in an extra internal connection
â˘âŻ If you donât want this behavior, for example:
â⯠You need to separate data sources (different databases)
â⯠Or youâre comfortable with the older 10.1.3 root AM design
â˘âŻ Use <No Controller Transaction>
16. 16 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Automatic ADF BC Application Module Nesting
â˘âŻ How this is achieved is through some
trickery under the ADF BC covers
â˘âŻ The implementation of this has
changed between releases
â˘âŻ Programmers can accidentally fall
afoul in transitioning from 11gR1 to
11gR2 or 12c
â˘âŻ 11gR1 functionality commonly
referred to âAutomagical AM nestingâ
Image: arztsamui / FreeDigitalPhotos.net
17. 17 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Automatic AM Nesting Behavior 11gR1
â˘âŻ Behavior for 11gR1 (Pre 11.1.2)
â˘âŻ 1st AM data control used becomes the master root AM of the data control frame
â˘âŻ Subsequent AM data controls within the same shared BTF chain will automatically
nest regardless under the master even if theyâre defined as a root AM
â˘âŻ As there is only 1 root AM at runtime, only one AM pool will be required
â⯠Implies you do not need to tune the AM pool of every root AM
â⯠Be careful that the root AM you think will become the master root AM does get
used first, otherwise a non tuned root AM will become the master
â˘âŻ As there is only 1 root AM the connection of the root AM data control is used for all
the nested AMs (the same as normal AM nesting behaviour)
â˘âŻ This highlights a limitation if the root AMs require different data sources, this
automatic behavior means this cannot be supported
18. 18 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Automatic AM Nesting Behavior 11gR2+
â˘âŻ Behavior for 11.1.2+ (and 12c)
â˘âŻ All root AM data controls remain as root â thereâs no automatic nesting
â˘âŻ Each root AM will have its own AM pool and can be tuned separately
â˘âŻ However the connection definition of the master root AM is used for all AMs
â⯠Limits database connections which is desired
â⯠But the same limitation if the root AMs require different data sources, this
automatic behavior means this cannot be supported
19. 19 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.19 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is unlikely to change the behavior of the
underlying connections as this would break the ability of
apps to scale....
....however Oracle reserves the right to change the
implementation details. As such if you programmatically
walked the automatic nesting in 11gR1 for example,
Oracle has changed the implementation such that your
code would now break in 11gR2+.
Image: Ambro / FreeDigitalPhotos.net
20. 20 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
â˘âŻ Root and Nested Application Modules
â˘âŻ Number of Root Application Modules
â˘âŻ Application Module Connection Sharing
â˘âŻ Future Proofing Application Module Design
â˘âŻ Shared Application Modules
21. 21 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.21 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
For most of our applications a
single root AM is satisfactory.
But what if we later realize we
wanted some of the benefits of
multi-root AMs, how can we future
proof our design?
Exercise
Image: imagerymajestic/ FreeDigitalPhotos.net
22. 22 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Best Practice â Pseudo root AMs
â˘âŻ In most cases a single root AM is satisfactory
â˘âŻ Yet donât dump all VOs under the single root AM
â⯠This will make it impossible to move to a multi-root AM model later if needed
â˘âŻ Use the logical grouping of nested AMs to segment the VOs in your
application (~pseudo root AMs)
â˘âŻ As nested AMs also appear in the Data Control palette as root AMs,
itâs a relatively simple task of rewiring the DataBindings.cpx to use
the nested AM as a root if you decide this is necessary later on
23. 23 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Best Practice â Legacy Systems
â˘âŻ Older systems may have already created multiple root AMs
â˘âŻ Arguably this may be by design (see previous reasons)
â˘âŻ But if accidental the app will be getting hit with the resource
overhead of multiple AM pools
â˘âŻ The pseudo root AMs fix will work here too
â⯠Create a new root AM and nest existing AMs
â⯠Reconfigure DataBindings.cpx to use new root AM
â⯠Test test test
24. 24 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.24 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Time
 for
 a
 challenge
 to
 see
 how
 well
 we
 know
 ADF
Â
Business
 Components.
Â
Â
For
 1
 user
 session
 we
 have
 mul=ple
 root
 AMs.
Â
Â
In
 deďŹning
 business
 rules
 for
 EOs
 and
 LOVs
 for
 VOs
Â
in
 the
 1st
 root
 AM,
 you
 want
 to
 access
 VOs
 via
 View
Â
Accessors
 in
 the
 2nd
 root
 AM.
Â
Â
How
 do
 we
 solve
 this?
Â
Exercise #1
Image: imagerymajestic/ FreeDigitalPhotos.net
25. 25 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.25 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Another
 challenge
Â
Â
Typically
 ADF
 instan=ates
 one
 root
 AM
 instance
 per
Â
user
 session
 and
 creates
 VO
 instances
 per
 root
 AM.
Â
Â
This
 is
 ďŹne
 for
 transac=onal
 data,
 but
 memory
 is
Â
wasted
 for
 read-Ââonly
 VOs,
 par=cularly
 for
 reference
Â
data.
Â
Â
How
 do
 we
 solve
 this?
Â
Exercise #2
Image: imagerymajestic/ FreeDigitalPhotos.net
26. 26 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
â˘âŻ Root and Nested Application Modules
â˘âŻ Number of Root Application Modules
â˘âŻ Application Module Connection Sharing
â˘âŻ Future Proofing Application Module Design
â˘âŻ Shared Application Modules
27. 27 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Shared Application Modules
â˘âŻ ADF provides two types of Shared
Application Modules:
â⯠Session Level - VOs are shared across root
AMs of the same user
â⯠Application Level - VOs are shared across
all user sessions
â⯠Configured via Model project properties â
ADF Business Components â Application
Module Instance options
28. 28 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
How Shared is Shared?
â˘âŻ "Session Level" Shared AMs
â⯠An instance of the shared AM is nested under the root AM you wish to share with
â⯠It is not shared by other root AMs or other users' sessions
â⯠If you share the AM with 2 separate root AMs, 2 separate instances of the shared
AM are created with their own state
â⯠In all manners acts just like a nested AM, sharing AM pool, connection and
transactions
â˘âŻ "Application Level" Shared AMs
â⯠At runtime an instance of the shared AM is created as a root AM in its own right
â⯠Only one AM instance is created and shared by all user sessions
â⯠Acts as a root AM with its own AM pool, a single connection and transaction
29. 29 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Application Level Shared AMs
â˘âŻ To support multiple sessions using same VO
â⯠Separate iterators are created for each session
â⯠If VOs are parameterized, multiple row sets are also created per parameter set
and stored in a query collection
â⯠e.g. For the following query
SELECT emp_id, name FROM employees WHERE dept_id = :deptIdVar
...run with values 10, 20, 30 and 40, 4 different query collections would be created
â⯠Number of query collections can become substantial
30. 30 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Application Level Shared AMs Tuning
â˘âŻ ADF BC pool monitor removes query collections on a timeout basis
â⯠jbo.qcpool.maxinactiveage (default 1800000 ms)
â⯠jbo.qcpool.monitorsleepinterval (default 90000 ms)
â˘âŻ To further restrict totals rows for each VO
â⯠Pool monitor checks if total number of VO rows exceeds "maximum weight"
â⯠If discovered query collections are ejected on LRU basis
â⯠jbo.qcpool.maxweight (default -1 of no limit)
â⯠Or can be set programatically for each VO by overriding the ViewObjectImpl
initSharedQCPoolProperties()!
//In view object implementation class
protected void initSharedQCPoolProperties(QCPoolProperties qcProp){
qcProp.setMaxWeight(10000);
}
31. 31 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Using Shared AM Client Methods
â˘âŻ Client methods defined at the AM/VO/VO Row level are not
executed on the Shared AM
â⯠At design time drag ân dropping these methods via Data Control Palette will create
configurations for normal AM instance, not the shared AM
â⯠Instead you call shared AM methods via other normal AMs
â˘âŻ Shared AM methods can read/write to VO state
â⯠Avoid writes (such as updating current row indicators) as this will confuse other
users sharing the data
SharedModuleImpl am = (SharedModuleImpl)
findOrCreateSharedApplicationModule(
"SharedModuleInstance", "model.SharedModule", SHARED_SCOPE_APPLICATION);
String result = am.sharedAppModuleMethod("someParameter");
Courtesy Avrom Roy-Faderman - http://www.avromroyfaderman.com/
32. 32 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Using Shared AM Client Methods
SharedModuleImpl am = (SharedModuleImpl)
findOrCreateSharedApplicationModule(
"SharedModuleInstance", "model.SharedModule", SHARED_SCOPE_APPLICATION);
// Accessing View Object methods
String result = am.getAllDepartments().sharedAppModuleVoMethod("someParameter");
Courtesy Avrom Roy-Faderman - http://www.avromroyfaderman.com/
â˘âŻ Accessing View Object methods via a shared AM
â˘âŻ Accessing View Object Row methods via a shared AM
â⯠Creates alternative RowSetIterator so primary RSI row is not disturbed
// Accessing View Object Row methods
RowSetIterator deptIterator = am.getAllDepartments.createRowSetIterator(null);
DepartmentsViewRowImpl firstDept = (DepartmentsViewRowImpl)deptIterator.first();
deptIterator.closeRowSetIterator();
String result = firstDept.sharedAppModuleVoRowMethod("someParameter");
33. 33 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.
Conclusion
â˘âŻ Though you can create multiple root AMs at design
time, it's also possible through the combination of
task flow features to create multiple root AM
instances even if you only have 1 at design time
â˘âŻ When working with root AMs, always remember the number of
connections that are taken out, this will seriously affect your
application's scalability
â˘âŻ Consider shared AMs to take the memory burden of read only
data off normal root AMs
34. 34 Copyright Š 2013, Oracle and/or its affiliates. All rights reserved.