design - adf architectural patterns

7/23/2019 Design - ADF Architectural Patterns

http://slidepdf.com/reader/full/design-adf-architectural-patterns 1/71

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




Real World ADF Design & Architecture Prin

ADF Architectural Patterns




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 patte

•

How ADF applications can be composed and separ

–

Consider the pros and cons of each approach –

Acknowledge potential anti-patterns and best practice

–

Match patterns to your requirements and capabilities

Imag




“Design engineering is more than a mere balancing act betweenbest options among a sea of possibilities, and then implementing

options through the careful orchestration of available resources. manage the challenges of the design process, it is also necessa

develop an instinct for choosing design paths and systemconfigurations that provide some measure of flexibility . This

wiggle room as projects advance toward completion, often crea

angel in the architecture’ to serve as a countermeasure for sitwhich ‘the devil is in the details.’”

Mark ValentineCourtesy 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 a

•

“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 requ

•

Consider your

–

Processes

– Reuse requirements

–

Team’s size –

Team’s expertise & capabilities

–

Organization’s infrastructure




Program Agenda

•


•

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

ChannelFine Grained

Pattern Genealogy

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts Cylinder

Pillar




The Small and Simple Application Arch

Fine Grained

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts 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

F r am ew or k

E x t en s i on s

ViewController

Unbounded Task FlowV i ew C on t r ol l er

E x t en s i on s

Page Templates

Declarative Components

Skins

Pages





•

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 infrastructu

Advantages





•

Poor mapping of business processes to technical solutio

•

Tight coupling, poor modularization & separation of conc

–

Developers can break each others’ work

–

Developers can fight for control of primary code artifa

–

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

Find Grained

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts 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





Application Workspace

Model

Entity Objects

View Objects

AppModule

F r am ew or k

E x t en s i on s

ViewController

Unbounded Task FlowV i ew C on t r ol l er

E x t en s i on s

Task Flow Templates

Declarative Component

Skins

Pages Page Templates

Bounded Task Flow

Fragments

Bounded Task FlowFragments

Bounded Task Flow

Fragments





•

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

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 –

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 complic

Disadvantages




The Sum-of-the-Parts Architecture

Fine Grained

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts Cylinder





•

One master application workspace with an Unbounded T

•

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 ArchitectureCommon

Mo

Entity Obje

View Obje

AppModu

Task Flow

Unbounded Task Flow

Pages

BTF Workspace

ViewController

Bounded Task Flow

Fragments

Bounded Task Flow

Fragments

Page Te

Declarative

Sk

ViewCExten

BTF Workspace

ViewController

Bounded Task Flow

Fragments

Bounded Task Flow

Fragments

ADF Libraries

A DF

L i b r ar i e s

E A R

S f





•

What functionality logically goes in to a BTF application w

•

What is the granularity of each BTF?

•

Task flow transaction options

•

Is reuse a consideration?

•

Deployment considerations

–

One EAR vs. WLS shared libraries


Th S f th P t A hit t





•

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 individu

team lead for master application

Advantages

Th S f th P t A hit t





•

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 o

lost

Disadvantages

Th S f th P t "Alt ti "




1

Master Workspace

ViewController

The Sum-of-the-Parts "Alternative"

Common

Mo

Entity Obje

View Obje

Task Flow

Unbounded Task Flow

Pages

BTF Workspace

ViewController

Bounded Task Flow

Fragments

Page Te

Declarative

Sk

ViewCExten

BTF Workspace

ViewController

Bounded Task Flow

Fragments

ADF Libraries

A D

F L i b r ar i e s

E A R

Model

View Objects

AppModule

F r am e

w or k

E x t en s i on s

Model

View Objects

AppModule

F r am e

w or k

E x t en s i on s

AppModu

Th T f O D l A hit t




The Two-for-One-Deal Architecture

Fine Grained

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts Cylinder

Th T f O D l A hit t





•

Extension of Sum-of-the-Parts pattern

•

Reuse means BTFs can be used across applications

Characteristics

The Two for One Deal Architecture





BTF Workspace

ViewController

Bounded Task Flows

MasterWorkspace

BTF Workspace

ViewController

Bounded Task Flows

BTF Workspace

ViewController

Bounded Task Flows

ADFLibrary

ADFLibrary

ADFLibrary

ADFLibrary






•

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 w

Advantages






•

Repeated:

–

What functionality logically goes into a BTF application work –

What is the granularity of each BTF?

