Oracle ADF Architecture TV - Design - ADF Architectural Patterns

Real World ADF Design & Architecture Principles
ADF Architectural Patterns
ORACLE
PRODUCT
LOGO
15th Feb 2013 v1.0

Learning Objectives
•  At the end of this module you should be able to:
–  Identify separate ADF architectural patterns
• Understand the moving ADF parts within each pattern
• How ADF applications can be composed and separated
–  Consider the pros and cons of each approach
–  Acknowledge potential anti-patterns and best practices
–  Match patterns to your requirements and capabilities
Image: imagerymajestic/ FreeDigitalPhotos.net

“Design engineering is more than a mere balancing act between finding the
best options among a sea of possibilities, and then implementing those
options through the careful orchestration of available resources. To fully
manage the challenges of the design process, it is also necessary to
develop an instinct for choosing design paths and system
configurations that provide some measure of flexibility. This maintains
wiggle room as projects advance toward completion, often creating ‘an
angel in the architecture’ to serve as a countermeasure for situations in
which ‘the devil is in the details.’”
Mark Valentine
Courtesy of Defence Electronics (Previously RFDesign.com)
http://rfdesign.com/mag/radio_flexibility_designers_best/

ADF Application Architecture Patterns
•  In scope
–  Architectural patterns within an ADF application
•  Out of scope
–  Architectural patterns across systems
–  Server, hardware & network topologies

•  “However beautiful the strategy, you should occasionally look at the results”
•  “The best-laid schemes of mice and men” (often go awry)
•  “No plan survives first contact with the enemy”
•  “One size doesn’t fit all”
•  Oracle is presenting “blueprints”
•  Oracle is not dictating end designs
•  You are

•  Take time to discuss merits of each pattern vs. your requirements
•  Consider your
–  Processes
–  Reuse requirements
–  Team’s size
–  Team’s expertise & capabilities
–  Organization’s infrastructure

Program Agenda
•  ADF Application Architecture Patterns
•  Anti-Patterns
•  A Peek at Oracle’s Fusion Applications

9 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.9 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Multi-Access
Channel
Fine Grained
Pattern Genealogy
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Cylinder
Pillar

The Small and Simple Application Architecture
Image Source: http://bit.ly/GzVLDf
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

•  One application workspace = one deployment EAR
•  Model: ADF Business Components
–  Typically one Application Module
–  Transaction support provided by root AMs
•  ViewController
–  One Unbounded Task Flow
–  No Bounded Task Flows
Characteristics

Application Workspace
Model
Entity Objects
View Objects
AppModule
Framework
Extensions
ViewController
Unbounded Task Flow
ViewController
Extensions
Page Templates
Declarative Components
Skins
Pages
EAR

•  Model: ADF Business Components
–  Single or multiple root Application Modules
–  Design focuses on a page at a time
–  No need to consider reuse outside of application
Design Considerations

•  Very simple architecture
–  Self contained
–  Easy to build and deploy
•  Suits small teams and/or beginners and/or small apps
–  Suits teams moving technical platforms and learning
•  Not essential to have complete development infrastructure (e.g. CI)
Advantages

•  Poor mapping of business processes to technical solution
•  Tight coupling, poor modularization & separation of concerns
–  Developers can break each others’ work
–  Developers can fight for control of primary code artifacts
–  Unit testing is difficult
–  Post re-architecting is difficult
•  As solution grows, building & deploying slows
–  Build is an all or nothing affair
Disadvantages

The Colossal Architecture
Image source: http://bit.ly/GzDTsR
Find Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

•  Synonyms: uber, monolithic
•  One application workspace = one deployment EAR
–  One Unbounded Task Flow
–  One to many Bounded Task Flows
•  Extreme contrast to the Simple Application Architecture
Characteristics

Application Workspace
Model
Entity Objects
View Objects
AppModule
Framework
Extensions
ViewController
Unbounded Task Flow
ViewController
Extensions
Task Flow Templates
Skins
Pages Page Templates
Bounded Task Flow
Fragments
Bounded Task Flow
Fragments
Bounded Task Flow
Fragments
EAR

