If you prefer to package and deploy your EJBs in a JAR file, create a directory for your class files. If you are also using the EJB deployment descriptor (which is optional but supported in the EJB 3.2 programming model), you can package it as META-INF/ejb-jar.xml.

For more information see, Packaging EJBs in a JAR.

myEJBjar/
     META-INF/
          ejb-jar.xml
          weblogic-ejb-jar.xml
          weblogic-cmp-jar.xml
     foo.class
     fooBean.class

EJBs can also be packaged directly in a web application module (WAR) by putting the EJB classes in a subdirectory named WEB-INF/classes or in a JAR file within WEB-INF/lib directory. Optionally, if you are also using the EJB deployment descriptor, you can package it as WEB-INF/ejb-jar.xml.

For more information see, Packaging an EJB In a WAR.

myEJBwar/
     WEB-INF/
          ejb-jar.xml
          weblogic.xml
          weblogic-ejb-jar.xml
          /classes
               foo.class
               fooServlet.class
               fooBean.class

The EJB 3.2 No-interface local client view type simplifies EJB development by providing local session bean access without requiring a separate local business interface, allowing components to have EJB bean class instances directly injected.

The no-interface view has the same behavior as the EJB 3.0 local view. For example, it supports features such as pass-by-reference calling semantics and transaction, and security propagation. However, a no-interface view does not require a separate interface. That is, all public methods of the bean class are automatically exposed to the caller. By default, any session bean that has an empty implements clause and does not define any other local or remote client views, exposes a no-interface client view.

You can follow these links to explore code examples of a no-interface client view:

• Example of a Simple No-interface Stateless EJB

• EJB 3.1: Example of Simplified No-interface Programming and Packaging in a WAR File.

• EJB 3.2: Example of a Message-Driven Bean with No-Methods Listener.

For more detailed information about the implementing the no-interface client view, see "Accessing Local Enterprise Beans Using the No-Interface View" in the "Enterprise Beans" chapter of the Java EE 8 Tutorial at https://javaee.github.io/tutorial/ejb-intro004.html#GIPSC.

The EJB 3.2 business interface is a plain Java interface that describes the full signature of all the business methods of the EJB. For example, assume an Account EJB represents a client's checking account; its business interface might include three methods (withdraw, deposit, and balance) that clients can use to manage their bank accounts.

The business interface can extend other interfaces. In the case of message-driven beans, the business interface is typically the message-listener interface that is determined by the messaging type used by the bean, such as javax.jms.MessageListener in the case of JMS. The interface for a session bean has not such defining type; it can be anything that suits your business needs.

See Example of a Simple Business Interface Stateless EJB and Example of a Simple Stateful EJB for examples of business interfaces implemented by stateless and stateful session beans.

For additional details and examples of specifying the business interface, see Specifying the Business and Other Interfaces.

• Business Interface Application Exceptions
  
• Using Generics in EJBs
  
• Serializing and Deserializing Business Objects
  

The timer service provides methods for the programmatic creation and cancellation of timers, as well as for locating the timers that are associated with a bean. Timers can also be created automatically by the container at deployment time based on metadata in the bean class or in the deployment descriptor. Timer objects can be created for stateless session beans, singleton session beans, message-driven beans, and 2.1 entity beans. Timers cannot be created for stateful session beans.

A timer is created to schedule timed callbacks. The bean class of an enterprise bean that uses the timer service must provide one or more timeout callback methods, as follows:

• Programmatic Timers – For programmatically-created timers, this method may be a method that is annotated with the Timeout annotation, or the bean may implement the javax.ejb.TimedObject interface. The javax.ejb.TimedObject interface has a single method, the timer callback method ejbTimeout.

• Automatic Timers – For automatically-created timers, the timeout method may be a method that is annotated with the Schedule annotation.

• 2.1 Entity Bean Timers – A timer that is created for a 2.1 entity bean is associated with the entity bean's identity. The timeout callback method invocation for a timer that is created for a stateless session bean or a message-driven bean may be called on any bean instance in the pooled state.

The EJB 31. Timer Service supports calendar-based EJB Timer expressions. The scheduling functionality takes the form of CRON-styled schedule definitions that can be placed on EJB methods, in order to have the methods be automatically invoked according to the defined schedule.

Calendar-based timers can be created programmatically using the two methods in the javax.ejb.TimerService that accept a javax.ejb.ScheduleExpression as an argument. The ScheduleExpression is constructed and populated prior to creating the Timer. For creating automatic calendar-base timers, the javax.ejb.Schedule annotation (and its corresponding ejb-jar.xml element) contains a number of attributes that allow for calendar-based timer expressions to be configured.

For detailed information about the seven attributes in a calendar-based time expression, see "Section 18.2.1, Calendar Based Timer Expressions" in the Enterprise JavaBeans 3.2 Specification (JSR-345) at http://jcp.org/en/jsr/summary?id=345.

