acm-header
Sign In

Communications of the ACM

Practice

Middleware 101


smoke coming from the top of a computer, illustration

Credit: JL Stock

back to top 

In computer science, systems are typically divided into two categories: software and hardware. However, there is an additional layer in between, referred to as middleware, which is a software pipeline—an operation, a process, or an application between the operating system and the end user. This article aims to define middleware and reflect on its necessity, as well as address controversies about when and where it applies. It also explores the application of middleware in emerging technologies such as cloud computing and the Internet of Things (IoT), as well as future middleware developments.

The term was introduced in the early 1980s. It encompasses complex software solutions that modernize legacy systems—typically mainframes—through new features such as software and application components. Initially, it was solely used to expand the layer separating the network and application layers. Subsequently, its use expanded to serve as the layer above the operating system and network layer, and below the application layer. This means that middleware could now facilitate the generic communication between the application component and the distributed network.

Through middleware, a programmer has the option to implement a decentralized solution instead of having to interact and analyze different components.18

In recent literature3,12,14,16 multiple definitions have been used, depending on the field of research. On the one hand, both a software and a DevOps engineer would describe middleware as the layer that "glues" together software by different system components; on the other hand, a network engineer would state that middleware is the fault-tolerant and error-checking integration of network connections. In other words, they would define middleware as communication management software. A data engineer, meanwhile, would view middleware as the technology responsible for coordinating, triggering, and orchestrating actions to process and publish data from various sources, harnessing big data and the IoT. Given that there is no uniform definition of middleware, it is best to adopt a field-specific approach.

The main categories of middleware are as follows:11

  • Transactional. Processing of multiple synchronous/asynchronous transactions, serving as a cluster of associated requests from distributed systems such as bank transactions or credit card payments.
  • Message-oriented. Message queue and message passing architectures, which support synchronous/asynchronous communication. The first operates based on the principle that a queue is used to process information, whereas the second typically operates on a publish/subscribe pattern where an intermediate broker facilitates the communication.
  • Procedural. Remote and local architectures to connect, pass, and retrieve software responses of asynchronous communications such as a call operation. Specifically, the first architecture calls a predetermined service of another computer in a network, while the second interacts solely with a local software component.
  • Object-oriented. Similar to procedural middleware, however, this type of middleware incorporates object-oriented programming design principles. Analytically, its software component encompasses object references, exceptions, and inheritance of properties via distributed object requests. It is typically used synchronously, because it needs to receive a response from a server object to address a client action. Importantly, this type of middleware can also support asynchronous communication via the use of (multi) threads and generally concurrent programming.

Academics have further segregated middleware depending on the application module it serves, such as database and Web server. There are several types of middleware, falling into these key categories: reflective, agent, database, embedded, portal, and device (or robotics).4,15

First, reflective middleware constitutes components that are specifically designed to "easily operate with other components and applications," while agent middleware has multiple components that operate on complex domain-specific languages and laws.

Second, database middleware focuses on DB-to-DB or DB-to-apps communication—either natively or via call-level interfaces (CLIs)—while embedded middleware acts as the intermediary for embedded integration apps and operating-system communication.

Third, portal middleware creates a context-management tool in a composite, single-screen application, while device (or robotics) middleware simplifies the integration of specific device operating systems or robotic hardware and firmware.

The first categorization is broader, emphasizing architecture operating principles, while the second categorization is application-driven. For this reason, the first segregation is preferable to define middleware accurately per architecture integration instead of its application properties. All types of middleware are presented in Figure 1.

f1.jpg
Figure 1. Types of middleware.

Back to Top

The Use of Middleware

In developing an application, the three necessary elements to consider are scalability, maintenance, and automation. First, developers avoid horizontal scaling, which is just adding resources to expand the capabilities of the main system. They strive for workload partitioning—optimally distributing job scheduling over the overall network. As for maintenance, the separation of concerns principle is very important for developers, both to make each entity reusable (modularity) and to bundle its properties (encapsulation). (Typical modular examples include the Linux kernel, since the code base can be altered—added/removed—and a LEGO set where different elements can be used multiple times to build a system.) Moreover, developers focus on automating operations to reduce errors and make an application available 24/7 or ad hoc (that is, on-demand provisioning).

