ADF Architecture Square

2. 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.

3. ADF Architecture Square http://bit.ly/adfarchsquare • Oracle ADF Development Essentials • ADF Code Guidelines • ADF Naming and Project Layout Guidelines

4. ADF Architecture TV http://bit.ly/adftvsub

5. One Size Doesn’t Fit AllOracle ADF Architecture Fundamentals Chris Muir Senior Principal ADF Product Manager Oracle Development Tools

6. Program Agenda • Architectural Challenges for ADF Projects • Decisions that will affect your ADF Architecture • ADF Application Architecture Patterns • Anti-Patterns • Best Practices

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

8. If you make poor early architectural choices in your project they can have severe repercussions later Image: Rasmus Thomsen / FreeDigitalPhotos.net

9. 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

10. 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

11. Program Agenda • Architectural Challenges for ADF Projects • Decisions that will affect your ADF Architecture • ADF Application Architecture Patterns • Anti-Patterns • Best Practices

12. 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.’”

13. 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

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

15. 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

16. Pattern Genealogy Two for One Deal Cylinder Pillar Sum of the Parts Fine Grained Monster Small and Simple Application

17. 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

18. 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

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

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

21. 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

22. 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

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

24. 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

25. 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

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

27. 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

28. 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

29. The Sum-of-the-Parts Architecture Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. The Two-for-One-Deal Architecture • Extension of Sum-of-the-Parts pattern • Reuse means BTFs can be used across applications • Characteristics

37. 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

38. 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

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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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?

48. Pillar Architecture Two for One Deal Pillar Cylinder Sum of the Parts Fine Grained Monster Small and Simple Application

49. 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

50. 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