Design - ADF Architectural Patterns

1
Copyright 2013, Oracle and/or its affiliates. All rights reserved.
ORACLE
PRODUCT
LOGO
Real World ADF Design & Architecture Principles

ADF Architectural Patterns
2
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 doesnt 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
Teams size
Teams expertise & capabilities
Organizations infrastructure
Program Agenda

Anti-Patterns
A Peek at Oracles Fusion Applications
Pattern Genealogy
Two for One
Deal
Sum of the
Parts
Cylinder
Fine Grained
Colossal
Small and
Simple
Application
Pillar
Multi-Access
Channel
The Small and Simple Application Architecture

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

Characteristics
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
11

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

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

Advantages
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)
14

Disadvantages
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
15
The Colossal Architecture

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

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

Application Workspace
Model
View Objects
AppModule
Framework
Extensions
Entity Objects
ViewController
Bounded Task Flow

Fragments
18
Fragments
Bounded Task Flow
Fragments
Task Flow Templates

Page Templates
Skins
EAR
Pages
Bounded Task Flow
ViewController
Extensions
Unbounded Task Flow

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?
19

Advantages
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
20

Disadvantages
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 arent externally reusable
Bounded Task Flows transaction options can be complicated
21
The Sum-of-the-Parts Architecture

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

Characteristics
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
23

BTF Workspace
Common Workspace
ViewController
ViewController
Model
Bounded Task Flow
Bounded Task Flow
Fragments
Fragments
Bounded Task Flow
Bounded Task Flow
Fragments
Entity Objects
View Objects
AppModule
Fragments
Task Flow Templates
Master Workspace
ViewController
EAR
Unbounded Task Flow

Pages
ADF Libraries
ADF Libraries
24
Framework
Extensions
BTF Workspace
Page Templates
Skins
ViewController
Extensions

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
25

Advantages
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
26

Disadvantages
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
27
The Sum-of-the-Parts "Alternative"

BTF Workspace
BTF Workspace
Model
Model
View Objects
Entity Objects
View Objects
ViewController
ViewController
Bounded Task Flow
Bounded Task Flow
Fragments
Fragments
ViewController
Unbounded Task Flow
Pages
ADF Libraries
Master Workspace
EAR
Task Flow Templates
ADF Libraries
28
AppModule
Framework
Extensions
AppModule
Model
Framework
Extensions
AppModule
Framework
Extensions
View Objects
Common Workspace
Page Templates
Skins
ViewController
Extensions
The Two-for-One-Deal Architecture

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

Characteristics
Extension of Sum-of-the-Parts pattern

Reuse means BTFs can be used across applications
30

Master
Workspace
ADF
Library
Master
Workspace
BTF Workspace
ViewController
Bounded Task Flows
BTF Workspace
ViewController
ADF
Library
Bounded Task Flows
ADF
Library
BTF Workspace
ViewController
Bounded Task Flows
31
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?
32

Advantages
All the benefits of Sum of the parts +

Reuse initially feels cool
Its like reaching nirvana after learning and much hard work
33

Disadvantages
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
34
The Cylinder Architecture

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

Characteristics
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 isnt separated into ADF Library
Each cylinder has its own Model layer
ADF BC framework extensions are an exception
36

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

How fat or thin should the cylinders be?

What functions should each cylinder contain?
Wheres the logical line drawn for a cylinder?
This is not just about BTF granularity;
What is the granularity of the cylinder?
38

Advantages
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
39

Disadvantages
Duplicated functionality across cylinder Model projects
Creates a maintenance issue
Application parts must be versioned separately
Doesnt isolate you from database changes
No separation of concerns within a cylinder
One massive application which may overwhelm the JVM resources
40
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.
Whats the solution?
41
Pillar Architecture
Two for One
Deal
Sum of the
Parts
Cylinder
Fine Grained
Colossal
Small and
Simple
Application
42
Pillar
Multi-Access
Channel
Pillar Architecture
Characteristics
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
43
The Pillar Architecture