Middleware can act as a facilitator to achieve scalability, maintenance, and automation. Specifically, it adds a layer that simplifies complex systems into small integrations, allowing for their association with the network of distributed resources.2 This means that middleware provides agility during software development while simultaneously decreasing the time for a full software cycle; it also provides developers with easier future scaling.

Moreover, middleware can support rapid prototyping by incorporating the "fail fast, succeed faster" principle. It allows developers to apply, adopt, and evaluate business changes instantly. Middleware can also reduce project cost and generally promote entrepreneurship and innovation.9

Back to Top

Middleware's Capabilities

Before the widespread use of the Internet and the adaptation of high-speed connections, most applications were developed as single-tiered, independent software solutions. This software was "monolithic," built to serve a specified purpose and activity, and thus not designed to connect and interact with other applications and software components. Single-tiered software needed a complex middleware solution either to share information with different modules, such as client/server, or to deliver a request from host/resource-management software.

After the Internet revolutionized the way developers operate, an increasing number of transactions driven by multiple computing devices connected to a large, distributed computer network (also referred to as IoT). Distributed computing introduced SOA (service-oriented architecture) instead of monolithic applications. Specifically, SOA consists of multitiered software solutions that implement the separation of entities and services, thus breaking down each component into microservices. This is achieved by decreasing the system's complexity and further increasing its modularity. In this scenario, middleware considers each entity as unique and autonomous. Thus, future modifications are addressed to a specific service (module) and not to the overall system's components.

This middleware "is an approach for developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API."13

Middleware is closely connected to APIs (application protocol interfaces), serving as the tier or a software bundle for different APIs used by a programmer. This means that middleware can simplify sophisticated applications so that the developer focuses on not only the communication of components but also the business logic and the systems' interaction. This is an important aspect in the era of IoT, since APIs are the main gateway to connect devices and send information without errors.

Back to Top

IoT Middleware

The term IoT describes a large network of interconnected devices that gather real-time data fused by multiple smart sensory devices.15 To achieve that, electronic devices (mobile/tablet/computer) send data to an external service hosted in a cloud or edge-computing infrastructure. Recent research has focused on developing an IoT network that will not only interact with its surroundings, but also act autonomously without requiring a user's intervention. Under this scope, IoT researches pervasive/ubiquitous computing as the future of computing applications.10 Computers are no longer associated with single devices or a network of devices. Pervasive computing is defined as "the entirety of situative services originating in a digital world, which are perceived through the physical world."8

Moreover, the architectural principles to develop an IoT application include a review of security, energy consumption and monitoring, reliability, interpretability, and communication.19 As mentioned, middleware provides an abstract tier for all these functions. Based on its software licensing, it can be categorized as corporate-maintained, open sourced, or device-specific (for microcomputers/actuators such as Raspberry Pi or Arduino).

Figure 2 depicts how IoT middleware typically handles its operations based on the following separation of concerns:

f2.jpg
Figure 2. IoT middleware layers.

  • The hardware layer (also known as the edge layer) includes all the sensory devices, as well as the sensor network in which they operate. This tier is responsible for gathering and processing the available data.
  • The operating system's layer (that is, the access gateway tier) performs the necessary data-transformation operations for information to be extracted and loaded accordingly.
  • The network layer (that is, the Internet layer) focuses on sending data to the next layer by securing a continuous, safe, and nondisruptive communication stream.
  • The middleware layer handles the message communication protocols and services. Specifically, this layer checks systems for operation and data-transmission failures, in addition to providing access protocols for the application.
  • Finally, the application layer is solely responsible for providing services (typically by API) to the end user by enabling the broadcast of services to various application endpoints (for example, different developers and departments).

