Identify correct and incorrect statements or examples about EJB programming restrictions

The JEE5 container, in which EJBs run, provides a variety of services to our EJBs. Many of the burdens of creating enterprise components are relieved from the developer through the EJB container. For example, the whole lifecycle of an EJB is managed and controlled by the EJB container, so you never actually invoke the constructor on an EJB - after all, actually instantiating an EJB is the job of the container. And of course, EJBs are inherently multi-threaded, so we don't start trying to spin off new threads, and handle multi-threaded access within our EJBs either. These are the types of restrictions that Sun is talking about when they made this objective - they want to ensure that developers not only know how to use EJBs, but how not to use EJBs as well!

Page 116 of the Jave EE, JSR-244, lists a variety of programming restrictions, some of which apply to EJBs, with others applying to other JEE containers. It's a good read, and it will certainly help you understand what Sun is getting at when they penned this objective.

"The Java EE programming model divides responsibilities between Application Component Providers and Java EE Product Providers: Application Component Providers focus on writing business logic and the Java EE Product Providers focus on providing a managed system infrastructure in which the application components can be deployed. This division leads to a restriction on the functionality that application components can contain. If application components contain the same functionality provided by Java EE system infrastructure, there are clashes and mis-management of the functionality.For example, if enterprise beans were allowed to manage threads, the Java EE platform could not manage the life cycle of the enterprise beans, and it could not properly manage transactions.
Since we do not want to subset the J2SE platform, and we want Java EE Product Providers to be able to use J2SE products without modification in the Java EE platform, we use the J2SE security permissions mechanism to express the programming restrictions imposed on Application Component Providers. In this section, we specify the J2SE security permissions that the Java EE Product Provider must provide for each application component type. We call these permissions the Java EE security permissions set. The Java EE security permissions set is a required part of the Java EE API contract. Portable applications will rely on only the set of permissions specified here."

Java EE applications should not attempt to load JDBC drivers directly. Instead, they should use the technique recommended in the JDBC specification and perform a JNDI lookup to locate a DataSource object. The JNDI name of the DataSource object should be chosen as described in Section EE.5.6, “Resource Manager Connection Factory References.” The Java EE platform must be able to supply a DataSource that does not require the application to supply any authentication information when obtaining a database connection. Of course, applications may also supply a user name and password when connecting to the database.

When a JDBC API connection is used in an enterprise bean, the transaction characteristics will typically be controlled by the container. The component should not attempt to change the transaction characteristics of the connection, commit the transaction, roll back the transaction, or set autocommit mode. Attempts to make changes that are incompatible with the current transaction context may result in a SQLException being thrown. The EJB specification contains the precise rules for enterprise beans.

Support for the new BLOB, CLOB, ARRAY , REF, STRUCT, and JAVA_OBJECT types not required. All parameter types (IN, OUT, and INOUT) must be supported.

To allow this ORB instance to be safely shared between components, portable components must restrict their usage of certain ORB APIs and functionality:
• Do not call the ORB shutdown method.
• Do not call the org.omg.CORBA_2_3.ORB methods register_value_factory
and unregister_value_factory with an id used by the container.

The Preferences API in the java.util.prefs package allows applications to s and retrieve user and system preference and configuration data. A Java EE application typically will not have the RuntimePermission("preferences") necessary to use the Preferences API. This specification does not define any relationship between the principal used by a Java EE application and the user

The EJB container and the web container are both required to support access to local enterprise beans. No support is provided for access to local enterprise beans from the application client container or the applet container.

portable Java EE applications must not use the following interfaces:
•javax.jms.ServerSession
• javax.jms.ServerSessionPool
• javax.jms.ConnectionConsumer
• all javax.jms XA interfa


The following methods may only be used by application components executing in the application client container:

• javax.jms.Session method setMessageListener
• javax.jms.Session method getMessageListener
• javax.jms.Session method run
• javax.jms.QueueConnection method createConnectionConsumer
• javax.jms.TopicConnection method createConnectionConsumer
• javax.jms.TopicConnection method createDurableConnectionConsumer
• javax.jms.MessageConsumer method getMessageListener
• javax.jms.MessageConsumer method setMessageListener
• javax.jms.Connection method setExceptionListener
• javax.jms.Connection method stop
• javax.jms.Connection method setClientID

A Java EE container may throw a JMSException (if allowed by the method) if the application component violates these restrictions.

Application components in the web and EJB containers must not attempt to create more than one active (not closed) Session object per connection. An attempt to use the Connection object’s createSession method when an active Session object exists for that connection should be prohibited by the container. The container may throw a JMSException if the application component violates this restriction. Application client containers must support the creation of multiple sessions for each connection.

-From javaeespec Chapter 7