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 [EMAIL PROTECTED] - http://www.s-und-n.de Weblogging at: http://www.need-a-cake.com ================================================================= --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