A review of some of the most promising open-source projects regarding IoT middleware6 highlights the following: OpenIoT for sensor systems in the cloud; FIWARE for translating protocols of communication between devices; LinkSmart (formerly known as Hydra) for fast deployment and high scalability of data storage and machine learning; DeviceHive for IoT abstraction of automation layers regarding communication, control, and management; and ThingSpeak for industrial IoT frameworks regarding smart applications.


In developing an application, the three necessary elements to consider are scalability, maintenance, and automation.


Similarly, IBM, Amazon Web Services (AWS), Microsoft Azure, Google, and Oracle have developed corporate middleware.1 Based on the highlighted projects, several middleware frameworks focus on automating either a specific task or a core business activity process.

Back to Top

The Future: Cloud Containers and Microservices

While developers use virtualization (layering of resources into infrastructure), hypervisor (interpreters of the operating system), guest operating systems (with their own kernels), and applications, middleware promoted a decentralized deployment in a single multipurpose environment. This became evident following the exponential increase of containers—software environments that can be rapidly and easily deployed multiple times via the same server (host) in an isolated environment, also referred to as a sandbox. Like Java's motto, "Write once, run anywhere," containers are an independent software environment with unique code, libraries, runtime, and dependencies. Middleware tiers have also shifted from virtualization to containerization for the same purpose of optimizing communication and abstracting the communication protocols to develop a software pipeline.

From the scope of a developer,7 the shift to cloud-computing solutions means that less coding is required, since most of the work in the cloud infrastructure is performed "under the hood." In other words, several aspects of distributed programming and enterprise development previously handled by a local middle tier can now be handled remotely. More specifically, common issues to be tackled include scaling, resilience observability, resource management, and continuous integration and delivery. This means that enterprises will limit the number of middleware developers. Instead of deployment, they will focus on architecture and application development.

Back to Top

Conclusion

Middleware can be used during several phases of the software cycle—from its architecture and development to its deployment. The perpetual need for the digital transformation of businesses (from monolithic to microservice implementations) has showcased that middleware is here to stay. Whether segregating a sophisticated software component into smaller services, transferring data between computers, or creating a general gateway for seamless communication, you can rely on middleware to achieve communication between different devices, applications, and software layers. Moreover, there is a need to educate new developers about middleware and highlight its importance through modern education techniques and learning systems.5,17


Like Java's motto, "Write once, run anywhere," containers are an independent software environment with unique code, libraries, runtime, and dependencies.


Following the increasing agile movement, the tech industry has adopted the use of fast waterfall models to create stacks of layers for each structural need, including integration, communication, data, and security. Given this scope, it is no longer important to study the potential expansion of cloud or data services. Emphasis must now be on endpoint connection and agile development.

This means that middleware should not serve solely as an object-oriented solution to execute simple request-response commands. Middleware can incorporate pull-push events and streams via multiple gateways by combining microservices architectures to develop a holistic decentralized ecosystem.

Back to Top

References

1. Agarwal, P., Alam, M. Investigating IoT middleware platforms for smart application development. Smart Cities—Opportunities and Challenges 58 (2020), 231–244. Springer; https://link.springer.com/chapter/10.1007/978-981-15-2545-2_21.

2. Al-Jaroodi, J., Nader, M. Middleware is STILL everywhere!!! Concurrency and Computation: Practice and Experience 24, 16 (2012), 1919–1926; https://dl.acm.org/doi/abs/10.1002/cpe.2817.

3. Becker, C., Julien, C., Lalanda, P., Zambonelli, F. Pervasive computing middleware: current trends and emerging challenges. CCF Transactions on Pervasive Computing and Interaction 1, 1 (2019), 10–23. Springer; https://link.springer.com/article/10.1007/s42486-019-00005-2.

4. Bishop, T.A., Ramesh, K.K. A survey of middleware. In Proceedings of 18th Intern. Conf. Computers and Their Applications, 2003, 254–258; https://www.researchgate.net/publication/221205414_A_Survey_of_Middleware.

5. Ciufudean, C., Buzduga, C. Digital engineering education applications. Trans. Adanvces in Englineering Education 17 (2020), 10–14; http://www.doi.org/10.37394/232010.2020.17.2.

