I have the following classes:
public class ScoringService {
@Inject
public ServiceOne service1;
@Inject
public ServiceTwo service2;
@Inject
public DecisionHandler dh;
public void scoreData() {
Data d1 = service1.getData();
Data d2 = service2.getData();
Data newData = process(d1, d2)
dh.handle(newData);
}
}
public class DecisionHandler {
@Inject
public ServiceOne service1;
public void handle(Data newData) {
service.updateData(newData);
}
}
ServiceOne
and ServiceTwo
are @Stateless annotated EJBs.
I know that container makes pools for that Stateless EJB and also proxies for injections and stuff. So in my case is it possible that there will be two different instances of ServiceOne
in both instances of ScoringService
and DecisionHandler
? And therefore there will be overgenerated ServiceOne
instances? I mean the ScoringService
with injected DecisionHandler
in it will be called for one purpose and there is no need two hold two instances of ServiceOne
.
I made the DecisionHandler
a separate class to disassemble complex logic concentrated in one ServiceClass
. Also I can make the DecisionHandler
as a plain class with a method and instantiate it during call. How should I understand that I should make it an EJB?
I become to think that it some outdated stuff for only Client-Server model with thick cliend to help making calls to the servers EJBs through remote calls and it SHOULDN'T be used in projects with web or self-running computing programs. Is that true?
So in my case is it possible that there will be two different instances of ServiceOne in both instances of ScoringService and DecisionHandler?
if you are talking about @Stateless
then it is up to the container (application server). You are not supposed to take any assumption on the number of EJBs serving clients. So you can have one or two, it is unpredictable.
I made the DecisionHandler a separate class to disassemble complex logic concentrated in one ServiceClass. Also I can make the DecisionHandler as a plain class with a method and instantiate it during call. How should I understand that I should make it an EJB?
If your application server is JEE compliant (i.e. not Tomcat) and your application is middle/big sized and you need transaction, scalability, and you want a class to act as a stand alone component with specific business logic, then you probably need an EJB. Besides, have you tried to run your classes ? Because if they are not managed by the container, the @Inject
is not working.
I become to think that it some outdated stuff for only Client-Server model with thick cliend to help making calls to the servers EJBs through remote calls and it SHOULDN'T be used in projects with web or self-running computing programs. Is that true?
Unfortunately, most people think the current specification for EJB is still 2.x, while instead 3.x is out since 2009. EJB in their current specification are scalable, transactional...they have many benefits rather than disadvantages, and they fit perfectly in a web context.
However just because you have mentioned remote call: @Remote
interface have a little overhead to think about and some design decision to be made (coarse grained vs fine grained interface).
[Update]
Regarding scalability, these are few fragments from the official EJB 3.1 specification, there are many more:
Just in the introduction
Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure.
Then...
A typical EJB container provides a scalable runtime environment to execute a large number of session objects concurrently.