Java development is at a crossroads. The open standards have done lot of good for the Java platform and language, but they have brought in some problems too. Developers are often drenched in the complexities that surround Java development. Worse yet, these complexities are so overwhelming that the actual business problems take a back seat.

When I started working with Java, I mentioned my move to a colleague of mine, a Microsoft devotee. He wasn't willing to move to the Java platform until supporting integrated development environments (IDEs) were as powerful and easy to use as Visual Basic. Although at the time nothing in the Java world was as simple or configurable as Visual Basic, I bit the Java bullet - and the bullet tasted like VisualCafé. Originally from Symantec Corp. (www.symantec.com) but now owned by an independent company created by Warburg, Pincus and BEA Systems, VisualCafé was the closest Java IDE in the industry that could compare to VB, and it remains on the bleeding edge of support for new Java technologies. This month in EJB Home I'll discuss what to look for in an IDE that supports EJB, as well as the support for Enterprise JavaBeans development that has been integrated into the VisualCafé Enterprise Edition for WebLogic.

In EJB/CORBA integration, complexity can range from simple to complex and depends in part on the direction of the communication. From EJB to CORBA, communication is relatively simple because the EJB bean invokes CORBA as it does any external resource. CORBA-to-EJB communication, however, depends on the application server's support of RMI-IIOP. If the application server doesn't support RMI-IIOP, then it's best to create a wrapper or adapter class that redirects or delegates the function calls from the client via a CORBA servant, which then calls the EJB.

Are you tired of going through the cumbersome process of creating local/remote component and home interfaces for your EJBs, as well as the necessary WebLogic XML deployment descriptors? Wouldn't it be wonderful to develop only the particular EJB bean file and have another tool generate all of the necessary interfaces and WebLogic deployment descriptors? Look no further: XDoclet to the rescue! XDoclet is an open-source tool that uses attribute-oriented programming concepts to automatically generate various source code files based on embedded XDoclet-specific javadoc comments.

The standard EJB 2.0 container- managed persistence (CMP) query language known as EJB QL allows users to retrieve container-managed entity beans, subject to constraints that are described using the same object-relationship model that was constructed to describe beans in EJB deployment.

Working as a BEA consultant, I've helped customers successfully design and deploy applications on various versions of the WebLogic Server (WLS). BEA has been supporting container-managed persistence (CMP) entity beans since EJB 1.0, and a few of our customers have used them. Unfortunately, some used them without understanding the ramifications; others heard about performance constraints and completely excluded entity beans from their architecture/design choices.

One of the toughest challenges of any software development architecture is reconciling the object-oriented paradigm with that of the relational database. If this isn't done properly, the object layer will become too closely tied to the database schema and any change to the database schema will cause a large amount of rework in the object layer.

This is the second in a series of three articles discussing the clustering capabilities of BEA WebLogic Server 6.1 (WLS). This month we discuss replica-aware stubs, their impact on a clustered system, and how they're used with EJBs.

Entity Enterprise JavaBeans (EJBs) are a convenient means to map persistent data to Java components. Container-Managed persistence (CMP) provides rapid development since the EJB container automatically handles loading and storing the persistent data. However, along with their many advantages, Entity EJBs can lead to very slow performance when used incorrectly. This column details a few common pitfalls which trip up EJB programmers and hinder the performance of their Entity beans.