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

Editor to share with you how Java uses the EJB container, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's learn about it!

The architecture of Java EJB:

The upper-level distributed application of EJB is based on the object component model, while the lower-level transaction service uses API technology. EJB technology simplifies the development, configuration, and execution of enterprise applications written in JAVA. The specification of the architecture of EJB is developed by Sun Microsystems. Inprise's EJB container is based on version 1.1 of the specification.

EJB technology defines a set of reusable components: Enterprise Beans. You can use these components to build your distributed applications like building blocks. When you have written the code, these components are combined into specific files. Each file has one or more Enterprise Beans, plus some configuration parameters. Finally, these Enterprise Beans are configured on a platform with EJB containers installed. Customers can navigate to a beans through the home interface of these Beans and generate an instance of the beans. In this way, the customer can call the application method and remote interface of Beans.

EJB server manages EJB containers and functions as a bridge between containers and low-level platforms. It provides the EJB container with the ability to access system services. For example: database management and transaction management, or for other Enterprise application servers.

All EJB instances run in the EJB container. The container provides system-level services that control the life cycle of EJB. Because the container has mastered most system-level issues (hehe, do not know how to translate). Developers of Enterprise Beans do not need application logic to take into account. Generally speaking, the EJB container has mastered the following system-level issues.

1. Security- configuration descriptor (The Deployment descriptor) defines different application functions that customers can access. The container achieves this effect by allowing only authorized customers to access these functions.

2. Remote Connectivity- container manages low-level communication issues for remote links, and hides communication issues.Enterprise Beans developers and customers from both Enterprise Beas developers and customers when writing application methods as if they were using a local platform. Customers also don't know that the method they call may be handled remotely.

3. Life Cycle managment- customers simply create an instance of Enterprise beans and usually cancel an instance. The container manages the instance of Enterprise Beans, which enables Enterprise Beans to achieve maximum performance and memory utilization. The container can activate and deactivate the Enterprise Beans in this way, keeping the instance pool shared by many customers. Wait.

4. The Trasction management- configuration descriptor defines the transaction requirements of Enterprise beans. Containers manage complex issues that manage distributed transactions. These transactions may require updating the database between different platforms. The container makes these transactions independent and non-interfering with each other. Ensure that all updates to the database occur successfully, otherwise, roll back to the state before the transaction.

Enterprise Beans components:

Enterprise Beans is a component of enterprise applications based on distributed transaction processing. All Enterprise beans have the following characteristics:

Enterprise beans contains application logic for dealing with enterprise data.

Enterprise beans provider defines the client interface for Enterprise beans (the remote interface for Enterprise beans). Such an interface is not affected by containers and servers. Therefore, when an Enterprise beans is assembled into an application, there is no need to change the code and recompile.

Enterprise beans can be customized

Various system-level services, such as security and transaction features, are not part of Enterprise beans class. Instead, it is implemented by tools that configure and assemble applications.

There are two types of Enterprise beans: Session beans and entity beans.

Session beans:

A Session beans is an object that executes as a single client. In response to a remote task request, the container generates an instance of Session beans. A Session beans has a client. To some extent, a Session bean to the server means that its client.Session beans can also be used for transactions, it can update shared data, but it does not directly depict the shared data.

The life cycle of Session beans is relatively short. Typically, Session beans is alive only when client maintains a session. Once client exits, Session beans is no longer associated with client. Session beans is considered instantaneous, because if the container crashes, client must re-establish a new Session object to continue the session.

A Session bean typically declares interoperability or conversations with client. In other words, Session bean grasps the information of Client through the call of method during the client session. A stateful Session bean is called a stateful Session bean. When client terminates its interoperability with Session beans. The session is terminated, and bean no longer has a status value.

A Session bean may also be a stateless session bean. Stateless Session beans does not know the information or status of its customers. Client can call the methods of beans to complete some operations. However, beans only knows the parameter variables of client when the method is called. When the method call is complete, beans does not continue to hold these parameter variables. In this way, all instances of stateless session beans are the same, unless it is in the middle of a method call. In this way, stateless Session beans can support multiple client. The container can declare a stateless Session beans. You can assign any Session beans to any client.

Entity Beans:

Entity Beans provides a view of objects for the data in the database. For example, an Entity bean can simulate a row of related data in a database table. Multiple client can share access to the same Entity bean. Multiple client can also access the same Entity bean.Entity beans at the same time to access or update underlying data through the context of the transaction. In this way, the integrity of data can be guaranteed.

