content:
JDO Overview Session BEAN and JDO Advantages Disadvantages Entity Bean Some Contrast Conclusions Reference Information About The Author's Evaluation
related information:
J2EE Adventure Series The Abcs of EJBSJAVA Data Objects Practices CASTOR JDO Getting Started with JAXB Data Binding DeveloperWorks Toolbox Subscribe
There is also a Java area:
Teaching tools and product code and components all articles practical skills
Compare Java data objects and EJB technology
Level: Intermediate
Kyle Gabhart (Kyle@gabhart.com)
Consultant, Gabhart Consulting 2003 July
The "Explorer" column of the last month introduced J2EE technology for data persistence: entity bean, JDBC, and Java data objects (Java Data Object, JDO). This month, the company Java expert Kyle Gabhart no longer specifically discusses more mature JDBC technology and EJB technology, but mainly introduces JDO. Although this technology is not mature compared to other technologies, you will find that JDO has some unique advantages.
Application components should implement requests for enterprise services. To implement these requests, application components often have to change the status of underlying data storage. These changes are absolutely unable to destroy the integrity of persistent data storage. (In the first article about data persistence, we define persistent data storage as a stand-alone data repository, even when the server crashes or the network fails, this data repository can protect it.) To ensure that lasting Sex, application components must be able to handle concurrency, connection management, data integrity, and synchronization. J2EE's three data management technologies can handle these features for developers, but each technology has its own processing method.
We explored the advantages and disadvantages of entity beans and JDBC last month. This month, we will see how Java data objects are combined with stateless session beans, and how the solution is compared to standard entity bean applications. Since JDO is still a quite new technology (the latest J2EE persistence solution), we will first outline its working principle.
JDO Overview The relationship between Java applications and persistent data management has not been easily handled. Many persistence mechanisms store data with a relationship rather than object-oriented methods. That is, the data is stored in a table consisting of records containing fields, rather than being stored as self-contained objects (these objects have internal data and reference to other objects, while other objects also have internal data and reference). Conversion to the object-oriented representation into relationships indicating that it is very troublesome, easy to make mistakes and reduces application performance. Until recently, a few inquirable persistence mechanisms (such as SQL BLOB and Java serialization) are very troublesome. Most persistence mechanisms allow developers to handle persistence, or use non-Java language (eg SQL) to interact with backend data storage.
The advantage of JDO is that it is very simple. Developers use Java language persistent storage object instances and retrieve instances from memory. Processing logic, synchronization, and failover, etc. are transparently processed. Developers don't need to use the inconvenient sequence mechanisms provided by SQL or Java languages, only POJO (unformatted ordinary Java objects) can be used to deliver object references to memory using the JDO interface and retrieve object references from memory.
J2EE Persistent Technique Entity Bean provides robust data persistence. The BEAN container handles most of the work of data integrity, resource management, and concurrency features, allowing developers to focus on business logic and data processing without having to consider these low-level details. Use Bean management persistence (BMP) entity bean, developers write persistent code, but is determined by the container when the code is executed. Use container management persistence (CMP) entity bean, the container generates persistence code and manages persistence logic. JDBC can provide easy EJB development and deployment with the platform when combined with session beans, and there is no common resource usage and memory overhead in EJB technology. Similar to BMP entity beans, this solution requires developers to write persistent codes. Unlike BMP Bean, it also requires developers to write persistent logic. Therefore, developers should be responsible for determining when to keep data to data storage and when to store data from data. Java Data Objects (JDO) are the latest persistence mechanism. JDO provides object-oriented persistent data storage. Developers can use Pojo (unformatted ordinary Java object) to load and store lasting data. JDO also uses a lot of JDBC used in the advanced architecture. It uses an insertable architecture in which developers write their code into a standard interface set (JDO API), while suppliers provide these interfaces. This allows the application of the application "insert" any data store that supports the JDO API using the application of the JDO interface. Like JDBC, this can make transplantation, and promote competition between suppliers, resulting in better products, because the supplier will strive to provide more effective and more powerful implementation.
Session Bean and JDO Session Beans are the base of the J2EE architecture combined with EJB technology. This is especially true for stateless session beans. As previously discussed, the stability and predictability of stateless session beans make it particularly suitable for managed persistent enterprise data.
But the session bean itself cannot access persistent data storage. They must be combined with other technologies (such as entity beans, JDBC or JDO) to create a persistent data management mechanism. A conversation bean is combined with JDO to combine them with JDBC, but JDO is handled by more object-oriented and more Java-censors.
The powerful combination is accessible to the external resource by requesting the resource manager connection plant by requesting the EJB container. EJB components using JDBC are doing this, and the EJB component using JDO is also doing this. The first thing that the session bean must do is to obtain reference to the PersistenceManagerFactory by calling the JNDI query. Then get the PersistenceManager instance from the factory. If the session bean is using the container-managed transaction, each business method will use the factory to get a new PersistenceManager instance, and then turn off the instance before exiting the method. If you are using a BEAN-managed transaction, the developer will determine the start condition and end condition of the transaction. Therefore, the same PersistenceManager instance can be used in multiple business method calls. Again, multiple transactions can be opened and managed in a business method. The PersistenceManager API supports all of these programs.
The JDO API interacts with the PersistenceManager is simple and very intuitive. Developers have long lasting by calling the makepersistent () method. Moreover, this method characteristic is overloaded to allow various object types to be considered a persistent object (single object, object array, or object collection). Search objects are equally simple. The getObjectByID () method uses the unique value (similar to the primary key) determined by the developer (similar to the primary key). JDO also supports type-based queries that can retrieve individual objects or object collections based on the specified type (ie, the subclass and classes that implement common interfaces). Similar to JDBC, JDO supports basic transactional controls: Begin (), commit () and rollback (), and pointing out that the PersistenceManager instance should adopt an optimistic or pessimistic transaction management method. Advantages As a combination technology solution, session beans and JDO provide many advantages, some from session beans, while others come from JDO. As we have learned last month, the main advantages of using session beans without using entity beans:
Simple design. From the viewpoint of architecture design, it is much more simply by session beans to handle data management than using entity Beans. Fine-grained control. Because session beans are common work program components, they allow developers to fully control the entire persistence process, including cache, persistence, concurrency, and synchronization.
These two advantages are not unique to the session bean / jdo combination: the session bean and JDBC have the two advantages. However, JDO does provide some unique advantages:
Simple coding. The JDO architecture hides the developer's low-level persistence details, allowing them to focus on the perspective of the business process, not to fall into the trivial details of data persistence logic. Improve productivity. JDO programmers can operate in an object-oriented example. This usually makes it easier to develop, smoother and more difficult, because programmers do not have to convert frequently between the ideological system and object-oriented ideological systems. Object-oriented persistence. JDO's object-oriented nature not only increases developer productivity, but it also takes into account the remaining persistence mechanisms provided by relationship durability. JDO does not only last for Java objects; it also transparently processes the persistence of the entire related object map. Therefore, when an instance is persisted, any internal reference to other object instances is also stored (unless they have been declared). JDO also stores the full information of the type hierarchy, and can implement requests based on the type (parent class, and interface), not only the specific local types of lasting instances.
Summary, combine session beans with JDO can produce three main advantages: simple (in design and development), productivity, and enhanced data persistence.
Disadvantages From its advantages, session beans and JDO are perfect combinations to solve all persistent problems! But let's consider some of the shortcomings of this method:
JDO is immature. JDO is still in the early days. When writing this article, the release of JDO 1.0 specification is less than a year. As a result, the JDO community is still very small, the largest and most prestigious JDO portal can show off, but their members have more than 5,000. Although these data do not mean that JDO is a bad technology, they do indicate that it is still in front. Almost no few companies are willing to try to use JDO in business-level implementation. All of these status makes JDO developers and architects have almost no proven design modes or case studies to guide their JDO development. Session beans are not transactional. J2EE clients cannot directly access JDO objects. Enter requests must be processed by servlet or session beans. Therefore, although it is easy to declare a JDO object as a transaction, a non-transactional component must be used to access them. When the transaction semantics directly encodes the application code of the session bean, the developers must do everything possible to ensure that the business rules, process control, and transaction integrity of each function are reserved and fault tolerant. Although the transaction that uses container management can greatly alleviate this problem, this limits the control of the developer's control for persistence processes, and removes the architecture of the system generated by many controlled transaction. Flexibility. Summary, the combination of session beans and JDO has two major disadvantages: JDO is a technique without practice, and the session bean introduces an intrinsic non-transactional layer to the business process.
Entity Bean We have discussed the advantages and disadvantages of the entity bean in more detail, so it only summarizes the closestness of this relationship with this article.
As the company's data persistence mechanism, the entity bean has five main advantages:
standardization. The EJB specification is mature, so there are many advantages: well-known design patterns, case studies and best practices, as well as the development tool set supported by suppliers. Container management services. EJB containers make developers don't have to manage common enterprise features such as security, transaction, connection and external resource management. Transparent persistence. Entity Beans provides two transparent options for processing persistence. Persistence (CMP) entity beans managed automatically all persistence semantics in the container. BEAN-managed persistence (BMP) entity bean allows developers to write persistence logic, but still alleviate responsibility for ensuring data integrity and concurrency (by assigning these tasks to the container). Business support. Entity Beans provides two transaction support models. Declare transaction semantics in CMP beans. In BMP beans, developers directly implement these semantics. In both cases, it is a container management transaction, and it is determined that a given transaction should still roll back. Component-based design. The entity bean is designed to be self-contained, these components use the deployment descriptor configuration, and they can deploy them into any J2EE application server without modifying any code.
On the other hand, there are four major disadvantages of entity Bean:
Design complexity. The service and automatic and transparent persistence of the container introduces complexity for the entire application design. Entity Beans can also be accessed through session beans, which means that each transaction contains at least two corporate beans, and usually more. The build cycle is very long. The time compared to the EJB cycle (Design / Construction / Test / Integration / Test / Deployment) is 2 to three times the ratio of Java persistence solutions. Response time. The entity bean is related to the particle size of the bean instance. Therefore, developers always face the choice: either load the beans as it is, and solve the problem of longer response time in other aspects; either decompose the data into a smaller entity, thereby creating a more complex system architecture. Resource usage. The entity bean consumes a large number of system resources.
Summary, entity beans have benefited from standardization and industry best practices, reducing some of the complexities developed and provides a firm component-based design. However, the cost paid for these advantages is that entity beans typically introduce complexity and long build cycles, making it more difficult to design and develop the system design and development of them. The entity bean also has a good reputation due to excessive resource and the response to large entities. When comparison is compared to any two techniques, it is important to not only consider their differences, but also consider their similarities. As a J2EE technology, the entity bean and Java data objects have several common features. Let's discuss these features and then discuss the unique advantages and disadvantages of each solution.
Entity Beans and JDO have the following features:
Transparent persistence. The freedom of transparent persistence is that people dream of, developers don't have to know the technical persistence details. JDO and entity beans have enabled Java programmers to enjoy this. portability. JDO and entity beans are based on standards that are not related to suppliers. Applications written in their respective standard APIs can be transplanted to different suppliers' API implementations. Flexible transaction management. JDO and entity beans have provided developers to choose from: Managing transactions, or automatically managers. JDO uses the PersistenceManager management transaction, and entity bean assists the Transaction Management to the EJB container.
When it is determined that the entity bean is used to use JDO, consider the following advantages and disadvantages of these two technologies:
Best practices and complexity. Enterprise JavaBeans technology includes rich literature, an already text design pattern and best practices, a delicate tool, and a large number of J2EE programmers with EJB technical experience. A disadvantage is that the complexity of entity beans allows you to use all of these useful assets to ensure the success of the project. Aiming at a large number of EJB technology, architect designers and developers must find balance in the availability of experienced programmers, design patterns and industry best practices. Lack of experience and simplicity. For the shortcomings in best practices, JDOs make up for simplicity. It is simple and easy to use, and Pojo is easier to understand than "entity" concept. Although Java programming experts with practical JDO experience is very small, this technology is easy to master. The J2EE architect designer and developers must trade out the impact of the lack of model, best practices and case studies. Lack of old support. Currently, there is no major relational database management system (RDBMS) provider supports JDO. Therefore, developers must migrate system data to support JDO vendors, or to use JDO only for new projects or components that do not rely on old RDBMS data stored. New persistence example. JDO takes into account the rich object-oriented persistent mechanism, which takes advantage of object synthesis (objects containing other objects) and inheritance (identifying object types through a complete type hierarchy). Although JDO's object-oriented persistent examples have brought a lot of convenience to application developers, it also grasses and confused database administrators (DBA). At present, JDO does not provide a mechanism for combining a stored procedure, so DBA will spend hard to learn how to use XML declaration constraints, or how to guide Java developers how to manage data. We discovered that JDO is more suitable for new projects, new components, or existing applications independent of old RDBMS. Resource usage. Although the available performance benchmark test procedures are very small, we can assume that the server resources consumed by the transparent persistent application will be more than JDO-based applications.
Conclusion In this J2EE Explorer series column articles, we have completed the exploration of data persistence, which is one of the most technically technically domains in Java development. Although J2EE has three reliable techniques for handling data persistence, no one is perfect.
Over the years, JDBC has been a standard for Java developers for data access. It is a firm and proven technology that allows architect designers and developers to use existing relational database infrastructure and existing expertise to generate database queries. Over time, it has developed into a perfect database driver that can provide complete cache and resource pool mechanisms, which is clear that this makes developers a lot. As a business persistence technology, there are still some shortcomings in JDBC, which allows developers or databases to manage concurrency and data integrity. Despite this shortcomings, it is widely used due to its maturity, universal applicability and performance. Entity Beans is slightly mature than JDBC, but they still provide a reliable solution for business data persistence. Just as using JDBC, architect designers and developers can use existing relationship database infrastructure and existing expertise to generate database queries when using entity Beans. Entity Beans can simplify the process of developing robust data persistence code, because EJB containers provide many lifecycle companies, such as security, resource management, transaction control, and transparent persistence. Entity Beans provides a powerful data persistence solution that transparently handles a lot of semantics and details for developers. This powerful feature and relaxed development is that entity beans are resource-intensive, and it is very complicated to properly set it.
Java data objects are an alternative technique that is attractive to the JAVA data object for J5EE camps. JDO's pure surface to object methods and design make it shorter than the other two persistence techniques than other two kinds of persistence techniques. However, JDO does not have JDBC or EJB technology mature, which causing developers and architect designers who are unable to get enough resources when making design and deployment decisions. Moreover, the JDO requires DBA to make a clear commitment to use it to use the new data management examples for the use of all the ease of use of JAVA developers.
Next month, we will explore enterprise messaging to end the first adventure in the EJB technology field. When I arrived, I hope to have a happy explore!
