Shulou(Shulou.com)06/02 Report--

This article mainly introduces "the introduction of the Java EE framework". In the daily operation, I believe that many people have doubts about the introduction of the Java EE framework. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about the introduction of the Java EE framework. Next, please follow the editor to study!

Recommendations to ensure an efficient development process

A long time ago, J2EE, especially application servers, was considered too bloated and "heavyweight". For developers, developing applications using this technology can be tedious and frustrating. However, because the name of the J2EE framework has been changed to Java EE, this assumption no longer applies. How does Java EE differ from other enterprise frameworks and what is the lightweight standard of the framework?

One of the most important aspects to consider when choosing a technology is the developer's productivity in the development process. Engineers should spend as much time as possible implementing use cases and revenue-generating functions, as this will move the company towards its goals.

The technology and method you choose should minimize the developer's time. Specific time: waiting to build, test, and deploy; configure applications; implement pipes that are independent of business use cases; and configure the build environment and external dependencies. But most of the available technologies do not do so.

1. Why the standard?

One of the biggest advantages of Java EE over other frameworks is the standardization of the API used. Standards may sound boring and not innovative enough-in essence, this is true because Java specification requests (JSR) have become a well-proven result in the industry in the past. But there are several advantages to using these standards.

two。 Integration specification

Specific API in Java EE-such as context and dependency injection (CDI), JAX-RS,JSON processing (JSR 353), and Bean validation-work well together and can be seamlessly combined with each other. Most importantly, CDI is used as the "glue" between application components. The specification includes things such as * "if the container supports specifications An and B, then A must integrate seamlessly with B and work well." *

For example, JAX-RS supports JSONP types, such as JsonObject as a request or response entity, which allows you to call Bean validation-including the correct HTTP status code if validation fails (see listing 1).

@ Path ("duke") public class DukeResource {@ GET public JsonObject getDuke () {return Json.createObjectBuilder () .add ("name", "Duke") .build ();} @ POST public void create (@ Valid @ NotPlayedYet Game game) {/ / game object has been validated at this point}}

Listing 1. JSONP and Bean Validation integration of JAX-RS

Using the JSONP type means that the content type will be application / json, and if the validation fails, the HTTP status code 400 Bad Request will be sent. This doesn't require any configuration code to get everything done.

Another example is CDI, which enables developers to inject any bean and user-defined objects into Java EE managed components through @ Inject. See listing 2 for an bean authentication Validator that uses another CDI managed bean directly.

Public class GameNotPlayedValidator implements ConstraintValidator {@ Inject GameHistory history; public void initialize (NotPlayedYet constraint) {/ / no initialization needed} public boolean isValid (Game game, ConstraintValidatorContext context) {return! history.exists (game);}}

Listing 2. CDI integration for bean validation

Integration is a major aspect of the specification that provides a direct developer experience. Developers can rely on the application server for integration and configuration, so they can focus on the application's business logic.

3. Drive development according to configuration convention

Because of Java EE's configuration convention-driven approach, most real-world applications do not require a lot of configuration. The days of tedious XML descriptors are over. For simple Java EE applications, you do not need a single XML file.

Due to declarative annotations, a simple annotated plain old Java object (POJO) handles HTTP requests (@ Path) or acts as Enterprise JavaBeans (EJB) bean (@ Stateless)-including transactions, monitors, or interceptors, respectively. In the past, these methods have been well documented in various frameworks and standardized in Java EE.

XML descriptors can still be used for deployment-time configuration if needed, but configuration conventions help maximize developer productivity.

4. External dependence

A few actual enterprise projects work without any additional dependencies in the deployment artifacts. But the reasons for these dependencies are primarily technology-driven-including, for example, logging or entity mapping frameworks or common libraries such as Apache Commons or Google Guava-rather than use cases.

Java EE 7-especially when used with Java 8-has enough functionality to cover most use cases without any other dependencies. Most of the content out of the box can be achieved with a minimum amount of code, for example, through the injectable configuration of the CDI provider, through the interceptor's circuit breaker (see Adam Bien's open source library), or through complex collection manipulation of Java 8 lambda expressions and streams.

Of course, you can argue not to reinvent the wheel here. But in fact, in order to save some self-written lines of code, it doesn't make much sense to include megabytes of external dependencies in the deployment artifact.

Experience has shown that the biggest problem is not the dependency that is directly introduced, but the dependency that is transmitted. Passed dependencies often conflict with existing library versions on the application server and lead to challenging conflicts. During the working day, developers spend more time managing these conflicts, rather than focusing on the time it takes to implement small functions into the project. This mainly applies to dependencies that are technology-driven rather than use-case-driven.

