Oracle ADF Architecture TV - Design - ADF BC Application Module Design
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 178 views

Slides from Oracle's ADF Architecture TV series covering the Design phase of ADF projects, considering ADF Business Components application module design. ...

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

Statistics

Views

Total Views
178
Views on SlideShare
177
Embed Views
1

Actions

Likes
0
Downloads
10
Comments
0

1 Embed 1

http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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