| 
         
        
	
	 |  
	
	 | 
	
		| 
 Emerging Online Software Crisis, an Ironic twist & An opportunity to Triumph 
		 |  
		|   |  
		| Hi Earthlings, |  
		 |  
		| 
 Web applications are essentially a set of web pages (or screens) that are dynamically generated. 
Today most of the web pages usually contain HTML, DHTML and JavaScript code. However, many promising technologies 
are emerging, such as, Adobe’s Apollo/MXML/Flash, W3C’s SVG, X3D, Xforms, Mozilla’s XUL and 
finally Silverlight/XAML from Microsoft (the great lord of software). 
		 |  
		 |  
		| 
 Therefore, most future web pages would certainly contain complex 2D 
and 3D components build using one or more of these technologies. 
The code to present the interactive components would 
be very complex. Large applications may comprise of 
hundreds of such components, which must be dynamically 
generated based of real-time information, security,
user profile, preferences or custom data 
collected from various data sources. For example, information 
such as weather patterns for real-time simulation/modeling, dials 
and meters for command and control systems (or digital dashboards), or various 
interactive components for air-traffic control systems. 
		 |  
		 |  
		| 
 Furthermore, these 
components in the application must be integrated, so 
that, they can collaborate or communicate with each 
other. Only macho super-nerds can try to build real applications. 
No one can create a “real” application with 
out integrating all the complex components. Usually this integration 
would be very complex and source for many errors. For 
example, it creates tight coupling or many interdependencies 
among the components (or various code sections), which 
increase the complexity exponentially. 
		 |  
		 |  
		| 
 Today, every one 
agrees that development of large software applications 
is intensive manual, error prone and complex process. 
Now, please imagine the complexity, if you need to design 
and develop software, which needs to generate a large 
application (e.g. few million lines), which entirely 
comprises of dynamic data driven complex 2D & 3D 
components (written in strange languages and cryptic
instructions).
 
		 |  
		 |  
		| 
 Let me put it 
