Enterprise JavaBeans (EJB) is a specifications and structure of development and deployment of distributed servers, with transaction-processed, secure business components. The EJB architecture is the foundation and core of J2EE, and J2EE defines the entire standard application development architecture and a deployment environment. In this architecture, application developers focus on packaging business logic and business rules, all of the issues related to infrastructure services and underlying allocation issues are handled by application containers or servers. Even the runtime attributes of application components belonging to transactions, persistence, safety, etc. can be customized in deployment environments using highly flexible statements. This architecture defines a container and a server model - the container is an environment where the application component survives and executes, but this container is home in one server. The J2EE platform provides a simplified development model that has industrial intensity scalability, supporting reasonable integration and flexible deployment, unrelated to developers and application servers, which makes some dedicated application servers and dedicated distributed objects. The frame becomes ancient times. EJB's role and responsibility EJB specification defines several standard roles and responsible, as follows: 1.EJB server provider's application server should be an expert in distributed transaction, system services, etc. 2. EJB container provider provides an EJB component instance runtime and deployment tool. The EJB server / container provider is a typical operating system developer, a database developer, or an application server developer. EJB server and EJB container should be provided by the same developer, because both the ejb1.1 specification (final version) or EJB2.0 public draft version (being modified) does not define the interface between the two . 3. BEAN's provider or EJB assembly developed by EJB developers contains business logic and business features. Each EJB component provided by EJB developers should meet the following conditions: EJB implementation should include all necessary components - container contract methods, such as: ejbcreate (), ejbremove (), etc. and some business methods (Business method); home interface; Remote interface; if you need to help classes. The HOME interface provides the signature for the method of creating, deleting, and looking up the EJB instance, and the Remote interface defines the signature of the business method. 4. Application assembly puts some EJB components developed by the bean provider into a complete J2EE application. 5. Deployer is an expert in the target product environment deployed by the application, which installs the application component in the application server and configures their transactions, persistence, and security. This way you can manage complex problems, such as: transaction, concurrency, persistence, and security. 6. System managers are responsible for the configuration and management of the server, run monitoring and load balancing. 7. Application user interface developers are responsible for user interface and representation logic. The focus of this article focuses on the restrictions on the code of the BEAN provider / EJB developer and the EJB component. The EJB component constraints EJB developers do not need to write system-level services in the EJB component implementation of code, EJB provider / developers need to know and strictly abide by some restrictions, these restrictions and development stable and transplantable EJBs The interests of the components are related. The following is some of the Java features you should be avoided, and you should strictly limit their use in your implementation code of your EJB component: 1. Use static, non-final field. It is recommended that you declare all static fields in the EJB component as Final type. This ensures that the previously identical run semantic, so that the EJB container can distribute the flexibility of the component instance between multiple Java virtual machines. 2. Use thread synchronization primitives to synchronize the operation of multiple component instances. Avoid this problem, you can make the EJB container distribute component instances between multiple Java virtual machines.
3. Use the AWT function to complete the input and display output of the keyboard. The reason for constraints is that the commercial components of the server means providing business features without including the I / O functionality of the user interface and keyboard. 4. Use the file access /java.io operation. The EJB business component means that the use of the resource manager such as JDBC to store and retrieve data instead of using the file system API. At the same time, the deployment tool provides storage environment entities in the Deployment Descriptor (Descriptor), so that the EJB component can be in an environmental entity inquiry by environmental naming context. Therefore, the demand for using the file system is basically excluded. 5. Monitor and receive the socket connection, or use the socket to make multiple channels. The EJB component does not mean providing a network Socket server function, but this architecture allows EJB components to communicate as a Socket customer or an RMI customer and can communicate with the code outside the container. 6. Using the Image API query EJB component The class that the security rule cannot be accessed. This constraint enhances the security of the Java platform. 7. To create or get a class loader, setting or create a new security manager, stop Java virtual machine, changing input, output, and error flow. This constraint enhances safety while retaining the capacity of the EJB container to manage operational environments. 8. Set the socket factory to be used by URL's Serversocket, Socket, and Stream Handler. Avoid this feature, you can strengthen security while retaining the EJB container to manage operational environments. 9. Use any method to start, stop and manage threads. This constraint eliminates the possibility of conflicting the responsibility of the EJB container manages deadlock, threads, and concurrency issues. By limiting 10-16 features, your goal is to block a potential security vulnerability: 10. Read and write file descriptors directly. 11. Get safety policy information for a specific code. 12. Load the original class library. 13. Access the packets and classes that the Java general role cannot be accessed. 14. Define a class in the package. 15. Access or modify security configuration objects (policies, security, providers, signs and entities). 16. Use the subdividing classes and objects in the Java serialization. 17. Pass the THIS reference pointer as a parameter or returns the THIS reference pointer as a return value. You must use the result of getEJBObject () in sessionContext or EntityContext. The Features listed above the Java2 platform is in fact that the standards of the Java programming language and the Java2 standard are all standards, powerful features. The EJB container allows you to use some or all of the restricted features from J2SE, although it is not available for EJB components, but you need to use J2SE security mechanism instead of using J2SE API. The Java2 platform defines a security policy set for the security policy set by the EJB container in the EJB1.1 specification, which appears in the programming limit of the EJB component. Through this strategy, some licenses are defined, such as: java.io.filepermission, java.neet.netpermission, java.io.seflect.ReflectPermission, java.lang.security.securityPermission to strengthen the program limit listed before. Many EJB containers do not strengthen these restrictions, they hope that EJB component developers can follow these programming restrictions or have ventilated ideas violate these restrictions. Violation of these restricted EJB components, which will rarely transplant between multiple EJB containers than the standard methods. In addition, some uncertain, difficult to predict problems will be hidden. All of this is enough to make EJB component developers should know these programming limits, and should also comply with them seriously. Any implementation code that violates these programmable EJB components cannot be checked when compiling, because these features are indispensable parts in Java language and J2SE.
These limits for EJB components are also applicable to the Help / Access (Helper / Access) class used by the EJB component, and the J2EE application is packaged into a file with .ear (represents Enterprise Archive) extension. In this EAR file, it is a standard format for sending to the file deployment. EAR files include EJB components in one or more EJB-JAR files, and may have library files dependent on EJB-JAR. The code in all EAR files is an application that is well thought out and comply with programming restrictions and access licenses. Future version of the specification may specify the ability to customize the security license by deploying tools. By specifying a license permitted by legal components, it also specifies a standard method: such as reading the file from the file system What are the requirements. Some EJB containers / servers currently provide more or less license permissions than standard permissions in their deployment tools, which are not required in the EJB1.1 specification. Understanding these constraints The EJB container is the runtime environment of EJB component survival and execution, and EJB containers provide some services for EJB component instances such as transaction management, safe persistence, resource access, and client connections. The EJB container is also responsible for the management, expansion problem and concurrent processing of the EJB component instance. Therefore, the EJB component is hosted in a managed execution environment - ie EJB container. The EJB container is also the middlemen of the EJB component and the external world. It provides a client connection service to allow application customers to access and use the features provided by the EJB component. transfer. EJB containers are also EJB components and intermediaries accessing other resources and services, because EJB containers intervene in application components and J2EE services, which can transparently introduce services defined by component deployment descriptors, such as transaction management, security, persistence, Concurrency processing and status management. The resource is an object that encapsulates the access to the resource manager because a resource factory is an object used to build resources. For example, a JDBC connection represents an object that implements a Java.sql.connection interface, which is used to provide resources to access the database management system, and implement the object of the Javax.Sql.DataSource interface is a resource factory that is like this JDBC. Similarly, there are many resource factories that have obtained JMS, Javamail, and URL, and there is no other resource factory except. (J2EE connection architecture, currently being modified, will look forward to the specification of J2EE future versions, this connection architecture defines the standard resource adapter and the contract attached to connection, transaction, security management, so the application server will be standard and Insert a variety of enterprise information systems, including ERP (such as SAP R / 3), main framework transaction processing system, and database system. Because EJB containers are completely responsible for EJB components, concurrent processing, resource access, security, etc. Therefore, the possibility of conflicting the lock and concurrent management of the container itself needs to be eliminated. Many restrictions need to be used to fill in potential security vulnerabilities. In addition to the issue of EJB container responsibility and security conflict, EJB components also means just focusing on Business logic, it relies on the services provided by the EJB container instead of directly solving the underlying system layer. Possible problems typically, the transplantation between EJB components in the container is inevitably related to the following questions: 1. It needs Relying on restricted features are not enhanced in a particular EJB container. 2. It needs to be available from the container from the container.
