Book Image

Java EE 8 Cookbook

By : Elder Moraes
Book Image

Java EE 8 Cookbook

By: Elder Moraes

Overview of this book

Java EE is a collection of technologies and APIs to support Enterprise Application development. The choice of what to use and when can be dauntingly complex for any developer. This book will help you master this. Packed with easy to follow recipes, this is your guide to becoming productive with Java EE 8. You will begin by seeing the latest features of Java EE 8, including major Java EE 8 APIs and specifications such as JSF 2.3, and CDI 2.0, and what they mean for you. You will use the new features of Java EE 8 to implement web-based services for your client applications. You will then learn to process the Model and Streaming APIs using JSON-P and JSON-B and will learn to use the Java Lambdas support offered in JSON-P. There are more recipes to fine-tune your RESTful development, and you will learn about the Reactive enhancements offered by the JAX-RS 2.1 specification. Later on, you will learn about the role of multithreading in your enterprise applications and how to integrate them for transaction handling. This is followed by implementing microservices with Java EE and the advancements made by Java EE for cloud computing. The final set of recipes shows you how take advantage of the latest security features and authenticate your enterprise application. At the end of the book, the Appendix shows you how knowledge sharing can change your career and your life.
Table of Contents (14 chapters)

Building decoupled services

Maybe you have, at least heard something about building decoupled things in the software world: decoupled classes, decoupled modules, and also decoupled services.

But what does it mean for a software unit being decoupled from another?

In a practical way, two things are coupled when any changes made to one of them requires you to also change the other one. For example, if you have a method that returns a String and changes it to return a Double, all the methods calling that one are required to be changed.

There are levels of coupling. For example, you could have all your classes and methods very well designed for loose coupling, but they are all written in Java. If you change one of them to .NET and would like to keep all of them together (in the same deployment package), you need to change all the other ones to the new language.

Another thing to mention...