730 likes | 1.02k Views
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract .
E N D
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
ADF Architecture Square http://bit.ly/adfarchsquare • Oracle ADF Development Essentials • ADF Code Guidelines • ADF Naming and Project Layout Guidelines
ADF Architecture TV http://bit.ly/adftvsub
One Size Doesn’t Fit AllOracle ADF Architecture Fundamentals Chris Muir Senior Principal ADF Product Manager Oracle Development Tools
Program Agenda • Architectural Challenges for ADF Projects • Decisions that will affect your ADF Architecture • ADF Application Architecture Patterns • Anti-Patterns • Best Practices
Architecture Challenges for ADF Projects • Beginner teams are overwhelmed with ADF features to learn • Struggle to consider the bigger picture • Require guidance while learning • Don’t know where to start • Constantly challenged with decisions Image: winnond / FreeDigitalPhotos.net
If you make poor early architectural choices in your project they can have severe repercussions later Image: Rasmus Thomsen / FreeDigitalPhotos.net
Architecture Challenges for ADF Projects • How to select an architecture that’s • Easy to learn? • That will grow? • Provide flexibility? • Wont railroad developers into a dead end later? • But still accommodates your requirements? • Easy to maintain? Image: bennylin0724 / Flikr.com
Architectural Decisions • Decisions that may affect your architecture: • Team size, skills, capabilities • Requirements based around legacy decisions & architectures • Single vs multiple applications • Single vs multi-page • Multi-browser tab support • Level of reuse • Consecutive or parallel application development • Application customization (MDS) • Legacy application modernization • Integrating mobile
Program Agenda • Architectural Challenges for ADF Projects • Decisions that will affect your ADF Architecture • ADF Application Architecture Patterns • Anti-Patterns • Best Practices
Mark Valentine Courtesy of Defence Electronics (Previously RFDesign.com) http://rfdesign.com/mag/radio_flexibility_designers_best/ “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.’”
ADF Application Architecture Patterns • Investigate & discuss • Separate ADF architectural patterns • The moving ADF parts within each pattern • How ADF applications can be composed and separated • Pros and cons of each approach • Match patterns to your requirements and capabilities
ADF Application Architecture Patterns • In scope • Architectural patterns within an ADFapplication • Out of scope • Architectural patterns across systems • Server, hardware & network topologies
ADF Application Architecture Patterns • Quotes • “The best-laid schemes of mice and men” • “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
Pattern Genealogy Two for One Deal Cylinder Pillar Sum of the Parts Fine Grained Monster Small and Simple Application
The Small and Simple Application Architecture Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application Image Source: http://bit.ly/GzVLDf
The Small and Simple Application Architecture • 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
The Small and Simple Application Architecture Application Workspace Model Entity Objects Framework Extensions View Objects AppModule ViewController EAR Unbounded Task Flow Page Templates Pages Declarative Components ViewController Extensions Skins
The Small and Simple Application Architecture • 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
The Small and Simple Application Architecture • 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 • Requires little development infrastructure (e.g. ALM, CI) • Advantages
The Small and Simple Application Architecture • 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 Monster Architecture Two for One Deal Pillar Cylinder Sum of the Parts Find Grained Monster Small and Simple Application Image source: http://bit.ly/GzDTsR
The Monster Architecture • 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 Monster Architecture Application Workspace Model Entity Objects Framework Extensions View Objects AppModule ViewController EAR Unbounded Task Flow Bounded Task Flow Task Flow Templates Fragments Pages Page Templates ViewController Extensions Declarative Components Bounded Task Flow Bounded Task Flow Fragments Fragments Skins
The Monster Architecture • Granularity of Bounded Task Flows • What are their functional boundaries? • How many Bounded Task Flows? • Do we make them all find grained (~service)? • Or course grained (~complete process)? • Or a mix of both? • Design Considerations
The Monster Architecture • Relatively simple architecture still • Bounded Task Flows introduce • Improved business processtodesign 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
The Monster Architecture • 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 Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application
The Sum-of-the-Parts Architecture • 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
The Sum-of-the-Parts Architecture Common Workspace BTF Workspace BTF Workspace ViewController ViewController Model Bounded Task Flow Bounded Task Flow Entity Objects Fragments Fragments Framework Extensions View Objects Bounded Task Flow Bounded Task Flow AppModule 1 Fragments Fragments Task Flow Templates Page Templates ADF Libraries ADF Libraries Declarative Components Master Workspace ViewController Skins Unbounded Task Flow ViewController Extensions EAR Pages
The Sum-of-the-Parts Architecture • 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 • Design Considerations
The Sum-of-the-Parts Architecture • 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
The Sum-of-the-Parts Architecture • 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 of the box is lost • Disadvantages
The Two-for-One-Deal Architecture Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application Image source: http://bit.ly/GzDTsR
The Two-for-One-Deal Architecture • Extension of Sum-of-the-Parts pattern • Reuse means BTFs can be used across applications • Characteristics
The Two-for-One-Deal Architecture Master Workspace BTF Workspace Master Workspace ADF Library ViewController Bounded Task Flows BTF Workspace ADF Library ViewController Bounded Task Flows BTF Workspace ADF Library ADF Library ViewController Bounded Task Flows
The Two-for-One-Deal Architecture • What are the requirements of the BTF now vs the future? • What BTFs are already available? • Should all BTFs be designed for reuse? • Design Considerations
The Two-for-One-Deal Architecture • All the benefits of “Sum of the parts” + • Reuse initially feels “cool” • It’s like reaching nirvana after learning and much hardwork • Advantages
The Two-for-One-Deal Architecture • Repeated: • What functionality logically goes in to 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 Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application Image source: http://yhoo.it/GzStM7
The Cylinder Architecture • 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
The Cylinder Architecture Cylinder Workspace 1 Cylinder Workspace 2 Model Model Entity Objects Entity Objects Common Workspace Framework Extensions Framework Extensions View Objects View Objects Task Flow Templates AppModule AppModule Page Templates ViewController ViewController Declarative Components 1 Bounded Task Flows Bounded Task Flows Skins ADF Libraries ADF Libraries ViewController Extensions Master Workspace ViewController Unbounded Task Flow EAR
The Cylinder Architecture • Doesn’t have to align itself to a subsystem/silo. • 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? • Design Considerations
The Cylinder Architecture • 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
The Cylinder Architecture • 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 Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application
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 Architecture Pillar Workspace 1 Pillar Workspace 2 Model Model Entity Objects Entity Objects Common Workspace Framework Extensions Framework Extensions View Objects View Objects Task Flow Templates AppModule AppModule Page Templates ViewController ViewController Declarative Components Bounded Task Flows Bounded Task Flows Skins Unbounded Task Flow Unbounded Task Flow ADF Libraries ViewController Extensions EAR #1 EAR #2