Mastering Enterprise JavaBeans™ and the Java 2 Platform, Enterprise Edition - Roman E

Understanding EJB 1.1 665

has synched with Java 2, and allows you to return java.util.Collection classes as well.

New ejb-client jar file. One common question deployers ask is, “which classes do I need to deploy with my client applications that call enterprise beans?” EJB 1.1 allows you to specify the exact classes you need with an ejb-client JAR file. An ejb-client JAR file is an archive of classes that must be deployed for any clients of a particular ejb-jar file. You specify the name of the ejb-client JAR file in your XML deployment descriptor, as shown in Source D.12.

Primary key class creation can be deferred until deployment time. When you’re developing beans, you occasionally might not know which primary key should be associated with one of your container-managed persistent entity beans. This is especially true if you’re shipping a bean for others to use, and each deployed environment may have a different underlying storage, and each storage may require a different primary key structure. If you’re in this situation, EJB 1.1 allows you to defer the creation of the primary key class until deployment time. The deployer will then need to create the appropriate primary key class. See the EJB 1.1 specification for more details here.

javax.ejb.deployment deprecated. EJB 1.0 defines a package called javax.ejb

.deployment. You use these APIs to access serializable deployment descriptors in-memory. You could write a small Java program that generated deployment descriptors using this package. Don’t worry about understanding this package—since EJB 1.1 deployment descriptors are XML documents rather than serialized Java objects, EJB 1.1 completely deprecates javax.ejb.deployment.

...

<ejb-jar>

<enterprise-beans>

...

</enterprise-beans>

<!--

This is an optional instruction to the deployer that he must make the EmployeeClient.jar file accessible to clients of these beans. If this instruction does not exist, the deployer must make the entire ejb-jar file accessible to clients.

-->

<ejb-client-jar>EmployeeClient.jar</ejb-client-jar>

</ejb-jar>

Source D.12 Declaring an ejb-client JAR file within an EJB 1.1 Deployment Descriptor.

Go back to the first page for a quick link to buy this book online!

666 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

For More Information

For the complete (and final) EJB 1.1 DTD, see the EJB 1.1 specification, linked from this book’s accompanying Web site at www.wiley.com/compBooks/roman. There is also a comprehensive sample deployment descriptor in the EJB 1.1 specification. You can use it as a template for your own deployment descriptors.

Beyond EJB 1.1

On December 8, 1998, at the Java Business Expo in New York City, Sun Microsystems announced a roadmap for the future of EJB. The road ahead is segmented into three phases:

Phase One is represented by the EJB 1.1 specification, which is rolling out as this book goes to press. It focuses on stabilizing the application servers that vendors create. The enhancements to the specification is mostly issue clarifications and bug fixes. It “improves” security, but certainly doesn’t eliminate the issue. It replaces serialized deployment descriptors with XML. It does not address heterogeneous EJB servers and interoperability, nor does it define an event service based on JMS. Entity bean support has become mandatory in EJB 1.1.

Phase Two is represented by the EJB 2.0 specification, which should roll out in late 2000. EJB 2.0 promises some enhancements to provide vendors with more sophisticated legacy integration. It will define a standard framework for existing enterprise information system connectors. In other words, if 3rd party enterprise software developers (such as SAP) were to integrate with EJB, they would only have to build one connector, and that connector could run in any EJB server. EJB 2.0 also promises support for relationships between entity beans, handling such things as cascading deletes (what happens if you delete an entity bean that refers to another entity bean?). Finally, EJB 2.0 will have JMS support for asynchronous communications.

Phase Three will standardize the mapping between a specific deployment scenario and EJB. The goal is to allow developers to create applications built upon the Java 2 Platform, Enterprise Edition without binding themselves to the specifics of an underlying proprietary technology, such as a database, transaction server, or directory server. This release should enable true portability and interoperability across multivendor implementations.

The roadmap for EJB appears in Table D.2. Note that Sun will likely take a bit longer than what we see in this chart.

