Is EJB middleware? Or is middleware used in EJB?

Question

I am confused between these two nuances:

Is EJB itself middleware, or is there any middleware used in the deployment of EJB?

Same goes for RMI- is RMI itself middleware or is middleware used in RMI?

Fowkes

Answer 1

EJBs are a component of Java EE, which is a middleware.

RMI is another one, and also another component of Java EE.

You can see that these terms aren't too precise.

Hatshepsut

Answer 2

I agree with EJP.

Middleware, as it says, is software that provides service for distributed applications, it connects kernel(like server) and user apps.

EJB is a component architecture in server-side and is part of Java EE, it is built on RMI. So both of them are components of middleware.

Kirman

Answer 3

Define Middleware, if it is in the middle what is it between? I agree with the basic idea of this Wikipedia definition:

Middleware is a computer software that provides services to software applications beyond those available from the operating system. It can be described as "software glue".[1] Middleware makes it easier for software developers to perform communication and input/output, so they can focus on the specific purpose of their application

So the key idea is you write software and exploit something more sophisticated than the plain operating system. I would not say that middleware is only doing communication and input/output, as I'll explain later.

Now define EJBs. There are two things here: the EJB itself, that is application software that you write; you write an EJB as part of your application development so it is not middleware. But you write to a specification defined by Java EE, and deploy your EJB to an EJB Container provided by an Application Server. The EJB Container and App Server are providing something more sophisticated than the operating system. So the container and server are middleware.

The EJB Container facilities include communications (eg. RMI access and JDBC database access) but also include things such as security and transactions.

Wideangle

Answer 4

For me, I liken middleware to the UNIX philosophy per McIlroy: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

The middleware is all about handling the "text streams".

Each program does one thing, does it well. Having said that, it works on its own, but is also written to work together with others. If a program is to work on its own, then in my view, it is asynchronous. For this you need the middleware if it's to work with others.

I think the RPC (RMI) stuff is too tightly coupled, and synchronous, so it fails my definition of middleware. I think the EJB is trying to do far too much than handle "text streams".

There's obviously more to this topic. Try Middleware but it all gets too complicated for me, probably because people are trying to define middleware as stuff that allows programs from different vendors to talk to each other. Now you get into rivalry and competition, "standards" and ISO stuff.

Accumulative

Middleware is all about mediating between systems. It doesn't have to have anything to do with text streams. The McIlroy quote from 1978 concerns the 'Unix philosophy', and specifically the shell architecture, and has nothing specifically to do with middleware, or this question, which concerns EJBs, which were conceived about 20 years after McIlroy uttered that statement. -1 – Hatshepsut

So text streams are the most basic form of middleware out there. After all, they allow different programs to talk to each other. – Accumulative

@Wideangle Look at STOMP – Accumulative