On Saturday, September 21, 2002, at 05:37 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... > 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. > 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. > 2) The intended usage is: > > a) If one wishes to implement a soap service, > a pipeline beginning with the generator > and ending with the serializer is > constructed. > > b) If one wishes to implement a soap client, > a pipeline with the transformer is constructed. > > 3) Construction: > > It seems to me there are really two fundamental > modules to this effort: a module that converts > a sax stream to HTTP-SOAP, and a module that > convert HTTP-SOAP to an xml sax stream. Both > modules are used twice in the overall project, > both being used in the transformer component. > > 4) Issues: > > a) First, how does this proposal sound to you? > Is this the type of soap implementation you > would like to see? > > b) Are any of the existing cocoon soap related > software suitably reusable and appropriate > here. > > c) Is apache soap/axis suitable for use here? > My preliminary examination of these packages > are they overlap too much with existing > cocoon to be easily integrated. > > 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. > e) Should WSDL be incorporate into this proposal? > Please someone correct me if I'm wrong, but > don't WSDL and XmlSchema do almost the same > thing? It seems like most of WSDL was a early > solution before XmlSchema became ready. I think > ebXml also makes no reference to WSDL. > > 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. --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]>
