If you have an application on TomEE and want to deploy it on Microsoft's Azure cloud, then this blog post is for you. Once everything is configured, the build and the deployment will require only a single command line and you will be able to access the application from anywhere in the World! Downloading TomEE-Azure Module We have already prepared a TomEE/Azure module ( cloud-tomee-azure module found in the TomEE examples) to make working with TomEE in Azure much easier. To take advantage of this module, you will first need to checkout TomEE from Github: git clone [email protected]:apache/tomee.git Then, navigate…
Read More
In a previous article, WebSocket and Lock it! we showed how to use basic authentication on websocket calls to an application deployed on TomEE. In this article, we explain how to add SSL/TLS security to the connection between the client and the application server. To demonstrate this, we've created a new wss-secured-websocket project. This work is valid both for Secure Websocket (WSS) and HTTPS. Adding transport layer security is important in order to protect the data exchange. Payloads and headers are sent in clear text when using simple HTTP. This is critical when considering the authentication header. As you can…
Read More
This is the final of a series of 3 articles dedicated to the MicroProfile Fault Tolerance. We started by introducing and giving an overview of the specification in “MicroProfile Fault Tolerance, Take 2”. Next, we explained the different annotations and their options in “MicroProfile Fault Tolerance Annotations”. Now we take a look at practical MicroProfile Fault Tolerance examples using TomEE 7.1. This version of TomEE is compliant with MicroProfile v1.2 and includes the Geronimo Safegard library implementing the Fault Tolerance v1.0 spec. The MicroProfile Samples project We’ll be using the microprofile-samples project created by Roberto Cortez and which is available on…
Read More
In our last article about Microprofile Fault Tolerance we explained the motivation for this project and the need to provide a few design patterns under the microservice friendly Microprofile spec, namely: Bulkhead – isolate failures in part of the system. Circuit breaker – offer a way to fail fast. Retry – define criteria on when to retry. Fallback – provide an alternative solution for a failed execution. We also presented some of the libraries that implement this Microprofile specification, including the Geronimo Safegard library, the one used on TomEE 7.1. Lets now dive a bit deeper into the spec and…
Read More
Understanding Fault Tolerance and the strategies of resilience and eventual consistency are extremely important to microservices. This article an update and expansion of an article written in April of this year. It’s the first part in a series of articles explaining how the MicroProfile Fault Tolerance specification is used in microservices. The Rise of Resilience and Eventual Consistency The Rise of Resilience and Eventual Consistency For decades the prevailing wisdom for handling transactions in distributed systems has been the use of SQL Relational Databases, binary communication protocols, and two-phase commit transactions. All-or-nothing and reliable transactions were paramount, data had to…
Read More
My road trip from Coimbra, Portugal to Madrid, Spain, where I spoke to the Madrid JUG about REST security, was beautiful, but full of wrong turns, some potholes, and flash thunderstorms. It reminded me of my adventure in learning and coming to understand REST security. There are so many security specifications that it's easy to get turned around and to encounter new technical concepts. The "Deconstructing REST Security" talk, originally created by David Blevins, is like a clear roadmap to navigate the potholes and thunderstorms of REST security. It makes navigating the difficulties far simpler, providing both context and a clear route to…
Read More
The need With the rise of microservices or large scale distributed systems and communicating through HTTP and NoSql databases, we also see the rise of eventual consistency. The focus on reliability or the perfect operation at all times had to shift to resilience; the ability of an application to recover from certain types of failure and yet remain functional. All-or-nothing and reliable transactions were paramount, data had to be safely stored above all, sacrificing the user experience and cost. The objects on those transactions could also be very complex, frequently using multiple tables and even different databases. Typically, if a…
Read More
