Microservices and their frameworks like spring boot allow to start fast but can easily produce architectures that are difficult to maintain. OSGi on the other hand provides great modularity but is regarded as more complex than spring boot and alike. This Talk shows how to create lean and modular microservices using OSGi, maven and bndtools. The build result is a runnable jar or docker image and nicely fits microservice deployments. See how OSGi allows the flexibility to deploy each microservice on its own and let them communicate over (REST) remote calls or deploy them together and talk using OSGi services locally using the same business code bundles.

Creating a modular system leads to a number of benefits, from technical improvements to organizational improvements. However, at scale modularity can require a significant amount of mental energy. The OSGi model is fundamentally based on the idea of injecting knowledge into individual modules which frameworks use to great effect. But given hundreds or thousands of modules the sheer volumn of information can make reasoning about them difficult. Luckily OSGi defines mechanisms for performing operations to reason over arbitrary number of modules. This talk will review and demonstrate the capabilities of these mechanism.

Data is being produced everywhere, there are sensors in thousands of homes, metrics collection from your cloud applications, industrial sensors manage the safe provision of water and electricity. The question is, what do we do with all of this data? How do you cope with thousands (or millions) of push-based data events per second? A crucial part of any of any solution is to have the right primitives. An asynchronous, push-based event processing pipeline is essential. OSGi Push Streams offer the power and simplicity of Java 8 streams, but with the power of asynchronous push-based events. This talk will describe the work happening in OSGi’s Push Streams RFC, using streams and promises to build scalable event processing pipelines. Finally the speaker will demonstrate live processing of real IoT data streams using OSGi Push Streams!

Today’s Web applications are large and complex systems. Most of them are also hard to support, maintain and improve. In this talk we will focus on a crucial requirement to make a Web application maintainable - to build it from small pieces of modules, each of them replaceable, pluggable and testable. We will explore the different ways of achieving it, what JavaScript provides OOTB and finally, how to share code between the server and the browser.

We have been working in the area of modular software development for many years now. This talk is structured into two parts. The first part is about the basics behind modularity. What is modularity? What are best practice patterns behind it? How can we use Java to create real modular systems? What is the problem with WAR files and ServletContainers? Why can OSGi handle modularity so much better than JEE can? What about WildFly’s module system to create modular systems? How can we “make” JEE more modular? After part one the attendees know the difference between JEE-, OSGi- and Wildfly-ClassLoader-Architecture. And they will understand why (and how) OSGi allows to write much more modular systems then JEE containers do. In the second part, I will do a live demo and we are going to write a highly modular web application based on OSGi and Vaadin. We will make use of the brand new Vaadin-OSGi-R6 implementation based on the OSGi Prototype Scope. After this talk, the attendees will have good knowledge about modularity in web applications, the problems we are facing and a best practice implementation for a highly modular web application.

Web applications have grown a lot, and they consume a really huge amount of data. One of the most important aspects that were holding them back was the client started transactions. Some alternatives were created trying to overcome the previous problem (like long-polling), but the main problem affecting to all these alternatives was the HTTP overhead. Trying to solve many of the problems described above, the WebSocket alternative was created. RFC 6455 defines an important new capability for web applications: a full-duplex, two-way communication channel between the client and the server. Thanks to this fact, we can have a low level, bidirectional communication channel where transactions can be started in both endpoints. During the talk we’ll discover how Websockets work, how we can use them in our OSGi container using the Whiteboard pattern, and, last but not least, we will learn how to build applications that can benefit from all the new goodies offered by this infrastructure we’ve built.