•  Granularity of Bounded Task Flows
–  What are their functional boundaries?
–  How many Bounded Task Flows?
–  Do we make them all fine grained (~service)?
–  Or coarse grained (~complete process)?
–  Or a mix of both?
•  What makes a suitable declarative component and what is a
suitable single view activity Bounded Task Flow?

•  Relatively simple architecture still
•  Bounded Task Flows introduce
–  Improved business process to design mapping
–  Improved modularization but not perfect
–  Options such as transaction features (vs. root ADF BC AMs)
–  Programming by contract now possible
•  Improved ability to test modules
Advantages

•  Developers can still accidentally tightly couple code
•  Build is still an all or nothing affair
•  Unit testing is still hard
•  Regression testing is an all or nothing affair
•  Bounded Task Flows aren’t externally reusable
•  Bounded Task Flows transaction options can be complicated
Disadvantages

The Sum-of-the-Parts Architecture
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

•  One master application workspace with an Unbounded Task Flow
•  Model
–  Split into separate application workspace
–  Published and consumed as ADF Library
•  One to many separate “BTF” application workspaces
–  Each contains one to many Bounded Task Flows
–  Published and consumed as ADF Libraries
Characteristics

1Master Workspace
ViewController
Common Workspace
Model
Entity Objects
View Objects
AppModule
Framework
Extensions
Task Flow Templates
Unbounded Task Flow
Pages
BTF Workspace
ViewController
Bounded Task Flow
Fragments
Bounded Task Flow
Fragments
Page Templates
Skins
ViewController
Extensions
BTF Workspace
ViewController
Bounded Task Flow
Fragments
Bounded Task Flow
Fragments
ADF Libraries
ADFLibraries
EAR

•  What functionality logically goes in to a BTF application workspace?
•  What is the granularity of each BTF?
•  Task flow transaction options
•  Is reuse a consideration?
•  Deployment considerations
–  One EAR vs. WLS shared libraries

•  Full power of BTFs
–  Reuse is now a strong possibility
–  Excellent separation of concerns
–  Loose coupling - each BTF can be self contained
–  BTFs can be tested standalone
–  Scope of regression testing can be limited to BTFs
•  Suitable for large projects and teams
•  Ownership - developers become responsible for individual BTFs,
team lead for master application
Advantages

•  Complex architecture, not suitable for beginners
–  Dependency management is now an issue
–  Build management is now an issue
–  Designing BTFs for reuse can be difficult
•  Within model layer ability to apply ADF BC security out of the box is
lost
Disadvantages

1
Master Workspace
ViewController
The Sum-of-the-Parts "Alternative"
Common Workspace
Model
Entity Objects
View Objects
Task Flow Templates
Unbounded Task Flow
Pages
BTF Workspace
ViewController
Bounded Task Flow
Fragments
Page Templates
Skins
ViewController
Extensions
BTF Workspace
ViewController
Bounded Task Flow
Fragments
ADF Libraries
ADFLibraries
EAR
Model
View Objects
AppModule
Framework
Extensions
Model
View Objects
AppModule
Framework
Extensions
AppModule
Framework
Extensions

The Two-for-One-Deal Architecture
Image source: http://bit.ly/GzDTsR
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

•  Extension of Sum-of-the-Parts pattern
•  Reuse means BTFs can be used across applications
Characteristics

BTF Workspace
ViewController
Bounded Task Flows
Master
Workspace
Master
Workspace
BTF Workspace
ViewController
Bounded Task Flows
BTF Workspace
ViewController
Bounded Task Flows
ADF
Library
ADF
Library
ADF
Library
ADF
Library

•  What are the requirements of the BTF now vs. the future?
•  What BTFs are already available?
•  Should all BTFs be designed for reuse?

•  All the benefits of “Sum of the parts” +
•  Reuse initially feels “cool”
•  It’s like reaching nirvana after learning and much hard work
Advantages

•  Repeated:
–  What functionality logically goes into a BTF application workspace?
–  What is the granularity of each BTF?
•  Dependency management can become a nightmare
–  Different versions of BTFs between applications need to be
managed
–  Different versions of BTFs running on different version of ADF
need to be managed
–  Potential solutions: tools such as Maven & Ivy
Disadvantages

