Ensure the efficient development process recommendations
A long time ago, J2EE, in particular, the application server is considered too bloated and "heavyweight." For developers, the use of this technology to develop applications can be very tedious and frustrating. However, the name of the J2EE framework has been changed to Java EE, so the assumption is no longer applicable. Java EE compared to the difference between what corporate framework and the framework with other lightweight What is the standard?
In the choice of technology, one of the most important aspects to consider is developer productivity in the development process. Engineers should spend as much time as patients and revenue-generating capabilities to achieve, because it will allow the company toward the goal.
Techniques and methods should be chosen to minimize the time developers. Specifically what time it: Wait build, test and deploy; configuration applications; business use with the embodiment of unrelated conduit; build and configure the environment and external dependencies. But most of the available technology have not done so.
1. Why standards?
Compared with other frameworks, one of the biggest advantages of Java EE is the use of a standardized API. Standards may sound very boring and not enough innovation - in essence, this is true, because the Java Specification Request (JSR) has been the result of the past have been well-proven in the industry. But the use of these standards has several advantages.
2. Integration Guidelines
Java EE particular API - such as context and dependency injection (CDI), JAX-RS, JSON processing (JSR 353), and verification Bean - can work well together, and may be combined with one another seamlessly. Most importantly, CDI is used as a "glue" between application components. The specification contains information such as "If the container support specifications A and B, then A and B must seamlessly integrate and work well."
For example, JAX-RS support JSONP type, for example, JsonObjectas a request or response entity, which supports calls Bean checking function - if the verification fails, including the correct HTTP status code (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. JAX-RS and Bean Validation integration of JSONP
Use JSONP content type means the type will be application / json, and if the verification fails, sends an HTTP status code 400 Bad Request. This configuration without writing any code that can make everything complete.
Another example is to enable developers to CDI by @Injectinjection Java EE bean managed component object and any user-defined. See Listing 2, to understand a bean validation Validator, which directly use another CDI Managed bean.
public class GameNotPlayedValidator implements ConstraintValidator<NotPlayedYet, Game> {
@Inject
GameHistory history;
public void initialize(NotPlayedYet constraint) {
// no initialization needed
}
public boolean isValid(Game game, ConstraintValidatorContext context) {
return !history.exists(game);
}
}Listing 2. bean validation of CDI integration
Integration is a major aspect of the specification, developers can provide direct experience. Developers can rely on an application server integration and configuration, so you can focus on the business logic of the application.
3. Press the convention over configuration-driven development
Because Java EE configuration convention driving method, most practical applications do not require extensive configuration. Tedious XML descriptors days are over. For simple Java EE applications, you do not need a single XML file.
Because declarative annotations, plain old Java objects (POJO) a simple annotated handle HTTP requests ( @Path), or separately as JavaBeans Enterprise (the EJB) bean ( @ Stateless) - including transactions, monitoring or interceptors. In the past, these methods have been well documented in various frameworks, and has been standardized in Java EE.
If necessary, XML descriptor can still be used when the deployment configuration, but the convention over configuration helps to maximize the efficiency of developers.
4. external dependencies
A few practical business project did not work under any circumstances additional dependencies in the deployment of the workpiece. But these reasons dependencies largely driven by technology - including, for example, or logging entity mapping frame or the like Apache Commons or Google Guava library used - rather than cases.
Java EE 7 - especially when used in conjunction with Java 8 - has sufficient functionality to cover most use cases without any other dependencies. Most of the contents out of the box can use a minimal amount of code to implement, e.g., by injection CDI provider can configure, via the interceptor breaker (see Adam Bien open source library), or by a complicated collection operation Java 8 lambda expressions and streams.
Of course, you could argue that not to reinvent the wheel here. But in fact, in order to save a few lines of code written from the external megabytes of dependencies included in the deployment workpiece does not make much sense.
Experience has shown that the biggest problem is not directly dependent on the introduction of, but passed dependent. Dependent on the application server and the existing library version conflicts are often passed, and lead to challenging conflict. During working hours of the day, developers want to spend more time managing these conflicts, rather than focusing on the time needed to implement a small function to the project. This mainly applies to the case of not having the art embodiment drive driven by dependencies.
Documents relating to simple Java EE 7 project Maven Project Object Model (POM) inspired, see Listing 3, the document inspired by Adam Bien Java EE 7 Essentials Archetype .
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sebastian-daschner</groupId>
<artifactId>game-of-duke</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>game-of-duke</finalName>
</build>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<failOnMissingWebXml>false</failOnMissingWebXml>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
</project>Listing 3. Java EE 7 Maven POM file
Of course, sometimes do need application integration software to achieve the goal of libraries is essential. However, these dependencies required to prove by business needs. In general, it makes sense, saves time and effort to minimize the production of external libraries.
For the test dependencies, it is a different story, because the library, such as JUnit, Mockito or, in some cases, Arquillian - is essential. But again, focus on the test list of dependencies is also significant.
5. Thin Provisioning Artifacts
Since the application server knows Java EE API, so the API does not have to be included in the deployment artifact. Only contain business logic - with minimal glue code and cross concerns.
Accordingly, the size in kilobytes of the workpiece can build very short time, because the build process need to be replicated many things. This can be a difference of a few seconds in each build on. If the summary developer and continuous integration (CI) server all the extra time it takes, it will make a big difference. The higher the frequency of the project - especially true for continuous delivery (CD) scenario - the greater the impact.
In addition to a shorter building time, small-scale deployment artifacts also ensure shorter release and deployment time. Since achieved already included in the run-time, so in all cases, the time spent moving parts is minimal.
The ideal framework 6.Docker
This is the perfect framework for Java EE causes of Docker containers such technology. Docker mirror layer-based, build image, the basic image already contains an operating system, Java runtime and applications. Thus, each unique content added in the last construct is deployed kilobytes thin workpiece. Compared with fat WAR or JAR independent method, which saves time and storage - not only build on each, and when the image version or release.
No matter at what stage, with streamlined deployment artifacts can be achieved very fast and efficient deployment pipeline.
7. Modern Application Server
J2EE application server software is a heavyweight in the start-up and deployment time, and resources reflect the size of the installation space area. But in the new world of Java EE, which are no longer applicable.
All modern Java EE 7 application servers (such as WildFly, Payara, WebSphere Liberty, Profile and TomEE) can initiate and deploy in a matter of seconds. Due to internal, fully modular, they can only load and deploy the required components to streamline the application artifacts as soon as possible.
Now the installation dimensions and footprint is very reasonable. The application server will not consume more than a simple servlet container stuff, but it has a full Java EE functionality. Interestingly, now run the browser instance consumes more memory.
Having said that, each server only deploy one application is possible, may also be justified - either in a container or in the interior. By "each container for each application server one application" approach, you can provide an efficient and flexible solution for modern micro-services architecture.
8. Packaging
In the packaging process, we should not continue to use the EAR files. The entire application is deployed on a separate dedicated server, it requires us to have access to all the components method in that environment, doing so can save more time to build and deploy. In addition, it also avoids the class loading hierarchy tends to cause the problem EAR file.
In most cloud services and micro deployment, use a separate JAR package. Realize when they contain applications and operations. Java EE in the art, this method may use vendor-specific tools to achieve chain, e.g. WildFly Swarm, Payara Micro or TomEE Embedded.
However, due to the above reasons, I strongly recommend to separate the business logic runs as possible. This means that the application is packaged in a WAR file that contains only the application code.
In my opinion, if the company due to the "political" rather than technical reasons beyond the control of the installation or operation process, the independent JAR file is a useful solution. We can solve a considerable number of non-technical problems and then transported everything you need to deploy the workpiece and requires only JRE.
9. Recommendations on efficient development processes
One of the most effective enterprise project solution is as follows:
- Only used when providing API Java EE 7 and Java 8
- Kilobytes build a WAR file size, and contains only the minimum pipe business logic (e.g., JAX-RS resource or JPA)
- Construction of Docker image - only to add the WAR file to the application server that contains the configuration of the base image
- Transmitted through the use of containers to deploy applications CD pipes
10. Conclusion
"Heavyweight Java EE" is certainly the end of the day. API Java EE included providing seamless integration within the efficient and enjoyable experience, and standards developers. In particular, when the separated application code and operating method for fast, efficient development process.
The new multi-vendor sponsored MicroProfile plan, the future may further reduce the required components of Java EE.
Reference material
- Java EE 7 Essentials Archetype
- Blog article: " Stop saying 'Heavyweight' "
- Java EE circuit breaker implementation
Original: https: //community.oracle.com/docs/DOC-1008823
Author: Sebastian Daschner
Translator: [KeepGoingPawn] (https://blog.csdn.net/hengji666
September welfare, public concern number backstage reply: 004, receive translations in August highlights! Go on welfare Re: 001, 002, 003 can receive!
