Java EE Enterprise Beans (Chinese translation)

enterprise|j2ee| Chinese translation: Software Institute Huang

1 Introduction. Enterprise Beans is part of the Java EE implementation of Enterprise JavaBeans (EJB) technology, which runs in the EJB container. EJB is the Run-time environment (Runtime environment) of a Java EE server. Although the EJB container is transparent to enterprise application developers, it provides services at the system level, such as enterprise beans transaction processing. These Java EE core Business application services enable you to quickly build and use enterprise Beans.

What is 1.1Enterprise beans?

Enterprise Beans is a server-side component that is written in the Java language and is used to implement enterprise-level logical applications. Enterprise-class logic applications are a number of highly targeted code. For example: In a financial inventory application, Enterprise beans must implement the Checkinventorylevel and Orderproduct methods. By invoking these methods, the remote client can get the appropriate service from the Enterprise Application server.

The advantages of 1.2Enterprise Beans Enterprise Beans can make a huge distributed application simple, for several reasons:

The first EJB container provides a system-level service for enterprise beans, where application developers can focus on the business logic needed to develop application systems without worrying about the implementation of specific service frameworks. The EJB container is responsible for the system-level service and security recognition mechanism without the need for developers to care. The second is that enterprise Beans rather than the client contains the enterprise application logic, and client developers can focus on client applications without writing enterprise logic or database access code. The obvious advantage of such a thin client is that the client can run on a small device. Third, because enterprise beans is a stand-alone component, new applications can be constructed on existing beans that can run on different Java-EE servers.

1.3 When should we use Enterprise Beans? If your system needs to be applied like this, you can consider using the Enterprise Beans:l system to be upgradeable. In order to adapt to more and more users, you need to distribute the system applications on different machines. Not only enterprise beans can run on different machines, but it is transparent to the client, and the original access position remains unchanged. L transaction processing requires data integrity. Enterprise beans supports this transaction processing mechanism, where transactions can concurrently access a shared module. L system applications have a variety of clients. With just a few lines of code, remote clients can easily access enterprise Beans. In this way, the client can diversify, thin, numerous.

Type 1.4Enterprise beans The following figure summarizes three different types of enterprise beans. Enterprise Beans Type Use session for client tasks entity describes an existing persistent enterprise entity Message-drivenjava Information Service API Listener to handle unsynchronized information

2 What is a session bean? A session Bean represents a user in a Java-EE server. In order to access the application deployed on the server, the client invokes the method of the session bean. The session Bean separates the client from the complex internal implementation by executing the enterprise-level tasks within the server, and completes the tasks assigned by the client. As its name shows, a session bean is like an interactive session (interactive session). A session bean is not shared and can be used only for one client. Similarly, a interactive session can only be used by one client. As with interactive sessions, a session bean is not persisted (the data is not saved to the database). When a client terminates a session, its sessions bean terminates and no longer connects to the client.

2.1 State Management mode session beans are of two types: stateful and stateless

1. Stateful session Bean the state of an object is made up of the value of its instance variable. In a session bean, its instance variable describes a unique client bean's sessions.       Because the client's sessions are "talked" through beans, the state of the bean is often called the dialog state (conversational). Status is the duration that identifies a session. If the client removes or stops a bean, the state disappears. But the transient nature of the state is not a flaw, because when the client finishes a session bean, there is no need to preserve its state.

2. Stateless session bean a stateless sessions bean does not specifically save the state of the client conversation. When a client invokes a method of a stateless session bean, the bean's instance variable saves a state, but only during the time that the method was invoked. When the method call is complete, the state no longer exists. Unless, in the process of invoking the session Bean method, all stateless session beans are allocated an instance equally by the EJB container to any client. Because stateless session beans support multiple clients, they can provide better applications that require a large number of clients to implement together. In other words, for the same number of client services, an application requires a stateless session bean that is less than a stateful session bean. At the same time, the EJB container has to save the information in the stateful session bean to another zone, but no stateful session bean is required. Thus the stateless session bean can have a better performance.

