On Sunday, September 22, 2002, at 08:54 PM, Steven Punte wrote:
>> PERFUME: >>> >>> 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 pipeline. 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 above. I'm quickly running into my ignorance of soap with this discussion though, so my input may be a little flawed. -Justin --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