Entity Beans can survive relative to the imam for a long time, and the state is continuous. Entity beans survives as long as the data in the database exists. Not in terms of the application or service process. Even if the EJB container crashes, Entity beans is still alive. The Entity Beans lifecycle can be managed by the container or by Beans itself. If the container controls the issus that ensures the persistence of the Entity beans. If it is managed by Beans itself, you must write code for Entity beans, including calls to access the database.

The Entity Beans is identified by the primary key (primary key, a unique object identifier). Typically, the primary key is the same as identifying a piece of data in the database, such as a row in a table. The primary key is that client can locate specific blocks of data.

EJB roles:

The EJB architecture makes it easy to develop complex applications by dividing the programming process into six different roles. Six different roles, each with a specific task. The 6 roles include lower-level services, application development, configuration, and operation instructions (issues)

The EJB architecture simplifies the work of application developers. In the EJB architecture, container and proxy services do a lot of the work that programmers do in other environments. Such agents provide a lot of system-level services that previously require programmers to write code.

Infrastructure roles; (underlying construction role)

EJB Server Providor service providers are typical agents that provide distributed low-level services. EJB service providers provide a platform and facilities that distributed application developers need. A runtime environment for distributed programs is also provided.

The EJB Container Providor container provider is an expert in distributed systems, transaction processing, and security. The container provider provides a configuration tool for EJB and runtime support for these configuration instances.

A container is a runtime system for one or more EJB. It combines Enterprise Beans and EJB services, including transaction services, security services, distributed network management and so on. A container is a tool for both customizing code and generating detailed code for a particular Enterprise beans. The container also provides a tool for configuring Enterprise beans and a way to manage monitoring applications.

Application roles: (application role)

Enterprise beans Provider:Beans providers are experts in the field of applications. For example, a Beans provider may be an expert in finance or telecommunications. The Beans provider provides the business methods of the business tasks,Enterprise beans, defines the romote and home interfaces of beans, and defines the configuration descriptor of beans. Because containers manage system-level tasks, Beans providers do not need to care about distributed processing, transaction processing, security performance, and other aspects that are not relevant in terms of application.

Application Assembler program assembler:

This is an expert at assembling custom Enterprise beans and other components, such as GUI client,applet,Servelet, into a complete application. Under the Enterprise Configurator, when assembling into an application, the assembler only cares about the interface of beans, including romote interface and home interface. Regardless of how these interfaces are implemented. The result of assembly is an application, or a more complex Enterprise beans composed of multiple Enterprise beans.

Deployment and Operate roles configuration and operation roles

The configurator configures a special operating environment for a particular Enterprise beans. In order to adapt to the application, the configurator combines multiple Enerprise beans and configures the corresponding operating environment by modifying the properties of the Enterprise beans. For example, the configurator sets the transaction and security policy by setting the corresponding properties of the configuration descriptor. Another task of the configurator is to combine the application with existing Enterprise management software.

System Administrator system manager

Is related to configuring the application. The manager configures a lower layer that manages Enterprise computing and network services, including EJB services and containers. The administrator monitors the operation of the application server and takes corresponding measures when the application server is not running properly. Typically, administrators use Enterprise management tools to deal with applications and configure them through the hooks provided by the container.

Traditional application developers are now providers of Enterprise beans. It may also be the assembler of the application. This allows them to focus on application problems or application logic. When installing Enterprise beans, the configurator defines a series of configuration guidelines. The complexity of the mechanism and the guidelines for implementing the configuration are left to a dedicated agent. Although distributed applications are still more complex, the job of application designers becomes easier because all the complex work is left to EJB servers and container providers.

Through a large number of pre-design definitions and naming conventions, EJB achieves the aforementioned goals. Such a programming architecture limits some freedom, but allows EJB servers and container providers to assume the design of the application and support them in an effective way.

Design patterns and naming conventions for EJB:

There are three ways to build an object-based, multitier, distributed system: a stateless service approach, a session-based approach, and a persistent object approach.

A stateless service is a function that provides a function through the operation of an object, but does not maintain the state of the session. When a customer uses a stateless object, the customer cannot provide information about the last operation.

Session-based design produces a middle-tier object called a session (Session). This session can be seen as an agent for this client. Typically, the life of a session is determined by the customer and the service program in which it is located. The customer can move the object if the session is completed. If the service is terminated, the session object times out. The session object becomes invalid.

The persistent object design pattern binds a piece of data that exists in the database. Provides some operations to manipulate this piece of data. Persistent objects are shared by multiple customers. The lifespan is determined by the library where the data is stored.