2.2 When do I use the session Bean? In general, you should use the session Bean in the following environments:

l have only one client accessing the bean instance at any time.

L do not need to preserve the state of the bean for long, but only for a period of time (possibly a few hours).

Stateful session beans are more appropriate for the following conditions:

L Use the state of the bean to describe the session between the bean and a specific client.

The L bean needs to save the invocation information when the client accesses the Bean method.

The L bean, as the intermediary of the client and other system application components, presents to the client that the component is a simple object.

The L bean processes data streams for several enterprise beans in the background. For example, view the ACCOUNTCONTROLLEREJB session Bean application in Chapter 18.

To improve performance, you should select a stateless session bean if the bean has the following characteristics:

The state of an L bean does not hold information for any particular client.

L in a single method call, the bean completes a series of tasks for all clients. For example, you can send an online order verification message with a stateless session bean.

The L bean reads from the database those data sets that are often used by clients and whose properties are read-only. For example, a bean that retrieves the number of rows representing the sales of the product this month.

3 What is a entity Bean?

An entity bean (Entity Bean) represents an enterprise entity that is running persistently. Corporate entities such as: Customers, orders and products. In the Java EE JDK, the persistent storage structure is a relational model database. Typically, each enterprise entity has a table in the relational model database that corresponds to it, and a row in the table (a tuple) represents an instance of the entity. For an example, see chapter Fifth, sixth.

What is the difference between a 3.1Entity bean and a session bean?

The Entity bean differs from the session bean in several ways. The entity bean is persistent, it allows shared access, has its own identity (key code), and may also be associated with other entity beans. If you use a database system frequently, you should be familiar with persistent data. The data in the database is permanent, because even if you shut down the database system or stop its application service, the data still exists.

Persistence of

Because the state of an entity bean is stored in a persistent database, it is persistent. Persistence means that when an application or a Java EE server process is finished, the state of the entity bean persists.

There are two models for the permanence of Entity beans: Bean self-management mode and container management mode (bean-managed and container-managed). In bean self-management mode, the instance of the entity bean you are writing to manage the persistence itself, so the code includes the call to the database access. If your bean is managed by the container, the EJB container will automatically generate a call to the database access. The code you write does not need to include database access calls. For more information, refer to the Container Management Persistence section.

Shared access

An entity bean must be shared access by multiple clients. Because multiple clients need access to the same data, this also appears to be the importance of the entity bean in transaction processing. Typically, the EJB container provides management of transaction processing. So, you can enumerate the properties of the transaction in the bean's deployment manual. You do not have to write your own boundary conditions for the transaction, and the container automatically marks those boundaries for you. See Chapter 14 For more information.

Unique identification

Each entity Bean has a unique identity. For example, a customer, it is identified with the customer ID number. A unique identity, or a master code, allows the client to find the specified entity bean. For more information, see the Unique identification section of the Bean Self-management mode.

The link sex

Just like a table in a database, an entity bean is also associated with other entity beans. For example, in the application of a college student registration, STUDENTEJB and COURSEEJB must be in contact, because students are enrolled in a class.

You can use bean self-management persistence and container management persistence to achieve the connection between entity beans. In bean self-management mode, you have to write your own code to achieve their connection. In container management mode, the container helps you manage the connection between entity beans. Because of this, people often associate entity beans in container management mode with the name Container management contact (container-managed relationships).

3.2 Container Management mode

Container management mode, where the EJB container Controls access to the database by all entity beans. No access calls to the database are specified in the entity bean's code. Therefore, the bean's code does not have to be bound to a specific database. Because of this softness, when you deploy a sample bean to a different Java server, you don't need to change or recompile the code. In simple terms, your entity beans are more independent.

To generate a database call, the container needs to collect information about the abstract schema in your entity bean.

Abstract pattern

As part of the Entity Bean Deployment Description, the abstract schema defines the persistence and connectivity of the bean. The word "abstract" distinguishes between this pattern and the physical pattern in which the data is actually stored. For example, in a relational database, the physical schema is composed of tables and attributes.