The Cylinder Architecture
Image source: http://yhoo.it/GzStM7
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

•  Similar in nature to Sum-of-the-Parts patterns
•  Application is made up of many cylinders
–  Cylinder is self contained business/functional area
–  Each cylinder is an application workspace
•  Model layer isn’t separated into ADF Library
–  Each cylinder has it’s own Model layer
–  ADF BC framework extensions are an exception
Characteristics

1
Master Workspace
ViewController
Common Workspace
Task Flow Templates
Unbounded Task Flow
Cylinder Workspace 1
Model
Page Templates
Skins
ViewController
Extensions
Cylinder Workspace 2
Model
ADF Libraries
ADFLibraries
ViewController
Bounded Task Flows
ViewController
Bounded Task Flows
Entity Objects
View Objects
AppModule
Framework
Extensions
Entity Objects
View Objects
AppModule
Framework
Extensions
EAR

•  How fat or thin should the cylinders be?
•  What functions should each cylinder contain?
•  Where’s the logical line drawn for a cylinder?
•  This is not just about BTF granularity;
•  What is the granularity of the cylinder?

•  Reduces dependencies on most actively changing Model layer
•  Logically groups related BTFs together
•  From team and project point of view:
–  Related BTFs are worked on together
–  Independent cylinders are worked on separately
–  Aligns well to project phases
–  Regression testing can focus on one cylinder at a time
Advantages

•  Duplicated functionality across cylinder “Model” projects
–  Creates a maintenance issue
•  Application parts must be versioned separately
•  Doesn’t isolate you from database changes
•  No separation of concerns within a cylinder
•  One massive application which may overwhelm the JVM resources
Disadvantages

If our cylinders end up as massive
applications in their own right, the
single deployed EAR and its
resource requirements are going to
overwhelm even the largest JVM.
What’s the solution?

Pillar Architecture
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

Pillar Architecture
•  Extension of the cylinder pattern
•  Each application is an application in its own right
•  Each “pillar” results in its own EAR
•  But to the user it feels like one application
Characteristics

Pillar Workspace 1
Model
Pillar Workspace 2
Model
ViewController
Bounded Task Flows
ViewController
Bounded Task Flows
Entity Objects
View Objects
AppModule
Framework
Extensions
Entity Objects
View Objects
AppModule
Framework
Extensions
Unbounded Task Flow Unbounded Task Flow
The Pillar Architecture
Common Workspace
Task Flow Templates
Page Templates
Skins
ViewController
Extensions
ADFLibraries
EAR #1 EAR #2

•  A number of separate WLS servers to deploy your application
•  To provide a seamless user experience, you’ll need to consider:
–  SSO
–  A common UI Shell or equivalent
–  Find a mechanism for sharing state between disparate applications

•  A flexible change control procedure:
–  Patching can focus on fixing affected cylinders only
–  Changes to one pillar doesn’t require a redeployment of the whole application
–  Result in less downtimes for the other pillars
•  Performance of one application isn’t affected by another
Advantages

•  Implementing SSO
•  Implementing state sharing mechanism
Disadvantages

The Multi-Access Channel Architecture
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Image source: Salvatore Vuono / freedigitalphotos.net
Multi-Access
Channel
Pillar
Cylinder

ADF Mobile and other solutions can
make reuse of our ADF BC projects
remotely via SDO web service calls.
Let's consider the following picture....
Exercise

Master Workspace
ViewController
The Multi-Access Channel Architecture?
Common
Workspace
Unbounded Task Flow
Cylinder Workspace
Model
ViewController
Bounded Task Flows
Entity Objects
View Objects
AppModule
Framework
Extensions
SOAP - HTTP
HTML - HTTP

Is this architecture
suitable for multi-access?
Should we directly
reuse all of our ADF
BC components for
web services?
What are the
advantages and
disadvantages?
Exercise

Program Agenda

Anti-Patterns
•  Everything is a template
•  Fine grained architecture