The EJB 3.2 Timer Service supports the automatic creation of a timer based on metadata in the bean class or deployment descriptor. This allows the bean developer to schedule a timer without relying on a bean invocation to programmatically invoke one of the Timer Service timer creation methods. Automatically created timers are created by the container as a result of application deployment.

The javax.ejb.Schedule annotation can be used to automatically create a timer with a particular timeout schedule. This annotation is applied to a method of a bean class (or super-class) that should receive the timer callbacks associated with that schedule. Multiple automatic timers can be applied to a single timeout callback method using the javax.ejb.Schedules annotation.

When the clustered EJB Timer implementation is used, each Schedule annotation corresponds to a single persistent timer, regardless of the number of servers across which the EJB is deployed.

By default, EJB timers are persistent. A non-persistent timer is a timer whose lifetime is tied to the JVM in which it is created. A non-persistent timer is considered canceled in the event of application shutdown, container crash, or a failure/shutdown of the JVM on which the timer was started.

Non-persistent timers can be created programmatically or automatically (using @Schedule or the deployment descriptor).

Automatic non-persistent timers can be specified by setting the persistent attribute of the @Schedule annotation to false. For automatic non-persistent timers, the container creates a new non-persistent timer during application initialization for each JVM across which the container is distributed.

You can configure two types of EJB timer services: clustered or local.

• Clustered EJB Timer Services
  
• Local EJB Timer Services
  

1. Ensure that you have configured the following:

   • A clustered domain. See Setting up WebLogic Clusters in Administering Clusters for Oracle WebLogic Server.

   • Features of the Job Scheduler, including:

     • HA database, such as Oracle, DB2, Informix, MySQL, Sybase, or MSSQL.

     • JDBC data source that is mapped to the HA database using the <data-source-for-job-scheduler> element in the config.xml file.

     • Leasing service. By default, database leasing will be used and the JDBC data source defined by the <data-source-for-job-scheduler> element in the config.xml file will be used.

   For more information about configuring the Job Scheduler, see The Timer and Work Manager API in Developing CommonJ Applications for Oracle WebLogic Server.

2. To enable the clustered EJB timer service, set the timer-implementation element in the weblogic-ejb-jar.xml deployment descriptor to Clustered:

   <timer-implementation>Clustered</timer-implementation>
   

   For more information, see the timer-implementation element description in the weblogic-ejb-jar.xml Deployment Descriptor Reference in Developing Enterprise JavaBeans, Version 3.2, for Oracle WebLogic Server.

This section summarizes the Java programming interfaces defined in the EJB 3.2 Specification that you can use to program timers. For detailed information on these interfaces, refer to the EJB 3.2 Specification. This section also provides details about the WebLogic Server-specific timer-related interfaces.

• EJB 3.2 Timer-related Programming Interfaces
  
• WebLogic Server-specific Timer-related Programming Interfaces
  

As stated in the EJB 3.2 specification, a remote client accesses a session bean through the bean's remote business interface. For a session bean client and component written to the EJB 2.1 and earlier APIs, the remote client accesses the session bean through the session bean's remote home and remote component interfaces.

The remote client view of an enterprise bean is location independent. A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine.

As stated in the EJB 3.2 specification, a local client accesses a session bean through the bean's local business interface or through a no-interface client view representing all the public methods of the bean class. For a session bean or entity bean client and component written to the EJB 2.1 and earlier APIs, the local client accesses the enterprise bean through the bean's local home and local component interfaces. The container object that implements a local business interface or the no-interface local view is a local Java object.

A local client is a client that is collocated in the same application with the session bean that provides the local client view and which may be tightly coupled to the bean. A local client of a session bean may be another enterprise bean or a Web component. Access to an enterprise bean through the local client view requires the collocation in the same application of both the local client and the enterprise bean that provides the local client view. The local client view therefore does not provide the location transparency provided by the remote client view.

The client of an enterprise bean obtains a reference to an instance of an enterprise bean through either dependency injection, using Java programming language annotations, or JNDI lookup, using the Java Naming and Directory Interface syntax to find the enterprise bean instance.

• Using Dependency Injection
  
• Using the JNDI Portable Syntax
  
• Customizing JNDI Names
  

To enable an EJB to open an HttpURLConnection to an external HTTP server using the java.net.URL resource manager connection factory type, specify the URL, or specify an object bound in the JNDI tree that maps to a URL, using either the @Resource annotation in the bean class, or if using deployment descriptors, by using the resource-ref element in ejb-jar.xml and the res-ref-name element in weblogic-ejb-jar.xml.

