Hello. Welcome to lesson 1 in our EJB course. This is just to introduce what EJBs are, and how they're used. We want to understand their purpose, we want to understand their roles and responsibilities which introduces the different types of EJB and what they're used for, and very importantly, we want to understand how EJBs fit into our Java Enterprise Edition Architecture. Where would we use EJBs in an application development? We're in the business of building multitier systems. What I mean by that is, we have a frontend, and we have a backend consisting of various server components living and breathing on a server. The EJB standard and framework provides a means of creating server-side components. They provide a standard way on how they communicate, how they're built, without us having to do all that ourselves and getting lost in the complexity of various communication mechanisms. Remote communication in Java is complex. If I can make something easy that you can leverage, then that's great. The complexity is being done by someone else, the framework. The goals of EJB are; I want to create a distributed application that I can write, give to you, and you can run wherever you want. Write once, run anywhere. I want it to be part and parcel of my architecture and fit seamlessly into the Java EE architecture. That way, I'm conforming to a standard, and I know I'm in a good place. I want to relief from the developers all the verbose details of remote communication from one JVM to another JVM. How do I manage database connections or data sources? How do I get components to get hold of their dependencies at the right time so we have container dependency injection for that? How I do I talk to a database? I don't want to get lost in SQL land. I want to make it really easy, so I can have a framework to say, okay, this is your Java object, I'll take it from here. I'll put this in a database. We do that as it says here, through JPA, which later became Jakarta Persistence Architecture. There are three main types of EJB. The first one, session beans. It says, here they provide a business service in a distributed, transactional environment. They do. They provide the means of starting transactions when they're first invoked, and anything they call further downstream will be in that transaction. They also provide a means of injecting security mechanisms here, as well as another type of service. The key thing here is that these session beans are managed by what we call an EJB container. This will be part of a JEE compliant server. This container is important. It manages the creation and destruction of the session beans, but it also provides the software through which the outside world can communicate with your session bean. You don't have to code all that, you just deploy it to the EJB container. The server and EJB container say, great, I've got that. I'll expose it, so the rest of the world, so people can access it. I'll take care of the requests. As they come in, they go through the container down to the session bean, and the response as well. The second type of EJB is a message driven bean. It's really all to do with consumers of messages of queues or topics. They do this in asynchronous manner. What that means is, they're pulling against a queue or topic and taking messages off as messages are put on by a producer. This means it's interacting with the Java messaging system or JMS. The asynchronous is done through a producer placing something on a queue and then going on to do something else, and the consumer, the message driven bean, is taking it off. There is no weight from the producer to say, oh, did the message driven bean consume it? No. It's an asynchronous communication mechanism. Third type of EJB, Jakarta Persistence or JPA. How do I talk to databases? How do I shield you from the complexities of SQL and JDBC? How do I make it easy? We do this through object relational mapping, and we do this through various managed beans within JPA itself. You might have heard of model view controller. On the left-hand side, we see the roles: view, controller, model. On the right-hand side, we see common JEE implementations: HTML and JSP for views. Servlets to receive requests and delegate them down to the model, and then down the bottom, we have the various EJBs that will be comprising part of our model along with our own plain old Java objects that we create. Servlets may talk to session EJBs locally or remotely. The session EJB may talk through JPA to a database. The servlet can place messages on a queue, the message driven bean then consume off that queue. In this course, we're all about the model. Now, I need to talk about the EJB container a little bit more. We create these EJBs, these component-based platform-independent artifacts. We organize them into components that we can deploy to any GEE server that has an EJB container like TomEE. The Java EE servers provide the services such as the containers through which we can communicate with our deployed EJBs. In fact, Java EE compliant server will have more than one container. They'll have a web container for invoking servlets, and they'll have an EJB container in order for requests to be passed through to our deployed EJBs. Because we have these containers, you don't have to worry about that communication mechanism. You don't have to worry about, when do I create them? When do they get destroyed? The container takes care of that through various configurations that we create ourselves, but we don't do that ourselves. This means you can just concentrate on business problems and business logic, and then just deploy it. The EJB container provides various services for our EJBs transactional support, we may utilize security, managing data sources and persistent mechanisms. The complexity that is involved in remote communication from one JVM to another, we can even expose EJBs, so it's web services. We can intercept requests to say, you're trying to get to this method on this component EJB, I'm going to intercept the request and take a look at what you're sending, and I can do the converse on the response. There's even timers and schedulers as well, and as I've mentioned before, we can interface with the JMS architecture for both producing and consuming. There will be perhaps an embedded JMS broker in the JEE server that we can utilize to do that. When I look at the overall architecture of Java EE to create these distributed applications, we can see that our EJBs are server-side components. They can be invoked through a web browser, through the web container, and it's servlet which can then delegate down to a session EJB, and then maybe through JPA to a database, but it is not the only means of communicating with an EJB. We can create remote clients. We can write the client in Java, and we can use something called remote method invocation or RMI. It is a complex communication mechanism that involves the generation of various artifacts that run time or proxies, they call them stubs and skeletons, and we can go through those to hide the complexity of what is really happening underneath, which is a remote invocation of an EJB. We can communicate both ways. In this course, we will be communicating both remotely with Java clients and we will also be using servlets in order to communicate with our EJBs within a web application. Little bit of a history lesson here. The EJB specification was originally developed back in 1997 by IBM. Later adopted in 1999 by Sun MicroSystems, and enhanced under the Java Community Process through several JSRs developing the EJB 2 specification in 2001 to 2003. This version of the EJB specification was quite complicated because it involved a variety of XML deployment descriptors. However, JSR 220 came along in 2006, made it so much easier in that we used annotations rather than these XML deployment descriptors. The behind the scene's container had got more sophisticated as well, so we could achieve the same by running a lot less code. 2020 saw the introduction of EJB 4 or Jakarta Enterprise Beans 4 which is really basically just a tooling release as part of the Jakarta EE9 specification. In this course, we'll be dealing with EJB 3, developing session beans, message driven beans, and communicating to a database using JPA. Our JEE compliance server will be TomEE.
