Oracle ADF Architecture TV - Design - ADF BC Application Module Design

Real World ADF Design & Architecture Principles
ADF BC Application Module Design
15th Feb 2013 v1.0

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

Program Agenda
•  Root and Nested Application Modules
•  Number of Root Application Modules
•  Application Module Connection Sharing
•  Future Proofing Application Module Design
•  Shared Application Modules

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

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

Program Agenda

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)

root AMs, you want:
per user session
your app (rare)
3.  Configure different AM tuning
AM
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

root AMs, you want:
per user session
your app (rare)
AM
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)

root AMs, you want:
per user session
your app (rare)
AM
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

root AMs, you want:
per user session
your app (rare)
AM
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)

Program Agenda

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

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>

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

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

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 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

Program Agenda

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

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

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

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

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

Program Agenda

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

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

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

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);
}

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/

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");

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

Oracle ADF Architecture TV - Design - ADF BC Application Module Design

More Related Content

What's hot

Viewers also liked

Similar to Oracle ADF Architecture TV - Design - ADF BC Application Module Design

Recently uploaded

Oracle ADF Architecture TV - Design - ADF BC Application Module Design