Enterprise JavaBean (EJB) is a JEE component that runs on an application server.

Enterprise JavaBeans are used for developing scalable, distributed, server-side components and typically encapsulate the business logic of the application.

EJB managed beans are Thread Safe, transactional, bandwidth-throttled,(has pooling capability), monitored (on EE server console we can check running EJB, avg response time, number of request handled etc)

The life-cycle of EJBs is handled by an application server, such as JBoss WildFly or Oracle GlassFish. it’s up to the application server to handle non-business logic related issues such as transaction handling, component lifecycle management or dependency injection.

POJO + Annotations.

https://www.baeldung.com/ejb-intro

• Component Types- (similar to scopes in CDI)

@Singleton executed once per application.

@Stateless - single state per application and shared between methods

@Stateful - multiple instances maintained and one state assigned to each EJB client.

**@Resource **annotation injects the session context into the remote bean

The SessionContext interface provides access to the runtime session context that the container provides for a session bean instance. The container then passes the SessionContext interface to an instance after the instance has been created. The session context remains associated with that instance for its lifetime.

@Local- A @Local annotated bean can only be accessed if it is in the same application as the bean that makes the invocation, i.e. if they reside in the same .ear or .war.

A @Remote annotated bean can be accessed from a different application, i.e. an application residing in a different JVM or application server.

@MessageDriven - for receiving JMS messages.

-Services

@Transactional- Enterprise JavaBeans use Java Transaction API (JTA) for managing transactions.

Create interface and mark it with @Remote/@Local Create impl class implementing this interface and put @stateless/@stateful/@Singleton on it In client class declare ejb with @EJB on it.

A Stateful Session Bean maintains the conversational state (both within and between transactions) with the client it is communicating.

Each client creates a new instance of Stateful Bean and is not shared with other clients.

So, Stateful session beans can maintain state with multiple clients, and the task is not shared among clients

When the communication between the client and bean ends, the Session Bean also terminates.

Note: Stateful Session beans cannot use instance pooling because a bean instance is tied to a client for the life of the bean's service to the client. For efficient resource management, most EJB containers imlement the passivation mechanism when dealing wit stateful beans.

It is a 2 step process: passivation and activation

Can be used to solve producer-consumer type problems

@Stateful public class StatefulEJB {

public String name;

}

public class EJBClient1 {

@EJB
public StatefulEJB statefulEJB;

}

public class EJBClient2 {

@EJB
public StatefulEJB statefulEJB;

}

   ** ejbClient1.statefulEJB.name = "Client 1";**
    **ejbClient2.statefulEJB.name = "Client 2";**
    **assertNotEquals(ejbClient1.statefulEJB.name, ejbClient2.statefulEJB.name);**
    **assertEquals("Client 1", ejbClient1.statefulEJB.name);**
    **assertEquals("Client 2", ejbClient2.statefulEJB.name);**

A stateless session bean is a type of enterprise bean which is commonly used to do independent operations. It does not have any associated client state, but it may preserve its instance state. ** they can maintain instance state across different requests. **

A Stateless Session Bean doesn't maintain any conversational state with the client. The bean contains the state specific to the client only till the duration of method invocation. Consecutive method invocations are independent unlike with the Stateful Session Bean.

The container maintains a pool of Stateless Beans and these instances can be shared between multiple clients.

Stateless session beans maintain no state with the client. For this reason, they can be used to create a pool of objects which interact with multiple clients

The EJB container normally creates a pool of stateless bean's objects and uses these objects to process client requests. As a result of this pooling mechanism, instance variable values are not guaranteed to be maintained across lookup method calls.

Since stateless beans don't have any state per client, they are better performance wise

They can handle multiple requests from multiple clients in parallel and

Can be used for retrieving objects from databases

https://stackoverflow.com/questions/26309050/how-is-state-of-instance-variables-of-a-stateless-bean-preserved-for-next-invoca

A Singleton Session Bean maintains the state of the bean for the complete lifecycle of the application.

Singleton Session Beans are similar to Stateless Session Beans but only one instance of the Singleton Session Bean is created in the whole application and does not terminates until the application is shut down.

