Definition of EJB
Forgive me for the generic subject, but I have been researching for some time in various places and have not found anything that satisfactorily explains what an EJB is in fact and what it is for.
I am adept at using real examples at all for better understanding and have found few adherents of this style in the tutorials I have seen. they usually say that EJB is essentially a managed component that is created, controlled and destroyed by the J2EE handler container running. That tells me nothing or very little. In fact I left the text with more doubts than before.
Looking for more, I was able to understand that EJBs are standalone modules that receive requests and return responses, like any method, with the advantage that they can be invoked from external applications. Is that correct?
A simple and practical example would be an EJB that receives the CPF from a client query whether or not it is approved to perform a buy with check. Within this EJB there would be several business rules (account time, occurrences in the credit protection bodies, etc.), even consultations with other EJBs, with the aim of "pulling the plug" of the client and finally return a yes or no to those who invoked it. This EJB could be used by any client : a mobile, web, or desktop application.
Does anyone have anything else to add?
However, I have some doubts: what is the difference of an EJB for a WebService? (the latter yes I know what it is and I have used it several times).
What is the relationship of JPA to EJB? I've done several applications using Hibernate, which is a JPA framework. Does that mean I used EJB?
Thank you!
3 answers
About EJB
Quickly defining EJB is: "the guy to take care of the business rule".
It was created to control the transaction, messages, project Security, etc.
The characteristics of EJB are:
- allow injection: they can be injected or have other components injected inside them
- security control: just write down your EJB it will be protected from improper access
- transaction control: you can control how the transaction should work, both in automatic mode and me programmatic mode
There are some types of EJB that we can quickly define:
- Stateles: they answer only one call and can then be used for other calls from any customer. The server creates a pool of this guy so in case the demand increases/decreases the server can control the amount active instances. They can also be used as WebServices, just put a annotation and that's it. [=
- Stateful: this guy works like HttpSession as long as the reference remains alive. Usually this guy is placed inside the user's HttpSession, so when the HttpSession dies it will also die. I honestly never used and never saw much use for it
- Singleton: an EJB that will only have one instance for the entire project. Ideal to be used in the DAO layer, for example.
- MDB: messaging service. Almost equal to one Stateles being the difference that it cannot be called directly, but only when a message arrives by a message provider.
EJB is a specification, to be able to use it you need a server like JBoss, Glassfish, TomEE...
Before version 3.1 you needed to package your EJB inside a JAR and attach the jar along with your WAR inside an EAR. If you didn't package everyone inside an EAR your EJBs would have to be of the remote type. An EJB remote uses RMI for connection which has impact on performance. When an EJB was inside an EAR it could be used as a location, there it improves performance and other aspects.
WebService + EJB
WebService in littlewords is: expose a service to the web and nothing else. By using only the WebService you can receive a Request from anywhere in the world. An EJB can expose a method to the web as a WebService and still have all its benefits. Without EJB it will be necessary to use another means to control transaction, security, timer, etc.
Since EJB is a JEE implementation it already comes on servers and are quite easy to start using (I say of the newer versions, the older ones are complicated).
Ending
It is not a WebService, but may have Services exposed as Webservices. They control the transaction and with this it becomes the ideal place to put the rules of the business. Has messaging service, timer and others.
Dude, I'm not going to give you a giant answer, because there are already hundreds of sources:
My answer:
"Any class annotated with @Stateless, @Stateful or @Singleton which runs inside an Application server", that is an EJB.
Why EJB ?
" support transaction, lifecycle management, dependency injection, security, remote and local access... and much more. All this managed by the container." If you you know what these concepts are, by now you should have understood what it is and why to use. If you do not know exactly what they are, or how an application server (JBoss, Websphere, Glassfish, etc etc) works, I advise you to take a good look at basic subjects about web application and / or enterprise application An EJB "module" is a file .jar (which have POJOs, EJBs, etc etc) which may or may not be part of a larger file (.ear) and runs inside a application.
Hugs
What really made me understand was this site:
Http://entjavastuff.blogspot.com.br/2011/02/ejb-transaction-management-going-deeper.html
To make the idea more concrete, the article focuses on one aspect of EJBs:
- transactions
This includes transactions with the database (or with more than one database) and sending messages. And at that point, an EJB transactional method actually gets a lot simpler to write than try to treat all the possibilities of commit and rollback on the basis of try/catch / finally.
Of course there are other features in EJBs (remote calls, asynchronous calls, timers, messages, object pooling, dependency injection, interceptors, security), and many materials place an overemphasis on remote calls, hence the confusion with web services...