When a request for a dynamic data web page received by the web-server, it runs the CGI or JSP/Servlet associated with the URL and passes the browser-information and parameters send by the requesting browser. This JSP/Servlet-executable may access the database or other live-data sources to generate the web-page file.

The web page returned might be a simple HTML document or a document that contains XML-graphics (e.g. XAML, X3D or SVG) language instructions, which can be viewed by appropriate platform (or viewer or browser). This web document is usually referred to as web page, due to the legacy of the Web. But the document can be a large application that contains many interactive graphics components, and these components further collaborate or communicate with each other; comparable or even far more complex than any GUI applications one finds on desktop PC (e.g. Windows or UNIX/X11) created using traditional programming languages such as VisualBasic.

The platform executes the instructions in the web document (i.e. source code for the application) to present the web page or application. Some platforms may require that the XML-document be translated (e.g. from MXML to Flash) or compiled (e.g. XAML to *.exe) into an executable program, before the platform runs the application.

The invention outlines a component-based software development process to generate the source code for the online application. The online GUI-application design and development process emulates the process employed by the product (e.g. automobile or computer) makers to design and manufacture their products.

The component-based paradigm based on a simple idea: How any one designs custom parts and build automated assembly line to manufacture a product?

The steps and process employed by a manufacturer to design and build a new product (e.g. a computer or an automobile) comprises of: The product designers or architects partitions the product into many of its components. The architect specifies the desired functionality and features for each of the custom components (or parts) and place order to the Component Factories or CF. Some of the components offer standardized interfaces (e.g. car battery, stereo system); and for other components (e.g. new engine, new gear-box or new dash board) the product designers need to pre-define desired interfaces, which are used to integrate or assemble the part into the product.

This simple ability to execute each task independently (manufacturing by the specialists and mechanized integration at the assembly line using simple interfaces) revolutionized the manufacturing. This is the core innovation of the assemble line in manufacturing. An ideal component paradigm for the software building process must accomplish this separation of activities, so that, the manufacturing can be executed by specialists and even low skilled people can assemble the component in minutes.

Usually using a part is much simpler than manufacturing it. The maker of the part deals with the complexity of making the ready to assemble component and hides the manufacturing complexity internal operational complexity from the user, who integrates the part. The user mostly needs to know the interfaces to access its features and services. For example, automaker buys a battery and connects wires to use its services. The battery maker deals with the complexity of making the battery and hides the manufacturing and technical design complexities. The automaker needs to know its interfaces to integrate the battery and other complexities are largely hidden from the automaker.

The most important aspects of assembly line paradigm in manufacturing is: Clear separation and encapsulation of the internal complexity of the component and its simple external interfaces. The components are designed to hide its internal complexity and offer extremely simple interfaces, so that, user needs little skill and effort to assemble the parts (and needs no knowledge on internal design or technology to make the part). Such components are usually called “Loosely Coupled” components.

There are two attributes that a software program (i.e. CF/AC) must possess before it qualifies as a ready to plug-in component. First of all, its inner workings must be hidden from the outside world (especially from the user to use it as a subcomponent). Companies like Gateway or Dell do not concern themselves with the issues involved in designing or manufacturing hard disk drives, and certainly don't need to start dwelling inside. This is where solution lies to solve the software crisis.

We must create ideal plug-in CF/AC that can hide internal complexity and provide simple interfaces to plug it in. Most of the application code must be assembled using, only such plug-in ACs; akin to the way one assembles computers. If one opens a PC, he would notice mostly “loosely coupled” parts, which are connected to each other by wires to facilitate flow of electrons between them. One could replace any part with the assistance of a screwdriver and don’t need to understand internal design of the part. The product essentially must be nothing-but collection of “loosely coupled” parts.

Likewise, many large components used in the complex products are also partitioned in to subcomponents and manufactured by assembling the subcomponents. For example, the graphics card in a computer contains many IC-chips and other parts. The designers/maker of the graphics card defines desired functionality and interfaces for each of the IC-chips and orders the chips from chip designers/makers. Also, the graphics card maker may incorporate few standardized chips (e.g. EPROM, Math processor and memory) that provide desired functionality. Such standardized parts are usually called COTS (Commercial Off-the-shelf) parts.