Go back to the first page for a quick link to buy this book online!

Understanding EJB 1.1 667

Summary

In this appendix, we’ve seen the new features in EJB 1.1. Although EJB 1.1 is a minor update from EJB 1.0, it is a very important update because it allows you to write very portable enterprise bean code. This, along with the Java 2 Platform, Enterprise Edition, provides for a stable, robust development platform for the enterprise.

Go back to the first page for a quick link to buy this book online!

670 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

should make products compatible, every vendor’s product will realistically differ from the next in some semantic ways, which will impact your deployment. Ideally, you want to make the right choice the first time you make the purchase.

Unfortunately, there is currently no way to verify whether a product truly is compatible with EJB 1.0. There is no “EJB 1.0-compliant” brand that Sun Microsystems issues to container/server products, because there is no process to verify that a container/server is indeed compatible with EJB 1.0.

With the advent of the Java 2 Platform, Enterprise Edition (J2EE), things are changing. Sun plans to release a compatibility test suite with J2EE, and this test suite verifies that a particular vendor’s product is indeed compatible with the J2EE specifications, including the new EJB 1.1 specification. What this means to you is that you will be able to verify compatibility by looking for a J2EE seal of approval which Sun Microsystems stamps on J2EE-compliant products. This seal should significantly reduce compatibility problems between application server products, and should be the first thing you check when you purchase J2EE software.

But until J2EE-compliant products begin to emerge (unlikely to happen until early 2000), your best bet is to read magazine articles and white papers to deduce whether a vendor’s application server does indeed implement the EJB specification accurately. This is a necessary step you must take, because otherwise, you may be gambling on a proprietary distributed object framework. If you eventually decide to migrate your software to a different vendor’s application server, your porting costs will be significantly reduced if you have written portable enterprise beans.

Entity Bean Support

As you’ve seen from the entity bean chapters in Part II, and from the e-commerce deployment in Part IV, entity beans are a crucial part of any significant EJB deployment. Entity beans provide an object view into a database or other storage, allowing you to interact with business data at an object-level granularity.

The EJB 1.0 specification does not mandate that container/server products support entity beans—rather, products only need to support session beans. In EJB 1.1, which is part of the Java 2 Platform, Enterprise Edition, every EJB container/ server must support entity beans.

When choosing whether entity bean is support is necessary, ask yourself whether your server-side deployment really needs the functionality of entity beans. If you’re using a design based on objects, then entity beans are a natural mechanism to map your persistent entities to permanent storage, while session beans map to your process entities. If you’re using traditional procedural design methodologies, rather than object design methodologies, you won’t miss entities quite as much.

Go back to the first page for a quick link to buy this book online!

Making a Purchase Decision 671

You can count on entity beans to be supported in future versions of every serious EJB server product. Most multi-tier deployments will have a wide variety of both entity and session beans, yielding a rich object model that represents underlying business entities as well as processes, respectively.

Persistence

If you are modeling your persistent data as entity beans, you need to choose a persistence mechanism. Should you persist your objects yourself (using beanmanaged persistence), or hand off persistence to the EJB container/server (con- tainer-managed persistence)? Once you make this decision, you need to choose an EJB container/server product that supports your persistence method of choice. Let’s review the tradeoffs between the two persistence models that we first presented at the end of Chapter 9.

Bean-Managed Persistence

Bean-managed persistence is your best bet if you have a legacy system, since you need to control how data is persisted to that legacy system. Bean-managed persistence is also useful if you have very complex relationships between your persistent data. For example, if you’re persisting your objects into multiple tables of a relational database, some EJB containers may not be able to handle this mapping. Performing the persistence yourself via JDBC makes your beans portable to any EJB container that supports entity beans.

