I was reading some stuff about it and I gathered that it’s just a fancy name for interprocess communication. Is that a fair assessment? Or does it include things like Tomcat or a J2EE app server? I noticed that JBoss lists Seam under their middleware offerings and I would consider that a Rails-esque app framework. Also, what is MOM? Does the SOAP/WSDL/UDDI stack count? How about Message driven ejbs?
I actually don’t hear the term middleware much anymore, but I am curious.
I used to work a lot on developing, configuring, supporting, etc, middleware.
The basic concept is that you’ve got a database on machine A (a server) and apps that want to use that data and run on machine B (a client). You’ve normally got lots of machine Bs, all sitting on people’s desks - machine A might be a big thing downstairs in the computer room. Machines B are all networked to machine A.
Now, the software you’ve got on machine A, that handles the data on that server, doesn’t know nor care what software all your Bs have. Likewise, the Bs don’t have a clue about what’s on A.
Your server A might be running Unix, your clients B running Windows … there’s no compatibility yet.
So … you write a layer of software that runs on A to talk to your database, and another layer that runs on your Bs to talk to A’s new layer and also to your client app. It’s a “missing link”, and there are two parts to it - the server side and client side, which communicate together over the network. That’s your middleware. In the end your app can get at the database.
Most middleware these days uses ODBC - that would probably be a better search term.
I don’t hear it much either anymore (may be the business I’m in), and don’t think the term ever really developed a precise definition. However, IMO SW that works above the OS but below the application is middleware, so “Interprocess communication” is as good a definition as any. I’d lump web servers, SQL servers–basically everything you listed as middleware.
MOM is short for “Message Oriented Middleware”; it is that subset of middleware which deals with queuing messages for a multi-tasking client until they can be acted upon.
My understanding is that the term gained siome currency as part of the legal case to break up Microsoft. In the judge’s decision, the middleware layer that is so prevalent in web-based computing was (in his opinion) a crucial tool in assuring that competition could develop against the Windows OS. Microsoft’s attempts to undermine commercial middleware (e.g. their proprietarydevelopment of a JAVA competitor) was seen by the judge as illegal. Please don’t quote me on that; it’s been a while since I read his decision, and am sure I have some of the facts wrong, but I think the general drift is correct. I’d be interested in anyone who can better fill-in the details…
Would you call ODBC middleware or is that too low-level? You could call a database-backed web app middleware if I understand your definition correctly. The app I work on is tiered like this: Struts | Business Logic | O/R mapping layer | Oracle. Would the JDBC that underlies the mapping layer (JDO in our case) be the middleware? Would the mapping layer? The whole app? I guess the confusion is caused by not knowing what front and backware are, to coin a phrase. I have seen CORBA be referred to as middleware and from what I know about that, it’s job is to provide IPC between to pieces of software not necessarily written in the same language.
Middleware is essentially any abstraction layer for anything, so that set objects can fit together nice.
I once built a set of abstraction layers for cellphone programming so that any software built for the abstraction layer could intelligently display itself on different displays with different keycodes and whatnot. We called it middleware even though it was just a Java class that you extended.
Don’t take my definition too seriously - that was how it was undertood in the UK in the 1990s, at least. I’m not in that game anymore, so the usage may have changed. I should have included that disclaimer.
Essentially, if you said you were a middleware developer, people knew that you were using “thin client” techniques to communicate with databases over a network, almost always using SQL to shove the majority of processing load onto the server and minimise network traffic. There was no reason that you couldn’t use the same technique on a local machine, of course - you just point the client at the same machine - but that was almost unheard of in the field I worked in.
I’ve not heard of it being used outside of a database context before as Sage Rat describes, but it makes sense to generalise the concept.
I’ll 'fess up to being a bit of an old fogey in the IT world these days.
Middleware usually implies a functional role in the stack, and possibly the integration of multiple data sources
Client-side: Integrated Display and data entry
Middleware: Business rules/behaviours, Reporting, Messaging services and access to multiple data sources
Data-side: Multiple Databases/stored procedures
To me, the definition is a little more general. “Middleware” is any independent program that sits between two other programs and converts data.
For instance, at my work, we technical writers use Structured FrameMaker to write manuals. The company is moving towards storing all the data for projects in a humungous central database instead of letting it be scattered hither and yon over assorted network drives and thus be difficult to find.
The format for a lot of the data in the archive will be XML-based, and the data will be shared among many users, most of whom do not have FrameMaker. We writers will eventually need to archive our data in this new format, which is not FrameMaker’s native format.
We will therefore have to get a piece of “middleware” to sit between FrameMaker and the database and convert documents to and from FrameMaker’s internal formats.
That’s a perfect example of “middleware” to me. Middleware is not needed for us to use our program in our own little area, but it’s needed to convert data to and from another format so that we can trade data with other users in the wide world beyond.