These are called stateless Session, stateful Session, and Entiry Beans.Session Beans patterns respectively in the EJB specification: session-based design patterns. The Entiry Beans pattern is the persistent object design pattern. Each pattern defines some interfaces and naming conventions.

Enterprise JavaBeans infrastruct (infrastructure of EJB)

Containers and service providers implement the infrastructure of EJB. These infrastructures deal with the distributed aspects of EJB, transaction management, and security aspects. The EJB specification defines the infrastructure and J ava API requirements in order to adapt to a variety of situations. Instead of specifying what technologies, platforms, and protocols to implement them.

Enterprise beans, container, and server explain the requirements of the EJB infrastructure, which must provide a channel for customers to communicate with Enterprise beans. Although this is not defined by the EJB specification. But it is also important to ensure the safety of the passage. Especially when the customer accesses the remote Enterprise beans through internet. The EJB infrastructure must also be able to strengthen the access control of Enterprise beans.

The continuity of all Enterprise beans data must be guaranteed. The low-level structure of EJB must provide the ability to integrate with existing systems in an enterprise-level computing environment. All Beans communication is part of a distributed transaction and needs to be managed by the EJB low-level structure. For a successful configuration, the EJB low-level must provide a hooks for distributed application management tools.

Container

Container is probably the most important concept in EJB. Because it provides maximum convenience to program developers. Object-based middle-tier software platform such as CORBA or remote procedure call RMI liberates program developers from network transmission by providing object positioning mechanism, data reorganization mechanism and so on. The concept of container goes a little further. By simplifying the complex aspects of distributed applications, such as security, transaction coordination, and data persistence.

Once the Enterprise Beans is ready, it can be configured. It is packaged into a standard JAVA file, ejb-jar file. An ejb-jar file can include one or more Enterprise Beans. For each Enterprise beans, it consists of its interface, class, and configuration descriptor.

Enterprise Beans Provider provides the following to the ejb-jar file:

The remote interface of Enterprise Beans, which describes the functions that can be called by the client.

Enterprise Beans's home interface, home interface enables customers to generate and locate an instance of Enterprise Beans.

The Enterprise class itself implements the semantics of Enterprise beans.

Deploy Descripot configuration descriptor, deployer provides information that is not declared in the code by using the configuration descriptor. Such as policies and attributes. EJB 1. 0 specification defines the configuration descriptor as javax.ejb.deployment. The SessionDescriptor class or an instance of javax.ejb.deployment.EntityDescriptor, but this is not recommended in version 1.1. Instead, XML is used to define the configuration descriptor.

Configuring an Enterprise Beans means installing an Enterprise Bean into the container. The installation process includes the following aspects:

Make sure that different Enterprise beans can work together. Register an Enterprise Bean with the name service. The communication system through the EJB service provides access to EJB.

Implement the affairs management and security policy. You can have as many Enterprise beans as you want in an EJB container. In addition to installation and execution, the container also provides tools to configure Enterprise beans. Why use Inprise's EJB container? The full service provided by the Inprise EJB container fully supports EJB1. 1 specification. An efficient container for running and managing EJBs. Provide naming services, transaction services, implanted inside Java RDBMS. Programming, configuration simple and sufficient examples to demonstrate how to use EJBs and EJB containers. For Enterprise beans developers, the EJB container is an advanced Enterprise product. Because it has the following advantages: complete, flexible runtime environment: the EJB container fully implements EJB1. 1, including all its functions.

Every Enterprise bean generated by a tool is both an Enterprise bean object and a CORBA object.

EJB containers can be configured individually, 100% pure JAVA services, or as fully distributed configurations. This flexibility means that you can adapt your application to your requirements.

Unlike other EJB services, there is no restriction that Inprise's EJB container service must be separated. Instead, any number of Enterprise beans can be placed in any number of containers, and these containers can also be placed on any number of machines. It also supports distributed transaction protocols and allows separate rulings of Enterprise beans. Allow partial configuration of your application and optimize your performance.

Inprise's EJB is based on Vbroker and RMI-IIOP.

The EJB container is built on top of Inprise's Vbbroker. VisBroker has been proven to be the leader of ORB under all conditions. No matter under the joint testing of major companies, or in the actual application environment. VisiBroker provides a good runtime for the completion of tasks.

For better performance, Vbroker uses a large number of runtime optimizations, advanced multilinking, link pooling and management, thread pooling and management.

Communication between customers and Enterprise beans,Enterprise benas, and between Enterprise beans and other CORBA objects is done through the IIOP mode of VisiBroker. VisiBroker is fully adapted to CORBA2. 3 specification, RMI- IIOP is realized by the way of value transfer. This means that complex JAVA data types can be written to IIOP with new IDL value types. Just like in CORBA2. (3) the same as in the specification. It is important to coordinate how data and services transmit complex data types. Otherwise, the synergy will be compromised. The EJB container can work with all others that support RMI-over-IIOP.

