J2EE Architecture is a standard for developing Enterprise business systems that effectively replaces all other models.
J2EE is a component-based programming model. This means it consists of many components (perhaps combined in modules) that reside in runtime systems called containers. Along with the standard J2EE services for connection with EIS and communication, they create a stable and secure environment for business applications.
The main concepts in the J2EE architecture are:
The J2EE Architecture
A component is an independent software unit. It can be used independently, or for development of modules used in applications. In addition to the JavaBeans™ component model defined in J2SE, J2EE defines the following components.
Web components exist in Web containers that manage client requests using Web browsers. Web containers are situated in the middle tier. J2EE defines two kinds of Web components:
EJB components exist in EJB containers that manage client requests – directly or using Web containers. The EJB containers are situated in the middle tier. The EJB components typically contain the business logic of the application.
Applications exist in containers that ensure access to J2EE services and communication. They are executed on their own virtual machine, and are situated in the client tier.
Java Applets exist in containers that ensure the environment for the applets’ execution. Applets run on their own virtual machine. Typically, Web browsers provide their execution environment.
Containers are the interface between a component and the low-level, platform-specific function that supports the component. Before a Web, enterprise bean, or application client component can be executed, it must be assembled into a J2EE application and deployed on its container.
The assembly process involves specifying container settings for each component in the J2EE application, and for the actual J2EE application. The container settings customize the underlying support provided by the J2EE server – include services such as security, transaction management, lookup functions, and remote connectivity. Some of the highlights are:
Because J2EE architecture provides configurable services, application components within the same J2EE application can behave differently based on where they are deployed. For example, an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment.
The container also manages nonconfigurable services such as enterprise bean and servlet life cycles, database connection resource pooling, data persistence, and access to the J2EE platform APIs described in J2EE APIs. Although data persistence is a nonconfigurable service, the J2EE architecture lets you override container-managed persistence by including the appropriate code in your enterprise bean implementation when you want more control than the default container-managed persistence provides. For example, you might use bean-managed persistence to implement your own finder (search) methods or to create a customized database cache.
The deployment process installs J2EE application components in the following types of J2EE containers.
J2EE Server and Containers
The user's Web browser downloads static or dynamic Hypertext Markup Language (HTML), Wireless Markup Language (WML), or Extensible Markup Language (XML) Web pages from the Web tier. Dynamic Web pages are generated by servlets, or pages created using the JavaServer Pages technology (JSPs) running in the Web tier.
A Web page downloaded from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java Virtual Machine (JVM) installed in the Web browser. However, client systems probably need a Java plug-in and a security policy file so the applet can execute successfully in the Web browser.
JSP pages are the preferred API for creating Web-based client programs because no plug-ins or security policy files are needed on the client systems. Also, JSP pages enable cleaner and more modular application design because they provide a way to separate application programming from Web page design. This means personnel involved in Web page design do not need to understand Java programming language syntax to do their job.
Applets that run in other network-based systems such as hand-held devices or car phones can render Wireless Markup Language (WML) pages generated by a JSP page or servlet running on the J2EE server. The WML page is delivered over Wireless Application Protocol (WAP) and the network configuration requires a gateway to translate WAP to HTTP and back again. The gateway translates the WAP request coming from the hand-held device to an HTTP request for the J2EE server, and then translates the HTTP server response and WML page to a WAP server response and WML page for display on the hand-held device.
An application client runs on a client machine and provides a way for users to handle tasks, such as J2EE system or application administration. It typically has a graphical user interface created using Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is also possible.
Application clients directly access enterprise beans running in the business tier. However, if the J2EE application needs to open an HTTP connection to establish communication with a servlet running in the Web tier, the application client is able to open such HTTP connection.
SAP J2EE Engine implements the set of standard J2EE services defined by the Java™ 2 Platform Enterprise Edition Specification, v.1.2: