Components
Component based development is traditionally defined as the process of building systems by way of combination, aggregation and integration of pre-engineered and pre-tested software objects. This approach provides three benefits; reusability of software, control of complexity, and control of change. Also the by-products; rapid application development, increased software quality, improved maintainability and modifiability. Most applications built with components will be highly "customizable".
An Evolving Definition
Earliest discussions of component technology were limited to compound document technology such as Microsoft's Object Linking and Embedding. Soon afterward, Visual Basic and VBX controls were the only components in the focus of the industry. VBXs were a poor standard for component software. First, the VBX API and data structures were inherently 16-bit oriented, and the pointers with the APIs were linked to the 16-bit segmented Intel architecture. VBX controls were then replaced by 32-bit OCX controls and later by ActiveX controls as the de facto standard for software components in Windows environment. Today, encapsulated software objects such as ActiveX controls and JavaBeans are the industry standards for software components.
De Facto Standards
ActiveX/COM, Java/JavaBeans/Enterprise JavaBeans, and CORBA/IIOP are the three leading object models for components, distributed object computing and interapplication communication.
Attributes of Component Software
Attributes of the various types of component software:
Encapsulated software objects limit interaction to clearly defined public interfaces. An object's behavior cannot be changed except through the proper interface calls. It is important to understand that a component encapsulates both state (data) and behavior (methods). Components can encapsulate (and therefore abstract) a wide variety of functionality such as two-phase commit, interapplication communication protocols, security and authentication services, existing systems, and so on. Encapsulation also allows existing data and processes, including legacy code, to be "wrappered" and used in new system development efforts.
Purists believe that inheritance is required to model reality and increases the modifiability of the code. However, for most in the industry, components are synonymous with encapsulated binary objects, most notably JavaBeans and ActiveX controls.
Components can be classified based on their size relative to the systems they are building. Fine-grained components are typically small in size and have applicability across a wide range of application types. Fine-grained components usually take the form of desktop-bound visual controls. In contrast, large-grained components, as the name implies, are larger in size, but necessarily more limited in their applicability across a broad range of application types. Large-grained components are typically closely related to an organization's business model, and are more server-centric. The term "business object" is often used to describe large-grained, server-centric components that map to common business entities and processes.
Out of necessity, many parties settled on the definition that a component is any piece of software that is designed to facilitate reuse. Perhaps the most important quality of components is that they can be used in conjunction with other components to build systems.
To sum up, a broader, more inclusive definition of software components is software objects providing some type of known service, or specifications capable of creating such objects, can be used in combination with other components to build systems via a well defined interface. Given this definition, it is possible to distinguish five classes of components; class libraries, encapsulated software modules, framework environments, CASE models, and prebuilt applications:
Class Libraries
Class libraries and encapsulated software components are examples of fine-grained components. Class libraries can be of two types; "standard" libraries, such as C++ and Java classes, and proprietary classes, such as 4GL classes. C++, Smalltalk, are Java are representative of standard 3GLs.
Encapsulated Software Objects
Encapsulated software objects differ from class libraries by virtue of the fact that they are usually not delivered as source code, and they must run inside some type of container application. Three de facto standards for component model exist. The first component standard, promulgated by a single vendor Microsoft, is ActiveX controls. ActiveXcontrols are based on Microsoft's Component Object Model (COM). COM is Microsoft's object model that specifies the intra-application and interapplication communication interfaces between OLE compliant components (ActiveX controls).
The second component software model, JavaBeans (one word), is promulgated by Sun's Solaris and Java Software Divisions, as well as Borland, IBM, Apple, Lotus, Netscape, Oracle, Symantec, and others. Java Beans (two words), conversely, is the name given to the software components that adhere to the JavaBeans specification. JavaBeans builds on the core functionality of Java, but Beans and Java are not synonymous. JavaBeans builds on Java's core functionality such as portability and networkability, and extends this functionality into the area of component-based development.
The third standard for encapsulated software objects is CORBA components, which are based on the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA). CORBA components can be developed in a variety of languages, including C++, Smalltalk, Java, and Ada, although support is dependent on any vendor's given implementation. CORBA objects can be deployed across Windows, UNIX, and many other platforms.
ActiveX controls, CORBA components, and JavaBeans differ in many key areas, and these differences determine their applicability in a given situation. First, Java Beans must be built using Java language, while ActiveX controls and CORBA components can be created using any number of languages, such as C++, Visual Basic (in the case of ActiveX), and even Java. Since Beans are written in Java, they are portable to all environments that support the Java virtual machine. ActiveX controls and CORBA components are delivered as machine-specific binaries, with ActiveX controls limited to Win32 environments. Basically, ActiveX and CORBA components lack the portability of Java Beans, but they are optimized for the native platforms they were compiled to.
References:
Build Vs Buy: Maximizing the potential of Components by Dan Kara : Component Strategies Sep 98