cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: Heads Up: Cocoon and Web Services
Date Thu, 14 Feb 2002 00:36:03 GMT
Giacomo wrote:
>
> The Axis commuity is very resistant to technologies like Avalon as Berin
> has tried to convince them many times :\

Rant mode on.

Slow down.  Actually, the more I think about it, stop altogether.  Let
understand what problem we are trying to solve before we proceed with cries
for the Avalonization of Axis.  In fact, take a deep breath of a good
helium/oxygen mixture as we are about to take a deep dive and I don't want
any heads exploding here.

Lets start with the concept of a pipeline.  Forget the limitations of an
individual JVM.  Forget the limitations of the language.  Forget the
limitations of your processor.  We are now defining a pipeline that spans
space.  A pipeline that also spans time.  In fact, it is nodes in the graph
need not only be computing resources, they can often be the invaluable
albeit unpredictable squishy entities that we call Homo Sapiens.  The unit
of exchange between these nodes are called documents.  If you can grasp
this picture, you understand the motivation for WSFL
(http://xml.coverpages.org/wsfl.html).

Now lets drop down a level.  Imagine a system architect trying to design
such a pipeline.  As much as possible, he or she needs predictable nodes.
They expect messages that conform to a set of preconditions, do some useful
processing, and may produce messages that have known shapes.  How would you
like a world in which the return type of every method was "Object"?  The
intent of my previous question wasn't to ask if there was an algorithmic
way  in which the schema of the output can be determined, what I am more
interested in is how such definitions would fit into the Cocoon way of
structuring such a pipeline.

Dropping down a level again, lets look at individual messages.  They are
rather simple.  They have an envelope, a single body, and a variable number
of headers.  Headers are meant to convey contextual information, such as:
identity or signatures, transactions, or routing.  In fact, it is at this
level that digital signature processing provided by Apache's xml-security
fits in.  In Axis, the way such logic is snapped in is via handlers.  Their
primary purpose is establish the context so that the engine that processes
the body can focus on what it does best.

Dropping down a level again, the body is essentially processed as a series
of SAX events, intended to be evaluated in a system where the context is
already established.  The processing could invoke scripts, interact with
databases, or be a series of simple transforms.  Truth be told, Axis
doesn't care.  Separation of concerns and all that.  In fact, Axis doesn't
even require that the inputs or outputs conform to the declared schemas,
such information is intended for the consumption of the overall system
architects.

Given this context, do we know of something that excels at transforming a
document into another document via a series of transformations that
interact with the environment?  You talk about Separation of Concerns and
Inversion of Control... could you envision such an engine executing in the
context of the container that is Axis?

 - - - - -

This is but one topology by which Axis and Cocoon could collaborate.  A
much simpler topology is one with an XML database like Xindice in the
middle.  It is represents the persistent state of the system.  Cocoon
publishes from this source.  Axis services requests that interact with the
database.

 - - - - -

What problem are we trying to solve here?  Instead of starting every
conversation with "but first Axis must be Avalonized" and then disappear
muttering tsk, tsk, tsk sounds , take a moment to understand both Cocoon
and WebServices and explain how you see these concepts fitting together and
what the appropriate steps are to making that a reality.  And as this is
Open Source, focus on what part of the solution you wish to contribute.

Rant mode off.

- Sam Ruby


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message