Next logical abstraction: Loosely Coupled (or plug-n-play) parts

Many software experts believe that an innovative software component paradigm or CBSDF (Component Based Software Development Framework) has great potential to solve ‘Software Crises’, the term coined to describe, development of software projects taking too long (or miss schedules), poor-quality, far exceed budget, not work very well or even end in failure. Countless research efforts have been underway for decades to find an ideal software component paradigm.

Plug-n-play Components are essential to build True Component Paradigm:

To build TRUE component paradigm, we must invent plug-n-play components (i.e. "loosely coupled" components). To build an automated assembly line, one should first create ready to assemble (or plug-n-play) components. For examples, plug-n-play components for the cars are Engine, Stereo, Gearbox, Battery and Seats, which are manufactured elsewhere; and assembled on highly automated assembly line. But, steel, rubber, plastic and leather are not ready to assemble components, since they cannot be used in an automated assembly line. They are just ingredients used to build the plug-n-play components. Isn't it impossible to build an efficient assembly line that can use non plug-n-play ingredients, such as steel, plastic or silicon sheets? 

Likewise, to build a TRUE component paradigm for the software applications, we must define what is an ideal plug-n-play component for the software, and create elegant processes to manufacture such plug-n-play components. This plug-n-play parts are also refer to as loosely coupled parts. Then, it is possible to invent simple automated mechanisms to assemble (or couple) the loosely coupled parts. Also it is even more important to remove (or decouple) each part for easy maintenance (e.g. 'Service-access' during maintenance cycles of the application), for example, if the component need to be independently refined or replaced to meet the evolving business. 

Today’s fundamental understanding of software components is insidious and flawed. It is impossible to use such components as plug-n-play parts. For example, the components, such as, EJB (to get data, define business rules, policies, supply-chain or dataflow algorithms) only supply business (or application) logic portion of the plug-n-play application-components. On the other hand, presentation or GUI classes such as Charts, Maps, Meters, Trees and GUI-controls (ex. Lists, menus, Dials, and buttons etc.), define presentation templates and only contain presentation (a 'recipe' for drawing) logic portion of the plug-n-play part. 

Let me repeat the manufacturing analogy, it is hard to build an automated assembly line that can use the molds (e.g. casting, lathe machines, forging or molds to shape the metal) and the raw metal (that will be shaped into the part). The automated assembly lines need ready to plug-in fully functional finished-parts, which are made in factories elsewhere, to meet the given specifications. For example, a car Battery is a plug-n-play part, but led/acid are ingredients of battery and  not plug-n-play parts. Isn't too complex to assemble such ingredients in an assembly line for the automobile? 

Now lets come to the software parts: consider a simple example, a ‘Pie chart’ for an application. One could create a pie chart finished-part using a reusable GUI class for pie-chart. The GUI class is nothing but a template or a mold for the part. The GUI-class contains necessary logic (or “recipe”) to present a pie chart component, which needs configuration and run-time data-input to mold the Pei-char. One writes code to access database or may use reusable EJB to get data. Then writes code to initialize a Pie-chart object using the data, to present the finished pie-chart component in the application. In this case, the GUI Class for the Pie-chart clearly acts as a mold (or a template) to mold the data, and the data is the raw material to make the final part. Therefore, neither EJB nor pie chart class are ideal plug-n-play components for the application. 

Those traditional abstractions (e.g. GUI or Data Classes) are used as ingredients or tools, and manually hard coded (i.e. tightly coupled) to merge them to build plug-n-play parts. Therefore, they are just ingredients used to build ready to plug-in-parts for the application. Any research focused to improve traditional components (i.e. EJB, GUI or such API), might allow one to build better components, since, better ingredients would help us build better products for less and faster.

However, those component abstractions (e.g. GUI or EJB objects are only ingredients in plug-n-play components) themselves may never be able to become ready-to-snap-in components in an application. Analogous to better ingredients such as steel or composite material may allow us to build stronger, lighter and better automobile components for less; but the ingredients such as bare metal-sheet can rarely be used on an assemble line. 

True component paradigm can be built by: 

1. Define characteristics of true plug-n-play components, such as functionality, services and clear interfaces; especially must be decoupled (or untangled code) and have clearly recognizable boundaries to be programmatically or automatically plug-in to (or out of) the application code, to independently refine/update or to replace by a newer component at any later date. 

2. Create simple processes to manufacture such plug-n-play or finisher-parts, each of which custom build to meet each user/application’s unique functional needs and interfaces. 

3. Invent elegant and intuitive mechanisms to automate the integration (e.g. simple semantic interfaces based integration, or CASE tools) of such components, which is the necessary condition for a true component paradigm.

This web site briefly summarizes those processes and mechanisms and also illustrates them using simple examples. The inventions are far broader than the simple illustrative examples given.