Fine Grained Architecture
Fine Grained
Small and
Simple
Application
Colossal
Two for One
Deal
Sum of the
Parts
Multi-Access
Channel
Pillar
Cylinder

•  Granularity of BTFs is reduced to its smallest size
–  The goal is reuse of totally everything
•  BTFs can be wrapped in BTFs to create composites of functionality
•  Reuse must be a mindset, not just a nice to have
•  Reuse must be considered at every phase of the project
Characteristics

Service BTF
Service BTF
Service BTF
Service BTF
Service BTF
Composite BTF

•  Extreme reuse (like an extreme sport)
•  Patterns start to appear in patterns
•  If you love “pain” this pattern is for you
Advantages

•  Not for the feint hearted
•  Performance issues – lots of re-querying of data
•  Overcomplicates even simple applications
•  House of cards – requires strong team discipline
•  “Worst case” dependency management
Disadvantages

Program Agenda

A Peek at Oracle’s Fusion Applications
Some Statistics
Product
Tables
EO
VO
AM
Services
Task
Flows

CRM
996
1137
2520
341
377
2122

Financials
1310
1534
4867
563
119
2329

GRC
170
173
405
86
57
764

HCM
1269
1597
4038
558
130
2872

Incen:ve
Comp
169
171
230
46
8
167

Procurement
211
285
953
113
14
428

PPM
480
523
1775
207
21
691

SCM
932
1028
3336
512
439
1422

Setup
73
86
261
45
50
162

Total
5,610
6,534
18,385
2,501
1,215
10,957

Source: OOW 2010

•  Made up of multiple Java EE applications (not 1)
–  Financials, CRM etc. plus a Common application
•  One app would result in a massive JVM heap
•  Growing problem as more applications are added
•  No one customer will install and run all applications
Overview

•  Each application is designed to
–  Be sold separately
–  Run standalone if need be
–  Presents itself as a self contained page with overall FA
•  Applications are divided into functional areas
–  Financials: payable, receivables
–  Division of functions per application is up to the respective teams
Overview

•  There is no single composite “Fusion Apps” Java EE application
•  Each application has
–  Its own WLS domain/cluster (and by inference URL)
–  Served in a page with its own UI Shell
•  UI Shell is present in each EE application
–  Feels like one application to users, really many
–  Runtime applications do not share state via Java EE
–  All state is shared via database and FMW infrastructure
Overview

•  1 to1 relationship with Java EE application and JDev workspaces
•  There are no non-runnable workspaces (common workspaces)
•  All projects for application are contained in the 1 workspace
JDeveloper Workspaces

•  Projects can have broad or fine granular functionality
•  Projects can be divided by following dimensions:
–  Functional – e.g. Expenses could have Entry, Auditing and
Approval projects
–  Technology – e.g. ADF BC vs. UI
–  Internal or common/shared
•  Common projects are designed to:
–  Be reused by other applications through ADF Libraries
–  Have few/zero dependencies from other workspace projects
Workspaces and Projects

•  The granularity of task flows takes all sizes
•  Many common fragments = 1 to 1 with task flow
•  e.g. Customer header, customer popups
•  Other more “complex” task flows have many fragments/activities
Task Flows

What pattern does
Fusion Applications
use?
Exercise

Conclusion
•  There is no perfect solution – live with your decisions
•  Reuse is good but shouldn’t be taken to its extreme
•  You must consider your team and organization’s capabilities &
infrastructure when picking a pattern
•  Don’t create solutions that work against the overall framework
•  Consider all your options, what are you hoping to achieve?

Further Reading
•  Section 38 Reusing Application Components of the Fusion
Developer's Guide for Oracle Application Development Framework
11.1.2.3.0
–  http://bit.ly/adfdevguide11123sect38

Oracle ADF Architecture TV - Design - ADF Architectural Patterns

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Oracle ADF Architecture TV - Design - ADF Architectural Patterns

Similar to Oracle ADF Architecture TV - Design - ADF Architectural Patterns (20)

Recently uploaded

Recently uploaded (20)

Oracle ADF Architecture TV - Design - ADF Architectural Patterns