On Thu, 29 Nov 2001, Chris Finn wrote:
> >> 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.
Yes, many of us know that.
> 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
This is one of the possibilities we already have today (but not in a
really architectured way).
>
> 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
This is what we have as action-set today. But yes, Actions always execute
before the pipeline. This is the point I was mentioning in my previous
mail.
> 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
thats the same as Berin outline from the Axis design:
Request
+---------- inbound pipe
+---------- Actions
outbound pipe ----------+
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.
This is the case already Actions ARE out of the outbound pipeline today.
No matter how hard you try any action selected by the sitemap engine is
executed immediately. The outbound pipeline always runs afterwards when
all parts for the outbound pipeline are collected.
>
> I don't think this is any different than what you've
> been discussing, but the terminology might be a little
> more clear.
Oh, cool, you see it the same way as I do.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