1. In ejb-jar.xml, specify the URL in the <jndi-name> element of the resource-ref element.
2. In weblogic-ejb-jar.xml, specify the URL in the <jndi-name> element of the resource-description element:

   <resource-description>
       <res-ref-name>url/MyURL</res-ref-name>
       <jndi-name>http://www.rediff.com/</jndi-name>
   </resource-description>
   

   WebLogic Server creates a URL object with the jndi-name provided and binds the object to the java:comp/env.

1. In ejb-jar.xml, specify the name by which the URL is bound in JNDI in the <jndi-name> element of the resource-ref element.
2. In weblogic-ejb-jar.xml, specify the name by which the URL is bound in JNDI in the <jndi-name> element of the resource-description element:

   <resource-description>
       <res-ref-name>url/MyURL1</res-ref-name>
       <jndi-name>firstName</jndi-name>
   </resource-description>
   

   where firstName is the object bound to the JNDI tree that maps to the URL. This binding could be done in a startup class. When jndi-name is not a valid URL, WebLogic Server treats it as an object that maps to a URL and is already bound in the JNDI tree, and binds a LinkRef with that jndi-name.

You can control the attributes of the network connection an EJB uses for communications by configuring a custom network channel and assigning it to the EJB. For information about WebLogic Server network channels and associated configuration instructions see Configure Network Resources in Administering Server Environments for Oracle WebLogic Server. After you configure a custom channel, assign it to an EJB using the network-access-point element in weblogic-ejb-jar.xml.

Container-managed transactions are simpler to program than bean-managed transactions, because they leave the job of demarcation—starting and stopping the transaction—to the EJB container. You configure the desired transaction behaviors using EJB annotations javax.ejb.TransactionAttribute or by using EJB deployment descriptors ejb-jar.xml and weblogic-ejb-jar.xml.

• For more information about using EJB annotations to specify container-managed transactions in a bean file, see Specifying Transaction Management and Attributes.

• For more information about using EJB deployment descriptors to specify container-managed transactions, see Container-Managed Transaction Elements in Developing Enterprise JavaBeans, Version 3.2, for Oracle WebLogic Server.

Key programming guidelines for container-managed transactions include:

• Preserve transaction boundaries—Do not invoke methods that interfere with the transaction boundaries set by the container. Do not use:

  • The commit, setAutoCommit, and rollback methods of java.sql.Connection

  • The getUserTransaction method of javax.ejb.EJBContext

  • Any method of javax.transaction.UserTransaction

• Roll back transactions explicitly—To cause the container to roll back a container-managed transaction explicitly, invoke the setRollbackOnly method of the EJBContext interface. (If the bean throws a non-application exception, typically an EJBException, the rollback is automatic.)

• Avoid serialization problems—Many data stores provide limited support for detecting serialization problems, even for a single user connection. In such cases, even with transaction-isolation in weblogic-ejb-jar.xml set to TransactionSerializable, exceptions or rollbacks in the EJB client might occur if contention occurs between clients for the same rows. To avoid such exceptions, you can:

  • Include code in your client application to catch SQL exceptions, and resolve them appropriately; for example, by restarting the transaction.

  • For Oracle databases, use the transaction isolation settings described in isolation-level in the weblogic-ejb-jar.xml Deployment Descriptor Reference appendix in Developing Enterprise JavaBeans, Version 3.2, for Oracle WebLogic Server.

1. Make sure your bean is a container-managed session or entity bean.

   You can configure automatic retry of container-managed transactions for container-managed session and entity beans only. You cannot configure automatic retry of container-managed transactions for message-driven beans because MDBs do not acknowledge receipt of a message they are processing when the transaction that brackets the receipt of the message is rolled back; messages are automatically retried until they are acknowledged. You also cannot configure automatic retry of container-managed transactions for timer beans because, when a timer bean's ejbTimeout method starts and is rolled back, the timeout is always retried.

2. Make sure the business methods for which you want to configure automatic retry of transactions are defined in the bean's remote or local interface or as home methods (local home business logic that is not specific to a particular bean instance) in the home interface; the methods must have one of the following container-managed transaction attributes:

   • RequiresNew. If a method's transaction attribute (trans-attribute element in ejb-jar.xml) is RequiresNew, a new transaction is always started prior to the invocation of the method and, if configured, automatic retry of transactions occurs if the transaction fails.

   • Required. If a method's transaction attribute (trans-attribute element in ejb-jar.xml) is Required, the method is retried with a new transaction only if the failed transaction was begun on behalf of the method.

   For more information on:

   • Programming interfaces, see Programming Access to EJB Clients.

   • The trans-attribute element in ejb-jar.xml, see Container-Managed Transaction Elements in Developing Enterprise JavaBeans, Version 3.2, for Oracle WebLogic Server, which provides detailed information about creating and editing EJB deployment descriptors.

