The component architecture is a framework for building software based on reusable components. Each component encapsulates well-defined functionality into a binary unit that can be stored in a library and dropped into an application without requiring modification of other components.
The benefits are reduced development and testing time, enhanced reliability (because components are pre-tested), and the flexibility to change applications by adding or replacing components without major disruption.
What is component-based architecture? Think of a component as a Lego block. When building a structure out of Lego blocks, you can choose from a variety of shapes, sizes, and colors. There are also blocks that are purpose-built to be doors, windows, and other structural elements. Each block has all the features it needs to connect to others, and adding or subtracting blocks generally has minimal impact on the structure.
Software is much more complex than little pieces of plastic, of course, but the concept is similar. Each component is built to perform a task in a way that’s defined by the architecture. Components are stored in a library and assembled by developers. Components talk to each other through application program interfaces for simplicity. Communication is facilitated by an object request broker, which is sometimes called a “software bus” because it provides a single communications plane that all components use. Communication can occur in a number of ways, such as asynchronously, through broadcast, through a message-driven system, or as part of an ongoing data stream.
The concept isn’t new, having been discussed in academic papers as early as the late 1960s. IBM’s System Object Model, which was introduced in the early 1990s, was the first commercial effort to define a way to build software from components. Microsoft’s Component Object Model and Object Linking & Embedding, which were introduced around the same time, provided the first frameworks for use in commercial deployment.
Software components have a number of common characteristics:
Components are the building blocks of service-oriented and microservices architectures, in which applications are assembled from loosely coupled and discrete services. Microservices are the dominant architecture used in DevOps and cloud-native development. It’s valued for its productivity benefits since developers assemble most of the application rather than building it from scratch.
One example of a component is the spreadsheet functionality in Microsoft PowerPoint. When editing the data underlying a chart or graph, users are presented with a spreadsheet that looks and acts like Microsoft Excel. While it’s not a full version of Excel, the spreadsheet widget has enough functionality to support basic spreadsheet functions.
Other examples of components include a function that calculates tax in an eCommerce transaction or one that challenges the user to answer questions upon login.
Related reading: The Top 5 Benefits of Developing with Containers
A component architecture can have some drawbacks, which means it isn’t appropriate for every scenario. For one thing, it requires the application to be broken down into modular and functionally separate pieces, which can be a challenge when applications are quite large. Also, the need for reusability of a component can limit its customization options.
Finding a component that exactly matches the requirements of an application can be difficult too, and because a great many components may need to be monitored in a given application, updates and maintenance of component libraries can be complex.
There are numerous alternatives to component-based architecture. These include:
Components have become a fundamental building block of modern software. While the term is less used today than it was 20 years ago, the concept is sound and has proved adaptable to a constantly changing technology landscape.
If you’re interested in more information, do read What is Component-Based Architecture? blog from Mendix.
Posts by Paul Gillin
