cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Fagnani-Bell <jus...@paraliansoftware.com>
Subject Re: PERFUME PROPOSAL: SOAP FOR COCOON
Date Sun, 22 Sep 2002 05:52:31 GMT

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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message