Unfortunately, as we saw in Part II, crafting a bean-managed persistence layer into your entity beans requires many man-hours to build and maintain compared to leveraging container-managed persistence. You’ll also find that much of your bean-managed persistence code is buggy and unwieldy, since database operations are represented as strings that cannot be validated at compile time. Additionally, bean-managed persistent entity beans are tied to a particular database schema, and if the schema changes, you will probably need to modify the code of the application.

Container-Managed Persistence

Container-managed persistence is useful if you are looking to very quickly develop an application that does not rely on a complex legacy system. If you are building a system from the ground-up with EJB, container-managed persistence will save you significant time and effort because the container handles all the data mapping for you, and your debugging time should be reduced because there is no unwieldy JDBC code to test. And since your code contains no data access

Go back to the first page for a quick link to buy this book online!

672 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

logic, your application code is completely independent of the underlying database schema.

Additionally, some EJB containers will be providing APIs for plugging in thirdparty persistence modules, such as a module that persists your entity beans to an object database rather than a relational database. There are other possibilities as well, such as persisting to a file, persisting to a relational database using a simple object-relational mapping, persisting to a relational database using a complex object-relational mapping, or persisting using user-defined persistence routine (which may implement persistence through a legacy application).

There is a downside to container-managed persistence: It is very difficult to port your entity beans between EJB containers. As we saw in Part II, entity bean persistence is not portable across container products—each vendor performs it differently. This greatly increases your switching cost when porting beans between application servers. Some EJB servers do not support complex mappings of entities to databases (mappings that span multiple tables or databases). Ultimately, a future version of the EJB specification should standardize on a persistence service, but until that happens, my advice is to tie yourself to one container vendor that supports complex mapping to databases, and only port to a different vendor if absolutely necessary.

Choosing a CORBA-based versus an RMI-based EJB Product

In Chapter 11, you saw how enterprise beans can be deployed in either Java RMIbased EJB servers or CORBA-based EJB servers. The Java RMI-based servers communicate using JRMP or IIOP as the protocol, whereas the CORBA-based servers communicate via IIOP.

CORBA-based EJB servers have a single advantage over Java RMI-based EJB servers: legacy integration. If you have an existing deployment written in another language that is CORBA-compatible, such as C++ or COBOL, then CORBA can help you to reuse that existing code base in an EJB environment. Since CORBA-based EJB products bundle ORBs with their application servers, you are in a natural situation to build on your existing investments.

Usage of RMI-IIOP API

Whether your EJB server is CORBA-based or RMI-based, it should always support the Java RMI-IIOP API. RMI-IIOP is the de facto API to call enterprise beans,

Go back to the first page for a quick link to buy this book online!

Making a Purchase Decision 673

and is the only API you should be using if you want to write portable client code. Make sure your vendor supports RMI-IIOP.

Accessibility of JTA via JNDI

When you want to control transactions from clients, you must look up the Java Transaction API (JTA) UserTransaction interface via the Java Naming and Directory Interface (JNDI). Some EJB server vendors have proprietary APIs, which again make your client code not portable. Be sure your EJB server supports accessing JTA via JNDI.

Protocol Issues

Another question you should ask your container vendor is what protocol they use behind the scenes. If it’s a CORBA-based EJB server, it most likely uses IIOP as the transport layer. If it’s a Java RMI-based EJB server, it may use IIOP, JRMP, or a proprietary protocol. And as we saw in Chapter 11, IIOP is an industry-standard protocol, is much more robust than JRMP, and offers a host of features that JRMP cannot match. For example, if you separate the tiers of your deployment with a firewall (to protect your secure data), the firewall navigation support of IIOP becomes quite handy. IIOP also offers the ability to combine heterogeneous EJB servers in a single distributed transaction, and supports propagation of security information between application servers.

Integrated Tier Support

Throughout this book, we’ve concentrated on EJB as a server-side component model. But for many deployments, a client-side GUI will also be tied to that backend system. In particular, e-commerce and other related initiatives will need a mechanism for tying Web components written with Java servlets, JavaBeans, or Java Server Pages (see Part IV for concrete examples of servlets communicating with enterprise beans).