The advantage of using this process is that, the IC-chip maker deals with the complexity of the designing and making the chip and the graphics card maker only concerned with the public interfaces and functionality to use the part. This process allow graphics card designer to only focus on a smaller part of the total complexity and rely on the subcomponent makers to deal with other parts of the complexity separately.(This process effectively distributes the complexity between the part makers).

This process is useful to partitions a larger problem into smaller independent problems, each of which may be addressed separately from each other (preferable by the specialists, who have core competence in the respective area). Each of the subcomponent hides internal complexity and only exposes its services through its simpler interfaces. In general, the parts (e.g. IC-chips) could be readily integrated to build larger part, hence reduces the complexity and skills needed by the maker.

Likewise, The IC-chip maker in turn may use parts made by his other suppliers and so on. Usually many parts (e.g. hard disk) used in complex products (e.g. PC), in turn are complex. The makers of those parts may employ similar process to obtain ready to assembly parts to make their product. This process may be repeated until basic part is sufficiently less complex or Commercial-Off-The-Shelf (COTS) parts. This kind of decomposition of the larger parts into independent “loosely coupled” parts is essential for an Ideal component paradigm.

This chain of dependence allows each component designer to focus on a smaller part of the overall complexity, when designing the component. The assemblers mostly care about the interfaces and functionality of each of the subcomponent and needs little skill or technical knowledge on the internal complexity and design aspects of the part.

The CBSDF invented almost comparable process for the software, to secure the same benefits or results. The application designer or architect partitions the application in to many basic independent ready to plug-in “loosely coupled” components (also called Application Components or AC), such that, each provides certain functionality; and also may support one or more services to other components. Now, each CF can be designed to create custom AC based on user profile and other unique application needs. One of the inputs to the CF is “HTTP-request object”, which may contain user’s profile. The output of the CF is a ready to plug-in AC. The CF creates the AC, so that, it has simplest possible interfaces, even the less skilled can integrate it (or plug it in).

The CBSDF may employ simplified service oriented architecture “SoA” between the “loosely coupled” ACs. Many books and web sites outlined SoA. Please also refer to definition for “loosely coupled”. The term “loosely coupled” has a very profound meaning among component researchers. Please refer to UDDI or Directory Services. The ACs in the application are an ideal example for the “loosely coupled” components.

