Oracle ADF Architecture TV - Design - ADF Architectural Patterns

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


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

Framew

ork E

xtensions

ViewController Unbounded Task Flow View

Controller

Extensions

Page Templates

Declarative Components

Skins

Pages

EA

R



•  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

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


Pillar

Cylinder



•  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

Characteristics


The Colossal Architecture Application Workspace

Model

Entity Objects

View Objects

AppModule

Framew

ork E

xtensions

ViewController Unbounded Task Flow View

Controller

Extensions

Task Flow Templates


Skins

Pages Page Templates

Bounded Task Flow

Fragments

Bounded Task Flow

Fragments

Bounded Task Flow

Fragments

EA

R



•  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


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


1

Master Workspace ViewController

The Sum-of-the-Parts Architecture Common Workspace

Model

Entity Objects

View Objects

AppModule

Framew

ork E

xtensions

Task Flow Templates

Unbounded Task Flow

Pages

BTF Workspace ViewController

Bounded Task Flow

Fragments

Bounded Task Flow

Fragments

Page Templates


Skins

ViewController Extensions


Bounded Task Flow

Fragments

Bounded Task Flow

Fragments

ADF Libraries

AD

F Libraries

EA

R



•  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


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


BTF Workspace

ViewController Bounded Task Flow

Fragments

ADF Libraries

AD

F Libraries

EA

R

Model View Objects

AppModule

Framew

ork E

xtensions

Model View Objects

AppModule

Framew

ork E

xtensions

AppModule

Framew

ork E

xtensions


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


Pillar

Cylinder



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

Characteristics




Bounded Task Flows

Master Workspace

Master Workspace


Bounded Task Flows


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


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



Common Workspace

Task Flow Templates

Unbounded Task Flow

Cylinder Workspace 1 Model

Page Templates


Skins


Cylinder Workspace 2 Model

ADF Libraries

AD

F Libraries

ViewController Bounded Task Flows


Entity Objects

View Objects

AppModule

Framew

ork E

xtensions

Entity Objects

View Objects

AppModule

Framew

ork E

xtensions

EA

R



•  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


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



Entity Objects

View Objects

AppModule

Framew

ork E

xtensions

Entity Objects

View Objects

AppModule

Framew

ork E

xtensions

Unbounded Task Flow Unbounded Task Flow

The Pillar Architecture

Common Workspace

Task Flow Templates

Page Templates


Skins


AD

F Libraries

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


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

Framew

ork E

xtensions

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


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


A Peek at Oracle’s Fusion Applications

•  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 A Peek at Oracle’s Fusion Applications


•  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 A Peek at Oracle’s Fusion Applications



•  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
