-1

What are some major distinctions between EJB and the other technologies that perform the same function, and why is there such focus on the technologies that are, or are not supported, as opposed to other systems that refer to things such as "supporting EJB" as a feature that is either there, nor not?

Dan Chase
  • 993
  • 7
  • 18
  • Why? That's a matter of opinion! – Stephen C Oct 19 '20 at 01:14
  • @StephenC Even the more open-ended interpretation of this question as "why did the designers put so much into EJB" is answerable as a matter of historical context. – chrylis -cautiouslyoptimistic- Oct 19 '20 at 01:49
  • Well, yea, maybe. But this is a programming Q&A site, and the history of the EJB specifications is not really going to help the OP. Basically, Dan is asking the wrong question ... if the goal is to understand EJB concepts and/or decide if EJB is what is required for some project. A question about the history of EJB or its "design principles" or "why certain products don't implement it", etc might be better asked on the SoftwareEngineering site. – Stephen C Oct 19 '20 at 01:56
  • 1
    Note almost all of the sub-questions are really about why >>people<< do things or say things with respect to EJB, or why >>people<< designed it the way it is. When it boils down to it, the real reasons that EJB is what it is are not available to us. They will typically boil down to compromises involving people and companies, differences in goals ... and hidden agendas and egos. (Been there, seen it first hand.) – Stephen C Oct 19 '20 at 02:02
  • @StephenC I keep forgetting about the software engineering forums, I think you're right ,it's more theory than it is about EJB technicalities itself (because the spec itself is easily read and can be understood). Even though, I'll still mark the one answer, given it explains the use of RMI, versus just a packet of data. – Dan Chase Oct 19 '20 at 02:07
  • @StephenC Looks like Chrylis saw the proper question in by ramblings, maybe I could re-do the question to fit the answer, as it's the reason I posted. – Dan Chase Oct 19 '20 at 02:18
  • 2
    There's probably not a lot of point. And (IMO) the rewrite is still "too broad". – Stephen C Oct 19 '20 at 03:46

1 Answers1

2

The original concept of EJB was much closer to what are now called microservices, where the individual components could be deployed across a variety of different servers (EJB containers).

Whereas modern microservices mostly use HTTP calls or message queues, however, EJB communication happened over a Java-specific protocol called RMI, which uses Java serialization to route method calls across the network more or less transparently. This network intermediary is the reason for needing an interface (in earlier versions of EJB, it was even more complex!): On the "local" side, the object actually behind the interface is a proxy that will serialize your method call and transmit it to wherever the EJB implementation is deployed.

Java EE (Enterprise Edition) includes a collection of features that cover a wide variety of "enterprisey" operations, including transactions, service directories, persistence, Web (Servlets), and distributed method calls. Tomcat is calling out that while it implements the Servlet API, which is one part of Java EE, it doesn't implement all of these other components, and if you need them you'll need a different container, such as GlassFish or WildFly.

chrylis -cautiouslyoptimistic-
  • 75,269
  • 21
  • 115
  • 152
  • Wait, so are you saying there would be a server, with EJB's deployed, and no web front-end receiving HTTP, just RMI? That's a pretty big difference then? – Dan Chase Oct 19 '20 at 02:14
  • 1
    @DanChase Sure. There might be an HTTP server somewhere, but there also might be components using all sorts of interfaces (CORBA, messaging, EDI, reading files from a spool directory), and HTTP was just one of _many_ common integration points, not anywhere close to today's dominance. – chrylis -cautiouslyoptimistic- Oct 19 '20 at 02:15
  • I think what you gave is the answer I was seeking. I didn't ask it very clearly, but didn't really know how. Much appreciated! – Dan Chase Oct 19 '20 at 02:16