6. da Cruz, M.A.A., Rodrigues, J.J.P.C., Sangaiah, A.K., Muhtadi, J.A., Korotaev, V. Performance evaluation of IoT middleware. J.f Network and Computer Applications 109, C (2018), 53–65; https://dl.acm.org/doi/abs/10.1016/j.jnca.2018.02.013.

7. Farahzadi, A., Pooyan, S., Rezazadeh, J., Farahbakhsh, R. Middleware technologies for cloud of things: a survey. Digital Commun. and Networks 4, 3 (2018), 176–188; https://www.sciencedirect.com/science/article/pii/S2352864817301268.

8. Ferscha, A. Pervasive computing. Hagenberg Research. B. Buchberger et. al. Eds. Springer, 2009, 379–431; https://link.springer.com/chapter/10.1007/978-3-642-02127-5_9.

9. Helland, P. Fail-fast is failing… fast! acmqueue 19, 1 (2021); https://dl.acm.org/doi/10.1145/3454122.3458812.

10. Hong, J. The privacy landscape of pervasive computing. IEEE Pervasive Computing 16, 3 (2017), 40–48; https://ieeexplore.ieee.org/document/7994573.

11. IBM Cloud Education. What is middleware, 2021; https://www.ibm.com/cloud/learn/middleware.

12. Zhang, J., Ma, M., Wang, P., Sun, X.D. Middleware for the Internet of Things: a survey on requirements, enabling technologies, and solutions. J. of Systems Architecture: The EUROMICRO Journal 117, C (2021); https://dl.acm.org/doi/abs/10.1016/j.sysarc.2021.102098.

13. Lewis, J., Fowler, M. Microservices: a definition of this new architectural term, 2014; https://martinfowler.com/articles/microservices.html.

14. Medeiros, R., Fernandes, S., Queiroz, P.G.G. Middleware for the Internet of Things: a systematic literature review. J. Universal Computer Science 28, 1 (2022), 54–79; https://lib.jucs.org/article/71693/.

15. Pinus, H. Middleware: Past and present a comparison. Seminar paper, 2004; https://bit.ly/3wdIttw.

16. Salazar, G.D.S., Venegas, C., Baca, M., Rodríguez, I., Marrone, L. Open middleware proposal for IoT focused on Industry 4.0. In Proceedings of the IEEE 2nd Colombian Conf. Robotics and Automation, 2018, 1–6; https://ieeexplore.ieee.org/document/8588117.

17. Salem, A.B.M., Mikhalkina, E.V., Nikitaeva, A.Y. Exploration of knowledge engineering paradigms for smart education: techniques, tools, benefits and challenges. Trans. Advances in Engineering Education, (2020) 1–9; http://www.doi.org/10.37394/232010.2020.17.1.

18. Schantz, R.E., Schmidt, D.C. Middleware. Encyclopedia of Software Engineering. J.J. Marciniak, Ed. Wiley and Sons, 2002; https://onlinelibrary.wiley.com/doi/10.1002/0471028959.sof205.

19. Singh, K.J., Kapoor, D.S. Create your own Internet of Things: a survey of IoT platforms. IEEE Consumer Electronics Mag. 6, 2 (2017), 57–68; https://ieeexplore.ieee.org/document/7879392.

Back to Top

Authors

Alexandres Gazis is a researcher and Ph.D. candidate in the department of electrical and computer engineering, Democritus University of Thrace in Xanthi. He is a member of the Technical Chamber of Greece and works as a software engineer at Eurobank S.A., specializing in core banking systems and mainframe development.

Eleftheria Katsiri is a tenured assistant professor in the department of electrical and computer engineering at Democritus University of Thrace in Xanthi, where she teaches operating systems, structured programming, human-computer interaction, and distributed and parallel systems. Since 2014, she has been an adjunct researcher of the Athena Research and Innovation Center.


Copyright © 2022 held by owner/author. Publication rights licensed to ACM.
Request permission to publish from permissions@acm.org

The Digital Library is published by the Association for Computing Machinery. Copyright © 2022 ACM, Inc.


 

No entries found