Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 133 134 135 136 137 138 < 139 > 140 141 142 143 144 145 .. 166 >> Next

JDO and Data Persistence 385
If you are working within a container, you should use the resource pooling capability provided by the container. Often it is invalid not to use the container resource pool, which can cause component developers to have problems with the portability of their code. Also, this allows for one convenient place for the container configuration to provide this service to all of its applications. It can be configured or changed without having to change every application that runs in the container.
The J2EE Connector Architecture is increasing in popularity for integrating backend systems. This architecture provides for resource managers, which provide similar access to heterogeneous systems like Enteprise Resource Planning (ERP) and Human Resources Management Systems (HRMS) systems.
Item 46: JDO and Data Persistence
The foundation of any enterprise application is the data layer. This also determines how data will be persisted on your system. To me, deciding on a proper data persistence mechanism is like passing a very large kidney stone. Perhaps that is an overstatement, but it's an arduous process that requires an exhaustive understanding of your system and the technologies that will allow you to apply the best solution to your data storage/retrieval activities.
A proper persistence strategy typically consists of storing information in byte streams through serialization, hierarchically arranged data in XML files, Enterprise Java Beans, relational/object databases, and now Java Data Objects (JDO). The problem is that once you make a commitment to one technology, there's always a lot of second-guessing because of unforeseeable implementation hardships and performance issues.
Relational databases and EJBs can be effective tools for performing data persistence activities, but Java Data Objects offer a powerful new alternative that should be considered in allowing object-based access to your back-end data stores. JDO's strength lies in its ability to allow developers to use both Java and SQL constructs to manage data manipulation and access, and in its binary portability across data stores.
There are always design and implementation trade-offs in software development, especially when it comes to data persistence and retrieval. Although serialization is fairly simple to implement and does a decent job of preserving relationships between Java objects, it is nontransactional and can be a performance hog. JDBC is great for handling transactions, but it can require extensive field management and data mapping activities and can be tedious when you are implementing several SQL language constructs. JDO is fairly new and is not fully developed, but it promises to make developers more productive by allowing business logic manipulation through the use of Java interfaces and classes without having to explicitly understand SQL operations.
To gain a better appreciation of the strengths of JDO and how its transactional capabilities should be considered along with traditional methodologies, you need to understand data persistence in its most common form: serialization. Serialization is a simple technique used to transfer and store objects in byte streams and, most recently, in XML, but this is performed in a nontransactional manner. The code below demonstrates a simple manner that data can be serialized to the system disk space and read back. The ObjectInputStream class on line 122 deserializes data that was created previously using ObjectOutputStream.
386 Item 46
001 package serialization;
002
003 import java.util.*;
004 import java.text.*;
005 import java.util.Date;
006 import java.io.*;
007 import java.net.*;
008 import java.beans.*;
009 import java.util.logging.*;
010
011 public class serializeBean {
012
013 private String firstname;
014 private String lastname;
015 private String department[];
016 private String ssn;
017 private String comments;
018 private String filename;
019 private String filename2;
020
021 //private String firstname2;
022 //private String lastname2;
023 //private String ssn2;
024 //private String comments2;
025
026 private Hashtable errors;
027
028 private static Logger logger = 2
Logger.getLogger(serializeBean.class.getName());
029
030 public boolean validate() {
031 boolean errorsFound=false;
032
033 logger.info("[validate:] lastname, firstname, ssn, comments=
" + lastname + ", " + firstname + ", " + ssn + ", " + comments);
034
035 if (firstname.equals("")) {
036 errors.put("firstname","Please enter a valid Firstname");
037 errorsFound=true;
038 }
039 if (lastname.equals("")) {
040 errors.put("lastname","Please enter a valid Lastname");
041 errorsFound=true;
042 }
043 if (ssn.equals("")) {
044 errors.put("ssn","Please enter a valid Social Security #") ;
045 errorsFound=true;
046 }
047 if (comments.equals("")) {
048 errors.put("comments","Please enter a valid comment");
Previous << 1 .. 133 134 135 136 137 138 < 139 > 140 141 142 143 144 145 .. 166 >> Next