oracle adf architecture tv - design - adf bc application module design
DESCRIPTION
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/adfarchsquareTRANSCRIPT
1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 defining 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 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 fine 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 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 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 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 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 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 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 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 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 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.