Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Is vaadin the right choice for real-time applications ?
I'd like to have your advices concerning our proof of concept architecture.
We want to develop a real-time web application displaying some events in our web interface.
Recently we switched to vaadin framework for our front end application and we'd like to have your opinions on this point.
The web application runs on Oracle WebLogic application server to display events that are pushed (published) by our Oracle event processing applications to a publish subscribe (pubsub) server alson running on Oracle WebLogic.
Right now, the web application (Vaadin) is composed of vaadin components that connect to the pubsub server as subscriber to be notified of a new event published.
When a new event is handled by the subscriber, we would like to refresh some our Vaadin components that are the graphical representation of events like charts ...
This web application needs to support a big amount of events and we have to be sure of our architecture choice to prevent some performance issues.
What are the limitations that you think we will reach with this architecture ?
Is the websocket or other protocols instead of pubsub is more convenient for this environment ?
Thanks for your opinions
as usual the answer is 'it depends', and when you talk about real-time then of course the question is how fast is fast enough, and how reliable is reliable enough.
I wouldn't want my car's brakes to be controlled by a web application on the open Internet -- yet, if a web application is fast enough (e.g. you control the servers' and clients' horsepower and the network latency and the maximum bandwidth both provided by the network hardware and used by the application) for your application then fine -- Vaadin is a good choice!!
It's hard to say how performant the parts in your application are (PubSub is often running atop Web Sockets, so you'll have to investigate what your implementation does and how to optimize it -- no decision/architecture is 'better' per se without more information).
But you can of course copy designs that are known to work; e.g. using BlueMix in the Cloud is fast enough for realtime data monitoring of a flying drone:
I am sorry if I cannot help too much here, but this is inherent to the subject matter.
Agree with Enver: it depends.
In terms of pushing real-time updates into the browser I don't think there is a better technology than WebSockets, currently.
Just wanted to point out something. Whatever your UI technology is (browser, fat client, etc) there's no UI technology which can cope with more can say 10 updates per second for the same data item. It is pointless to try to send more than this to the UI, for two reasons:
- The UI may become overwhelmed by the amount of re-painting it has to do. The result may be that the UI will become unresponsive from user point of view.
- You'll get the "petrol pump effect", i.e. updates will (unless #1 kicks in first) come in such short order that it becomes impossible for the human eye to see the actual values because they will appear to be 'spinning'. Obviously this point relates more to grids (i.e. cell-style updates) than to graphs.
Therefore, if you suspect that you are in this situation then you have no choice but to implement some kind of conflation strategy on the server so that the message rate from server to browser can be controlled. If you think about it is actually much easier in the polling scenario because then you are in full control of the message rate. But polling has its own drawbacks.
My experience comes mainly from updating grids/tables in real-time, not graphs. But I do believe the above still applies.
Best of luck.
We are using Vaadin as frontend UI for our embedded building automation controllers. This industry sector needs typical response time about 1 second, what can achieved with polling (BTW on a page presenting about 30 sensors and actors 1 second polling generates less traffic then push).
Do not forget, performance is not the only issue you should keep in mind. Vaadin expects the data modifications are performed by human sitting in front of the monitor. If you start to push data from the backend drivers, typical using properties as field data sources, you will have to solve tons of other problems like setting values on readonly fields etc. We ended up modifying parts of Vaadin source code.
Robert, could you please elaborate on what you felt you had to change and why?
Would it have been possible to implement the thing as an add-on (e.g. a second version of Grid or so) or was it so deep in the core you felt you had to change it there?
I personally care about IoT a lot and wonder what problems you were running into and how you solved them.
1. Memory: Embedded or IoT systems have typical less memory available. Our embedded system runs with 256 MB RAM. We can compile Vadin into one small jar file (about 4 MB including embedded Jetty server), which is great, but unfortunately, Vaadin code uses Java Beans introspection or even AWT class references that force the installation of the full Java JRE stack. To be able to run Vaadin on Java8 compact3 profile ( the difference is huge: compact3 24MB, Full Java 140 MB ) we had to replace java.beans with our introspection library (based on Java reflection), and to remove Java AWT (!) dependencies in ColorPicker. Our Vaadin core runs now with Java8 compact3 profile.
2. Vaadin JAR dependencies: Properly designed Vaadin app compiles shared + client code parts into a Widget set. In other words, client code should be referenced only from a shared module. That should avoid runtime dependencies on the client modules, which, in turn, do not have to be installed on the server. Unfortunately, we are still finding class references between server and client artifacts. These dependencies force the user to install client modules (and in some circumstances their dependencies). It consumes the valuable memory on a small embedded system.
3. One of the issues where I do not understand the code designer's idea: read-only fields. In Swing, for example, the read-only attribute is an attribute of the presentation layer, where read-only means that the user cannot modify the value of a component through the UI, while the code can still freely update the value of the widget. In Vaadin the read-only attribute ends up being on the data model side. That prevents both the UI and backend from updating a read only attribute. That is the serious problem on systems where the data are coming from a technological process (e.g. thermostat, light status, etc.), the fields should be read-only for the user but updateable by the code. BTW there is a setValue() method with a parameter allowing writing the value into the read-only field ... it's protected by definition and works only on subclasses. No comment.
There are much more issues. In the past, I tried to describe the problems in the Vaadin forum, mostly without any feedback. Today I am not sure if Vaadin is the right choice for data presentation on IoT devices.
if you need fastest turnaround times between client browser and IoT devices, please consider
using the client-side Vaadin offerings as well - see here: https://vaadin.com/elements , including
Charts for real-time sensor data visualization.
So basically "Vaadin" is no longer only "Vaadin Framework", but also "Vaadin Elements",
the latter coming with entirely different characteristics in terms of programming language
and client-and-server-and-IoT connectivity characteristics.
I am terribly sorry if the forum wasn't helpful in the past -- post like yours however do really
help others and make the forums better, in turn making more people join and share their
And needless to say -- Vaadin as a company is here to help with your projects, too.
Where the forums don't have an answer it's probably because our really good staff
is working in projects like yours for money and don't find the time to spend on the
forums unfortunately! htttps://vaadin.com/support
Here http://univagora.ro/jour/index.php/ijccc/article/view/1565/443 is the architecture of an application with similar requirements. I applogize for promoting my own papers. Unfortunately not done in Vaadin, but it can be adapted to run in Vaadin quite easy.
A few highlights:
- the application will never be realtime, if you consider the Google definition of realtime: In computer science, real-time computing (RTC), or reactive computing describes hardware and software systems subject to a "real-time constraint", for example from event to system response. Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines". Realtime means that if you failed the deadline, the call turns in an error and the system is considered faulty. Don't want to turn this in a philosophical debate. The dashboard will normally update when needed, with the goal of minimizing the delay between "data available" and "data displayed", and will let the user know the timestamp of the data. This is more or less what @Enver said on the car's breaks being controlled by a "not so realtime" system.
- there is a compromise between the amount of work done on server and on client. In my approach, I was expecting *many* (possibly hundred) of sessions, so most of the computation occurs once on the server, than shared to all the sessions.
- @Robert: in my case the sensors (developed by NASA JPL) have a modest hardware too; however, they don't run web servers but they transmit data to a central location (which is a Cray mainframe), where the actual processing takes place. My application runs on a COTS Intel server and collects processed data from the mainframe and does further processing by computing some statistics. Further versions apply a neural network on the signals. I don't think it is a good idea to host the server on the embedded system, this will slow down its main functions.
- The "petrol pump effect" mentioned by @Peter got mitigated by using a technique similar to double buffering, described in the paper.
I created a visualization application designs to visuallze big data using vaadin charts. it took a lot of hacking but in the end got it to work.
Thanks all for your answers
Someone pointed out on one forum that Vaadin is designed in the way that all must come trough the server, which could actually become quickly the bottleneck with dozen of users. So of course the idea is let the client process stuff and keep server side lighter. As far as I understood this is targeted by Vaadin Elements.
But it is not anymore pure Java facade, but you are open to Polymer and NodeJS stuff, I need to read more, but is my general assumption correct?
Thanks for confirmation.
Faisal Zeeshan: I created a visualization application designs to visuallze big data using vaadin charts. it took a lot of hacking but in the end got it to work.
Post the solution on github then :-))))
Here's an older article for Vaadin Framework 7 which also applies to Vaadin Framework 8.
server side in Java. Of course, you need to decide if you would rather like to go for a Vaadin Elements
based solution that's more strongly focused on the client side.
taste and technical necessity.