Introduction
Enterprise JavaBean (EJB) 2.0 Specification defines the architecture of server-side software components based on transactional, distributed object applications. Enterprise organizations can build their own components or purchase components from third parties. These server-side components are called Enterprise Beans, which are distributed objects resident in the Enterprise Javabean container, providing remote services to clients distributed in the network. Two-layer and three-layer environment
In two-layer client / server environment, programmers write applications that are closely integrated with vendor-specific software. Typically, two-layer applications access database services or transaction services directly from the client. Sometimes this app is called a fat client because the application logic resides on the client, which makes the client huge and complicated.
The three-layer client / server application uses an intermediate or intermediate layer, the application server, which is operated between the client application and the backend database. The intermediate layer stores the business logic of the system and coordinates the display of interact with the backend database on the client.
Using the three-layer architecture on the two-layer model is out of the following two motives:
Improved scalability, commercial system flexibility and scalability of improved scalability, availability The characteristics will produce bottlenecks, which inhibits scalability, availability, and performance as the number of clients increases. The three-layer system attempts to eliminate this bottleneck by more efficiently managing backend resources. This goal can be achieved by using resource management techniques, such as coexisting and cluster intermediate layer servers. Combine allows many clients to share insufficient resources (such as database connections), which can reduce the workload of the backend server, so that the three-layer system is more efficient. Since multiple servers and resources can support fault recovery and equalize the amount of loaded loads, the cluster can make the three-layer system more availability and scalability.
The three-layer system is more flexible and more scalable than the corresponding two-layer systems, because commercial logic and services (such as security and transactions) reside in the intermediate layer and are basically independent of client applications. If the three-layer system is implemented correctly, the service will automatically apply to the client request with Enterprise JavaBean, so the service is invisible. Since the service is not visible for the client, the changes to the service are also invisible. If a three-layer system is properly implemented, the changes and enhancements of commercial logic on the intermediate layer can also be hidden on client applications.
Alternatively, if the client and the middleware component is implemented in Java programming language, they are very likely to be portable. A class file that enables the client and the application server can be reset to the current most suitable host.
In the last two or three years, some suppliers have released Java-based three-layer application servers that interact with backend server operations and manage them. Although these middleware products support the distributed architecture, these architectures have made a very significant improvement in two-layer design (and Java application servers). Their main limitations are increasingly tends to be specific to a supplier. This means that the company must purchase a large number of suppliers' models, and the system is unmistable, resulting in suppliers to lock.
As object-oriented programming examples are increasingly popular, distributed object systems have gradually become growing. There is now some distributed object technology. The most popular is Corba, Sun Microsystems, created by Object Management Group, and Microsoft's DCOM and MTS (also name COM ). Each has its own advantages and disadvantages. Sun Microsystems Enterprise JavaBean is the latest technology to join this circle. In some aspects, it is both the actors of these technologies and is also a partner. Since other open standards (such as LDAP), CORBA (Public Object Request Intermediary Architecture) have been successfully solved in the three-layer calculation. Unfortunately, although CORBA has changed its distributed computing, it is too complicated, and the supplier cannot comply with the norms. CORBA has advanced distributed computing, but it has proven to be too difficult and difficult to achieve, and its portability is also poor than expected.
Enterprise JavaBean (EJB) is a solution for Sun Microsystems for Corba's portability and complexity. EJB introduces a simpler programming module than CORBA, which allows developers to create portable distributed components, called Enterprise Bean. The EJB programming module allows developers to create secure, transactional, and persistent business objects (Enterprise Beans), which uses very simple programming modules and declaration properties. Unlike CORBA, facilities such as access control (authorization security) and transaction management are very easy to program. CORBA needs to use complex API to use these services, while EJB is automatically applied to Enterprise Beans in accordance with a statement called "deployment description information". This model ensures that Bean developers can focus on writing business logic, while the container will automatically manage more complex but necessary.
Since the EJB specification issues a set of confirmed EJB containers (vendors) and EJB components (commercial objects), portability is realized in EJB. These contracts or rules are exactly what services must be provided for Enterprise Beans, and Bean developers need to use what API and declaration properties to create Enterprise Bean. Since the Enterprise Bean's life cycle is specified in detail, the supplier knows how to manage Bean during runtime, and Bean developers know what Enterprise Bean can do during it.
Enterprise JavaBean simplifies the development, deployment, and access of distributed objects. Developers with EJB Distributed Objects (an Enterprise Bean) simply realize objects in accordance with contracts and protocols established for Enterprise JavaBean. Supporting EJB application servers can, which are indeed, using any distributed network protocol, including local Java RMI protocol (JRMP), proprietary protocol, or CORBA network protocol (IIOP). Regardless of the basic network protocol used in a particular product, EJB uses the same programming API and semantics to access distributed objects in Java RMI-IIOP. The details of the protocol are hidden on applications and bean developers; for all suppliers, positioning and distributed beans are the same.
Note: Enterprise Bean is different from JavaBean. JavaBean is developed using Java.beans package, which is part of the Java 2 Standard Edition. JavaBean is a component that runs on the same address space on a machine. JavaBean is the component in the process. Enterprise Bean is developed using Javax.ejb package, which is a standard JDK extension, which is part of Java 2 Enterprise Edition. Enterprise Bean is a component that runs several address space across multiple machines. Therefore, Enterprise Bean is a process between processes. JavaBean is usually used as a GUI widget, while Enterprise Bean is used as a distributed business object. Finally, if some netizens want to communicate with my technology, please send it to Wyawxj@yahoo.com.cn. I am willing to learn and discuss with you.
