Modular architecture today

2,105 views
1,921 views

Published on

Devoxx 2012 University session "Modular Architecture Today" demonstrating how to apply some of the modularity patterns to build a system with a modular architecture.

Published in: Technology

Modular architecture today

  1. 1. 1
  2. 2. Modular Architecture Today Kirk Knoernschild @pragkirk 2
  3. 3. Java Application Architecture Modularity Patterns with Examples Using OSGiForewords by Robert C. Martin and Peter Kriens I’m dancing! By god I’m dancing on the walls. I’m dancing on the ceiling. I’m ecstatic. I’m overjoyed. I’m really, really pleased.” - From the Foreword by Robert C. Martin (a.k.a. Uncle Bob)Java Application Architecture will help you ‣Design modular software that is extensible, reusable, maintainable, and adaptable ‣Design modular software today, in anticipation of platform support for modularity ‣Break large software systems into a flexible composite of collaborating modules ‣Understand where to place your architectural focus ‣Migrate large-scale monolithic applications to applications with a modular architecture ‣Articulate the advantages of modular software to your team Visit http://modularity.kirkk.com for more information. 3
  4. 4. The Codehttps://github.com/pragkirk/poma/network or just Google pragkirk github 4
  5. 5. Goals Today 2 Simple Goals Today 1.) Start designing modular software tomorrow! 2.) Don’t flip the bit on OSGi as too complex! 5
  6. 6. Modular Architecture Today Introducing Modularity The Modularity Patterns Refactor to Modularity Introducing OSGi OSGi-ify the App 6
  7. 7. Agile Architecture Introducing Modularity What ch What Why i s mo d us to d allenges fac are th ula ay in e e ben neces design mo dul arity? efits o sar y c rity a mo dul ar sof ing f ag ile o mpon tware archit en ? ecture t of ? 7
  8. 8. Modularity - Not New! 1972 (or a bit before)On The Criteria To Be Used in Decomposing Systems into Modules by David Parnas at http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf 8
  9. 9. Defining Module Hey, it’s a JAR file! - unit of reu - unit se of co m - unit po of dep sition - unit loyme of ma nt nagem ent A module system provides a runtime environment for modules 9
  10. 10. The Facets Runtime Development Infras Progr Desig tructu am ming n Para dThink about when re Mo de igm l Runtim The fr The te you started using e plat amew chniqu suppo for m techn o r ks a nd to i de esobjects! Using the use d rt hel olog ie ntify enforc ps allow s that create an d language constructs e mo d us to the ri archit ular mo dul create o f mo ghtwere easy, but ecture ar sof dules set . tware creating designs was still really hard. The Design Paradigm - What’s the right granularity for a module? - What the right weight for a module? demo 10
  11. 11. Paradox Increa sing e decre volvab ases s ility ur viva bility (Reuse, Compose, Extend, Lightweight, Fine-Grained, ...) (Use, Maintain, Understand, ...) ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect” 11
  12. 12. Architectural Joints or Seams Here? Which Here? system area of the deman ds mo flexib re ility? Here? Here? Here? Here? Here? 12
  13. 13. Complexity and Knowledge Source: http://www.tensegrity.hellblazer.com/ Source: http://adaptevolve.blogspot.com/ 13
  14. 14. Complexity, Knowledge, & Modularity 14
  15. 15. demoArchitectural Joints or Seams Here? Which Here? system area of the deman ds mo flexib re ility? Here? Here? Modularizing software Here? Here? affects our design in interesting ways. Here? 15
  16. 16. Benefits of Modularity - reus e Increases architectural agility! - re du ce co m - ease ple mainte xity - incr nance easeexten sibilityUmm...we can already do this with objects, aspects, methods, and services! 16
  17. 17. All the Way Down ? Reuse Release Equivalence: Unit of reuse is the unit of release! 17
  18. 18. Agile Architecture The Modularity Patterns What are th mo dul e arity patter ns? 18
  19. 19. Base Patterns • Manage Relationships – Design Module Relationships. • Module Reuse – Emphasize reusability at the module level. • Cohesive Modules – Module behavior should serve a singular purpose. 19
  20. 20. Dependency Patterns • Acyclic Relationships - Module relationships must be acyclic. • Levelize Modules – Module relationships should be levelized. • Physical Layers - Module relationships should not violate the conceptual layers. • Container Independence - Modules should be independent of the runtime container. • Independent Deployment - Modules should be independently deployable units. 20
  21. 21. Usability Patterns • Published Interface - Make a module’s published interface well known. • External Configuration – Modules should be externally configurable. • Default Implementation - Provide modules with a default implementation. • Module Facade – Create a facade serving as a coarse-grained entry point to another fine-grained module’s underlying implementation. 21
  22. 22. Extensibility Patterns • Abstract Modules - Depend upon the abstract elements of a module. • Implementation Factory - Use factories to create a module’s implementation classes. • Separate Abstractions - Place abstractions and the classes that implement them in separate modules. 22
  23. 23. Utility Patterns • Colocate Exceptions: Exceptions should be close to the class or interface that throws them. • Levelize Build – Execute the build in accordance with module levelization. • Test Module – Each module should have a corresponding test module. 23
  24. 24. Agile Architecture Patterns Applied Ho w c Ho w d This is the Design an I u o they mo dul arity se the acco m h mo dat elp Paradigm patter archit e ns? ectura l shift s? 24
  25. 25. The System Design a system to handle payment and auditing of various types of bills. The system must integrate with 3rd party auditing software, and a legacy financials system that must be fed payment information for reconciliation. 25
  26. 26. The Class Model Note t he bi- a sso ci direct ations ional ! 26
  27. 27. demoInitial Systems Modules If I la ye but no r conceptua t phys lly then a ically, m the a d I realizing vantag layeri e ng? W s of layer ? hy do I 27
  28. 28. Physical Layers Module relationships should not violate the conceptual layers. 28
  29. 29. Abstract Modules Depend upon the abstract elements of a module. package client; import service.*; public class Client { Service service; } package service; public interface Service { public void doService(); } - “Inje ct implem ” the package service; entati Client. on int o public class ServiceImpl implements - “ Lo o ku p Service { implem ” the entati public void doService() { Client. on w it hin .... }; } 29
  30. 30. Abstract Modules What if to use Bill must be differ system ent au able s? diting 30
  31. 31. Abstract Modules Au ditF aca de into B 1 is in ill as jecte d Au ditF an aca de type. 31
  32. 32. Abstract Modules 32
  33. 33. Acyclic Relationships Module relationships must be acyclic 33
  34. 34. Recall - Abstract Modules Au ditF aca de into B 1 is in ill as jecte d Au ditF an aca de type. Same problem here 34
  35. 35. Recall - Abstract Modules 35
  36. 36. Uni-Directional 36
  37. 37. demoAcyclic Relationships 37
  38. 38. Separate Abtractions Separate abstractions from the classes that realize them. How d o I in with a tegra te nothe auditi r ng sy stem? Wher e doe s Audit Facad e2 liv e? 38
  39. 39. Separate Abstractions Shoul d I p ut Audit Facad e2 i n audit. jar? 39
  40. 40. Separate Abstractions 40
  41. 41. Colocate Exceptions Exceptions should be close to the classes that throw them Audit Facad e thro the A ws uditEx ceptio n. Exception goes here. 41
  42. 42. Independent Deployment Modules should be independently deployable units. How d o I re bill.ja use r wi t h financ out ial.ja r? Lik a bat e in ch ap plicat ion? 42
  43. 43. Independent Deployment 43
  44. 44. Independent Deployment 1.) PayAction invokes Bill.pay() and passes BillPayAdapter as a BillPayer. 2.) Bill.pay() invokes BillPayer.generateDraft() 3.)BillPayAdapeter.generateDraft() invokes Payment.generateDraft() passing itself as a Payable. 4.) Payment.generateDraft() invokes Payable.getAmount() 44
  45. 45. Independent Deployment 45
  46. 46. Implementation Factory Use factories to create a modules implementation classes. 46
  47. 47. demoThe Final Structure 47
  48. 48. Opportunities 48
  49. 49. Modular Architecture Today Introducing OSGi? This is the Is OS What is OSG Gi new? Who i s usin Infrastructure & i? g OSG i? Programming Model 49
  50. 50. Modularity is coming to the Java platform!OpenJDK 50
  51. 51. A Bit of History • JSR 8 - Open Services Gateway specification in 1999 (JSR 232 or JSR 291) • Gateway for providing services to home devices • lifecycle management, dependencies, installing, versioning, configuration • OSGi Alliance formed in 1999 and delivered V1.0 in 2000 • Very popular on the desktop; driven by Eclipse 3.0 adoption in 2003 • Today, just about all Java middleware products use OSGi • WAS, WebLogic, GlassFish, Paremus Service Fabric, JBoss, Geronimo, ... 51
  52. 52. Introducing OSGi Dynamic Module System for Java ClassLoaders - Each bundle has it’s own classloader and it’s own lifecycle µServices - Bundle exposes it’s behavior via well-defined interface MODULE Bundles - Bundle is a JAR file with manifest 52
  53. 53. A Valid Bundle myjar.jar Manifest.mf Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Scala Calculator JAR + Bundle-SymbolicName: scala calculator Bundle-Version: 1.0.0 Import-Package: com.extensiblejava.loan,scala.annotation.unchecked;us es:="scala.reflect,scala" ;version="2.8.0.final"<osgi:service id="LoanCalculator" ref="loanCalculator"interface="com.extensiblejava.loan.LoanCalculator"/> Register µServices<osgi:reference id="paymentFactory" µService Referenceinterface="com.extensiblejava.loan.PaymentFactory"/> 53
  54. 54. The Basic Workings Private packages Classloader restricts are implementation visibility Imported Exported packages packages Publishes the JAR is a module interface, ideally as Classloader gives µServices each module its own DYNAMICITY lifecycle 54
  55. 55. Modules as First Class Citizens INSTALLED STARTING start Because bundles have their own classloader, they can be managed independently. RESOLVED ACTIVE Hence, a very dynamic environment. stop UNINSTALLED STOPPING 55
  56. 56. demoThe Runtime - Dyn ami - Mult c deployme ipl nt - Enfo e versions rce de - Enca pen de psulat ncies ion 56
  57. 57. demoToo Complex?“OSGi provides little value and is too complex as demonstrated by our failed attempt to makemodularity invisible when porting our legacy system to it with over 150 third-party JARs.-- http://blogs.mulesoft.org/osgi-no-thanks“OSGi is a great solution for complex applications with stringent modularity requirements.”-- http://www.theserverside.com/news/thread.tss?thread_id=62590 57
  58. 58. A Modular System TODAY! 58
  59. 59. Standard Java Lack Encapsulation Everything is still visible; no dynamics! 59
  60. 60. No Encapsulation 60
  61. 61. Type Visibility Any public class in any JAR on the classpath can be seen by any other class on the classpath! With OSGi, you have control who sees what! Cookie Jar images courtesy of Richard Hall 61
  62. 62. Not Visible 62
  63. 63. demoEncapsulation Nothing can reach this class! 63
  64. 64. Modularity Today Platforms discourage modularity! Why a re design n’t we in mo dul g more ar sof tware ? 64
  65. 65. demoModularity Tomorrow This is the next generation application platform! - Dyn ami - Mult c deployme ipl nt - Expl e versions icit de pen de ncies 65
  66. 66. Modular Architecture Today OSGi-ify the App Ho w d o I bu Is it i Is it r applic ild nvasiv eally ations e to m to o co using y co de mplex OSGi? ? ? 66
  67. 67. Java Application Architecture Modularity Patterns with Examples Using OSGiForewords by Robert C. Martin and Peter Kriens I’m dancing! By god I’m dancing on the walls. I’m dancing on the ceiling. I’m ecstatic. I’m overjoyed. I’m really, really pleased.” - From the Foreword by Robert C. Martin (a.k.a. Uncle Bob)Java Application Architecture will help you ‣Design modular software that is extensible, reusable, maintainable, and adaptable ‣Design modular software today, in anticipation of platform support for modularity ‣Break large software systems into a flexible composite of collaborating modules ‣Understand where to place your architectural focus ‣Migrate large-scale monolithic applications to applications with a modular architecture ‣Articulate the advantages of modular software to your team Visit http://modularity.kirkk.com for more information. 67
  68. 68. Q&A 68

×