>> Giacomo wrote: >> [havn't found 'ossimoron' in my dict(?)] I think he meant oxymoron.
http://www.dictionary.com/cgi-bin/dict.pl?term=oxymoron Like "military intelligence" or "jumbo shrimp". I've thought about this problem a little bit, but probably not with the same depth or set of requirements as all of you. I think if you can come up with a design that solves the SOAP problem, it will be generalizable to other protocols and request types. And I'd *love* to see a solution that addresses SOAP...if Cocoon can do that eventually, it will become THE complete web services AND publishing AND XML processing platform. To throw more terminology on the fire, what if the inbound counterpart is: Deserialize --Takes any inbound request and turns it into a "virtual" Request that permits other objects in the pipeline to operate upon the data in a standard manner Dispatch --Schedules, dispatches, invokes any actions that need to be taken to fulfill the virtual request. This could include the reverse of aggregation (disaggregation?) to cause multiple threads of processing to occur. Processing, in this case, is the invocation of the appropriate actions which have been registered Act --The target of the dispatch stage, where an action is taken upon the request. There could be multiple actions chained together serially, or they could operate in parallel. One action could be deemed the "exit criteria" which then handed control to an outbound pipeline for response There could be a number of Deserializers; by far the most commonly used one would be a simple HttpRequest Deserializer that created the pseudo-HttpServletRequest structure. But others might exist for things like SOAP. These would pre-process the request (e.g., parse any embedded XML) and create appropriate representations in the virtual Request. The Dispatcher classes might implement flowmap/statemap behavior and any conditional processing that could occur as a result of the request. A Dispatcher would invoke 0 to many actions to complete the processing; these actions could do anything from store values in the session, prepare an FTP connection, satisfy a SOAP request, send an email, etc. At the end of this step, a "ResponseAction" could choose to hand over control to the sitemap's outbound pipeline processing. You'd then get Actions completely out of the outbound pipeline production and put them on the inbound side of the fence, along with a richer way of ordering them. I don't think this is any different than what you've been discussing, but the terminology might be a little more clear. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