3. Make sure the methods for which you want to enable automatic retry of transactions are safe to be re-invoked. A retry of a failed method must yield results that are identical to the results the previous attempt, had it been successful, would have yielded. In particular:

   • If invoking a method initiates a call chain, it must be safe to re-invoke the entire call chain when the method is retried.

   • All of the method's parameters must be safe for reuse; when a method is retried, it is retried with the same parameters that were used to invoke the failed attempt. In general, parameters that are primitives, immutable objects, or are references to read-only objects are safe for reuse. If a parameter is a reference to an object that is to be modified by the method, re-invoking the method must not negatively affect the result of the method call.

   • If the bean that contains the method that is being retried is a stateful session bean, the bean's conversational state must be safe to re-invoke. Since a stateful session bean's state is not transactional and is not restored during a transaction rollback, in order to use the automatic retry of transactions feature, you must first be sure the bean's state is still valid after a rollback.

4. Specify the methods for which you want the EJB container to automatically retry transactions and the number of retry attempts you want the EJB container to make in the retry-methods-on-rollback element in weblogic-ejb-jar.xml.

This section contains programming considerations for bean-managed transactions.

• Demarcate transaction boundaries—To define transaction boundaries in EJB or client code, you must obtain a UserTransaction object and begin a transaction before you obtain a Java Transaction Service (JTS) or JDBC database connection. To obtain the UserTransaction object, use this command:

  ctx.lookup("javax.transaction.UserTransaction");
  

  After obtaining the UserTransaction object, specify transaction boundaries with tx.begin(), tx.commit(), tx.rollback().

  If you start a transaction after obtaining a database connection, the connection has no relationship to the new transaction, and there are no semantics to "enlist" the connection in a subsequent transaction context. If a JTS connection is not associated with a transaction context, it operates similarly to a standard JDBC connection that has autocommit equal to true, and updates are automatically committed to the data store.

  Once you create a database connection within a transaction context, that connection is reserved until the transaction commits or rolls back. To optimize performance and throughput, ensure that transactions complete quickly, so that the database connection can be released and made available to other client requests.

  Note:

  You can associate only a single database connection with an active transaction context.

• Setting transaction isolation level—For bean-managed transactions, you define isolation level in the bean code. Allowable isolation levels are defined on the java.sql.Connection interface. For information on isolation level behaviors, see isolation-level in the weblogic-ejb-jar.xml Deployment Descriptor Reference appendix in Developing Enterprise JavaBeans, Version 3.2, for Oracle WebLogic Server.

  See Example 3-7 for a code sample.

import javax.transaction.Transaction;
import java.sql.Connection
import weblogic.transaction.TxHelper:
import weblogic.transaction.Transaction;
import weblogic.transaction.TxConstants;
User Transaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
//Begin user transaction
    tx.begin();
//Set transaction isolation level to TransactionReadCommitted
Transaction tx = TxHelper.getTransaction();
    tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
    (Connection.TransactionReadCommitted));
//perform transaction work 
    tx.commit();

This section describes two approaches for distributing a transaction across multiple beans, which may reside on multiple server instances.

• Calling multiple EJBs from a client's transaction context
  
• Using an EJB "Wrapper” to Encapsulate a Cross-EJB Transaction
  

WebLogic Server supports the use of ejb-client.jar files for packaging the EJB classes that a programmatic client in a different application requires to access the EJB.

Specify the name of the client JAR in the ejb-client-jar element of the bean's ejb-jar.xml file. When you run the appc compiler, a JAR file with the classes required to access the EJB is generated.

Make the client JAR available to the remote client. For Web applications, put the ejb-client.jar in the /lib directory. For non-Web clients, include ejb-client.jar in the client's classpath.

EJB 3.2 has removed the restriction that enterprise bean classes must be packaged in an ejb-jar file. Therefore, EJB classes can be packaged directly inside a Web application archive (WAR) using the same packaging guidelines that apply to Web application classes. Simply put your EJB classes in the WEB-INF/classes directory or in a JAR file within WEB-INF/lib directory. Optionally, if you are also using the EJB deployment descriptor, you can package it as WEB-INF/ejb-jar.xml. When you run the appc compiler, a WAR file with the classes required to access the EJB components is generated.

In a WAR file there is a single component naming environment shared between all the components (web, enterprise bean, etc.) defined by the module. Each enterprise bean defined by the WAR file shares this single component environment namespace with all other enterprise beans defined by the WAR file and with all other web components defined by the WAR file.

Enterprise beans (and any related classes) packaged in a WAR file have the same class loading requirements as other non-enterprise bean classes packaged in a WAR file. This means, for example, that a servlet packaged within a WAR file is guaranteed to have visibility to an enterprise bean component packaged within the same WAR file, and vice versa.

There is an example of using the simplified WAR packaging method bundled in the WebLogic Server distribution kit. See EJB 3.1: Example of Simplified No-interface Programming and Packaging in a WAR File.