Use of « the sum of the parts” architecture with UIShell with a great number of BTFs

[david.darte]

Hi,

I start working with a customer on a migration project from Oracle Forms to Oracle ADF.  The application to migrate contains more than 1000 Oracle forms that will be merged to get around 300 ADF bounded task flows.

Based on discussions with the customer, I’m currently proposing to go for “the sum of the parts” architecture combined with the tailor made development ADF framework in which functionalities of the out-of-the box Oracle ADF UIShell template will be integrated, like the dynamic tab feature.

The customer development ADF framework was designed (not by myself) on the use of only one ADF page containing a dynamic region in which all the BTFs (up to 300 BTFs) will be used and the dynamic tabs will be opened.  Each user (in average, 500 users) will also use the dynamic tabs feature in order to open up to 10 independent BTFs.

Based on the aforementioned context, some questions must be answered in order to avoid “performance issues” once the application will be promoted in production:

1. Having around 300 ADF libraries attached to Master workspace could be an issue during the deployment ? (none of them could be used as a shared libraries)
   
2. Is there another way around (dynamic for instance) to attach those ADF libraries to the Master workspace ?
   
3. Will it be issues to deploy this big “ear” file on the weblogic server ?
   
4. Is there any other way to make them collaborate without going to a “pillar” architecture ?
   
5. Memory footprint
   

• What about the memory footprint of having up to 300 BTFs executed through a dynamic region or/and dynamic tabs  (up to 10 at the same time through the use of dynamic tab) : managed bean used for handling the dynamic region or dynamic tabs ?  Menu items ?
  
• Is there any other objects others than the Application Module instance and the managed beans associated with BTF( for which documentation gives enough explanation/description) used by each BTF that we have to be concerned with ?
  

Thanks a lot in advance for giving me your feed back.

David Darte

[Florin Marcus]

Hi David,

I would agree with "Sum of the Parts - Alternative” architecture, where workspaces deployed as ADF Libraries will contain both task flows and View Objects.

We used this approach (UI Shell - one dynamic region loading BTFs - each tab running isolated BTFs)  with several occasions, on large (+1000) Forms-to-ADF modernisation projects.

In some cases, the application deals with thousands of users on daily basis, served by a cluster with two instances and we are doing great, performance-wise.

To go though each of your points:

"Having around 300 ADF libraries attached to Master workspace could be an issue during the deployment ? (none of them could be used as a shared libraries)"

I don't think that granularity of your ADF libraries would be a reason of significant performance concern. You may also consider flattening your jars into a single library. In theory there will be less file scanning, but I doubt the performance gain will be much.

Is there another way around (dynamic for instance) to attach those ADF libraries to the Master workspace ?

Not sure I truly get this one, but you can look at Weblogic's Production Redeployment (http://multikoop.blogspot.de/2013/06/weblogic-application-redeployment-using.html).

"Will it be issues to deploy this big “ear” file on the weblogic server ?"

We are having around a thousand task flows packaged into a single ear and we don't have any problems. We do use compression option on ADF library generation though.

"Is there any other way to make them collaborate without going to a “pillar” architecture ?"

300 task flows makes up a large application, but I am not sure if "pillar architecture" would be necessary.

"What about the memory footprint of having up to 300 BTFs executed through a dynamic region or/and dynamic tabs  (up to 10 at the same time through the use of dynamic tab) : managed bean used for handling the dynamic region or dynamic tabs ?  Menu items ?"

We haven't noticed large memory footprint regarding BTF's and dynamic regions, this is rather a problem of ADF BC components. We do cache our menu data.

"Is there any other objects others than the Application Module instance and the managed beans associated with BTF( for which documentation gives enough explanation/description) used by each BTF that we have to be concerned with ?"

I would use Disconnect Application Module Upon Release setting on AM for dealing with 500 users. Oracle documentation is rather ambiguous on this matter.

Cheers,

Florin

[Chris Muir]

As follow up to Florin's reply, Florin and team have a lot of experience in large scale ADF apps so his is well worth listening too.  I always appreciate Florin's input.

To throw my own thoughts in, whenever I see this sort of question (and let's just focus on the runtime performance part of your question for now), I always think "if I was asking the same questions and I couldn't rely on others for answers, how would I solve this?"

The answer always evolves around load/stress testing, + lots of monitoring.  I'd be taking care as I build the app to try and build the app out to the size and load you're specifying as soon as possible using tools like JMeter, then monitoring the heap, AM pool etc with the available monitoring tools.  This will give me empirical evidence to see what's happening under the hood.

Questionably how do you go about testing an app of the scale you're specifying before you've built it?  Well for example once you've built your first TF, I'd write a load test to spawn the 10 UI shell tabs per user based on that TF, then crank up the user sessions.  And as the solution fills out I'd be exploring other "what can we try now" scenarios to squeeze out issues early.

So the emphasis is when building large scale applications, you can't just pick an architecture and blindly hope it will scale at the end, you need to put the effort into testing it will scale as you design & build it, and make decisions along the way to re-architect, re-design or re-build if needed.  If you do this early on, you'll minimize the risks much later on of an app that just wont scale.  

CM.

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.