cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Langham" <mlang...@s-und-n.de>
Subject AW: Heads Up: Cocoon and Web Services
Date Thu, 14 Feb 2002 09:37:01 GMT
Sam wrote:

>>
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.
<<
In a way a pipeline is a looseley coupled set of services in itself. The
major problem being that there is currently no way for a system architect to
find out if a particular chain of components "will work". That can only be
decided if the pipeline is actually published and then triggered from the
outside. There are no contracts between transformers.

We did some internal work on this and I would just briefly like to describe
what we did:

Imagine each Cocoon processing step as being a service with an input port
and an output port. A port can be described using a n XSL Schema. You can
then define transitions between ports using stylesheets (if necessary). A
service can be then implemented by say a transformer. Now imagine an
authoring tool that will allow you to visually build pipelines. This tool
can check whether the output port of service A fits the input port of
service B if they are chained together. If not then the tool demands that
the author provides a transition (like a stylesheet).

The output is then an XML description of the flow through the pipeline and a
special component (the FlowProcessor) then interprets the XML and calls up
the defined services as needed.

Now I am not saying this is how it _should_ be done (and indeed this may not
be a very standardized way of doing it). However, instead of having say a
FlowProcessor, is this not something that Axis is already capable of doing?

So if we were able to provide the Cocoon components as Axis 'handlers' (not
quite sure whether that should be handler, pivot, service or a
combination) - would it not be possible to use Axis as the FlowProcessor for
us - working on SOAP messages (for example).

If we compare the current sitemap/pipeline processing model with the way
Axis works (can work) - are there not many similarities? The least of these
being SAX probably.

I guess in the end what I am trying to say is that now Cocoon 2.0 is out we
need to look at ways we can enhance what it is capable of doing - and stop
re-inventing the wheel - if there are other projects that can help us.

With Cocoon being an ideal platform for XML publishing/applications and Axis
being an ideal platform for building Web services...there has to be
something more there...

Matthew

--
Open Source Group               sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
           Weblogging at: http://www.need-a-cake.com
=================================================================



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


Mime
View raw message