cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Fagnani-Bell <>
Date Mon, 23 Sep 2002 08:05:22 GMT

On Sunday, September 22, 2002, at 08:54  PM, Steven Punte wrote:

>>>       1)      The implementation of Perfume shall result
>>>               in three distinct Cocoon components:
>>>               a)      A generator that can receive a soap
>>>                       message and turn it into an xml sax
>>>                       stream.
>> Why not use an Action? Then you could set sitemap variables, call 
>> other
>> actions, use an existing generator...
> 	Please elaborate more here.  I've only written one action component 
> so far, that is used to set a sitemap
> variable. How would an action component take the place of a generator 
> component.

My first reason for not using a generator to handle the SOAP request is 
that it doesn't quite fit into the role of generators, I think the 
generator should be used to create the response.

But the real problem I see here is how to do something useful with the 
SOAP request. Once you receive the request you've go to do something 
with it. If all you have is a SOAPGenerator and a SOAPSerializer, then 
all you can so is put some transformers in between them to turn the 
request into a response. You wouldn't be able to do a whole lot unless 
you wrote your own transformer. With the built in transformers the most 
complex thing I could see doing in using an XSLTransformer and the an 
SQLTransformer to do a database lookup. If you want to perform some of 
the functions that are typically done with Actions or flowscript you'll 
need Actions.

If you had a SOAPAction though, you could take information about the 
soap request and place it into sitemap parameters, from there you could 
use those parameters with selectors to choose appropriate pieces of the 

It's kind of analogous to the difference between RequestGenerator and 
RequestParamAction. RequestGenerator is useful for using the request 
parameters and headers in the output, but RequestParamAction is what 
you normally use when you need to setup parts of your pipeline based on 
the request.

>>> 	        b)      A serializer that can convert an xml
>>>                       stream into a return soap message.
>> Would the current XMLSerializer work for this? I'm not that familiar
>> with SOAP, but I was under the impression that it was xml documents
>> sent via HTTP.
> 	This is an interesting question.  I have a sneaky feeling that
> 	SOAP, especially originating from M$, has additional implied
> 	requirements than simply XML (i.e. setting HTTP parameters).
> 	It is just a suspicion at this point in time, and I'm hoping
> 	some more experience developers can comment here.

I'm not aware of too many important HTTP response headers besides 
content-length, redirect-to, and mime-type. I'm not that knowledgeable 
about it though.

>>>               c)      A transformer that can act as a soap
>>>                       client.  Incoming xml is transmitted
>>>                       as a soap message, the pipe is blocked
>>>                       until return or time out, and then the
>>>                       received message is returned into the xml
>>>                       sax stream.
>> Sounds nice. You could keep the piece that transforms the sax stream
>> into soap separate from the soap client. That way you could just use 
>> an
>> xsl stylesheet, or any other transformer, to create the soap and it
>> would be more controllable by the end user.
>> Another thought is to have a SOAPAction that does a similar thing, 
>> this
>> way you could receive a request, access a soap server, then setup the
>> pipeline based on the results of the soap request. And maybe there's
>> even a way to integrate this with flowscript so that flowscript can
>> perform actions based on incoming soap, or you could access a soap
>> service from within flowscript.
> 	Where can I find out more about flowscript?

Got me. I followed the discussion of the dev list for a while, but I've 
never played with 2.1 and there's no doc that I've found yet. I guess 
download 2.1.

>>>               d)      It seems like the generator and serializer need
>>>                       potentially an out-of-pipeline connection with
>>>                       each other.  Or that some method of the 
>>> generator
>>>                       conveying forward a soap related error to the
>>>                       serializer is needed.
>> If it was a soap action rather than generator it
> could set sitemap parameters, or fail.

> 	An alternate strategy is to require certain xml fragment(s), like an
> 	error structure, be propagated forward from the generator to the
> 	serializer.  Both strategies seem to require some participation on
> 	the user.  I'm wondering if there is a more robust strategy.

Marcus' reply to your post is interesting. Like I said, I don't know 
much about soap, but if the response needs to formatted acording to the 
request then some coordination will need to happen. There a few ways to 
do this; sitemap parameters, though the sax stream, or by placing 
objects into the request object or a context.

>>> 	              f)      Should the soap-client transformer be able to
>>>                       execute multiple soap request to different
>>>                       services and not just one action?  Probably so.
>> You could chain the transformers, or use an aggregator for this.

> 	The drawback to chaining transformers is that how does the original
> 	soap document specify which soap request is to be executed by
> 	which soap transformer.  Seems messy.

hmmm... you could use an XSLTranformer to format the stream into a soap 
request, the the SOAPTransformer performs the request, then another 
XSLTransformer transforms the response into a new request and send it 
to a second SOAPTransformer.

> 	How would an aggregator work here?

An aggregator would take several generators and send their output 
through SOAPTranformers in parallel, as opposed to the serial approach 

I'm quickly running into my ignorance of soap with this discussion 
though, so my input may be a little flawed.


Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message