another terms: you need to write an application (e.g. in java, C# or RoR) that 
needs to write yet another complex application (e.g. in XAML, SVG or MXML), using 
a cryptic markup language most of you probably don’t 
have sufficient experience (if you are brave enough 
to already learned it), that comprises of primitive 
XML-graphic instructions, such as lines and arcs. Remember 
a thumb rule: to generate each data driven code, usually 
you need to execute about 3 lines of code on the server. 
This code includes accessing data, user profile, customization 
and security etc. 
		 |  
		 |  
		| 
 Furthermore, have 
you seen the 3D and 2D instructions supported by the 
technologies, such as, XAML, Flash, SVG or X3D? Many 
would agree that they are highly cryptic and certainly 
not intended for manual consumption. Hence, it is logical 
they should never be written by human beings. Add to 
this, many complex and error-prone calculations for 
dynamic data driven transformations and animation of 
those cryptic graphic elements (e.g. path, time and 
view ports) for each component. 
		 |  
		 |  
		| 
 Add to that, debugging 
on newer versions of buggy browser. Remember the browser 
wars and what you did to make your web pages run on 
all the browsers. Recall how painful it is to maintain 
bug-to-bug compatibility to run on many browsers and
their versions. 
		 |  
		 |  
		 
		  Historically, 
software engineers alone developed the desktop applications. 
In contrast, web based GUI application development involves 
many disciplines, from application-domain experts, analysts, 
graphic designers (e.g. 2D and 3D component developers), 
to database administrators/architects, and of course 
software engineers. Combining the efforts of these diverse 
groups is a non-trivial management task (certainly doomed, 
if you have pointy-haired boss). 
		 |  
		 |  
		 
		  Many experts said 
that the software development was too complex and they 
called it “software crisis” decades ago, 
well before the advent of the web. This certainly gives 
a feeling that the future web GUI applications (e.g.
real time simulations or games), if ever 
created, adds an extra dimension of complexity, A 
real big one. Doesn’t it? Most experts 
agree creating online application certainly lot more 
complex (i.e. impossible). 
		 |  
		 |  
		| You may be thinking. OK, Online GUI applications are Doomed!
		 |  
		 |  
		| 
 Not so fast! There 
is an ironic twist and a happy ending. Today, most experts 
agree that the web adds an extra dimension of complexity 
(a big one). That’s what we said before, (OK it’s 
me), but you do agree. Don’t you? 
		 |  
		 |  
		| 
 OK, where is the 
Irony in it? The web is in fact, also offers an extra dimension 
of freedom and flexibility, however in deep disguise. 
This extra dimension is extremely unobvious, but very 
elegant and simple. This new dimension can be leveraged 
to build complex GUI application at fraction of the 
cost compared to similar 2D and 3D applications build 
for the traditional GUI platforms. 
		 |  
		 |  
		| 
 Wait a minute, 
Dude. We just spent US$10 million to build a cool 2D 
graphics intensive simulation that runs on SGI-UNIX 
platform. Are you saying that we could have built the 
same application for the web for half the cost? 
		 |  
		 |  
		| 
 Yep! In fact, 
you can build far better online-application that is 
more agile; it cost a quarter to maintain and takes 
quarter of the time to make large updates, if you need 
to adopt the application to frequently changing business 
needs. 
		 |  
		 |  
		| 
 Hey Dilbert’s 
out there, Don’t panic, when the over hyped AJAX/WEB2.0 
makes your pointy-haired boss or slick marketing guy 
tells you that they have already sold to the customers 
that next version of the 2D simulation application will 
run online, and tells you if you don’t do it, 
you will be fired. 
		 |  
		 |  
		| 
 No one would blame 
you, if you listen to the little red-guy with horns on your left 
shoulder and join competitor to build and deliver the 
online-application quickly to teach a lesson to your 
former pointy-haired boss or slick marketing guy. 
		 |  
		 |  
		
Have Fun, Earthlings,  E.T. Alien
		 |  
		 
		 |   |  
		 |  
		| 
 Please
let us give you a simple Example
 Imagine the complexity of
manually creating just one data-driven chart, with out using the reusable GUI Classes. For example, consider
the very popular Google’s stock quote chart
http://finance.google.com/finance?q=CSCO.
It has taken more than two years for Yahoo to respond. We don’t know how long it has taken to implement the chart, but we know it is in
Alpha/Beta for nearly 6 months
(i.e. Just one chart is not yet released to date as of Sep' 3rd, 2007).
 Any
one who built desktop GUI applications know: to build real GUI applications, one must include dozens of
complex data-driven GUI components. One must be able to hierarchically assemble
many real-time data driven custom GUI components as shown in sample SVG
webpage. Imagine creating this kind of applications without our
patent-pending GUI Classes and framework to build application by “hierarchies
assembling swappable modules (i.e. GUI components)”.
		  |  
		 |  
		| 
 Computer
Analogy to explain: OOP Vs. Loosely-coupled parts (*Useful*) 
Proof: Product-makers also would be in crisis, if they can't build Component-hierarchies
		  |  
		 |  
		| 
 Summary
for the 'Component-Oriented' programming
 If
one wants to invent component-oriented programming, what ought to be the
requirements or Objectives? That is, what the programmers must be able to do in
the component-oriented programming, which they could not do before? 
It
is not a complex question to answer, since the world already experienced two
programming paradigms: Structured programming and Object-oriented programming. 
The
structured programming allows developers to encapsulate related "data"
in an abstraction and it can be referenced through a variable. The Object
oriented programming allows developers to encapsulate related "data"
and "methods" in an abstraction and it can be referenced through a
variable. Each of the abstraction allows the programmers to build arrays
and hierarchies of Structs or Objects respectively. 
Likewise,
the "Component-oriented" programming must allow encapsulation of
related "data" & "code" for a component in an
abstraction, must allow referring through a variable. One must be able to use
the variables to build Arrays & Component-hierarchies. 
Is
there any advantages for the "Component-oriented" programming? 
The
product-manufacturing (e.g. computers & cars) processes are absolutely
component-oriented and reaping huge benefits. If they were not
component-oriented (i.e. no component-hierarchy), they would face similar
crisis, the software-makers are facing.  
For
example: The computer-makers end up building the "blended-devices"
computer, if they were not able to build component-hierarchy (e.g. assemble
devices to build each plug-n-play part). Each of the parts (e.g. Network-card or
Hard-drive) will be there. However each part is not encapsulated in a single
plug-n-play package. Instead dozens of devices belong to each part will be
spread across the large Circuit-board.
		  |  
		 |  
		| 
 Please
click here for a proof that there is a "Silver Bullet" 
Caution:
Please don't click on the link, if you can't spare at least an hour time!
		  |  
		 |  
	  |  
		 
           | 
         
        |