You want to specify the name of the abstract schema in your deployment. The name will be referenced by a queue written in JavaBeans Query Language ("EJB QL"). In container management mode, you must define an EJB QL queue for all search methods (except Findbyprinarykey) for the entity bean. When the lookup method is invoked, the EJB container executes from the queue. Refer to Chapter 8th for more information.

You may have found it useful to build an abstract model before writing code. Table 3-1 shows a simple abstract model in three entity beans. More contacts between them will be described in the following sections.

"

Figure 3-1 A High-level View of an Abstract Schema

Persistence field

The persistence field of an entity bean is saved to the database. In general, those fields form the state of the bean. At run time, the EJB container automatically synchronizes these states in the database. In deployment, the EJB container records the tables in the database for the bean, and records persistent fields to the properties in the table.

For example, a CUSTOMEREJB entity bean has such a persistent field: FirstName, LastName, phone, EmailAddress. In persistent container management mode, these fields are virtual. You declare these fields in abstract mode, but you do not write their instance variables in the bean code. Instead, these fields are determined by the access method.

Contact fields

A contact field is like the outer code of a database table that identifies a bean that is associated with itself. As with persistent fields, the Contact field is virtual and is determined in the access method in the enterprise bean. But the difference is that the contact field does not represent the state of the bean. The contact field is discussed in more detail in the chapter on the directionality of contact in container management mode (Direction in container-managed relationships).

3.3 The diversity of connection in container management mode

Here, there are four types of diversity:

One-to-one: (one-to-one) An instance of each entity bean is associated with an instance of another entity bean. For example, in a physical warehouse storage model, each enclosure contains an item, and STORAGEBINEJB and WIDGETEJB have one-to-one relationships.

One-to-many: (One-to-many) An instance of an entity bean may be associated with instances of multiple other beans. For example, a sales order can have multiple tuples (multiple orders). In such an order application, ORDEREJB has a one-to-many relationship with LINEITEMEJB.

Many-to-many One: (Many-to-one) An instance of multiple entity beans is associated with an instance of an entity bean. This association is the opposite of a one-to-many association. For example, as mentioned above, LINEITEMEJB has a many-to-many relationship with ORDEREJB.

Multi-Many-to-many: (many-to-many) entity beans have multiple contacts between entities. For example, in a university, a course has a number of students elective, and a student also take a number of courses. In such applications, COURSEEJB and STUDENTEJB are many-to-many relationships.

3.4 The direction of contact in container management mode

The relationship between entity beans is one-way and bidirectional. In a two-way connection, each entity bean has a contact field that corresponds to the other. With this contact field, the entity Bean's code can access the bean associated with it. If an entity bean has a contact field, we often refer to it as a bean that identifies the bean that it is associated with. For example, if ORDEREJB knew what LINEITEMEJB had, and Lineitemejb knew who orderejb belonged to, then the relationship between them would be two-way.

In a one-way connection, only one of the entity beans can have one contact field and the other bean correspond. For example, LINEITEMEJB has a contact field to identify PRODUCTEJB, but PRODUCTEJB cannot have a contact field and a LINEITEMEJB counterpart. In other words, LINEITEMEJB knows PRODUCTEJB, but PRODUCTEJB doesn't know which lineitemejb to contact.

EJB QL queues are often used to locate these connections. The direction of the connection, determined by whether the queue can locate one bean to another bean. For example, a queue can be positioned from LINEITEMEJB to PRODUCTEJB, but cannot be positioned from PRODUCTEJB to LINEITEMEJB. If LINEITEMEJB and PRODUCTEJB have two-way connections, then queues can be positioned in both directions.

3.5 When to use entity Beans

You can use entity beans in a moment:

The L Bean represents a business entity, not a process. For example, CREDITCARDEJB should be an entity bean, but CREDITCARDVERIFIEREJB should be a session bean.

The state of the L bean must be persistent. If the instance of the bean is terminated or the Java server stops, the state of the bean is persisted in the persistent storage (database).

