Top

Middleware Tech

September 22, 2015

Category:

Middleware is basically software that enables separate software applications to connect. It is the software layer between the OS and the applications in a network, on each side of the computing system.
The denomination as such appeared somewhere at the beginning of the 90s, although the concept of inter-applications messaging existed since the late 70s.
Middleware’s main purpose resides in connecting, both internally and externally, while smoothly integrating all system components, in order to avoid fragmentation.
This technology (or the related solutions) is precisely the “glue” allowing two systems to communicate. Its role is very important in enterprise systems, since connectivity with legacy systems, cloud, SaaS applications or business management software is vital.
It belongs to the Enterprise application integration (EAI) field and also to the Web Services subcategory.

The increasing number of device types, as well as of software services provided for the business world, raises new challenges in seamless integration. All enterprise data hosted on premise and in the cloud needs working connectivity solutions, and all these solutions are part of middleware.

Functions

The provision of messaging services for different application to inter-communicate is typical as a dedicated function, whether the messaging frameworks are Simple Object Access Protocol (SOAP), Web services, Representational State Transfer (REST) or JavaScript Object Notation (JSON).

Other middleware categories include:
• ESBs (a particular type of interoperability messaging – Enterprise Service Bus);
• TP monitors (transaction processing monitors that determine load balancing and forwarding transactions between servers);
• DCE environments (Distributed Computing Environment);
• RPC (Remote Procedure Calls) systems;
• Object Request Brokers (ORBs);
• Database access systems.

Another classification lists middleware types like this:
• Message Oriented  (MOM, again, one of the most common types);
• Object Middleware (manages communication between objects, instead of applications);
• RPC;
• Database Access Middleware (enabling database interaction, with many gateways and connectivity options, including SQL database software; another very common type of middleware; current standards are Open Database Connectivity – ODBC and Java Database Connectivity – JDBC);
• Transaction Oriented (or TP);
• Embedded (acting as a liaison between embedded applications and the real-time OS);
• Content-centric (regulating a provide/consume relation; similar to publish/subscribe middleware).

Providers

Middleware platforms strive to provide stability, scalability and speed. Examples of such platforms are Red Hat JBoss Data Grid, Mule ESB, Apprenda or Oracle Fusion Middleware. Here is a collection of whitepapers on this subject.

In addition, for a comprising comparison of business integration software, you may take a look here.

Another (future) function of middleware is allowing “all types of connections between machines (M2M, machine-to-machine) to be activated, managed, and monetized using a centralized and scalable platform”, as defined by Intraway, which demonstrated its IoT middleware at the 2015 CableLabs® Summer Conference.

An upcoming event reuniting providers and interested parties is the 2015 Middleware conference from Vancouver, Canada (December 7-11). You can also check here the topics section, for the most popular and debated issues, among which are the scalability, reliability and security issues, or middleware for mobile computing, big data cloud and IoT (various platforms and usage models).

Middleware issues and challenges

Architectural issues play an important part, since the basic function of middleware is, as shown above, a function of mediation and integration.
Naming and binding issues (another part of middleware design) that determine the way pieces of application software are connected to each other via this intermediary layer.
Management issues, inherent because of the systems’ dimensions and the perpetual need for observation, security, and processes like trade-offs between the autonomous state and the interdependent state for the different subsystems.
Performance issues, since this is a dynamic environment, relying on the interception and indirection mechanisms and requiring flexibility and optimization to avoid performance penalties.

Solutions for solutions

Although seemingly redundant, this final part refers to the issue of ending up with layer upon layer of middleware dealing with particular problems and congesting the entire system to such a degree that enterprises can actually end up using middleware solutions for the actual middleware.

Instead of that, a ZapThink older article talks about SOA (Service-Oriented Architecture), where building, running and managing this software layer is structured in a way that provides flexibility and agility.
A service-centrist mentality takes the place of the traditional integration-centrist mentality – the services are the nodal point of the cyber-infrastructure, and the integration descends to the process level. A SOA approach would reduce the need for “glue” in-between separate software applications, since the design of the applications itself and of the entire system would be constructed having integration in mind, as well as the specific services that a particular business needs to use in a cyber-environment.

Having in mind the current challenges in software integration, coming from the increasing volume of programs and applications, reconsidering such ideas might just prove useful.