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

The editor today takes you to understand the basic knowledge of EJB distributed objects. The knowledge points in the article are introduced in great detail. Friends who feel helpful can browse the content of the article with the editor, hoping to help more friends who want to solve this problem to find the answer to the problem. Let's follow the editor to learn more about the basics of EJB distributed objects.

The Enterprise JavaBean (EJB) specification defines the architecture for developing and deploying server-side software components based on transactional, EJB distributed object applications. Enterprise organizations can build their own components or purchase components from third-party vendors. These server-side components, called Enterprise Bean, are EJB distributed objects that reside in Enterprise JavaBean containers and provide remote services to clients distributed across the network.

Two-tier and three-tier environment

In a two-tier client / server environment, programmers write applications that are closely integrated with vendor-specific software. Typically, two-tier applications access database services or transaction services directly from the client. Sometimes this application is called a fat client because the application logic resides on the client, which makes the client large and complex.

A three-tier client / server application uses an intermediate or middle tier, the application server, which operates between the client application and the back-end database. The middle layer stores the business logic of the system and coordinates the display of interaction between the client and the back-end database.

There are two motivations for using a three-tier architecture on a two-tier model:

Improved scalability, availability and performance improved business system flexibility and scalability due to a two-tier system

It takes advantage of the processing power of the client, so it has good performance, but many clients have bottlenecks on the characteristics of a single back-end resource, such as a database, as the number of clients increases gradually. This suppresses scalability, availability, and performance. The three-tier system tries to eliminate this bottleneck by managing back-end resources more effectively. This can be achieved by using resource management technologies, such as pooling and clustering middle-tier servers. Pooling allows many clients to share inadequate resources, such as database connections, which reduces the workload on the back-end server and makes the three-tier system more efficient. Because multiple servers and resources can support failure recovery and balance the load of the growing number of clients, clustering can make three-tier systems more available and scalable.

A three-tier system is more flexible and scalable than the corresponding two-tier system because business logic and services, such as security and transactions, reside in the middle tier and are basically independent of the client application. If the three-tier system is implemented correctly, in the case of Enterprise JavaBean, the service is automatically applied to the client request, so the service is invisible. Because the service is not visible to the client, changes to the service are not visible either. If the three-tier system is implemented correctly, changes and enhancements to business logic in the middle tier can also be hidden from client applications.

In addition, if the client and middleware components are implemented in the Java programming language, they are most likely portable. Class files that implement clients and application servers can be easily relocated to the current most appropriate host.

In the last two or three years, some vendors have released Java-based three-tier application servers, all of which can interact with and manage back-end server operations. Although these middleware products support the EJB distributed architecture, these architectures have made significant improvements in the two-tier design (and pre-Java application servers). Their main limitation is that programming modules are becoming more and more vendor-specific. This means that the company has to buy a large number of models from a supplier, and the system is not portable, which leads to supplier locking.

With the increasing popularity of object-oriented programming paradigm, EJB distributed object system has gradually grown. There are already some EJB distributed object technologies. * CORBA created by Object Management Group, Java RMI of Sun Microsystems (JRMP) and DCOM and MTS of Microsoft (also known as COM+). Each has its own advantages and disadvantages. Sun Microsystems's Enterprise JavaBean is the technology to join this circle. In some ways, it is both a competitor and a collaborator of these technologies.

Due to the use of other open standards (such as LDAP) in three-tier computing, CORBA (Common object request Mediation Architecture) has been successful in solving the problem of supplier monopoly. Unfortunately, although CORBA fundamentally changed EJB distributed computing, the proven programming module was too complex and vendors could not adhere to the specification consistently. CORBA has advanced EJB distributed computing, but it has proved to be too difficult to implement, and its portability is worse than expected.

Enterprise JavaBean (EJB) is Sun Microsystems's solution to the portability and complexity of CORBA. EJB introduces a simpler programming module than CORBA, which allows developers to create portable EJB distributed components called Enterprise Bean. The EJB programming module allows developers to create secure, transactional, and persistent business objects (Enterprise Bean) that use very simple programming modules and declare 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 take advantage of these services, and EJB automatically applies these services to Enterprise Bean based on a declaration in a property file called deployment description Information. This model ensures that bean developers can focus on writing business logic, while containers automatically manage more complex but necessary operations.

Portability is implemented in EJB because the EJB specification enacts a clear set of contracts between EJB containers (vendor servers) and EJB components (business objects). These contracts or rules specify exactly what services the container must provide for Enterprise Bean, and what API and declaration properties bean developers need to use to create Enterprise Bean. Because the lifecycle of Enterprise Bean is specified in detail, vendors know how to manage bean,bean developers at run time and know exactly what Enterprise Bean can do during its existence.

Enterprise JavaBean simplifies the development, deployment, and access of EJB distributed objects. Developers of EJB distributed objects (a kind of Enterprise Bean) only need to implement objects in accordance with the contracts and protocols established for Enterprise JavaBean. Application servers that support EJB can and do use any distributed network protocol, including the local Java RMI protocol (JRMP), the proprietary protocol, or CORBA's network protocol (IIOP). Regardless of the basic network protocol used in a particular product, EJB uses the same programming API and semantics to access EJB distributed objects with Java RMI-IIOP. The details of the protocol are hidden from applications and bean developers; the method of locating and using EJB distributed bean is the same for all vendors.

Note: Enterprise Bean is different from JavaBean. JavaBean was developed using the java.beans package and is part of the Java 2 Standard Edition. JavaBean is a component running in the same address space on a machine. JavaBean is an in-process component. Enterprise Bean, developed using the javax.ejb package, is an extension of the standard JDK and is part of the Java 2 Enterprise Edition. Enterprise Bean is a component that runs across several address spaces on multiple machines. Therefore, Enterprise Bean is an interprocess component. JavaBean is commonly used as a GUI widget, while Enterprise Bean is used as an EJB distributed business object.

Thank you for your reading, the above is the whole content of "what are the basics of EJB distributed objects". Friends who learn it, let's get started. I believe that the editor will certainly bring you better quality articles. Thank you for your support to the website!

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.