4 What is a message-driven bean (Message-driven bean)?

Note: This section links to the Java Messaging Service tutorial (the Java Message Services Tutorial). Because message-driven beans depend on Java Message Service (JMS) technology. For a better understanding of message-driven beans, you can refer to the tutorial url:http://java.sun.com/products/jms/tutorial/index.html below.

Message-driven beans are enterprise-level beans that allow the Java server to process messages asynchronously. It plays the role of a JMS information listener, just like an event listener, just to receive events and replace them with receiving information. This information comes from some Java EE components, such as an application client, other enterprise-class beans, a Web component, or a JMS application that does not use the Java EE technology.

The message-driven bean is currently processing only JMS messages and may be able to handle other types of messages in the future.

See the 7th chapter for examples.

4.1 Message-driven beans and session beans, what is the difference between entity beans?

Message-driven beans and session beans, the biggest difference between entity beans is that the client message-driven bean does not have to be accessed through the interface. The interface is described in the chapter "Interface definition Client Access". and session beans, unlike entity beans, message-driven beans have only one bean class.

For several reasons, message-driven beans are similar to a stateless type session bean.

An instance of an L message-driven bean does not save data or session state for any client.

L All instances of the message-driven bean are equal, allowing the EJB container to assign a message to any instance. The container forms a pool of these instances so that the message flow can be disposed of immediately.

L A message-driven bean can handle messages from multiple clients.

A variable of the message-driven bean instance can store some state by manipulating the message of the client. For example, a JMS API connection, an open database connection, or an entity that is referenced to an enterprise bean entity.

When a message arrives, the container invokes the message-driven Bean's OnMessage method to process the message. The OnMessage method generally maps messages to one of five JMS messages, and controls it in line with the applied enterprise logic. The OnMessage method invokes a helper method, or you can call a session bean, an entity bean, to process the information in those messages, or to save it to a database.

A message may be converted before or after a transaction, so the operations in the OnMessage method are a separate transaction. If the message processing is rolled back, the message will revert back to its original form. For more information, please refer to chapter 7th.

4.2 When to use message-driven beans.

Session beans and entity beans allow you to send information, synchronously receive information, but do not allow information to be received asynchronously. To avoid binding to multiple sources of information, you might prefer to use synchronous blocking in a server-side component. To receive information asynchronously, use the message-driven bean bar.

Contents of 5.Enterprise Beans

To develop an enterprise bean, you must provide the following files:

• Deployment Description: An XML file contains information about the deployment, such as its consistency type and transaction properties. You can use the deployment tool to effectively generate a deployment specification through its new Enterprise Bean Wizard.

L Enterprise Bean Class: A method that implements an interface definition.

L Interface: Remote access, requires remote and local interface. Local access, local and local interfaces are required. See the "Defining Client Access Interface" section. (Note that these interfaces are not used by message-driven beans)

L Auxiliary classes: Enterprise beans require some other classes, such as exceptions and utility classes.

You package the file described above as an EJB jar file. The EJB jar is a model for storing enterprise beans, which is independent and can be used in a variety of applications. To build an application, you must package one or more models (such as EJB jar files) into the ear file. The ear is an applied document file. When you deploy the Eat file that contains the EJB jar file, you are deploying the enterprise bean to the Java server.

6.Enterprise Bean naming habits

Because enterprise beans are made up of multiple components, they often follow the naming conventions below. Table 3-2 brings together some of the naming conventions in this tutorial.

Table 3-2 naming conventions for Enterprise Beans

Item

Syntax

Example

Enterprise Bean name (DD)

<name>ejb

Accountejb

EJB JAR Display Name (DD)

<name>jar

Accountjar

Enterprise Bean Class

<name>bean

Accountbean

Home interface

<name>home

Accounthome

Remote interface

<name>

Account

Local Home interface

Local<name>home

Localaccounthome

Local interface

Local<name>

LocalAccount

Abstract schema

<name>

Account

DD indicates that this item is an element in the deployment description.