For file inspiration for the simple Java EE 7 project Maven Project object Model (POM), see listing 3, which is inspired by Adam Bien Java EE 7 Essentials Archetype.

4.0.0 com.sebastian-daschner game-of-duke 1.0-SNAPSHOT war javax javaee-api 7.0 provided game-of-duke 1.8 1.8 false UTF-8

Listing 3. Java EE 7 Maven POM file

Of course, sometimes applications do need to integrate libraries that are critical to achieving software goals. However, these dependencies need to be demonstrated by business requirements. In general, it makes sense and saves time and effort to minimize external production libraries.

This is a different story for testing dependencies, because libraries, such as JUnit,Mockito or, in some cases, Arquillian-are critical. But again, it makes sense to focus on the list of test dependencies.

5. Simplified deployment of Artifacts

Because the application server knows the Java EE API, the API does not have to be included in the deployment artifact. Contains only business logic-requires minimal glue code and cross-concerns.

Therefore, these kilobyte artifacts can make the build time very short, because the build process does not need to copy a lot of things. This can make a difference of a few seconds on each build. If you sum up all the extra time spent by developers and continuous integration (CI) servers, it makes a big difference. The higher the frequency of project construction-especially for continuous delivery (CD) scenarios-the greater the impact.

In addition to shorter build times, small deployment artifacts ensures shorter release and deployment times. Because the implementation is already included in the runtime, it takes the least time to move the part in all cases.

The ideal Framework of 6.Docker

This is why Java EE is the perfect framework for container technologies such as Docker. Docker mirrors are based on layers, and when you build an image, the basic image already includes the operating system, Java runtime, and applications. Therefore, the only thing added to each build is the last kilobyte thin layer of the deployment artifact. This saves time and storage compared to the fat WAR or stand-alone JAR approach-not only on each build, but also when the image is versioned or released.

At any stage, having a streamlined deployment artifacts enables a very fast and efficient deployment pipeline.

7. Modern application server

J2EE application server is the embodiment of heavyweight software in terms of startup and deployment time, installation size and resource footprint. But in the new world of Java EE, this no longer applies.

All modern Java EE 7 application servers, such as WildFly,Payara,WebSphere Liberty,Profile and TomEE, can be started and deployed in seconds. Because of their internal and comprehensive modularity, they can only load the required components and deploy a streamlined application artifacts as soon as possible.

The current installation size and floor area are very reasonable. The application server does not consume more than a simple servlet container, but it has full Java EE functionality. Interestingly, the browser instance that is running now consumes more memory.

That said, it is possible and reasonable to deploy only one application per server-whether in a container or internally. Through the "one application per container per application server" approach, you can provide efficient and flexible solutions for modern micro-service architectures.

8. Packing

EAR files should no longer be used during the packaging process. Deploying the entire application on a separate, dedicated server requires that we have access to all component methods in that environment, which saves more build and deployment time. In addition, this avoids the class loading hierarchy problems that EAR files tend to cause.

In most cloud and microservice deployments, a separate JAR package is used. They contain applications and runtime implementations. In the Java EE world, this approach can be implemented using a vendor-specific tool chain, such as WildFly Swarm,Payara Micro or TomEE Embedded.

However, for the above reasons, I strongly recommend that business logic be separated from the runtime as much as possible. This means packaging the application in a WAR file that contains only the application code.

In my opinion, a separate JAR file is a useful solution if the installation or operation process cannot be controlled due to company "political" problems rather than technical reasons. A considerable number of non-technical problems can then be solved when shipping everything needed in the deployment artifact and only JRE is needed.

9. Suggestions on efficient R & D process

One of the most effective solutions for enterprise projects is as follows:

Use Java EE 7 and Java 8 only when providing API

Build a kilobyte WAR file that contains only business logic and minimum pipes (such as JAX-RS resources or JPA)

Build Docker image-add only the WAR file to the base image that contains the configured application server

Delivered by using the CD pipeline of the container deployment application

10. Conclusion

The days of "heavyweight Java EE" must be over. The API included in Java EE provides an efficient and enjoyable developer experience and seamless integration within standards. In particular, the method of separating application code from the runtime enables a fast and efficient development process.

Through a new MicroProfile initiative initiated by multiple vendors, the components required for Java EE may be further reduced in the future.

At this point, the study of "introduction to the Java EE framework" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.