The single instance of the bean is shared between multiple clients and can be concurrently accessed.

https://stackoverflow.com/questions/14464823/difference-between-stateless-and-singleton

@Lock- for concurrency control in EJB.

@Remote- allows us to call the EJB remotely.

@Startup- to inform the EJB container to initialize the bean at the startup. This is called eager initialization. If we don't use @Startup, the EJB container determines when to initialize the bean.

@DependsOn- to define our bean's dependency on other Session Beans and using this we can define multiple Session Beans to initialize the data and load the beans in the specific order.

@Singleton @Startup @DependsOn({"DependentBean1", "DependentBean2"}) public class CountryStateCacheBean implements CountryState { ... }

@PostConstruct- makes a lifecycle callback method. it'll be called by the container upon instantiation of the bean:

**EJB provides two methods for implementing concurrent access to the Singleton Session Bean:

** Container-managed concurrency**, and Bean-managed concurrency

@ConcurrencyManagement- defines the concurrency policy for a method. It takes a ConcurrencyManagementType value. The options are:

ConcurrencyManagementType.**CONTAINER **for container-managed concurrency. ConcurrencyManagementType.**BEAN **for bean-managed concurrency.

By default, the EJB container uses container-managed concurrency.

for Container-Managed Concurrency - the container controls how clients' access to methods.

To specify the access level to each of the singleton’s business methods, we'll use @Lock annotation.

defines two values:

LockType.WRITE – This value provides an exclusive lock to the calling client and prevents all other clients from accessing all methods of the bean. Use this for methods that change the state of the singleton bean.

LockType.READ – This value provides concurrent locks to multiple clients to access a method. Use this for methods which only read data from the bean.

@Singleton @Startup @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) public class CountryStateContainerManagedBean implements CountryState {

private final Map<String, List<String> countryStatesMap = new HashMap<>();

@Lock(LockType.READ) 
public List<String> getStates(String country) { 
    return countryStatesMap.get(country);
}

@Lock(LockType.WRITE)
public void setStates(String country, List<String> states) {
    countryStatesMap.put(country, states);
}

}

_**@AccessTimeout **_annotation to define the number of milliseconds method times-out. After the timeout, the container throws a javax.ejb.ConcurrentAccessTimeoutException and the method execution terminates.

Bean-Managed Concurrency the container doesn't control simultaneous access of Singleton Session Bean by clients. The developer is required to implement concurrency by themselves.

https://www.baeldung.com/java-ee-singleton-session-bean

responsible for handling message processing in an asynchronous context.

By using messaging, programs can exchange data even if they're written in different program languages or reside in different operational systems.

It offers a loosely coupled solution; neither the producer or the consumer of the information need to know details about each other.

Therefore, they don't even have to be connected to the messaging system at the same time (asynchronous communication).

During synchronous communication, the requester waits until the response is back.

In asynchronous communication, on the other hand, the requester initiates the operation but isn't blocked by it; the requester can move on to other tasks and receive the response later

JMS provides peer to peer and publish/subscribe messaging models.

An MDB is a component invoked by the container every time a message arrives on the messaging system. As a result, this event triggers the code inside this bean.

We can perform a lot of tasks inside an MDB onMessage() method, since showing the received data on a browser or parsing and saving it to a database OR submitting data to another queue after some processing.

An MDB has only two states:

It doesn't exist on the container

created and ready to receive messages

The dependencies, if present, are injected right after the MDB is created.

To execute instructions before receiving messages, we need to annotate a method with @javax.ejb.PostConstruct.

Both dependency injection and @javax.ejb.PostConstruct execution happen only once.

After that, the MDB is ready to receive messages.

Transaction A message can be delivered to an MDB inside a transaction context.

Meaning that all operations within the onMessage() method are part of a single transaction.

Therefore, if a rollback happens, message system redelivers the data.

Therefore, MDBs allow us to decouple our applications into smaller services with localized responsibilities, allowing a much more modular and incremental system that can recover from system failures.

https://www.baeldung.com/ejb-message-driven-beans

@Asynchronous

@Schedule

both below are security annotations

@RolesAllowed

@RunAs