How do beans manage resource connections to back-end services other than databases ?

While EJB 1.1 provides the JNDI ENC for managing standard resources like URL, JDBC, JavaMail and JMS, connections to other types of resources are not addressed by EJB 1.0 or EJB 1.1, but there are solutions. Below is a list of some strategies that can provide access to "back-ends" besides relational databases.

Leveraging the instance fields:
Each EJB vendor implements resource management differently. In EJB servers where the instance is pooled and reused it may be possible to allow a back-end resource connection to be maintained through passivation. The back-end connection might wrapped in a CORBA or Java RMI object, accessed by a raw network socket, or some other connection facility.

This strategy works in stateless session beans and entity beans in EJB servers that pool and reuse these bean types. In stateless beans you can simply reference the resources using the instance fields -- stateless beans are not passivated in EJB. In entity beans you can also reference the connections using instance fields but the field used must not be declared as a container-managed field in the deployment descriptor.

In both stateless and entity beans there are methods can be used safely to open and close resource connections at the beginning and end of the beans life.

In stateless session beans long-lived resources should be opened in the setSessionContext( ) method and closed in the ejbRemove( ) method. These methods are invoked at the beginning and end of a stateless session instance's life; when it's first instantiated and before its evicted form the container.

In entity beans long-lived resource should be opened in the setEntityContext( ) method and closed in the unsetEntityContext( ) method. These methods are invoked at the beginning and end of an entity instance's life; when it's first instantiated and before its evicted form the container.

CORBA or Java RMI Services:
CORBA objects or Java RMI objects can be created that wrapper usual resources and expose them to the bean. These types of remote references will need to be handled with care as they can be affected by passivation, but the remote objects themselves are not part an EJB container and therefor are not passivated.

In stateful session beans the references will need to be released and re-constituted when the bean is activated using some kind of naming facility native to the reference type.

With stateless and entity beans the above strategy, Leveraging the instance fields works well with this strategy.

JNDI references:
It may be possible to access a JNDI service directly from the bean and to attach live resources to the JNDI service. This depends on the JNDI service provider and your EJB vendor.

Wait for EJB 2.0:
The next version of EJB, which may be branded EJB 2.0, is supposed to include a Connection specification that details how connections to non-standard resources can be make available to beans at run time. If this is done correctly it will solve this problem, but who knows when or if it will be incorporated into the specification. Don't hold your breath.