If you are developing a new web app, you may ask if you are making an enterprise JavaBeans component (EJB). Is the EJB component that must be part of each solution, or the lack of experience, the development team should completely avoid using EJB components? In most decisions, the answer must be determined according to the actual situation. Kyle and Lee helps solve this problem, they have listed some help you determine if an app is suitable for using EJB judgment criteria.
Under today's technical conditions, when and whether the EJB component is a very annoying issue facing the program team. To help you make a correct decision, we have prepared some questions for you to consider transferring from other techniques to EJB components, or considering a new solution that may use EJB components. We will also compare two scenarios that use EJB components and will see how they are applied correctly or incorrectly.
What is EJB component? The EJB component is a Java component model designed for enterprise-class applications.
The EJB component is based on standard distributed object technology, CORBA, and RMI server-side Java components. EJB components are always distributed, which is the most fundamental difference between them with standard Javabeans components. The EJB component provides the application's business logic part. Since they do not involve problems that represent layers, they must be used with other display technologies (such as servlets), serving JSP technology for HTML clients, or using Java applications such as AWT and SWING technology. A application server that implements EJB specification provides services that can solve complex issues such as security, resource sharing, continuous operation, parallel processing, integrity of transaction, thereby simplifying the business application system.
Sun's EJB component model requires EJB components to run in an EJB server (commonly referred to as application server). The advanced version of the WebSphere application server is used in our example, but the features discussed apply to most EJB servers.
Technical issues that need to be considered When you decide if the EJB component is suitable for proper technology for your actual situation, you may wish to consider several issues first. If your answer to all these questions is affirmative, then the EJB component is the appropriate technology you can use. Otherwise, other techniques may be more suitable.
Do you need to isolate business logic components with an external Internet? Many companies believe that their applications, especially those constitutive standards and data structures constituting business logic, are extremely important corporate property (for example, the company owned by the company constitutes part of the stock trading website). Allowing outsiders to access these original code and target codes that belong to the company's assets will have great harm to the company. Therefore, these companies need to place business logic behind a safe firewall (commonly referred to as no alert zone, also known as DMZ).
In this case, the distributed object component architecture (e.g., EJB technology) allows you to isolate valuable corporate assets to DMZ while indicating that layer code can access the EJB server within DMZ. The following figure depicts this distributed solution:
EJB inside the firewall
Here we assume that the representation of the logic is not as important as the business logic of the background. If this is not the case, then the security of this solution will drop, and the entire system may need to be placed within DMZ. If the entire application must (or can be placed behind the second floor firewall, select other techniques (such as issuing JDBC requests through Java Servlets) to be more reasonable.
This solution also has some efficiency defects. For example, when you install WebSphere, if you separate the client (Servlets and JSP files), this selection will reduce overall performance. Compared to the case where the client and EJB components are located in the same JVM, each of which needs to be increased by 20% in the request of the firewall.
Do you need more than one type of client access to shared data? Typically, one application has multiple types that require access to the same information. For example, an application may have a web-based HTML front-end for external customers, as well as a more complete application front end for internal personnel. Usually, this problem is solved by writing two shared the same data source (database table) to the same app. However, this method is not high, whether it is from the programming time or from the simultaneous database utilization. EJB technology solutions are integrated into a set of EJB components for different types of clients (such as servlet / html, and application) to access. The EJB component controls access to background data and manages current transactions and internal locks of the database. By removing the duplicate code in the application, reducing the work of writing database control logic, which reduces the total programming.
There are other solutions in this area - for example, Java applications can access Java Servlets via HTTP, while browsers can also access Java Servlets via HTTP. The problem with these solutions is that if the servlet is used to display information in the browser, it must contain some representation layer logic, which is redundant for transmitting information to another. Therefore, you finally have to use two partially repeated servlets to handle both cases. In addition, HTTP is not the highest efficiency of communication between program communication. You must design a data format that can be delivered from the HTTP pipeline - this is usually or based on the text format, such as XML (resolved by the receiver, generated by the sender), or object-based format, such as Java Serialization. Both formats require a lot of programming, and they are not as fast as local IIOP.
Do you need to read and write to shared data? Typically, the "Fat Client" solution requires access to access to shared data at the database level. The result is that the process of processing database locks and synchronization is very complicated, and if the database lock and synchronization problem will lose data integrity.
EJB technology can automatically handle these complex shared data synchronization issues. As mentioned earlier, the EJB component controls access to background data and manages the internal locks of current transactions and databases. This not only saves the workload of writing database control logic, but also ensures consistency and correctness of data, thereby reducing total programming.
Do you need to access multiple heterogeneous data sources with transaction processing? Many applications need to access multiple data sources. For example, an application may be both an Oracle database from the intermediate layer, but also to access large host systems such as CICS, IMS, such as MQSeries. The key to the problem is that some applications require this access to fully transaction, and data integrity can also be guaranteed between different data sources. For example, an application may require a detailed order information to be stored in the Oracle database while processing the user's ordering information, while using MQSeries in the CICS system in the CICS system. Whether it is a database update or an errors in the MQ queue, the entire transaction should be canceled.
In the past, the only choice to construct such a system is to use transactional monitors, such as Encina, CICS, Tuxedo, which use non-standard interfaces and develop languages such as COBOL, C, C . For example, the EJB container in the advanced version of WebSphere supports multiple concurrent transactions, with the ability to complete transaction submission and transaction cancellation between multiple DB2 data sources, all in a fully supported two-state transaction submission of. Currently, WebSphere is submitted to other data sources (such as Oracle, MQSeries, and CICS) only support single-state transactions. EJB containers in WebSphere in WebSphere can support more data sources to support the second state transaction submission. Most containers are supporting the submission of two status transactions under various data sources. Over time, we will see continuous progress in this area.
Do you need to be able to use the HTML document, servlets, JSP files, client login security seamless integration method level object security? Some types of applications have made it difficult for them to be implemented by Java applications due to their security restrictions. For example, in order to meet the requirements of management, applications, applications, to meet the requirements of the management, must restrict access to customer data. Until the EJB technology appears to limit a particular user to access an object or method. Prior to this, the implementable approach only: restrict access on the database level and capture errors thrown at the JDBC hierarchy; or restrict access on the application layer through the customer security password.
EJB technology can implement method-level security policies in any EJB component or method. The created user and user group can be granted or disabled from operating the operation of any EJB component or method. In WebSphere, the user group can be granted or disable access to the Web Resources (Servlets, JSP files, and HTML pages), and the user's ID can be securely passed securely from the web resource to the EJB component through the underlying security mechanism.
Does the architecture have standardized, lightweight, and components? For many visionary companies, key issues are to achieve mutual independence between platforms, vendors, and application server devices. EJB component architecture in line with industrial standards helps achieve these goals. EJB components developed for WebSphere can usually be used on other types of application servers and vice versa. Although this goal is not fully implemented, it has become a strategic development direction of many customers. In short, it is more convenient to use some features that may exceed standardized, but it has the greatest benefit from long-term standardization.
You should also take into account more and more optional tools and EJB standard optimization implementations, which are not available from the local management object framework. Since most companies do not engage in middleware services, it will focus more effectively in activities that are more directly related to your business.
Do you need multiple servers to meet the system's throughput and validity needs? The fat client system obviously does not adapt to thousands of users that the Web system may have. The problem of software release also requires weight loss to the fat client. The 24-hour uninterrupted operation feature of the Web site also makes time a key issue. But not everyone takes 24 hours to operate, and the system of 10,000 users can be handled at the same time. You should be able to design such a system: to achieve the scalability of the system without increasing the development and standardization difficulty.
Therefore, you have to try to make the business logic written to telescopically meet these needs. EJB technology provides a skeleton for building such a system with high retracte, high-utilization. For example, WebSphere helps developers build such systems through the following features. These features are also suitable for other EJB servers:
Object cache and sharing. WebSphere is automatically shared on the server level, thereby reducing time for creating objects and recycled fragments. This will make more processing time cycles can be assigned to real actual work. The workload of the server is optimized. WebSphere also makes the EJB server have the characteristics of group management. On the WebSphere Application server, you can create a server group across multiple nodes. In addition, you can create a model (abstract representation of the server) and clone them into multiple JVMs. You can configure the clone model to run on any server in the group. In addition, a plurality of cloning models of a server can also operate on a machine to make full use of the structural characteristics of the multiprocessor. Similarly, you can also manage all clones as a group. This improves reliability and avoids damage to the application server when individual is faulty. Automatic fault recovery can be supported by cloning. Because there are several clones that can be used to handle requests, failures are unlikely to destroy the system throughput and reliability. Since multiple nodes run the same service, the failure of a whole machine will not have catastrophic consequences. All of these features do not need to be specially programmed. With this scalable, there is no need to change the code of the server.
WebSphere supports publishing, cloning, and automatic failback of other server-side Java technologies such as Java Servlets, JSP files. However, these techniques that are more directed, and it is said to be the competitors of the EJB component, but it is better to supplement it. When the overall time and scalable are the critical key, the overall solution should include EJB components.
About the description of the two programs, or the description of the correct use of EJB components Now you have already understood whether an app is suitable for using EJB technology, let's compare two applications using EJB components, see EJB Is technology help or hindering developers to achieve their goals. In an example, the correct use of the EJB component makes the code more concise, it is more easy to understand. In another example, the EJB component is used to make the system are too complicated, and performance is not good.
Both applications are examples of multiple other applications, not from a single company or program team.
An example using the EJB technology failed as a member of the high-level technical team authorized to assess the new technology, and a program team initially designed this solution. The program has the following architecture (each box represents different programs running on their respective hardware):
Not desirable EJB architecture
Some specific designs of the architecture make the EJB assembly is not as attractive:
The main part of the application is the display of information, which is implemented by Java Servlets. The EJB component is only used to get, update the data. The data connection used in the transaction processing of the background host does not include data sources that follow the expansion architecture (XA) standard. The transaction cannot be canceled or submitted into a batch, and the access to each host is an independent request. Since the user cannot distinguish whether the user comes from the web or from the background host, the security characteristics of EJB technology are not available here. Servlets are a network request for each access to the EJB component. The internal logic of the component and the internal logic of the EJBLOAD () method performs a real host request, but the EJB component only performs data cache until the transaction is submitted by the EJBStore () method to the host. Each data accessed before transaction has caused a lot of network overhead.
The program team only uses the EJB component as a data mapping mechanism between host data and servlets, which is not an effective use of EJB technology. The applications in this example do not use the following features:
EJB Components Transaction Characteristics EJB Components Method Level Security EJB Components The scalability and distributed features of the EJB component (this program team only uses an EJB server) Business logic sharing between multiple types of clients with container management persistence (CMP) ) EJB component automatic data mapping
If data mapping is implemented directly by JavaBeans components in the same JVM in the same JVM, the system will be much more faster than using the EJB component, while avoiding a lot of network overhead. The system has become unnecessary (because local and remote interfaces, as well as distribution code). In fact, the program is later discarded and redesigned in a manner that does not use the EJB component, where data mapping is implemented by a set of standard JavaBeans components used by servlets. This makes the final system easier and faster. An example of a successful example of EJB technology a financial institution's program team designed this set of schemes, initially used Java and RMI technology. The system architecture is as follows:
RMI server architecture
In addition to a variety of types of clients, the program team also constructs the following two frame units in the system, not drawing in this figure:
A database mapping layer, maps its Oracle data table into Java classes, or in turn via JDBC on the RMI server. A user security frame unit is used to verify users from the browser or the application client, and then determine if the user has the right to perform RMI and database requests.
Since their application needs are closely connected to the goal of EJB technology, the program team is quickly transformed into the following architecture:
New EJB architecture
By using the container management persistence (CMP), the EJB component allows the program team to abandon the database mapping framework, turn on the complete and efficient implementation mechanism in WebSphere and Visualage for Java. By utilizing the security of EJB technology, the program team has reserved the method level safety while the application is abandoned. As a result, their applications become simpler due to the reduced amount of code that needs to be maintained.
Simply put, the following features of the app make it suitable for EJB technology:
A variety of types of clients with shared the same business logic use transaction processing to implement mappings related to objects with object-related mappings.
Since the system's design goal is to achieve the smallest network traffic by using the session level EJB components published simultaneously with the entity, the final architecture uses the EJB component well. For the previous architecture, since the client needs to make a large number of requests, it is likely to increase the network burden, and the system complicates the system due to the start of the client.
Summarizing a new system that may use EJB components, the first step in making correct decisions is to know how to determine if the EJB technology is suitable for this application, including the selection EJB component as a positive and negative impact brought about by means of implementation. .
Reference
A Mini-Pattern Language for Distributed Component Design (PDF format) describes a small language for constructing applications using techniques such as EJB. The Enterprise JavaBeans Specification, 1.0, and 1.1, describe what EJB components and how to create an EJB component. Enterprise Java Beans, Published By O 扲 Eilly & Associates, Sebastapol, California, 1999, is current about how to use the best reference for EJB components. The Visualage Developer Domain site contains more articles about the EJB architecture and how to create EJB components using Visualage for Java. For more information on WebSphere's transaction and persistence features, please visit the WebSphere home page.
About the Author Kyle Brown is a senior Java software engineer in IBM WebSphere service. He often talks about some important IBM customers to help them master how to use WebSphere and J2EE technology to solve their business problems. He wrote many articles for the company publication (for example, the Java Report), currently engaged in the Column of the Enterprise JavaBeans Components for Visual Development Technology Magazines. He is still the Design Patternal SMALLTALK COMPANON and Enterprise Java Programming With IBM WebSphere, the two books will be published by Addison-Wesley Press in 2000. His email: brownkyl@us.ibm.com.lee cook is a software engineer working on consultant and is currently working on the Analysis Software Development Team of WebSphere Website. Previously, he was engaged in the early development of WebSphere application servers and IBM ServleTexpress. He has participated in the development of resource monitoring components designed for servlets, EJBs, sessions, database sharing, and JVM resources to provide real-time graphics. His email: leecook@us.ibm.com.
