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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
