building highly modular and testable business systems with spring integration
TRANSCRIPT
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Building Highly Modular Business Systems with Spring Integration
Marius Bogoevici
About me
• Current • Software Engineer with Pivotal • Spring XD team
• Past • Spring Integration • Spring consultant • JBoss AS, JSR-299
2
What kind of modularity?
• Modularity means different things in different contexts • Libraries ? • Classloading ? Dependencies? Visibility?
• Jigsaw/OSGi • Services?
3
What kind of modularity?
• Modularity means different things in different contexts • Components (Libraries) ? • Classloading? Dependencies? Visibility?
• Jigsaw/OSGi • Services !
4
Microservices - only for HTTP/REST?
• HTTP/REST is the dominant context of discussion • Not an actual prerequisite requirement • Same principles, natural fit in event-driven architectures
5
Microservices - core principles
• No monolithic architectures • Standalone components • Split along business
features • Independent deployment
and scaling
6
Pipes and Filters: core concepts
• Enterprise integration pattern • Architectural style behind Spring Integration • Core components
• Filters: independent processing units • Pipes: connecting filters • Messages: move data between filters
7
www.eaipatterns.com
Spring Integration: Pipes and filters applied
• Channels -> Pipes • Endpoints -> Filters • Messages -> … well, Messages • Wide arrangement of EAI Patterns implementations
• Router • Splitter • Service activator • Channel adapter • (and many more)
8
Problem/Solution
• Problem: Transform an existing monolithic enterprise solution into a flexible, modular application
• Multiple steps: • Decompose the application into logical partitions • Split the application into independently running components • Use Spring XD as a runtime
11
Modular Spring Integration applications
• Modules: logical groups of channels and endpoints • Use business criteria for partitioning • Each module is self-contained • Connected via channels • Can use XML or annotations
20
What we got …
• Simpler, easier to understand partitions • Division by business functionality • There is still coupling between context fragments
• e.g. channel names must be known • Options:
• Splitting the application into independent libraries • Using conventions for loading the XML fragments
22
What we got …
• Context fragments are truly isolated partitions • Still, channel names must be unique • More verbose syntax (i.e. use of bridges) • Splitting into libraries is more natural now
24
How does our deployment look like?
26
Orderprocessing Drink making Delivery
assembly
Spring Boot Spring Boot Spring Boot
What we got …
• Channel adapters for linking components • Natural evolution of the previous steps • Solution components are deployed independently • Solution components can scale independently • Some overhead in setting up the channel adapters • Spring Boot makes running the independent services easy • We’re in microservice territory
27
Spring XD introduction
• Spring eXtreme Data • Unified, distributed, and extensible service for
• Data ingestion • Real time analytics • Batch processing • Data export
• Built on existing solutions • Spring Integration • Spring Batch
29
Spring XD modules
• Core concept in Spring XD • Runtime support for deployment/configuration
• Conventions for input and output channels • Automatically bridged together in streams • Data monitoring • Runtime allows for concurrency/scaling management
30
Spring XD and EAI solutions
• Spring Integration-based components are a natural fit; • Designed for distributed, modular solutions; • While designed for high-throughput data processing, less
demanding application can also benefit of the infrastructure;
33
Spring XD is for less eXtreme Data too :)
How does our deployment look like?
34
Orderprocessing Drink making Delivery
assemblyHTTP Log
Cafe stream