Security features can be owned by VisiBroker. Guarantee credit is a video transmission service from the customer.

The transaction context is also owned by visibroker. Ensure that when a CORBA customer starts a transaction and accesses the service of the EJB container. The transaction context is passed to the service and is used when the service needs to invoke resources in the environment.

The two-segment commit of the transaction is managed by the ITS of Inprise. If JDBC supports the two-phase commit protocol, EJB supports the two-phase commit protocol. At that time, if JDBC did not support two-phase commit, two-phase commit could not be completed.

The EJB container for Enterprise is a CORBA object:

Inprise's java2iiop compiler, like the EJB container, is CORBA compatible. The EJB container understands RMI calls, but it uses IDL to hold interface definitions. Although the Java2iiop compiler generates stub and skeleton from the java interface. IDL can also be generated from the java interface. And then use it in other languages. For a CORBA client, the EJB container is a CORBA service, and the EJB container tool is the same CORBA tool that controls EJB.

The EJB container is built on the JNDI and CosNaming,JTS/OTS base mountain. They all fully support CORBA.

Container support for different Enterprise beans:

The main feature of the EJB container is that it provides management and support for a variety of Enterprise beans. These include:

Stateful or stateless Session Enterprise beans.

Entiry beans includes persistence of container-manager and beans-manager.

The EJB container can include one or more jar files. Each jar file can also include multiple Enterprise beans. Each Enterprise bean includes a configuration descriptor. An EJBhome interface, an EJBremote interface, and the implementation code of Enterprise bean.

What makes Inprise's EJB container different is that it supports many current customers, including the following two aspects:

VisiBroler provides connection management, allowing a service to simultaneously support more customer connections than TCP connections. Use the least recent algorithm to close the connection.

For the customer, the container itself is stateless. This means that the container does not allocate memory for each new Enterprise bean session. In this way, the container can support any number of stateless Session Enterprise beans.

Support for configuration:

The Inprise container provides the compiler that generates the code. It also provides a validation tool to check your Enterprise beans before configuration. EJB1 is supported. The JNDI of 1 is named after the XML-based configuration descriptor.

Transaction Manager:

The transaction manager provides the means of transaction management. Includes distributed support for two-segment commit. Comply with the latest SUN JTS specification. The latest OMG OTS specification is also supported. Use JTS as little as possible during development and use robust ITS when configuring.

JDBC link pool and transaction synthesis:

All JDBC access to the database is done through the implementation of the DataSource object. The pooled links between DataSource objects and databases also include global transactions managed by JTS and database transactions managed by JDBC.

Naming service:

Naming services provide distributed naming management. The service conforms to JAVA's naming and directory specification (JNDS). It also follows the cosNaming specification of OMG. Similar to transaction services, you can use JNS or the more robust INS when configuring. The containers provided by JNDI can run on other JNDI implementations. This makes it possible to use other naming services, such as LDAP.

Security support:

Inprise's security service on top of CORBA is attached.

JAVA database:

Java database provides a fully relational high-performance database to store the state of Enterprise beans.

The JAVA database can be run either in a container of the same process or in a separate process to improve performance. In fact, JAVA databases are plug and play. It means that the end user can replace all JAVA versions with another implementation. For example, you can implement a background storage that uses another database to store session state and Entiry Data.

Persistence of container-managed Entity beans:

Inprise provides a CMP (Container-Managed Persistence) engine to provide transparent object-relational mapping and a persistence framework on pure JDBC. Further, third-party tools can be plugged in through the open API.

The combination of EJB and other components:

In the real world of the configuration environment, the four patterns of EJB can work with the following components:

Client links to Enterprise beans objects. Clients can be an EJB object of the java Enterprise bean interface or a CORBA object of the IDL interface. In Inprise's EJB container service, each Enterprise bean is both an EJB object and a CORBA object. CORBA customers can be implemented in all languages that support CORBA, including Clippers, Java and Delphi.

Access from Enterprise bean's database. Typically, an Enterprise beans object is an Entity beans object, either beans-managed or container-managed.

Back-end services: CORBA services, implemented in Clearing Java, Delphi, running in any CORBA-compliant ORB. EJB services, including all other inprise services, or other services that support IIOP agents. Other original services, including ERP system, main-frame program. Wait.

These are all the contents of the article "how Java uses EJB containers". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.