Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Composable Software Architecture with Spring

1,611 views

Published on

What does the architecture of a modern enterprise Java application look like? What have we as a community learned from our past? What does it mean to design a composable architecture? And how can Spring help developers meet the needs of enterprise applications in 2013 and beyond?

In this keynote presentation at Java Breeze, core Spring Framework committer Sam Brannen invites the audience to explore what it means to design, develop, and test modern enterprise Java applications following a composable software architecture model. Along the way, Sam will show how the Spring ecosystem and programming model fit into the larger picture of modern enterprise Java applications.

Published in: Software
  • Be the first to comment

Composable Software Architecture with Spring

  1. 1. Composable Software Architecture with Spring Sam Brannen @sam_brannen Java Breeze | Odessa, Ukraine | 18 May 2013
  2. 2. 2 Sam Brannen •  Spring and Java Consultant @ Swiftmind (Zurich) •  Developing Java for over 15 years •  Spring Framework Core Committer since 2007 •  Spring Trainer •  Presenter on Spring, Java, OSGi, and testing
  3. 3. 3 Swiftmind Your experts for Enterprise Java Areas of expertise •  Spring Framework •  Java EE •  OSGi •  Agile Methodologies •  Software Engineering Best Practices Headquarters •  Zurich, Switzerland •  @swiftmind •  http://www.swiftmind.com
  4. 4. 4 Agenda •  Enterprise Applications •  What we’ve learned as a community •  Composable Software Architecture •  Java EE + Open Source •  How Spring fits into the picture •  Spring 4.0 Roadmap
  5. 5. 5 Modern Enterprise Applications
  6. 6. 6 What does "enterprise" mean? Enterprise software is software used in organizations, such as in a business or government, as opposed to software used by individuals. Enterprise software is an integral part of a (computer based) Information System. -Wikipedia
  7. 7. 7 OK, sure... but what does that mean to developers?
  8. 8. 8 Furthermore … Enterprise software typically has interfaces to other enterprise software and is centrally managed. - Wikipedia
  9. 9. 9 Ahh, now we’re getting somewhere!
  10. 10. 10 Typical Enterprise Application •  Supports enterprise business process •  Is relatively large •  Should be robust, scalable, and offer high performance •  Does not run in isolation •  Interacts with multiple external systems and services …
  11. 11. 11 RDBMS
  12. 12. 12 LDAP
  13. 13. 13 SMTP
  14. 14. 14 FTP, FTP, SSH
  15. 15. 15 JMS, AMQP
  16. 16. 16 SOAP Web Services, REST Web Services
  17. 17. 17 Web and Mobile clients, etc.
  18. 18. 18 But each of these has its own APIs and potentially different protocols and exchange formats!
  19. 19. 19 So how should we design such enterprise applications?
  20. 20. 20 What we’ve learned as a community
  21. 21. 21 Things to avoid •  Tight coupling to the container or frameworks •  Tight coupling to protocols and exchange formats in our service layer •  Monolithic deployment units •  Anemic domain models •  Bloated transaction scripts •  Code tangling and scattering
  22. 22. 22 What we should aim for •  Modularity •  Layered architecture with –  a canonical domain model –  a dedicated orchestration layer •  Separation of concerns •  Externalized environment-specific configuration •  Design for testability
  23. 23. 23 How we achieve it •  OOA / OOD / OOP •  (@)POJO Programming Model •  Marshaling and automatic type conversion •  Dependency Injection (DI) •  Inversion of Control (IoC) •  AOP / Interceptor Model •  Automated out-of-container testing and CI
  24. 24. 24 Composable Software Architecture
  25. 25. 25 Composability Composability is a system design principle that deals with the inter-relationships of components. A highly composable system provides recombinant components that can be selected and assembled in various combinations to satisfy specific user requirements. (Wikipedia) •  Self-contained (modular) •  Typically stateless
  26. 26. 26 But it's not just about modularity and statelessness.
  27. 27. 27 It's a different way of thinking,
  28. 28. 28 a different way of designing,
  29. 29. 29 a different kind of architecture,
  30. 30. 30 with new possibilities…
  31. 31. 31 if done right.
  32. 32. 32 Think about different ways the same components can be...
  33. 33. 33 reused…
  34. 34. 34 repurposed…
  35. 35. 35 and composed…
  36. 36. 36 to meet different business requirements
  37. 37. 37 or to interact with different systems.
  38. 38. 38 Composable Architecture Visualized Infrastructure Repository Service Orchestration DomainModel
  39. 39. 39 How is this new? •  To be honest, it’s not really new, –  if you just look at the diagram… •  The web tier or presentation layer has always effectively been a type of orchestration layer. •  The difference is that we re-use all of the other layers with multiple types of orchestration simultaneously!
  40. 40. 40 Orchestration Layer •  Lies at the heart of a composable architecture •  Orchestrates all interactions with the service layer –  potentially interacting directly with repositories (e.g., in batch processing) •  Handles external protocols •  Converts from external formats into our canonical domain model •  Thereby… allowing application services to be composed in a multitude of different ways!
  41. 41. 41 Common Types of Orchestration •  Web controller –  HTTP, HTTPS :: HTTP request and response •  REST or SOAP Web Service endpoint –  HTTP/HTTPS :: XML, JSON, binary, … •  JMS or AMQP listener (or message listener container) –  JMS Message types, domain entities, … •  Messaging endpoint (e.g., gateway + service activator) –  Web service, FTP, file system, email, … •  Batch component (e.g., reader, writer, processor) –  Files, SQL, …
  42. 42. 42 Java EE + Open Source
  43. 43. 43 What's good about Java EE? •  Set of common enterprise standards for Java •  Consistent across containers and vendors (mostly) •  Great tooling and build support •  Catching up with innovation in open source –  Hibernate à JPA –  Spring DI / Guice / Seam à CDI
  44. 44. 44 Java EE is a one stop shop
  45. 45. 45 which is great…
  46. 46. 46 if everything you need is in that shop.
  47. 47. 47 But if Java EE doesn’t offer what you need…
  48. 48. 48 use open source frameworks
  49. 49. 49 either in a Java EE container
  50. 50. 50 or in an alternative light-weight container.
  51. 51. 51 Open Source Frameworks fill the Gaps •  Web frameworks and UI components •  NoSQL •  Big Data •  AMQP •  Mobile •  Social Media •  Batch •  Enterprise Integration (EAI) •  …
  52. 52. 52 How Spring fits into the picture
  53. 53. 53 Core Spring (Framework) •  DI + IoC + AOP •  Declarative –  transactions, caching, validation, formatting •  Spring MVC and REST •  JMS Message Listener Container –  Message-driven POJOs •  Testing framework
  54. 54. 54 Dependency Injection and Inversion of Control collectively decouple application code from the deployment environment
  55. 55. 55 DI + IoC à POJO Programming Model
  56. 56. 56 POJO Programming Model + AOP à Composability
  57. 57. 57 Spring is an Ecosystem •  Spring MVC •  Spring REST •  Spring Web Flow •  Spring Security •  Spring Web Services •  Spring Batch •  Spring Integration •  Spring Data •  Spring Mobile •  Spring Social •  Spring AMQP •  …
  58. 58. 58 Spring MVC and REST •  @Controller annotated components serve as MVC handler methods and REST endpoints •  Automatic type conversion •  Data binding to domain entities •  Marshaling –  JSON, JAXB, Castor, XMLBeans, JiBX, XStream, … •  Handler methods and endpoints orchestrate the service layer
  59. 59. 59 Spring Web Services •  @Endpoint annotated components serve as SOAP Web Service endpoints •  Marshaling (OXM) –  JAXB, Castor, XMLBeans, JiBX, XStream •  Endpoint methods orchestrate the service layer
  60. 60. 60 Spring JMS •  Message listener containers (MLC) support –  JMS MessageListener API –  Message-driven POJOs •  Automatic type conversion from JMS Message types into –  String, Map, Object, byte[] –  Customer converters also supported •  Marshaling –  Spring OXM, customer solutions, etc. •  MLC orchestrates the service layer
  61. 61. 61 Spring Integration •  Inbound and outbound messaging gateways –  Handle external protocols and APIs –  Too many to mention here! •  Automatic type conversion for method arguments and return types in Service Activators •  Marshaling and custom type conversion also supported •  The service layer can be orchestrated via declarative configuration (e.g., service activators in XML)
  62. 62. 62 And the list goes on …
  63. 63. 63 Composable Architecture – with Spring Infrastructure Repository Service DomainModel Spring REST Spring MVC Spring JMS Spring Integration Spring Batch Spring WS
  64. 64. 64 Composable Architecture Checklist þ  Modularity þ  Layered architecture þ Canonical Domain Model þ Orchestration: web, batch, integration, web services þ Service þ Repository þ Infrastructure þ  POJO programming model þ  Separation of concerns þ  Externalized environment-specific configuration þ  Testability, automated testing, and CI
  65. 65. 65 Roadmap for Spring 4.0
  66. 66. 66 1st Class Support for Java 8 based apps •  Language features such as lambda expressions –  for callbacks with templates –  for concurrent execution •  think fork/join, map/reduce, etc. •  APIs such as JSR-310 Date and Time –  Alongside Spring’s existing support for JodaTime
  67. 67. 67 Configuring Spring with Groovy 2 •  Configuring and implementing Spring-style applications using Groovy 2.x •  Groovy-based bean definitions •  Groovy as the language of choice for an entire application, as a direct and straightforward alternative to Java source files •  Groovy 2.0's static compilation support completes the picture here
  68. 68. 68 Support for Key Java EE 7 Technologies •  JMS 2.0 •  JPA 2.1 •  Bean Validation 1.1 •  Servlet 3.1 •  And fully covering JCache 1.0
  69. 69. 69 Enabling WebSocket-style Architectures •  Support for JSR-356 compliant runtimes •  Also supporting related technologies
  70. 70. 70 Fine-grained Eventing and Messaging •  Introducing fine-grained eventing and messaging within the application •  Building on our existing application event mechanism •  Aligned with our JMS message listener mechanism
  71. 71. 71 Pruning and Dependency Upgrades •  Removing a variety of deprecated packages across the framework –  See Spring Framework 3.2's deprecations! •  Raising minimum dependencies to Java 6+ –  Java SE 6+ and Java EE 6+ –  with some compromises for EE 5++ servers
  72. 72. 72 In Closing…
  73. 73. 73 Further Resources •  Spring Projects –  http://www.springsource.org/projects –  Reference Manuals –  Javadoc •  Spring Forums –  http://forum.springframework.org •  Spring JIRA –  http://jira.springframework.org •  GitHub Repositories –  https://github.com/SpringSource
  74. 74. 74 Blogs •  Swiftmind Team Blog –  http://www.swiftmind.com/blog/ •  SpringSource Team Blog –  http://blog.springsource.com/
  75. 75. 75 Q & A Sam Brannen twitter: @sam_brannen www.slideshare.net/sbrannen www.swiftmind.com

×