•

Dependency management can become a nightmare

–

Different versions of BTFs between applications need

managed –

Different versions of BTFs running on different version

need to be managed

– Potential solutions: tools such as Maven & Ivy

Disadvantages

The Cylinder Architecture





Fine Grained

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts 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

Task Flow

Unbounded Task Flow

Cylinder Workspace 1

Model

Page Te

Declarative

Sk

ViewCExten

Cylinder Workspace 2

Model

ADF Libraries

A DF

L i b r ar i e s

ViewController

Bounded Task Flows

ViewController

Bounded Task Flows

Entity Objects

View Objects

AppModule

F r am ew or k

E x t en s i on s

Entity Objects

View Objects

AppModule

F r am

ew or k

E x t e

n s i on s

E A 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 Mode•

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

Disadvantages

If our cylinders end up




applications in their o

single deployed EA

resource requirements

overwhelm even the l

What’s the solu

Pillar Architecture




Pillar Architecture

Fine Grained

Small and

Simple

Application

Colossal

Two for One

Deal

Sum of the

Parts Cylinder

Pillar Architecture




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

The Pillar Architecture




Pillar Workspace 1

Model

Pillar Workspace 2

Model

ViewController

Bounded Task Flows

ViewController

Bounded Task Flows

Entity Objects

View Objects

AppModule

F r am

ew or k

E x t e

n s i on s

Entity Objects

View Objects

AppModule

F r am

ew or k

E x t e

n s i on s

Unbounded Task Flow Unbounded Task Flow


Common

Task Flow

Page Te

Declarative

Sk

ViewCExten

A DF L i b r ar i e s

EAR #1 EAR #2





•

A number of separate WLS servers to deploy your applic

•

To provide a seamless user experience, you’ll need to co

– 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

– 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 so

Cylinder

Exercise




ADF Mobile and other solutions canmake reuse of our ADF BC projects

remotely via SDO web service calls.

Let's consider the following picture....

Ima

The Multi-Access Channel Architecture




Master Workspace

ViewController

CommonWorkspace

Unbounded Task Flow

Cylinder Workspace

Model

ViewController

Bounded Task Flows

Entity Objects

View Objects

AppModule

F r am ew or k

E x t en s i on s

SOAP - HTTP

HTML - HTTP

WhaExercise




Is this architecturesuitable for multi-access?

Should we directlyreuse all of our ADF

BC components forweb services?

advan

disadv

Ima

Program Agenda




• ADF Application Architecture Patterns

•

Anti-Patterns

•


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 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 f

•

Reuse must be a mindset, not just a nice to have

•

Reuse must be considered at every phase of the project

Characteristics




•

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




•


•

Anti-Patterns

•


A Peek at Oracle’s Fusion ApplicationsS St ti ti




Some Statistics!"#$%&' )*+,-. /0 10 23 4-"56&-.

!"# %%& ''() *+*, (-' ())

./0102/134 '(', '+(- -5&) +&( ''%

6"! '), ')( -,+ 5& +)

7!# '*&% '+%) -,(5 ++5 '(,

80290:;9 !<=> '&% ')' *(, -& 5

?@<2A@9=90B *'' *5+ %+( ''( '-

??# -5, +*( '))+ *,) *' C!# %(* ',*5 (((& +'* -(%

C9BA> )( 5& *&' -+ +,

)#'*, :;<=> <;:?@ =A;?A: B;:>= =;B=:

A Peek at Oracle’s Fusion ApplicationsO i




•

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 respe

Overview





•

There is no single composite “Fusion Apps” Java EE app

•

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 infrastructu

Overview





JDeveloper Workspaces





•

1 to1 relationship with Java EE application and JDev wo

•

There are no non-runnable workspaces (common works

•

All projects for application are contained in the 1 worksp

JDeveloper Workspaces

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

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 Librarie

–

Have few/zero dependencies from other workspace p

Workspaces and Projects

A Peek at Oracle’s Fusion ApplicationsTask 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/a

Task Flows

Exercise




What pattern doesFusion Applications

use?

Im

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 capabil

infrastructure when picking a pattern

•

Don’t create solutions that work against the overall frame

•

Consider all your options, what are you hoping to achiev

Further Reading




•

Section 38 Reusing Application Components of the Fusi

Developer's Guide for Oracle Application Development F

11.1.2.3.0

– http://bit.ly/adfdevguide11123sect38

design - adf architectural patterns

Documents