A microservice is an autonomous sub application for a strictly defined and preferably small domain. An application built from microservices is scalable, resilient, and flexible. At least, if the services and their infrastructure are well designed. One requirement on the used frameworks to achieve scalability and resilience is that they are lightweight. Lightweightness comes in different flavors. Microservices should be stopped and started fastly, and should consume few resources. The development and maintenance of microservices should be easy.
For this reason, in the Java world, Spring Boot is currently recommended as best choice regarding these requirements. Traditional Java EE application servers are too heavyweight, because they are not developed as basis for single services but as platform for running different applications simultaneously. Thus, they must be bloated.
Being a curious person I used some of my spare time in the last Christmas holidays to actually measure the lightweightness. First I chose Spring Boot and WildFly as “competitors”. I added WildFly Swarm which provides similar features as Spring Boot but is based on WildFly. Then looking at the requirements I decided to include a framework with a real small startup time in comparison to Java-based frameworks and chose Snap based an Haskell. For every framework I built a minimal micro service, wrapped it into a Docker container, and measured its weight.
In one of our recent projects we have encountered some memory leaks using standard JavaEE technologies like CDI and EJBs. Our application in question does a lot of communication using JMS as a transportation layer. To be able to handle different message types dynamically we have used the Instance Injection of CDI. Using that approach with CDI might get your trapped into some memory leak problems like we did, so we would like to share our experiences and what you can do about it.
Testing your processes is an important tasks to ensure and validate your expected behaviour of your application. An introduction how to do a proper test automation in process applications can be found the following camunda webinar: https://network.camunda.org/webinars/24
A normal approach for testing your processes is to have your actual service implementation mocked or swapped completely to your own implementation for testing purposes. For CDI based java delegates this is an easy task to do within the camunda BPM test environment.
But if your project does not allow you to rely on your favourite CDI or Spring based environment you have to configure your java delegates for service tasks via class name binding. Unfortunately there seems not to be an out of the box approach to test that kind of configuration easily.
Will will show you how to get use of the great extensibility of the camunda BPM engine to have plain java delegates mocked as easy as their CDI/Spring counterparts.
For simple web sites a static web site generator is often sufficient. Jekyll is such a well know generator. In our company we use JBake, because of its good integration in the Java infrastructure. More information on that is found here: Integration of JBake in Maven – Static Websites.
In my nonbusiness life, I like to play with Haskell. This is why I used Hakyll for a small personal web site. I wanted it to be responsive and choose to use Foundation. To do some styling of the Foundation classes I needed to use SASS and embed it into Hakyll. It took me about two hours to put everything together. To save this time in the future, I extracted a small template with everything in it.
When developing applications using the JBoss EAP/WildFly application server there is a repetitive task that has been solved differently over and over again: The configuration of the application server, i.e. installing JDBC drivers, startup scripts, data sources, JMS destinations, logging categories, etc.
Within our company there are several projects addressing this problem. In this post we’d like to propose a project to combine all those different requirements and experiences into a single build system.
JBoss EAP 7 and ActiveMQ Artemis as connector between temperature and humidity and the application architecture
Most IoT-Applications face similar challenges on its way from sensor to final aggregation in terms of usage and, where applicable relaying of data. In this article, we introduce an architecture based on the new Red Hat JBoss Enterprise Application Platform (JBoss EAP) in Version 7 to outline a IoT application as a showcase.
MQTT has certainly become a standard protocol for IoT and in this context the Internet of Things is integrated via MQTT.
One new major update of JBoss EAP 7 is ActiveMQ Artemis as Messaging Broker with support for MQTT as transport protocol. JBoss EAP 7 is our preferred technology, i.a. for IoT architectures because of its outstanding technological capabilities thus facilitating efficient development of scalable and secure applications.
A combined temperature and humidity sensor, the Bosch XDK, and Harting’s Mica Box are used to supply data. It is the MQTT and the JBoss EAP 7 Middleware that connect and build a bridge between this sensor setup and the rest of the world.
A few days ago, Red Hat released the major version 7 of the open source Java EE application server, Red Hat JBoss Enterprise Application Platform (JBoss EAP).
Red Hat JBoss Enterprise Application Platform (JBoss EAP) is the supported and quality assured version of the WildFly application server from the JBoss community.
The JBoss EAP 7 is based on the version 10 of the WildFly application server. In 2013 Red Hat renamed the JBoss AS community project to WildFly to avoid confusion with the JBoss brand which referred to several different things at once, the application server, the JBoss Community, and a range of other JBoss Products.
The main improvements and highlights of the JBoss EAP 7 release
This article focuses on the following main improvements and highlights of the new major release of the JBoss EAP 7:
- implementation of the new specifications of the Java Enterprise Edition 7
- enhanced modularity
- management improvements
- component updates
- compatibility and interoperability
tl;dr? A summary and pros and cons list can be found at the end of this article plus some useful shortcuts.
The German version of this article is published here.
What is Adobe Experience Design?
It’s Adobe’s missing piece for rapid prototyping of interactive wireframes and simple sharing of those. Design some screens for your app, pull some arrows between them to define interaction, check your work in the preview mode, share the link and do a live demo directly on your phone. The workflow is surprisingly easy.
The tool is currently available for Mac only in version 0.5.2. It’s a preview, hence we will be lenient and wait for features like layers and scrollable boxes.
We have been using successfully Jenkins for a long time, but our Jenkins environment was very outdated. The master and its slaves were still running on JDK1.6 with Jenkins version 1.456. So it was “very” old. Even the installation of new plugins was impossible because these were usually based on Java7. Overall we have 20 Jenkins slaves for 27 projects and 200 jobs. The projects are in several states: just started, ongoing, release or maintanence. The normal project work should not be disturbed by this upgrade.
Therefore we decided not to update the existing installation but to use a completely new Jenkins and update the JDK too.