sbp introduce plugin oriented programming to Spring Boot. It is inspired and builds on top of Pf4j project.
- Spring boot is good, but it is monolithic. It means you have to delivery the whole application for every single code change every time.
- We need a modern framework with flexibility and extensibility to rapidly deliver solution for complex business scenario.
- Not all projects need to consider scaling at the beginning stage, like Spring Cloud does.
- With sbp, we could think in micro service architecture only with Spring Boot, but no need to worried too much about "cloud native" things, like service discovery, traffic control, etc.
- It's a medium level preference between monolithic Spring Boot application and distributed Spring Cloud application.
- Turn monolithic Spring Boot application to be MODULAR.
- Much more LIGHTWEIGHT development and deployment for spiral extensible architecture.
- Install/update/start/stop plugins ON THE FLY.
- FULL STACK Web/Rest server-side features powered by Spring Boot, including:
- controller for request handling
- persistence (Spring Data/JPA/Jooq/Plain SQL)
- security
- AOP
- resource loading
- Code and test plugin project as STANDALONE Spring Boot project.
- NO extra knowledge NEED TO LEARN as long as you are familiar with Spring Boot.
- NO XML
vs OSGi Based Server (Eclipse Virgo \ Apache Karaf)
- OSGi based server need a server container to deploy, which is not cloud friendly.
- OSGi configuration is complex and strict, the learning curve is steep.
- Bundle cannot be run standalone, which is hard for debug and test.
Spring dm server has been dead, and its successor Virgo is now still struggling to live.
- Spring Cloud does not aim to solve similar problem as
sbp
, but so far it maybe the best choice to solve application extension problem. - With sbp, you will no need to consider too much about computer resource arrangement, everything stick tight within one process.
- Again, sbp is good for medium level applications, which have problem to handle business change rapidly. For large scale application, Spring Cloud is still your best choice.
- sbp should be able to live with Spring Cloud. After all, it is still a Spring Boot application, just like any single service provider node in Spring Cloud network.
- Create a Spring Boot project with multi sub project structure.
- For Gradle, it means multiple projects
- For Maven, it means multiple modules
- Take the demo projects for reference.
- Introduce
sbp-spring-boot-starter
to dependencies.- Maven
<dependency> <groupId>org.laxture</groupId> <artifactId>sbp-spring-boot-starter</artifactId> <version>0.1.13</version> </dependency>
- Gradle
dependencies { implementation 'org.laxture:sbp-spring-boot-starter:0.1.13' }
- Latest master code is always available with version
-SNAPSHOT
- Maven
- Add belows to
application.properties
.spring.sbp.runtimeMode = development spring.sbp.enabled = true # remember to add this line in case you are using IDEA spring.sbp.classes-directories = "out/production/classes, out/production/resources"
- Add anything you want in this project like
Controller
,Service
,Repository
,Model
, etc. - Create an empty folder named
plugins
.
- Create a plain Spring Boot project in the
plugins
folder. - Add
plugin.properties
file to the plugin project.plugin.id=<> plugin.class=demo.sbp.admin.DemoPlugin plugin.version=0.0.1 plugin.provider=Your Name plugin.dependencies=
- Introduce
sbp-core
to dependencies.- Maven
<dependency> <groupId>org.laxture</groupId> <artifactId>sbp-core</artifactId> <version>0.1.13</version> </dependency>
- Gradle
dependencies { implementation 'org.laxture:sbp-core:0.1.13' }
- Maven
- Add Plugin class
public class DemoPlugin extends SpringBootPlugin { public DemoPlugin(PluginWrapper wrapper) { super(wrapper); } @Override protected SpringBootstrap createSpringBootstrap() { return new SpringBootstrap(this, AdminPluginStarter.class); } }
- Add anything you want in the plugin project like
Controller
,Service
,Repository
,Model
, etc.
Everything is done and now you could start the app project to test the plugin.
- demo-shared: Shared code for app and plugin projects.
- demo-security: Security configuration demonstrate how to introduce Spring Security and secure your API via AOP.
- demo-apis: Class shared between app<->plugins and plugins<->plugins need to be declared as API.
- demo-app: The entry point and master project. It provides two
SpringApplication
DemoApp
does not have Spring Security configured.DomeSecureApp
include Spring Security, so you need to provide authentication information when access its rest API.
- plugins
- demo-plugin-admin
- Demonstrate Spring Security integration to plugin projects
- Demonstrate Spring Boot profile feature support.
- demo-plugin-author: Demonstrate share resource (like DataSource, TransactionManager) between api/plugins.
- demo-plugin-library: Demonstrate using Spring Data/JPA.
- demo-plugin-shelf: Demonstrate api expose and invocation between plugins.
- demo-plugin-admin
- Every single projects with
SpringApplication
could be run standalone. - It is basically a skeleton project that you could starts your own project. It almost contains everything we need in the real project.
- How it works
- Configuration
- Serve Static Content
- Persistence
- Security / AOP
- Deployment
- Trouble Shoot & Misc
- About demo project
- Road map
/*
* Copyright (C) 2019-present the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/