WoW - Why Applet Against AJAX

Why WoW Chose Applet Against AJAX?

Well, people never stop suggesting ajax for WoW so far. Sure, ajax is hot now, it can kill the Java 5 dependency, and will hopefully provide MacOS X users full access (till 1.5.0_06 version of Apple's JRE, WoW Traverser still can't fully work on MacOS, so bad :-().

But applet had been firmly decided from the start of WoW. I'm telling you why:

This is simply because ajax clients is going to consume more resources in web browsers, and I feel totally uncomfortable if any of my programs consumes any bit more resources while there is any less consuming solution exists, even though the higher costs are quite affordable by modern hardwares. I AM AN EXTREME ENVIRONMENTALIST! Any CPU usage and disk access will consume electric power drawn from the limited energy on earth, and ever heat our atmosphere! We are going to be swallowed up by the melted icebergs!

Okay, I'm kidding ha.

The Real Reason Is Architectual.

So do you think a Mind Mapping program could be a thin client? Anyway, I don't. A Mind Mapping client (so called a WoW Traverser in WoW's TSA term) has to be feature rich.

Encounting pure .java source code, 432KB common code out of total 1153.5KB (645KB client only code, and 76.5KB server only code) are reused between the server and client sides (for the WoW release at this writing). This is a rate bigger than 37%.

What this means? Well, if you write the client side code with ajax, assumes equal effort to implement the MindMapping functionalities (but do you really think AJAX is as handy in writing dynamic complex UIs as AWT/Swing is?), there will be 37% (432KB) code need to be rewriten in javascript, as well as corresponsive to their server side peers.

And what will happen in the further? Whenever you change or add node types/service APIs, you have to modify/write coupled code for both sides, in two different languages!

You might say: Why this has to be in this way?? The code at server side only implement service logics, and the client side code just invoke those services via their interfaces. It's just XML based web services invoked via HTTP as for AJAX.

Well, I'm going to disclose some incapabilities of a methodology long took for granted by programmers, from as early of the invention of Subroutine as for Assembly Languages. This methodology has been even inherited by the pioneer approaches trying to solve mass programming complexities such as SOA (Service Oriented Architecture).

That is the methodology of Invocation Based Interfacing. And don't bother to google this term, it's my invention, and quite self-explaining: Invokes to use other components.

I'm not to decry its value at all. It worked so long pretty well, until software developments get dramatically inflated by hardware capacity boosts in recent years, in addition of powered-ups by OOP (Object Oriented Programming) and many remarkable methodolgies succeed.

In a technology rich environment for software development and integration, the very trait of IBI (Invocation Based Interfacing) I would address here, which arises than solves problems is the need to define public, stable interfaces, which involves not only coding for APIs but also hardcore efforts for their specifications/contracts.

But Why and How NOT to define public interfaces??

This is all about new complexities come as services provided by software components go muti-dimentional, thus the work to abstract them into monolayered specifications becomes rather more complex than the components themselves. (Read on to get this meaning)

Well, it has been took for granted so long, and is extremely developed by the methodology of Interface Oriented Programming. Sure, it worked perfectly well and will continue to be the best approach for inside component design and development, and even for small to middle scale integrations.

But when come to mock up multi-dimensional components and applications, have you ever asked a question:

Is it still the best way and unavoidable necessary? To make components/applications work with all others by defining and invoking service interfaces?

I have. And after researches and studies, I concluded that: There is better solutions. The direct result and proof of concept is WoW's Traverser/Scener Architecture (TSA - http://www.webofweb.net/traverse/TSA).

We human beings like simplicities, but got no fortune as the mother nature is badly complex.

Several closely interrelated functionalities are combined into a single module, to perform specific tasks for a certain objective. In OOP, this is done by implementing a class with several public accessable methods exported to other portions of software applications. However, all of these have a common name: Application Programming Interface (API). Yes, Interface, which implies a monolayered common boundary, between two things. And this is quite descriptive when put within the abbreviation API.

Several functions/methods laid out at a same layer make it quite simple when looked from the outside. This is the TRUE simplicity gained from this approach, sure. This worked so long as experts kept abstracting interfaces out of hardcore implementations for all purpose functionalities, and application programmers ever happily invoking these interfaces in their applications to make them work as expected.

Until programmers started to feel harder and harder to understand these interfaces, and had to spend more and more time on studying the API Specifications, rather than implementing their own logics in the applications.