Then the larger AC designer sets up supply chain and builds assembly lines (which is again may be a CF) to build successively larger and larger ACs (See figure#1). The CF supply chain setup on the left side produces the source code for the application (or web page shown on the right side). Each CF generates the source code for the respective AC (a part for the web page), as shown. To run the application, one may load the source code in to appropriate platform.

If the assembly line needs to write integration code, the steps are very simple. For example, each AC may provide one or more services; and one or more other ACs located in the same web page, may request the services. The code for each communication link is: Just make the other AC to locate and call the service method. This usually needs about five lines of code or less.

Note: Our study showed that, on average, a typical large component would have two interfaces. It requires, very little skill and knowledge to write the 5 lines of integration code. This is a perfect match to the manufacturing; therefore we get the similar benefits.

Lets first discuss this in the context of a Car. The Car Battery supports only one service: supply 12V DC power. The gas tank supports one service: supply Gas to engine. The engine provides only one service: rotate the crankshaft and delivering the torque to gearbox. Most components (e.g. doors, car seats) in the automobile, does not provide any active services. They are static objects. They are assembled (or anchored) in to a specific place, but not actively collaborating with any other components. In the case of the applications, such AC does not need any integration code.

Similarly, in the software application, many plug-in components are just anchored in the container component and don’t collaborate with any other ACs in the application; hence not even single line of integration code is needed. For example, in a pie chart, usually the Title-component does not exchange any messages with any other ACs. On the other hand, in shopping cart application, the AC for the Invoice/Cart just provides one service: add an item to the Cart. Likewise, each AC to present a shopping Item may contain just few lines to request the service of the Invoice component.

Usually, it requires very little effort and skill to integrate most ACs. To integrate two components, all it required, is to make one AC call the service method of other AC, which is usually about 5 line of code. No special skill is needed to write such integration code. This is a good match to the manufacturing; therefore we get the comparable benefits.

Most well partitioned components, offer no more than two services. You could verify this for yourself. Take any large application you have been working. Please identify large ACs in it. If you partition the application carefully into AC, so that, each AC is logically cohesive unit (e.g. engine in a car is a good cohesive unit), then find out the average number of services provided by the ACs. Ignore the complexity of the implementation. Just imagine that some one else will be implementing the AC for you and you need to use it by accessing its services. How many different services you need?

If you ignore the internal complexity of the AC/CF and also the complexity of the message (e.g. an XML-string) exchanged between them, the integration code to request the service would be very simple. For example, consider Shopping-cart/Invoice. The Invoice can be a complex 3D SVG-Table, where user can edit many items, such as, number of items of each product, sizes and colors etc. This would require thousands of lines of code and many sub-AC hierarchies, to provide such interactivity. Furthermore, the AC for each product must send an XML-message, which contains hundreds of pieces of data (e.g. inventory, prices, available sizes, colors etc.). This XML-message must conform to a predefined XML-schema. However, the integration code for each product’s AC is: just call the service method of the Invoice’s AC to pass the XML-message.

Please remember, creating the XML-message is a basic functional requirement, hence, internal complexity of the CF for the Product’s (i.e. shopping item) AC; and consuming the XML-message is again a basic functional requirement, hence, internal complexity of the CF for the Invoice’s AC. Hence, the integration code (5 lines) don’t need to concern about this complexity. This interface compatibility may be mechanically validated, as discussed later. This allows two different developers; both have access to the XML-schema (or a contract written in WSDL), to work independently from each other to build compatible ACs. For example, in the PC, both CPU and the Graphics-card exchange complex data, and designed by specialists, but the integration is just few wires.

Using this process, we could build each CF independently, so that, it generates highly functional cohesive AC, which supports simple service based interfaces. We could easily create assembly lines to build larger and larger components and finally the application (which is often refer to as web document or web page, due to the legacy of Internet). The Application can be far more sophisticated than most Windows-XP GUI-applications. The application is not hand written, but created by many small and innovative CF; and furthermore simple innovative programs (e.g. container CF) may be used to integrate them (that writes simple 5 lines integration code to link each service). Since factories are writing the code, it is possible to create complex systems at fraction of the cost or create complex applications, which were impossible to write manually.

Like in manufacturing, these two activities (manufacturing and assembling) are completely independent activities in the CBSDF. Therefore, an Ideal assembly line paradigm is successfully emulated to build the software application or web document (manufactured by assembling plug-in parts); which is executes on the client.

When I am experimenting with the above CBSDF processes, I have realized that the software components (or AC) and assembly line paradigm, may offer far better productivity gains than the productivity gains enjoyed by the manufacturers since the introduction of the assembly line.

Since, most CF uses other CF to create its sub-ACs, to keep the complexity under control, one could limit the class code for CF between 25 to 250 lines and not to exceed 500 lines. Once all the CFs are ready, one could setup the manufacturing supply chain as shown in the right side in couple of days. Likewise, it would take couple of days to setup new assembly line, whenever one wishes to completely redesignor overhaul the product.

Please recall the pencil and MS-word (http://www.sandia.gov/LabNews/LN09-10-99/super_story.html) analogy. A long chain of manufactures deal with certain part of the complexity. They may use subcomponents and rely on their manufactures to deal with the manufacturing complexity. Likewise, the CBSDF, each CF may use subcomponents (hence rely on respective CF to deal with the complexity) to manufacture its component.

Therefore, each CF only deals with small part of the complexity. It relies on external interfaces of its sub-ACs, so that, each of the sub-AC’s CF could deal with internal complexity and hide it from next node in the supply chain. Each sub-CF is free to refine the manufacturing process to improve its AC’s performance and features etc.

One of the most important aspects, the product designers are concerned about is, providing service-access. This is one of the most crucial factors that determine to total cost of ownership, user satisfaction and ultimate success. For example, an automobile designer must design the car such that the components that suffer wear and tear can be replaced with minimum effort and cost. Also, user would be happy, if he could upgrade the product as his needs change or when he could afford. For example, stereo-system in the car; and CPU, DRAM or Graphics-card to play games in the home computer system, which would allow the owner to protect his initial investment, and upgrade the product to keep up with advancements in the technology or satisfy his evolving needs.

In the manufactured products, the larger component contains all its subcomponents and if one removes the container component, usually all its subcomponents (or parts) would be removed with it. For example, if one removes hard drive from a computer, it would remove all of its parts (or subcomponents), which are usually contained with in its package. To remove or to replace a component or part in a manufactured product, one usually needs little more knowledge than knowing its external interfaces that are used to assemble the component. One usually does not need the experience or knowledge of its subcomponents (or parts), their interfaces and technologies or processes used to design and manufacture the container component. This may be called component containment model, where the container component contains all its subcomponents and the component may be operated as a single building block.

Today, business spend 2 to 4 times more money to maintain the IT applications than original cost of building it, yet the results are often unsatisfactory and likely end up with code degradation. This is due to the fact that the software code processes are poor at providing service-access to the large custom components, which have many subcomponents. It is usually error prone and complex undertaking to update or replace each of them. Usually component code (and its subcomponents) is broken into sections and the sections are spread across many source files. Hence, it is hard to remove the container components and its objects and resolve the object dependencies.

However, It is very crucial for IT applications to quickly evolve (under time pressure) to meet changing business models (e.g. competitive threats or process innovations), to leverage latest technologies and to keep up with evolving regulations or policies. This forces new developers to add new functionality, with out disturbing the old code (due to the uncertainties of the object/code dependencies), which likely results in redundant implementations, degraded code structure, and dead code (i.e. unused code), for the future developers, who will be forced to add more patches to work around them.

Our CBSDF provides great Service-Access to all the ACs. Please remember, the application (or web page) code is the product. Each CF independently generates code for each AC in the product; hence it provides excellent service-access to each AC. One can independently refine each CF to update the AC’s features. If one deletes the CF on the left side, Zap! AC (and all its sub-ACs) disappears from the right side, leaving no traces. He could even easily replace the AC with a new AC, by substituting new CF in the place of old-CF. Nothing else is needed, as long as, the external interfaces are not changed. If the external interfaces are updated, he needs to change the simple (typically 5 to 10 lines of) interface code in the assembly line (i.e. code in the container component or product).

The process of assembling an AC involves, just instantiating the CF-object and writing few lines of assembling code below it. This integration code gets the data (e.g. name to access its services) from the CF-object. If one removes the CF and forgets one or two lines of its integration code, the compiler usually catches this slip up, because, these lines likely be referring to CF-object or names obtained from the CF. It is easy to locate the code that depends on the CF, by simple searching for the variables (of the CF and methods refer the CF). If one forgets to remove the integration code for the CF, compiler usually fail and display error messages, Therefore, removing any CF on left side, results in removing the AC on the right side, which is simple and routine mechanical process.

It is highly desirable that the process to remove or replace a component is simple, straightforward and mechanical (i.e. no creative stuff or complex debugging). This process should need knowledge of only basic services (or functions) of the component. It likely does not need knowledge of the design of the AC or complex debugging. This is accomplished by using class-based integration and standardized or pre-defined interfaces.

Definition of Semantic or class based integration: When one wants to replace a component, he should use a component of same type that provides same or equivalent services. For example, one like to replace an engine, he must use the new component (or part) of same class (i.e. engine) that provides same service. He should not use part of different class (e.g. a gearbox) that supports different service. Therefore, semantic substitution and integration means replace a part with another part that belongs to same class and provides same service or functionality. Borrowing ideas from hardware components, the goal of CBSD is to allow parts (components) of a software system to be replaced by newer, functionally equivalent, components.

Parametric Compatibility: Semantic integration only checks the class compatibility. However, for proper functioning, it must have parametric compatibility as well. To replace a part with a new part, it must satisfy parametric compatibility. For example, an AA battery and Car battery belongs to same class and both provide same service, each supply DC voltage. However they are parametrically incompatible, one deliveries 12V and up to 90 amps, while other delivers 1.5V and only 900 milliamps.

The CBSDF provides an elegant process to detect parametric incompatibilities, therefore substantially reduces the part-replacement costs. Incase of CBSDF, the service provider AC defines an XML-schema (which defines vocabulary and pieces of data needed to process the service-request. Please refer to WSDL for sample techniques one might employ for the interface-contracts). This is akin to, how the automobile manufacturer prepares specifications for the interfaces between the parts, so that, the parts fit properly and work well during the operation. The CBSDF may accomplish this by defining “interface-contracts”, which may be nothing but predefined XML-schema.

It would be a great help and substantially reduces the complexity of integration, if we can support a tool that automatically validates the compatibility between any two ACs (that are created by different teams). This automated checking and validation of the compatibility would eliminate difficult and error-prone integration tasks, such as, many uncertainties about code dependencies and also hard to find integration errors.

The requesting AC sends the request XML-message (which contains a URL to its XML-schema). Before processing the request, the service-provider AC may request an XML-schema validation-tool to validate the XML-message and requester’s XML-schemas against the service provider’s XML-schema. If they are not compatible, it generates a detailed error message that lists the incompatibilities. This helps even the less skilled to find most integration errors mechanically, with out much effort & debugging.

The contract validation tool is a generic tool that verifies the compatibility of the XML-schemas of the interacting components. Each component maintains private copy and it would update the private XML-schema, when the XML-message contents are updated to meet evolving needs. The components are designed to create (or consume) the XML- data, which is conforms to its private copy. Usually the consumer component of the XML-message may request the tool to validate the data. Usually, the XML-data contains a URL pointing to the XML-schema of the sender of the XML-massage.

This makes replacing or updating any AC simple and mechanical process. This way, the ACs are better components than, car parts. If you mechanic installs wrong oil-filer, it blows up your new Toyota Camry’s engine with out any warning. (It happened to my Camry). Such tools eliminate hard to find integration errors, eliminate uncertainties on potential code dependencies and substantially reduce the testing costs. When the integrator finds incompatible parts, he may send the XML-validation tool’s report to the developer of the incompatible ACs to redesign the CF to produce compatible ACs.

There are fundamentally many differences between Component based software development (or CBSD) and the Object Oriented Programming (or OOP). The most important aspect is, clear distinction between internal cohesion and external interfaces. An ideal component based development process must facilitate a mechanism for developers to create each component, such that:

The OOP-Object oriented programming does not make any such distinction between internal configuration (or initialization) methods/functions and external interface methods (or integration). For example, for a GUI-Class that depicts a moving object (e.g. taxi) on a vector map: (i). May be initialized using many set-methods, such as methods to set color, size, and other data (which certainly steps to manufacture the component); (ii). It also supports methods to set callbacks to integrate the GUI-component (This would allow this component to communicate user action or other events to other components, hence it is interface or integration code). In the Object-oriented programming, the GUI-Class for the moving-object do not make the difference between, these two types of methods (i.e. integration of the components and the initialization or manufacturing of the component).

On the other hand, in component based programming these two types of methods make the world of difference. The AC mostly supports only integration methods (e.g. may be called interfaces to access its services), which are used to integrate the AC. The builder of the component may use reusable GUI-classes to build the component, which support first type of methods of the GUI-class to initialize the objects to customize the component. The user of the component(or AC) uses the second type of methods to use this as a subcomponent in a larger component (or product). This separation is crucial for the Component based software development.

The first set of methods of the reusable class-code helps the builder of the component to build cohesive, fully functional, internally consistent and self-containing custom component. The second set of methods help the user of the component to integrate the component. The automated assembly line needs fully built part/component; and the internal implementation and complexity must be completely hidden and transparent to the user of the component. It must expose only simple interfaces.

Please see figures: Fig#3, Fig#4, Fig#5, fig#6, Fig#7, Fig#8,#9, Fig#10

The OOP badly deals with integration of the Objects, which forces numerous unstructured interactions between all these Objects. It creates numerous interdependencies among all the objects. The CBSDF do not eliminate most of this crisscrossing of interactions, but encapsulates both the application logic and presentational logic with in a CF class code, which builds the AC (an ideal loosely coupled component). The OOP treats this code as the integration code, while the CBSDF treats this code as the code needed to manufacture the AC.

In the OOP, this crisscrossing of interactions spread further into other ACs, when we integrate this AC with another AC.However, the CBSDF mostly eliminates the crisscrossing of the Object interactions between two ACs as shown in the figure#10; since it employees a recipe (e.g. Integration Logic) to dynamically integrate the ACs. The AC concept doesn’t exist in the OOP paradigm. There is no set boundary for the AC in the OOP paradigm. It is hard to separate the integration code to integrate the objects (for manufacturing) and the integration code for the run-time collaboration between different ACs. There is no way; OOP cancontain the AC (and it’s sub-AC’s) code in a file and stop the tangled code from happening, as shown in the other figures.

In the OOP, theapplication source code comprises of all the Objects, both Application Components (or AC) of the product and the Objects used for manufacturing each of the AC. The manufacturing process and product functionality is projected on to same plane. In the CBSDF, the manufacturing is separated from the each AC code.

The CBSDF separates the manufacturing process from the Product. The application (i.e web page) only contains the ACs; just like the PC box do not contain the steppers and etchers used to make the chips (e.g. CPU or DRAM). One does not find 2 billion fabs or 2 million dollar equipment made by Applied or KLA-tencor in the PC. The PC only contains final parts, and not the objects and tools used to make the parts.

One looks into the hood of an automobile, he wouldn’t find molds, forging-tools or lathe machine in the hood. He finds only finished parts (e.g. engine and gearbox etc.) and not the objects used to manufacture the automobile parts. On the other hand, the source code for the OOP application contains many objects that are used to manufacture the AC as shown in the figures 5, 6 & 7. All the interactions in the manufacturing process are considered integration code. Typically, it takes several hundred lines of such integration code, to custom crate a chart (e.g. Pie) for each user; this process involves interacting with many objects, such as, DB-Obj for data, USER-Obj for preferences and other Objects for policies, calculating the values for the chart etc.

In the world of manufacturing, an Ideal plug-in component only exposes simple external interfaces and hides all its internal complexity from the user. A well-designed component provides very simple and flexible interfaces for the user. For example, the interface to an automobile or AA battery is just electric contacts, but completely hides internal details (e.g. nickel cadmium or alkaline etc.). All the complex chemical reactions between the ingredients that go inside the battery are hidden from the user.

The CBSDF strived to do this and successfully accomplished it. If one loads the code created by any CF (i.e. code for the AC alone) in to the viewer, he should see fully functional interactive component image (it may show few errors messages, when the AC fail to access services of other ACs). Therefore, it is possible to create and test each CF and its AC independently. This AC is a fully functional and cohesive code-block. The program or a larger AC (that emulates the assembly line) takes one or more such components (i.e. code-blocks) and uses them to construct larger component (it is again a larger code-block for the container AC, containing all its subcomponents, and so on).

As described above, the CBSDF uses assembly line paradigm to construct the application (which is often refer to as web document or web page, due to the legacy of Web. But XAML web page with 2D/3D components can be more complex than many Windows-XP applications). The web page code contains only the AC and not the Objects used to manufacturing the ACs. The developers create CFs to generate ACs and also develop programs or larger CFs, which emulate assembly line paradigm.

The CBSDF uses OOP on the server side, for example (i). Developers use OOP to design and develop each CF, which generates each cohesive functional component and (ii). Developers also use OOP to build the automated assembly line, which dynamically integrate the components to generate code for the application (or larger component).

The CBSDF uses CF and simple code to assemble the components to generate the web page (i.e. the application). The CF generates the components. The simple assembly line code generates the glue code based on simple “recipe” (or services of the generic component class that is independent from the internal implementation and features of the component) to integrate the components. The dynamically assembled application (or web page or application files) contains only the cohesive fully functional finished-components, and necessary glue code, in order for the components to collaborate.

An ideal component encapsulates and hides internal complexity/functionality from the external interfaces. The assembler relies only on simple generic services (e.g. 12V DC supply for a car battery) of the component and use the simple service interfaces to integrate the component (and does not care about the component’s implementation or code size either 2 or 2 million lines). In the CBSDF, only point of insertion for any component is it’s CF object. Therefore, the CF can provide excellent service-access, such that, the CF can be constantly refined; or the CF can be easily replaced at any later date.

The traditional Object-oriented programming uses only static flat file structure (which are manually created), hence, not possible to separate the activities in building the components, customization of the features, security, verification, assembling the components and other house keeping activities. Since, every thing goes in to same static flat files, it is impossible to physically distinguish these code sections (many objects used to build each AC) of these different activities, hence, not possible to preserve the independence of the ACs or provide independent service-access to the ACs/Objects.

Furthermore, each AC (i.e. many Object user to build the AC and its sub-ACs) code may be spread mostly randomly in many files, and impossible to write programs to replace or surgically remove an AC from the application. In the CBSDF, they are hierarchically structured, such that, the larger component contains all its subcomponents. If one removes the CF on the left side supply chain for any component, ZAP! code for the AC and all its sub-ACs gone, and leaves no traces at all.

Please look at the figure#1. The right side is the code for the application. There is no tangled code. The code blocks for each AC is well structured (i.e. each AC contains all its sub-ACs). On the left side, we have CF; each of which may even be a Portlet running on different servers located in different parts of the world (e.g. the CF may be a Protlet that generates the code for the AC). The Portlet supported by the content providers, could be generating any AC code. It may generate scores, statistics and playoff charts for eastern-zone basketball teams for the basketball fan and western-zone football teams for the next sports fan.

In the static file approach taken by the traditional OOP, this hierarchical structure is only virtual-one; and physical structure of the code comprise of many Objects to make each subcomponent and may be spread across many files and mixed with the Objects for other components and their integration code. There is no way to automatically identify all the code-sections of a component and it’s subcomponents, which are spread across multiple files and tangled with all the other code segments and inter dependencies.

The traditional OOP based application’s code consists of many other types of objects, which are not necessarily providing any useful function in the application (i.e. final product) after AC has been created. For example, EJB and DB-connection objects are shared by many components, which are used to access data from data sources. They are like many objects (e.g. drillers, conveyer belts, power-drills and boxes containing parts) one may find in the manufacturing floor around the assembly line, which are certainly provide necessary support to build the AC or assemble the AC, but they rarely end up in the final product. They are not components in the product (or application).

The Object-oriented programmers use other data-objects to communicate data between Objects. But many of them cannot be considered as components. For example, the interface between the battery and stereo system in a car is wires. The Object that is being exchanged is power. It is hard to argue that the electric power is a component in the car. Therefore, in the Component based programming, the collaboration between two components is not a component. In the component-based paradigm, each application component may request the services of other components. The services may be objects, but not components.

The OOP uses many such constructs, which do not conform to the Assembly line/Component based paradigm. Therefore, it is hard to obtain the productivity gains (e.g. building each component independently or provide independent service-access) for the OOP, similar to the productivity gains enjoyed by the manufacturers since the invention of the assembly line and “loosely coupled” components.