Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Figure 1: The J2EE environment
Click on thumbnail to view full image (25 KB)
Source: Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition, by Sun Microsystems' Nicholas Kassem and the Enterprise Team
Ever since its debut in early 1998, Java developers have been clamoring about working with Enterprise JavaBeans. I work at a Java-focused IT consulting and solutions firm, and we come across our share of Java developers who only want to work with J2EE or, more specifically, EJB. While EJB is an elegant technology, many developers new to that technology do not understand that it is not a one-size-fits-all solution. EJB brings with it a lot of bells and whistles (e.g., security, transactions) that are not required by every application. For example, sometimes developing Web applications with local classes is perfectly acceptable, especially for smaller projects, provided good object-oriented design principles are applied.
Also, EJB might not be needed for nondistributed applications such as batch processes in which speed might be more important than security and transactions. Due to the distributed nature of EJB, data must be marshaled (serialized) and unmarshaled (deserialized) to facilitate communication between a client and the EJB component (server). That consequently introduces a lot of overhead and can result in poorer performance. Using local classes in the same JVM might be a better option.
If EJB is appropriate for an application, then a different type of problem is often introduced: lack of theoretical and practical knowledge of EJB technology. I am surprised that so few Java developers who design J2EE-based applications have actually taken the time to read the J2EE Blueprints from Sun (see Resources section below).
Developers who are not very knowledgeable about how the EJB architecture works and expect that the application server will
handle all scalability issues can end up creating applications that do not scale. That can happen in several ways. For example,
when using Container Managed Persistence (CMP) for entity beans with products such as WebLogic in which each bean is mapped
to a single table, the application can perform poorly in a complex database environment. In such a situation, several developers
resort to using Bean Managed Persistence (BMP), which involves coding in the database calls in the Enterprise Bean. Here,
an inexperienced developer can face performance problems because there is no standard for how often methods such as
ejbStore() are called; in other words, improper design means that an Enterprise Bean can wind up hitting the database much more than
would be required. With BMP style, persistence-related portability issues need to be addressed as well.