As we mentioned in Chapter 1, it is advantageous to logically (as well as physically) partition your deployment into one or more tiers. For example, a typical three-tier deployment consists of a presentation tier for GUI-related activity, a business logic tier for business rules and processes, and a data tier for durable storage. By separating tiers into different processes or physical machines, each tier can scale independently of the others. Having multiple tiers also enables you

Go back to the first page for a quick link to buy this book online!

674 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

to protect sensitive data behind a firewall. The downside to separating your deployment into tiers is twofold: There are more machines to maintain, and performance deteriorates due to distributed objects communicating between tiers over the network.

To sidestep these problems, some EJB container/server products will offer the ability to represent multiple tiers as one. For example, with the Oracle 8i database, your application server and bean logic run within the database itself—a new alternative to traditional stored procedures. This minimizes roundtrips between business components and the data layer. Other products (such as IBM’s WebSphere) offer the ability to run GUI components (such as Java servlets or JSP scripts) in the same Java Virtual Machine as your enterprise beans. The result of these innovations is a high-performance, low-maintenance deployment.

In-Memory Data Cache

If you are using entity beans (and most deployments will), you should be aware that entity bean performance is not equal between application servers. Some application servers work in a “pass-through” mode, which means that any entity bean operations are “passed through” to the database, resulting in a low-level database transaction. Other vendors implement smart caching of entity beans, allowing some operations to occur in memory rather than at the database level. For example, if you’re merely reading the same data over and over again from an underlying storage, you should not need to hit the database on every method call.

The difference between pass-through and caching application servers is tremendous. Persistence Software, an EJB container vendor, has published a white paper contrasting the two, and the results are staggering: The caching application server had a 60-fold performance increase over the pass-through application server. See the book’s accompanying Web site for links to this white paper and other resources.

Scalability

Your EJB server should scale linearly with the amount of resources thrown at it. If you add extra machines with equal power (memory, processor power, disk space, and network bandwidth), then the number of concurrent users your server-side deployment can support, and the number of transactions your system can execute per second, should increase linearly. Be sure to ask your EJB server vendor for case studies and customer references to back up their scalability story.

Go back to the first page for a quick link to buy this book online!

Making a Purchase Decision 675

High Availability

High availability is critical for server-side deployments. You want the highest level of confidence that your EJB server won’t come down, and there are a number of things to look for to increase your confidence. For one, your EJB server vendor should have compelling numbers indicating the availability of their product, backed up by existing customers. Secondly, realize that your EJB server is only as available as the operating system and hardware that it’s deployed on. Be sure to ask your EJB server vendor what operating systems and hardware configurations they support.

Security

A typical EJB deployment leverages predefined security lists that are already available in existing systems. For example, an IT shop may store access control lists of users in a Lotus Notes LDAP server; you may need to use these lists in your EJB deployments. Many EJB products will offer aid and assistance with importing and exporting ACLs from existing deployments, so that you won’t have create your own solutions from scratch, saving you time when deploying EJB products. Some systems can even tap into existing security systems—they get the user and authorization information from the existing security service. Be sure to ask your EJB container/server vendor about these features.

IDE Integration

An essential component of any development is an easy-to-use Integrated Development Environment (IDE), such as Inprise’s JBuilder, Symantec’s Visual Cafe, or IBM’s VisualAge for Java. IDEs can assist in code management, automate programming tasks, and aid in debugging.

Some EJB container/server vendors are IDE vendors as well (such as IBM, Inprise, and Sun Microsystems). This duality allows them to seamlessly integrate their container/server product with their IDE. The end result is compelling: The IDE can aid in coding, debugging, and deploying your beans by working together with the application server. Other EJB container/server vendors who do not have their own IDE are forming strategic alliances with IDE vendors to gain a competitive edge in the marketplace.

Go back to the first page for a quick link to buy this book online!