Спикер:

Тема презентации:

Stanislav Sidorenko

DeviceHive Java Server and Spring Boot

What is DeviceHive?

DeviceHive is an Open Source Machine-to-Machine(M2M) framework. It contains a set of services and components that allow establishing a two-way communication with remote devices using cloud as a middleware. The devices can be anything connected: sensor networks, smart meters, security systems, telemetry, or smart home devices.

What is inside?

• JavaEE or .NET-based server• REST и Websocket APIs for devices and

Clients• Data storage: Postgresql and NoSQL

(MongoDB).• Device: Linux C/C++, .NET, .NET Micro

Framework, Java, Python, MicroChip and AVR native C.

• Client: Windows 8, iOS, Android, Windows Phone 7 and 8,.NET, HTML5/JavaScript.

What is inside?

REST, Websockets

REST, Websockets

REST, Websockets

binary

Client: something that manages DevicesDevice: almost everything.

Gateway: fake Device that quite smart to connect to DH and to manage other Devices.

Future: merge everything to one entity.

How does it work?

Client

Device

commandsnotifications

commands

notifications

Access control system: Networks

Client DeviceNetwork1n n n

AccessKey: allows authenticated client to act on behalf of Device

• Network list• Device list• IP/Domain• Actions

Basic access control. User has access to Device if and only if he has access to network

Access control system: AccessKeys

AccessKey: more smart security system similar to MAC

Privilege contains• Network list• Device list• IP/Domain• Actions

Client PrivilegeAccessKey11 n n

Java server implementation

• Java EE 7 platform:• JAX-RS 2.0• Websocket API 1.0• JPA 2.1• EJB 3.2• CDI 1.1

• PostgreSQL 9.x

• Glassfish 4, 4.1 as reference JEE7 implementation

• Wildfly 8, 8.1 was preliminary tested. There were some issues with websockets, but now the application works generally fine.

Feedback

• “We’d like to be able to deploy it to Tomcat”Existing code is built to .war application.

• “Do I need JEE application server? Oh.”

• “Deployment procedure is quite hard.”

OK, let’s try to simplify it. Spring?

• Again not so new technology stack, but quite rich.

• Application can be deployed almost everywhere. Only servlet container is needed (Tomcat, Jetty,..)

• Migration would not be so hard.

• JAX-RS -> Spring MVC or using Jersey (no code migration in fact)• EJB -> Spring @Service + spring-tx• Bean Validation API -> the same, just configuration changes.• JPA -> no changes again• CDI -> Spring DI (CDI events may be an issue).

• Spring Boot.

Spring Boot.

• Easy deployment

There are many “default” configurations that could be applied automatically.

• Standalone Spring-based applications

• “fat” executable jar• archive with two directories: /lib with jars and /bin with unix

shell and windows batch scripts.

• .war packaging is still possible

Maven integration

<build><plugins>

<plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId>

</plugin></plugins>

</build>

Goals:• boot:repackage• boot:run

Gradle integration

buildscript {dependencies {

classpath("org.springframework.boot:spring-boot-gradle-plugin:1.2.2")

}}

apply plugin: 'spring-boot‘

Tasks:bootRepackagebootRun

Sample application

@RestController@EnableAutoConfigurationpublic class Sample {

@RequestMapping("/") String home() { return "Hello World!"; }

public static void main(String[] args) throws Exception { SpringApplication.run(Sample.class, args); }

}

Starter POMs

• dependency descriptors, cover all required dependencies.

• named spring-boot-starter-*

Web applications: Use spring-boot-starter-web – attaches default servlet container and spring web dependencies.

spring-boot-starter-tomcat (default one)spring-boot-starter-jetty spring-boot-starter-undertow

• Versions• sprint-boot-starters parent pom• your own one.

Customizing the application

• Main configuration file: application.properties

• Read from classpath or location can be overridden:

java -jar myproject.jar --spring.config.location=...

• Spring Profiles

--spring.profiles.active=dev,qa,etc…

application-{profile}.properties is used

DataSources deployment

• Embedded datasources:• embedded H2, HSQL and Derby databases• just specify spring-jdbc and add runtime DB dependency• useful for testing

• Production datasource• add ‘spring-boot-starter-jdbc’ started pom• specify spring.datasource.* properties (url, user, pw, driver)• JNDI is also supported

Databases initialization

• JPA - spring.jpa.generate-ddl (good for testing only)

• Spring JDBC

Two files: schema.sql, data.sql or schema-${db}.sql and data-{db}.sqlAgain looks file for testing purposes only.

• Embedded Database migration tools

• FlywaySQL files in classpath:db/migration

• Luqibase

Looks fine for production deployments.

Creating deployable .war file

@SpringBootApplicationpublic class Application extends SpringBootServletInitializer {

@Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(Application.class); } public static void main(String[] args) throws Exception { SpringApplication.run(Application.class, args); }}

@SpringBootApplication == @Configuration @EnableAutoConfiguration @ComponentScan

Servlet container customization and other features

• Since container is embedded, it can be customized by the application• Basic options, e.g.

server.portserver.addressserver.sessionTimeout

• Container-specific customizations:TomcatEmbeddedServletContainerFactoryJettyEmbeddedServletContainerFactoryUndertowEmbeddedServletContainerFactory

Migration

Still in progress…

But we hope it will be done in nearby future.

TODO: comparison, tests, final decision…

Questions

?