The method of "Abstracting Complex Functionality To Interfaces" came for simplicity, yes, old approaches even worked well for abstracted persistent data storages, the Structural Query Language (SQL) was invented to enable application programs to retrieve and manipulate data via simple expressions, a perfect example for a good Interface.

But things started to change as Application Servers and Integration Servers came in response to realworld needs.

If you never thought about how hard SUN had tried to drive and maintain the Java Enterprise Edition Specifications, and how much effort the community had spent on them, think about it now.

But you are going to take these costs for granted, because things always go this way. Good APIs always need specifications, while an open and firm set of specifications will benefit us all, they worth this much.

Please do not think I am kidding in order to tell you that there exists better solutions for the vast chaos of software component integrations here.

Well, let's begin by looking at changes to Software Components (in a generalized concept) since end of the Golden Age of Invocation Based Interfacing methodology.

We take the example of Web Feeds Syndicator compared to Generic Dictionary.

Generic Dictionary is a primitive building block for useful softwares and has been widely implemented by almost any middle-level to high-level programming languages, for Java, the Map interface and its various implementations.

Web Feeds Syndicator is a relative new thing, but quickly became popular since the WEB 2.0 phenomena.

Note: Rest contents from here on need further detailed later, sorry for the incomplete work by now.

States and logics are never plain and monolayered, they grew up to mutidimension.
Their internal states turn not be clearly predicatable, can change according to more factors, than pre-defined operations within a single public interface.
They act more Roles out facing different aspects of their relatives.
They need to run constantly, not only on demand.
They may in a remote environment, when perform some operations, you may would do them as a whole in their local environment, instead of several call-return rounds.

Hosting Based Interfacing

Well, HBI is not an entirely new thing. Think of writing Stored Procedures for a Database System, a good example of HBI. Where applications can send their own packages of operations to be run by the server inside its environment. In addition to the normal invocations via SQL or other Invocation Based Interfaces.

A database server just Hosts the Stored Procedures with its own execution environment.

But Stored Procedure is too specific to database systems. When comes to generic interfacing between software components, we'll need some new concepts.

Task Agent: This is rather an Object Oriented saying, a Task Agent is an object which can be sent from one components to another component, by which this TA will be further Hosted to perform its destinated duties.
It's optional for a Task Agent, during the hosted execution, to produce new Task Agents, those are to be sent back to its sender component, or other components whatever known.
Task Agent Bus: The infrasturcture to allow transmissions of Task Agents between Software Components.
Task Agent Hosting: The act that a Software Component prompts to do on receiving and realizing Task Agents those take it as the target component.
Hosting Environment: Multi-dimensional execution context within which Task Agents will be so Hosted for their executions in order to complete their destinated duties.
This is the essential part why HBI is superior than IBI in solving inter-component interfacing. An environment can be rather more complex than any pre-defined monolayered method set. An environment doesn't anymore need complex specifications for different behaviors of a single method under different states. Instead, multi-dimensional objects, and their specific monolayered methods are used to express particular semantics.
And when the communicating components are distributed, compound logics need no call-return rounds to complete as a whole, thus intermediate states between these rounds don't anymore need to be maintained, as they are encapsulated by Task Agents. This greatly eases the transaction management.

In one word: Hosting Based Interfacing allows you define complex, multidimensional services provided by software components as in its native form, no more need to abstract them into monolayered specifications, which are obviously costly, even more complex to design as hard as to understand.

In WoW's Traverser/Scener Architecture(TSA):

Subclasses of Submissions and Guidances can be seen as Task Agent.

XT mechanism can be seen as Task Agent Bus.

And the Scener and Traverser at server and client sides respectively are Software Components those Host Submissions and Guidances respectively. Though they are unidirectional.

While the scener environment at server side is quite lightweighted since the use of TOB, which manages persistent object topograph with transient states seamlessly.

The traverser environment is rather complicated since the complexity of Mind Map interfaces.

But Still Why Not AJAX?

Well, traverser side JavaScript objects could have been implemented as peers to scener side Java objects, this is possible.

But this increases the complexity, to maintain transmissions of objects in logical, from in one language semantics to be in another. We are able to develop a framework for this matter, but this need much effort, and better left for future enhancements.

In the Java with standard SAX infrasturcture right in hand, transmitting Java objects through SAX events seems the most intuitive and elegant, so finally WoW stuck to Java Applet.