Modular architecture today
- 1. 1
- 2. Modular Architecture Today Kirk Knoernschild @pragkirk 2
- 3. Java Application Architecture Modularity Patterns with Examples Using OSGi Forewords 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. The Code https://github.com/pragkirk/poma/network or just Google pragkirk github 4
- 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. Modular Architecture Today Introducing Modularity The Modularity Patterns Refactor to Modularity Introducing OSGi OSGi-ify the App 6
- 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. 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. 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. 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. 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. Architectural Joints or Seams Here? Which Here? system area of the deman ds mo flexib re ility? Here? Here? Here? Here? Here? 12
- 13. Complexity and Knowledge Source: http://www.tensegrity.hellblazer.com/ Source: http://adaptevolve.blogspot.com/ 13
- 14. Complexity, Knowledge, & Modularity 14
- 15. demo Architectural 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. Benefits of Modularity - reus e Increases architectural agility! - re du ce co m - ease ple mainte xity - incr nance ease exten sibility Umm...we can already do this with objects, aspects, methods, and services! 16
- 17. All the Way Down ? Reuse Release Equivalence: Unit of reuse is the unit of release! 17
- 18. Agile Architecture The Modularity Patterns What are th mo dul e arity patter ns? 18
- 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. 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. 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. 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. 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. 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. 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. The Class Model Note t he bi- a sso ci direct ations ional ! 26
- 27. demo Initial 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. Physical Layers Module relationships should not violate the conceptual layers. 28
- 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. Abstract Modules What if to use Bill must be differ system ent au able s? diting 30
- 31. Abstract Modules Au ditF aca de into B 1 is in ill as jecte d Au ditF an aca de type. 31
- 32. Abstract Modules 32
- 33. Acyclic Relationships Module relationships must be acyclic 33
- 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. Recall - Abstract Modules 35
- 36. Uni-Directional 36
- 37. demo Acyclic Relationships 37
- 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. Separate Abstractions Shoul d I p ut Audit Facad e2 i n audit. jar? 39
- 40. Separate Abstractions 40
- 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. 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. Independent Deployment 43
- 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. Independent Deployment 45
- 46. Implementation Factory Use factories to create a modules implementation classes. 46
- 47. demo The Final Structure 47
- 48. Opportunities 48
- 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. Modularity is coming to the Java platform! OpenJDK 50
- 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. 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. 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 Reference interface="com.extensiblejava.loan.PaymentFactory"/> 53
- 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. 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. demo The Runtime - Dyn ami - Mult c deployme ipl nt - Enfo e versions rce de - Enca pen de psulat ncies ion 56
- 57. demo Too Complex? “OSGi provides little value and is too complex as demonstrated by our failed attempt to make modularity 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. A Modular System TODAY! 58
- 59. Standard Java Lack Encapsulation Everything is still visible; no dynamics! 59
- 60. No Encapsulation 60
- 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. Not Visible 62
- 63. demo Encapsulation Nothing can reach this class! 63
- 64. Modularity Today Platforms discourage modularity! Why a re design n’t we in mo dul g more ar sof tware ? 64
- 65. demo Modularity 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. 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. Java Application Architecture Modularity Patterns with Examples Using OSGi Forewords 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. Q&A 68