One of the principles of Java EE is to provide a productive enterprise API. As seen in the Concepts and design principles of modern Java EE section in the previous chapter, one of the biggest advantages is the ability to integrate different standards without developer-side configuration required. The Java EE umbrella requires the different standards to work well together. The enterprise container has to meet this requirement. The software engineers only develop against the APIs and let the application server do the hard integration work.

Following the convention over configuration approach, using different, integrated standards that are part of the umbrella specification doesn't require initial configuration. As seen in various examples previously, the technologies that have emerged from different standards within Java EE work well with each other. We have seen examples such as using JSON-B to automatically map objects to JSON in JAX-RS resources; integrating Bean Validation into JAX-RS and therefore HTTP responses by introducing a single annotation; injecting managed beans into instances defined by other standards, such as Bean Validation validators or JSON-B type adapters; or managing technical transactions that span JPA database operations in EJBs.

What is the alternative to using an umbrella standard that embraces various reusable technologies? Well, to introduce vendor-specific frameworks with third-party dependencies that need to be wired together with manual developer work involved. One of the biggest advantages of the Java EE API is having the whole variety of technology right at the developer's fingertips; providing productive integration and saving developers time for focusing on business use cases.