Lifting and shifting existing applications to the Cloud is a common task for many deveopers these days. This session will explain 3 common scenarios for moving Java EE standards based applications to Azure using concepts applicable to other cloud environments as well. One is of course using Containers and Kubernetes; Second is by using a platform runtime such as Azure AppService. And the third is by using Service Fabric. In the end, we will see the differences, pros/cons, and also open for Q&A.
Java EE, cloud native and service meshes — this doesn’t really sound like a good fit. Or does it? Is it possible to develop modern, cloud native Java Enterprise applications that fulfill concerns such as scalability, monitoring, tracing, or routing — without implementing everything ourselves? And if so, how to do this?
Testing is still a topic that most developers would like to avoid. Even though it is crucial for working software, developing and maintaining tests takes certain time and effort — especially when changes in existing functionality forces test scenarios to adapt or distribution needs to be taken into account. Omitting software tests can’t be the solution; therefore, how can we tackle enterprise tests in an effective and productive way?
There's been a lot of movement in the Java EE world. From the release of its 8th edition to the shift to Eclipse Foundation and recent rebranding to Jakarta EE. At the same time Eclipse MicroProfile shown up on the EE scene with the primary goal of evolving the spec towards microservice architectures.
With all these changes happening rapidly what has happened to Arquillian, the de-facto testing tool for Java EE applications?
During 20 years, we have been accustomed to Java EE (previously J2EE) managed by the Java Community Process. Not all of us were fully happy with this situation: we have often been frustrated by its slow process and its sometimes bloated specifications. But at least, it was considered as a long-term standard. In less than 6 months, everything has changed and now, we have Jakarta EE managed by the Eclipse Foundation. Who could have imagined such a change in a short period of time?
There used to be only one game in town for application servers -- You were either Java EE compliant or you weren't. And, to claim Java EE compliance, a special license was required that allowed you access to the test suites that would prove compliance. Some vendors and open-source projects obtained this license, while others did not. In short, it was not a level playing field. But, all of that is changing now that the Java EE test suites are being contributed to Eclipse under the EE4J project (Jakarta EE). All of these tests will now be freely available under the Eclipse Public License
Last fall at EclipseCon Europe we held a panel discussion on EE4J, the new top-level project at Eclipse for housing the Java EE contributions coming from Oracle. It was very well attended and had excellent discussion. Now that we are a few months further into this process, let's have another panel discussion on where we are at with Jakarta EE. We can start with some preliminary charts to explain the current state of affairs, and then open it up for questions. The make-up of the panel will be determined by who shows up from all of the Jakarta EE participants, but at least we can count on
Already we can see and feel that the development of "Java EE" after the contribution to Eclipse will be different from the past. We are seeing enthusiasm and participation from the various teams at an all-time high! But, what will be different after these contributions to EE4J (Eclipse Enterprise for Java) is complete? Come to this session to learn what's changing, besides just the name... :-) I will give you an overview of the projects already transferred and what projects are left. I will also give an overview of the new and updated processes, as well as what processes still need so
Microservices based architecture seems to be the common convergence point in the industry. But when it comes to security we are still struggling to evolve from monolithic systems or people oriented architecture.