This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

JVx application on embedded devices

In the last weeks, we did many experiments with JVx on Raspberry Pi, especially using a Pi as server for JVx applications. Our vision was that the business logic could run on a Pi without Java application server like Tomcat or Jetty. Our example application was a simple sensor recorder. We read temperature data and stored the read data into a JavaDB (on the same device). We knew that Jetty and Tomcat worked on a Pi but it was not necessary to run an application server without web content.

We tried different implementations:

  • Fun

    A recorder class that saved data directly in the JavaDB. A good old Java application with one DBStorage because plain JDBC was painful.

  • Because JVx can do that

    A simple recorder client with embedded JVx server. The client was a simple class with a DirectServerConnection. The server saved retrieved temperature data in the JavaDB.

  • Production

    The same simple recorder client but the server run standalone. The DirectServerConnection was replaced with a Netconnection.

The first implementation was for fun only and not relevant for our tests. Our Pi should be a server that measures data and allows accessing data from JavaDB (for charts). Some real client applications could use the temperature server for integrating temperature data. The same application could use other Sensor data from different RasPis (measuring lux, webcam, ...) - a RasPi (sensor) network.

The big problem was that JVx server didn't work without an application server. It worked embedded and via http, but we didn't have a plain socket implementation. It wasn't a JVx problem because the server component was ready for socket connections but we didn't have a Socket server. We made some experiments with vert.x and the result was a nice socket server. We also used JVx with vert.x Http server. Both implementations are available on GitHub. It worked like a charm but we didn't like the library dependencies. We already had a socket server API for our product VisionX, but it wasn't decoupled. Now it is!

We used the VisionX socket API and merged it in our applications library. After some modifications and bugfixes, in JVx, it's now possible to use it without additional dependencies. It's a simple socket server for JVx server component. We've used this server to run VisionX and had no problems. VisionX is a huge JVx application and if VisionX works, all other JVx applications will work.

It's very simple to use the the socket server:

NetServer server = new NetServer("servername", 556);

The server has a main method and you can use it without additional coding. Simply set the system properties server.hostname, server.port.

To open a connection, simply call:

IConnection con = new NetConnection("servername", 556);

MasterConnection appcon = new MasterConnection(con);

Not really rocket-science and just works!

The only problem was the server name and port configuration, for every client. Not really cool in a "sensor network". So we started a simple Broadcaster. It's a simple class that checks the network for existing servers. It's easy to use on client-side:

List<ConnectInfo> liConInfo ="MyAPP");

and the server side isn't too complex:

Broadcaster broadcaster = new Broadcaster();

The result contains a list of available hostnames and ports for the first found server. It's still space for a better solution, but I think that's the reason why vert.x uses hazelcast.

To cut a long story short: It's now possible to use complete JVx applications without Java application server, especially on embedded devices like RaspberryPi.

Sure, it's still recommended to use an application server if your device serves web content or a whole web application e.g. with JVx' vaadin UI (see IoT: Window shutter control).

Leave a Reply

Spam protection by WP Captcha-Free