ATANA - Autonomous Transforming Asynchronous Node Architecture

An attempt to model any software as a collection of XML transforming nodes S V Ramu (2002-06-08)

Meta Prelude

This article is a continuation to few other earlier articles, on the importance of
imagining the whole application as a web of data transforming nodes. This is already
used successfully in the web server scenario by
Cocoon.
In fact Cocoon brings alive
the possibility of generalizing any software as piplines of XSL transformation.
In an earlier article,
while discussing about the interesting
future of treating everything as XML, and in
other times
the idea of assuming functionalities as standalone nodes connected suitably
to form the whole application was very satisfying and promising.
Then why not push this grain of future
possibility now?! That is what this article is trying to do: To elaborate this
'pure XML-XSLT' based architecture, and see how far we can escape OOP/Java for
business logic. Not knowing Cocoon fully, this exercise might as weel turn out as
just the explanation to it. But, that is fine enough. What we want is a simple,
distributed and extensible way of looking at an application. If Cocoon is already
that, we can adopt that and proceed further. By the way, if this idea is appealing,
we will make this is as an early member of the new PoPP (Proof of Principle Prototype)
Archive that we are planning at TATTVUM.

The Architecture

As far as I know, this is exactly what Cocoon is doing. Except that I haven't
explored all its potentials and limitations, so cannot quote it for reference, except
reuse the terms like generators, serializers, etc.
Also, it is point less to wait for someone else to provide for us. Somewhere,
without worrying about false starts we have to clear our own dreams. In that sense
this article is an attempt to spell out as clearly as possible, what is really
needed in an architecture. Because without that being clear, we won't recognize the
good thing that is out there, even if we see it. This is just an active way of learning.
Instead of just trying to understand what is there, we try to define what we want and
start finding that. In that process, if an already existing thing answers our
question, we can pick it up and proceed further with new dreams. If there is no
answer for our unique question, then we create one. If you are mentally prepared,
this simulated rediscovery is very beneficial and always keeps you meaningfully busy.

More Developers - The prime goal of an architecture

When groping with the question of, 'What should I design?', the following approach is
very satisfying. The stress on parallelizability of a development process is not
much recognized. But, this could as well be a cool metrics to measure the merit of
a planning process.

The goal of designing a solution, is two-fold. One, to meet the requirement, of course. And
two, to maximize the possibility of parallel development through modularity. I think the
second is not recognized in such explicit terms. To make it bit more dramatic, the abstract
time line and abstract job assignment, should be furnished only by the architectural team,
and not some non-technical project manager. How could the managers know the possibility
of parallelism in the design? Their role is only supportive. Their job is to make the
timeline concrete with exact dates, and the job assignment concrete with exact names,
and then ensure that all these go along smoothly, and the real-time problems are properly
abstracted and given to the architect team for solution. This is the only way that
introverts and extroverts can coexist. People with mixture of both can be the nexus
people (spokespersons) or the manger of the whole project.
(Axioms of Software Business)

I used to dream about something like ODOPOT. It is, One Day, One Person,
One Task. At that time I myself new that I was not ready for that, and my colleges
did well to warn me that this is ambitious. Of course, it never got implemented.
Still, this is the goal that keeps one in track while evaluating a new silver bullet
of my own dreams or of others. Can an architecture allow us to think about the application
in a way, that will automatically decide about the number of ODOPOTs
required by the project? Like
Testable Requirements, ODOPOT too promises
to be an interesting way to look at the project size, and especially development.

Autonomous Node

Each ATA Node could be considered as a standalone and asynchronous XML aggregator
and XSLT converter. Thus if properly granularized, each node could very well be the
a unit Task for one person, and might even be for one day.
The luring point is that, a XML ATA Node is very well defined. We can tell what XML
inputs are there, what XML output we need, and what all XML configuration parameters
are there. The developer's task is to write the conforming transformation code.
Here, my take is that XSL could very well be the only language required, to the
exclusion of everything like Java or C++. This is what the PoP implementation will
latter try to test. Pushing this idea further, we can imagine that a group of related
XATANs (XML ATA Nodes) could be assigned to a group leader, with the well defined
list of XML inputs and XML outputs.

Thus each node should and can mind itself and itself alone. The Input, Control and
Output (ICO) being well defined, this is very much possible. This feature of the nodes
is very important for delegating the whole node to an individual developer. If this
node has too many configurable controls, and a huge input, or huge output, this
could be further zoomed in to a mini web of XATANs. This means that we can start the
application as a set of ICO of XMLs, and then break them into smaller XATANs, as we
go along. This is an autonomous and highly delegatable feature.

Transforming Node

In these early days, where XML based screens (XUL) is still
in their formative periods, there will be need for building such standard XML generators,
Serializers, and maybe even some Transformers. For these we might use Java or
C/CC++, but never for the application logic. Only these reusable parts
need conventional programming. The new data flow being fully in
XML, could be transformed with XSLT alone, with some support for routinely merging
of two or more XML as needed.

Any node is only a data transforming node. Whether we use XML or not, this true for
any conventional module based thinking. But when you use XML to define your Input,
Output and Control, the XSLT immediately presents itself as the best candidate for this
purpose, and thus making it clear that a XATAN is basically a transformation node.

Asynchronous Node

With all the hoopla about Network being the computer, P2P coming up in a
big way, and of course the hype on hype about Web Services, it is becoming clear
that the modern paradigm of programming has to include time delays and parallelism
as their main stress. A XATAN (rhymes with SATAN!) could be considered as a place where
time stops and moves in its own pace. How should the XATAN to XATAN's communication
be? If we assume that it is asynchronous, then how should we best model the
event/interrupt based programming in XML? If the calls are synchronous, how
to handle that with XML alone? These are important questions that have to be answered
while working on the prototype.

Keep Java in the background

I mean, keep all the traditional programming in the background. The idea is to use
Java or such like only for generating XML from non-XML sources. For XML to XML
transformation, use only XSL (which again is pure XML). How can we model the
inter XATAN calls with XML alone? How are we going to handle synchronicity with
XML alone? These are open questions right now. With Cocoon like examples (where
the XSP like custom XML scripting does the job), we must find a pure standalone
transformation based idiom. The goal is to completely avoid traditional
programing, and use only XSL and our custom declarative model.