Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Server-side Java: Create forward-compatible beans in EJB, Part 2

More key strategies for developing portable EJB 1.0 beans for EJB 1.1 servers

By Richard Monson-haefel, JavaWorld.com, 01/21/00

While the Enterprise JavaBeans specification (EJB) 1.1 provides a more stable and concrete specification than its predecessor, EJB 1.0, does, it also introduces forward-compatibility problems. Beans developed for EJB 1.0-compliant servers today will not automatically port to EJB 1.1 servers tomorrow.

In the first installment of this article, we developed the PortableContext, an abstraction that insulates bean developers from changes that affect forward compatibility. At runtime, PortableContext automatically changes its behavior to support either EJB 1.0 or EJB 1.1 conventions for accessing properties, JDBC connections, and other beans. This article will continue to enhance the PortableContext in order to encapsulate access to security from a bean. I will also demonstrate how you can use the PortableContext to make enterprise beans portable between brands of servers, as well as different versions of the specification. In addition, I'll address issues specific to entity bean portability and the changes to XML deployment descriptors.

This article covers some advanced topics, and is not intended for individuals new to Enterprise JavaBeans. Readers should already be familiar with Java development, JNDI, JDBC, and Enterprise JavaBeans. In addition, I have simplified exception handling so that example code is clear and easy to follow.

PortableContext

Last month, we developed the PortableContext so that it provided a common interface that hid implementation differences between EJB 1.0 and EJB 1.1 when accessing environment properties, JDBC connections, and other beans. Now we will extend the PortableContext to encapsulate differences between EJB 1.0 and 1.1 when utilizing the EJBContext security methods.

Bean access to security

Enterprise JavaBeans provides beans with limited access to authorization-based (access control) security. In EJB, a bean can obtain the security identity of its client and make sure that the client is a member of a specific security role or identity. EJB 1.0 and EJB 1.1 maintain slightly different semantics in the EJBContext to support these security features.

In EJB 1.0, the EJBContext is specifically designed to use the java.security.Identity type for identifying clients and verifying membership in a role; in EJB 1.1, the EJBContext uses the java.security.Principal type for this purpose. In EJB 1.1, the Identity methods used in EJB 1.0 are still available but are deprecated, which presents a forward-compatibility problem. Lists 1-A and 1-B show the security methods in the EJBContext for EJB 1.0 and EJB 1.1.

public interface EJBContext {
  public java.security.Identity getCallerIdentity();
  public boolean isCallerInRole(Identity role);
  ...
}

public interface EJBContext {
  public java.security.Principal getCallerPrincipal();
  public boolean isCallerInRole(java.lang.String roleName);
  // Deprecated
  public java.security.Identity getCallerIdentity();
  // Deprecated
  public boolean isCallerInRole(Identity role);
  ...
}

The change in the new spec is a result of change in the security architecture of the Java 2 Platform. However, the differences are cosmetic for most EJB developers, since the underlying objective is the same. The code fragments below demonstrate how a bean might use the EJBContext to determine a caller's identity and verify membership in a role under both the EJB 1.0 and EJB 1.1 specs.