All J2EE Components Are Written in The Java Programming Language
This sentence is clearly description of J2EE. I can only use Java to develop. I have heard that some open source enthusiasts can be done with .NET, then work through some converters, I don't know much about this thing. However, I have to develop .Net use Microsoft's things, don't think too much, after all, the one is professional. Develop J2EE or calculate it with Java.
The Java 2 Enterprise Edition (J2EE) IS A Multitiered Architecture for Implementing Enterprise-Class Applications and Web Based Applications.
This sentence has explained the way J2EE's presentation.
The Main Aim of J2EE Technology Is To create a Simple Development Model for Enterprise Applications Using Component Based Application Model.
J2EE's purpose is to make more simple development enterprise applications, but I think it is really not simple in configuring J2EE.
Note this May Not Be Ideal in All Scenarios: for Example, A Small Scale Application Might Be a better Fit for a Light-Weight Java Technology Solution
This sentence tells me that you don't want to be superstitious J2EE, you have to change due to needs. The appropriate architecture is selected according to the actual situation.
I will use the project to implement using web client. I have more energy to study this part.
As can be seen from the above figure, web browser wants to access Business Tier through servlets or JSP, and you can also use Java Beans Components between Web Tier and Business Tier.
Let's take a look at Business Components Communication.
Enterprise Beans has three types:
Session Beans (Stateless and Stateful)
Entity Beans (Bean Managed and Container Managed)
Message-Driven Beans
The document is described in Session Beans, "A Session Bean Repesents a Transient Conversation with aclient. When the Client Finishes Executing, The Session Bean and ITS Data Are Gone". Entity Beans has its opposite characteristics, "if the client terminates or if the server shuts down, the underlying service ensure" the entry bean data is saved ". Message-Driven Beans is a combination of sessions and JMS interfaces. JMS is a good thing. In a large retail system I have made, communication between various components is through JMS, but JMS now seems to be more expensive, and free There is another problem, often increasing memory consumption without any reason.
Here you must distinguish between two concepts Java Beans and Enterprise Java Beans. Java Beans can be used on the Server side and the Client layer, which can be used as part of a client application, or can run on the J2EE Server or between Server components and databases. But EJB can only be in the business layer of the Server layer. Here is the original description, "Java Beans are not considered J2EE components by the J2EE specification as JavaBeans are different from Enterprise Beans. JavaBeans component architecture can be used in both server and client tiers to manage the communication between an application client or applet and components running on the J2EE server or between server components and a database, whereas Enterprise JavaBeans components are only used in the business tier as a part of the server tier. JavaBeans have instance variables and has an accessor and mutator methods to access properties of bean or say Accessing The Data in The Instance Variables Which Simplifies The Design and Implementation of JavaBeans Components. J2EE Containers
J2EE's container provides a lot of convenience, such as multithreading, transaction, status, thread pool, etc., now the container has already provided. We only need to concentrate on the processing of business.
The container is actually a bridge between business components and system underlying functions. So I think that some time ago is spent repeating some underlying functions. If there are some projects accumulating, or you can reuse the thread pools, now J2EE Container is provided, but the time is spent on the configuration, so we have to rely on Tools to perform automatic configuration, if there is no such tools, the original intention of J2EE has lost, and developing an enterprise-level system will use more time.
J2EE Server itself has integrated Web Container and EJB Container. In fact, the client is also using Java's Container, which is our familiar JRE.
Packaging packing
I think that the most complicated thing in J2EE is packaged, a big pile of XML files, and there is nothing to check, only if the deployment will only know if it is correct. If all have to handw it, it is equal to returning to the original era. Fortunately, Lomboz will automatically use XDoclet to generate these things.
The web component will be packaged into Web Archive (.war). There will be Sevlets, JSP, and some static resources such as HTML, pictures, etc.
Business components will package into Java Archive (.jar). The script, Remote, Object Interface file, etc. included in the EJB deployment.
We will also see this file format in the client, in fact, it can be said to be a local executable.
The J2EE program will pack the above files into Enterprise Archive (.ear), including all the files required for deployment. As shown below: Role J2EE Platform Roles
There are many roles in the J2EE specification, namely Developer, Assembler, Deployer, System Administartor, Tool Rovider. In the current domestic development environment, the division of labor has not yet been in such a detailed point, and a person will have a number of characters. In addition to Tool Provider and developer, others can do it. ASSEMBLER This role I intend to use Daily Bulid tools to deal with this role, "The Application Assembler Takes All Building Blocks from the Application Company," The Application, the Application Company, "The Application, the Application Company," The Application, the Application Company, "The Application, the Application Company,". ". Deployer will use open source automatic deployment tool Ant, so we can concentrate energy in development services.