Pillar Workspace 1
Model
AppModule
View Objects
AppModule
ViewController
Bounded Task Flows
Bounded Task Flows
Unbounded Task Flow
Unbounded Task Flow
EAR #2
Common Workspace
Task Flow Templates
Page Templates
ADF Libraries
ViewController
EAR #1
44
Entity Objects
Framework
Extensions
View Objects
Model
Framework
Extensions
Entity Objects
Pillar Workspace 2
Skins
ViewController
Extensions

A number of separate WLS servers to deploy your application

To provide a seamless user experience, youll need to consider:
SSO
A common UI Shell or equivalent
Find a mechanism for sharing state between disparate applications
45

Advantages
A flexible change control procedure:

Patching can focus on fixing affected cylinders only
Changes to one pillar doesnt require a redeployment of the whole application
Result in less downtimes for the other pillars
Performance of one application isnt affected by another
46

Disadvantages
Implementing SSO
Implementing state sharing mechanism
47
The Multi-Access Channel Architecture

Two for One
Deal
Sum of the
Parts
Pillar
Cylinder
Fine Grained
Multi-Access
Channel
Colossal
Small and
Simple
Application
48
Image source: Salvatore Vuono / freedigitalphotos.net
Exercise
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....
49
The Multi-Access Channel Architecture?

Common
Workspace
Cylinder Workspace
Model
View Objects
AppModule
Framework
Extensions
Entity Objects
ViewController
Bounded Task Flows
SOAP - HTTP
Master Workspace
ViewController
Unbounded Task Flow
50
HTML - HTTP
Exercise
Should we directly
reuse all of our ADF
BC components for
web services?
What are the

advantages and
disadvantages?
Is this architecture
suitable for multi-access?
51
Program Agenda

Anti-Patterns
52
Anti-Patterns
Everything is a template
Fine grained architecture
53
Fine Grained Architecture

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

Characteristics
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
55
Service BTF
Service BTF
Service BTF
Service BTF
Service BTF
Composite BTF
56

Advantages
Extreme reuse (like an extreme sport)

Patterns start to appear in patterns
If you love pain this pattern is for you
57

Disadvantages
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
58
Program Agenda

Anti-Patterns
59

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
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
60
Source: OOW 2010

Overview
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
61

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
62

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
63
64

JDeveloper Workspaces
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
65

Workspaces and Projects
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
66

Task Flows
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
67
Exercise
What pattern does
Fusion Applications
use?
68
Conclusion
There is no perfect solution live with your decisions

Reuse is good but shouldnt be taken to its extreme
You must consider your team and organizations capabilities &
infrastructure when picking a pattern
Dont create solutions that work against the overall framework
Consider all your options, what are you hoping to achieve?
69
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
70
71

Design - ADF Architectural Patterns

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Design - ADF Architectural Patterns

Hochgeladen von

Copyright:

Verfügbare Formate

1

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Real World ADF Design & Architecture Principles

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

15th Feb 2013 v1.0

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Image: imagerymajestic/ FreeDigitalPhotos.net

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

ADF Application Architecture Patterns

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

ADF Application Architecture Patterns

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

ADF Application Architecture Patterns

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

ADF Application Architecture Patterns

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Small and Simple Application Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Image Source: http://bit.ly/GzVLDf

The Small and Simple Application Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Small and Simple Application Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Unbounded Task Flow

The Small and Simple Application Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Small and Simple Application Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Small and Simple Application Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Colossal Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Image source: http://bit.ly/GzDTsR

The Colossal Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Colossal Architecture

Bounded Task Flow

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Task Flow Templates

Bounded Task Flow

Unbounded Task Flow

The Colossal Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Colossal Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Colossal Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Sum-of-the-Parts Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Sum-of-the-Parts Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Sum-of-the-Parts Architecture

Bounded Task Flow

Bounded Task Flow

Bounded Task Flow

Bounded Task Flow

Task Flow Templates

Unbounded Task Flow

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Sum-of-the-Parts Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

The Sum-of-the-Parts Architecture

Copyright 2013, Oracle and/or its affiliates. All rights reserved.