Before starting an ADF Project

[Ibrahim Demir]

Hi ;

 

One of our partners will start an ADF project for a customer. As this will be their firs ADF Project they wanted to get some recommendations  before starting

 

1- Are there any best practice and design recommendation materials I can share with them? ( I have already shared the below materials from ADF Architecture Square.)

ADF Code Guidelines v1.00

ADF Naming and Project Layout Guidelines v2.00

 

2-Some of the pages will be browsed from a tablet (mostly ipad) Do we have any design principals for ADF Faces or advices for the pages that will be browsed from a tablet device.

 

3- What can  be alternatives for ADF Security?

 

Thanks.

 

(Sorry if you got this mail twice)

 

 

--
SAYGILAR / BEST REGARDS

IBRAHIM DEMIR | Senior Sales Consultant
Phone: +90 212 3352224 | Fax: +90 212 3296701 | Mobile: +90 530 1496756
Oracle Oracle Fusion Middleware

ORACLE Turkey | Ayazaga Mevkii Meydan Sok. Spring Giz Plaza Kat:10 Maslak | 34398 Istanbul

Oracle is committed to developing practices and products that help protect the environment

 

 

[Shaminda De Alwis]

3- What can  be alternatives for ADF Security?

Based on client’s specific requirements, following security module can be considered.

  àTwo factor authentication using OTP (One Time Password) coupled with LDAP.

  à Role based data security module (Using DB tables) : which will enable users to secure individual data objects and user defined attribute groups. Ability to view, edit and perform certain actions on an object or attribute group is determined by the role and the permission association.

By using alternative security module, adf essentials can be considered. 

P.S. On a different note, consider using a Root Application Module and Nested Application Modules to overcome datasource connection pooling issues.

Cheers,

Shaminda   

www.antlk.com

--
--
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/groups/opt_out.
 
 

--

Shaminda De Alwis

[Serge]

3- I don't really think there existing an alternative to ADF security.

The first Idea I have will be Spring-Security, but it's not suitable with ADF Architecture even though, that will make your ADF project more heavy.

ADF app is designed to be deployed on WLS , same to  realm security conf that has to be deployed on WLS security layer.

From my own prospective, using ADF without ADF-Security is like using new iphone and find and alternative for touch screen feature..

The advantageous solution that would save energy, time and problems for your customer will be to make it simple by using only the tools Oracle provides and advices as architecture around ADF.

Simon

2013/5/6 Ibrahim Demir <ibrahi...@oracle.com>

--

--
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/groups/opt_out.
 
 

--
Serge.

[Jan Vervecken]

hi

- about "... consider using a Root Application Module and Nested Application Modules to overcome datasource connection pooling issues ..."
-- While this would be something to consider when using JDeveloper 10g, is it really still something to recommend when using JDeveloper 11g?

regards
Jan Vervecken

[Leon Dorfling]

Hi

Once you have an understanding described in the 2 documents that you list. I recommend that you read Chris Muir's "Angels in Architecture" presentation. A big part of successful ADF implementations depends largely on adopting the correct architecture. 

Put a lot of effort into your design, focusing on;

1. Map use cases to application modules. Do not be afraid to create small application modules.

2. Map data, i.e view objects to your application modules.

3. Draw the flow of the applications pages and task flows.

4. Identify reusability as early as possible.

Development phases;

1. Develop and test the Business Service layer to as close to completed as possible. 

2. Develop and test your reusable task flows. 

3. Develop and test complex pages.

Obviously you will be doing a few iterations between the various layers, but by completing each phase before proceeding to the next will save a lot of re-work.

If you correctly design your business services, it would then be possible to have separate UI projects for ADF Faces and Mobile technology. If you are developing in 11g, I would strongly recommend using task flow transaction handling. Correctly understood and implemented makes transaction management a lot easier.

As far as security goes, once again stick to what Oracle & ADF offers. Initial learning curve, but well integrated into ADF and Weblogic technology.

Regards

Leon.

 

On 06 May 2013, at 10:17 AM, Ibrahim Demir wrote:

Hi ;

 

One of our partners will start an ADF project for a customer. As this will be their firs ADF Project they wanted to get some recommendations  before starting

 

1- Are there any best practice and design recommendation materials I can share with them? ( I have already shared the below materials from ADF Architecture Square.)

ADF Code Guidelines v1.00

ADF Naming and Project Layout Guidelines v2.00

 

2-Some of the pages will be browsed from a tablet (mostly ipad) Do we have any design principals for ADF Faces or advices for the pages that will be browsed from a tablet device.

 

3- What can  be alternatives for ADF Security?

 

Thanks.

 

(Sorry if you got this mail twice)

 

 

-- 
SAYGILAR / BEST REGARDS

<image001.gif>

IBRAHIM DEMIR | Senior Sales Consultant
Phone: +90 212 3352224 | Fax: +90 212 3296701 | Mobile: +90 530 1496756 
Oracle Oracle Fusion Middleware

