Hello, dear friends. In this video, we will start to examine EJB types with session beans, with stateless session bean. Let's begin. A session bean is an irrecoverable Java packet created to encapsulate business logic.

Any business logic which needs to be implemented over a network and should be maintained separately can be put into a session bean. Session beans are invoked by local or remote beans over the network as per business requirements. Session bean abstracts the complex business logic from the end user by invoking complex server processes by its get set methods. This forms an important component of EJB. This is mostly used over the network where we have distributed resources. As mentioned, it is irrecoverable. This means that it is not persistent even if it is a stateful session bean. The data contained in the session bean is not saved in the database.

There are three types of session beans: stateless session bean, stateful session bean, and singleton session bean. The three types of session beans all have their specific features of course but they also have a lot in common. First of all, they have the same programming model. A session bean can have a local or remote interface or no interface at all. Session beans are container-managed components so they need to be packaged in an archive and deployed in a container. The container is responsible for managing its session beans lifecycle, transactions, interceptors, and much more. Let's look at the stateless session bean. A stateless session bean is a type of enterprise bean which is normally used to perform independent operations. A stateless session bean as per its name does not have any associated client state but it may preserve its instant state.

What does stateless mean? It means that a task has to be completed in a single method call. Stateless session bean is a business object that represents business logic only. It doesn't have state. In Java EE applications, stateless beans are the most popular session bean components. In other words, conversational state between multiple method calls is not maintained by the container in case of stateless session beans. EJB container normally creates a pool of few stateless beans objects and uses these objects to process clients' request. Because of pull, instance variable values are not guaranteed to be the same across lookups method calls. It can be accessed by one client at a time. In case of concurrent access, EJB container routes each request to different instances. A stateless session bean can implement a web service, but a stateful session bean cannot.

They are simple, powerful, and efficient and respond to the common task of doing stateless business processing. Before examining an example, let's look at the lifecycle of a stateless bean. Because a stateless session bean is never passive-aided, its lifecycle only has two states, non-existent and ready for the invocation of business methods. First, the EJB container creates and maintains a pool of session beans. It injects the dependency and then, if any, calls the post construct method. The client now calls the actual business logic method. The container then invokes any PreDestroy methods that exist. Bean is now prepared for garbage collection. That's all for now. Let's look at an example. I'll show code snippets to give you a better idea. Let's get started. To create EJB application, you need to create bean component and bean client. To create the stateless bean component, you need to create a remote interface and a bean class. First, interface. This code is our interface. As you can see, we have used a remote annotation, and also in library, we have EJB remote library.

In interface, we have a method named merge and this method takes two string parameters. Now this code shows us the bean class. As you can see in library, we have stateless library. With stateless, we have given a map name to our stateless. In class, we have to override our method, and we have to define our merge operation. This method will merge our texts. The stateless bean client may be local, remote, or web service client. Here, we are going to create remote client. It will be console-based application and we won't use dependency injection. The dependency injection can be used with web-based clients only. First, we will create a context instance. After that, we will create an instance from merge implementation remote with mapped name. That will be enough. After that, we can call our method. If you run this code with Charles and Dickens parameters, the result will be, the author of this book is Charles Dickens. That's it. We have now covered stateless session bean. We'll continue with stateful session bean in the next video. See you in the following video.