ORACLE Turkey | Ayazaga Mevkii Meydan Sok. Spring Giz Plaza Kat:10 Maslak | 34398 Istanbul

<image002.gif>

Oracle is committed to developing practices and products that help protect the environment

[Shaminda De Alwis]

Hi,

Yes, something to consider during the design phase I.e volume of concurrent users accessing the application etc.

We are currently developing a product from ground up using oracle adf 11g. Up to date we have around 20 AMs which will grow.  We recently had few issues with connection pooling where we had to change the structure by introducing RootAM and configure WebLogic accordantly i.e. Maximum Capacity, Inactive Connection Timeout etc.

Regards,

Shaminda De Alwis

www.antlk.com

[Grant Ronald]

Just a heads up regarding ADF Architecture, we're working on a new set of material which is focused on this exact topic: the architectural decisions you need to address when embarking on an ADF project.  We hope to announce the release in the next couple of weeks - watch this space.
thanks

-- 
Grant Ronald
Director of Product Management
Oracle Application Development Tools
Author: The Quick Start Guide to Fusion Development: JDeveloper and Oracle ADF.

[Wes Fang]

For developing a brand new "enterprise" ADF Faces/BC application. 

This video is a must watch 

http://www.youtube.com/watch?v=toEuQvp73h8

-Wes

On Wednesday, May 8, 2013 10:31:05 AM UTC-4, Donovan Sherriffs wrote:

Hi,

The one thing I suggest to all clients embarking on a new ADF project - engage at lease one ADF expert (someone who has implemented and ADF application all the way to production) for advice.

ADF on the mobile device is an interesting exercise depending on the requirement I suggest creating 3 templates - tablet, phone and desktop and keep it simple.  (we have just finished a mobile enablement of our application) 

As to security after having a look I think it would be possible to replace ADF security inside the application but NOT recommended. 

Two docs I consult before development:

http://www.oracle.com/webfolder/ux/middleware/richclient/index.html

http://docs.oracle.com/cd/E17904_01/core.1111/e10108/adf.htm

Thanks

Donovan

[Mohammad Al Banna]

One of the architecture approaches we adopted described in (http://www.youtube.com/watch?v=toEuQvp73h8) video was the pillar architecture, one of the major drawbacks is the integration level between different workspaces where is has to be done, and how to authenticate users through different modules deployed to different weblogic servers, this is can be solved through implementing OAM or by using federation services from inside weblogic server to move session cookies between weblogic servers.

--

[Wes Fang]

our original app is in 10g and due to framework limitations at the time, we ended up with the "Monster Architecture" with over 100 nested AMs and thousands of jsps/beans all within the same App. After reviewing this video and various blog posts from Chris, I have created a prototype for our future system  using the "Cylinder" design (mainly because we do not need individual ear deployments yet). 

[Jean-Marc Desvaux]

Before starting, we took the necessary time to think how we were going to manage the numerous modules/applications we intend to build.

The major requirements driving our thinking process were :-

1/. Manageability of the deployed applications in terms of application updates, technology (Jdev, ADF runtime & weblogic,..) updates, ability to move one apps from one server to another and cohabitation of weblogic servers versions required for a progressive & smooth migration from one version to another, e.g we should be able to migrate one application by one application independently of each other.

2/. Ease of security management.

3/. Way to share context/state of application modules when user navigate from one app module to the other.

4/. Centrally manage navigation between modules etc..to easily switch weblogic server.

5/. Avoid a choice that can become a wrong one in the future, due to how the underlining technology evolves.

The only way I've found to satisfy these requirements was what Chris calls the Pillar Architecture in the mentioned ADF Insider Essentials presentation (which I had the pleasure to watch live at OOW'12 :)

With time, thinking of any ADF applications size to be built, believing that growth (or at least potential to grow) is intrinsic to any app, I am personally convinced that the Cylinder and Pillar architectures are the best bet for most cases.

The tricky (but not always complex) parts are to satisfy points 2/, 3/. & 4/.

For 2/. a sso & proper directory is essential and of course OAM and OID are perfect for that.

For 3/. & 4/. there are many possible approaches. One is to use the database to store "cross-apps" parameters and the application modules infos, including URLs.

The only disadvantage I've seen with this is in the case users are switching between many applications during a small period of time, which can lead to as many db connections (if one a single server, many AMs loaded too) as number of apps accessed. But this is in fact not better in other architecture choices except maybe the "Monster" choice, which I'm not sure is a recommended one in any case.

Finally, point 5/. is a quite constraining requirement and following it will depend on how long you plan to live with your apps. I prefer to avoid a too deep and complex integration which can become weak as technology evolves and try to stick to the highest possible level. I may be wrong (& I know most of the EMG gang will loudly disagree) but I see the UI shell for example as one of the things to avoid.

-Jean-Marc