cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Punte <steve17...@yahoo.com>
Subject Re: PERFUME PROPOSAL: SOAP FOR COCOON
Date Tue, 24 Sep 2002 00:15:46 GMT
> > PERFUME PROPOSAL:  SOAP FOR COCOON
> > 
> > For the web application project I'm orchestrating,
we
> > wish to add commercial quality support for SOAP 
> > messaging: both act as a client and as a server.
> > 
> > I have examined the existing soap client package,
> > and new soap package, but I'm uncomfortable with
> > them because the former is xsp based, and the
later
> > is implemented only as a reader.
> 
>     Is there something the reader currently
prohibits you from doing ?


	My anticipated application solution will probably
have two or 
	three XSL transformation steps, one or two SQL, and
possibly
	a custom transformer or two.  It is a style of
software architecture
	I call XML-Directed Software, and it seems highly
suitable
	for creating soap services.
	
	I'm under the impression a reader cannot do this. 
That somehow
	a reader is first, last, and all elements of a
pipeline.  Is
	this true, or am I misinformed?


> 
> > It is my opinion that Cocoon needs components that
can
> > 
> > play well together, and can be mixed and matched.
> > Therefore, I'd like to propose a package I call
> > "PERFUME."
> > 
> > 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.
> 
>     StreamGenerator ?
> 
> >               b)      A serializer that can
convert an xml
> >                       stream into a return soap
message.
> 
>     XMLSerializer ?
>     
>     or do you mean a serializer that can magically
convert something like:
>     
> <memory>
>   <total>123123123</total>
> </memory>
> 
>     into:
>     
> <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>  <soapenv:Body>
>    <ns1:getTotalMemoryResponse 
>
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";

> xmlns:ns1="Cocoon-JVM-Memory">
>    <getTotalMemoryReturn
xsi:type="xsd:long">123123123</getTotalMemoryReturn>
>  </ns1:getTotalMemoryResponse>
> </soapenv:Body>
> </soapenv:Envelope>  
> 
>     If this is the case, note that the serializer
requires knowledge of the
>     request content to build up the response xml
structure appropriately,
>     and also how it should convert the first xml
document into the second.


	Yes, it does looks the StreamGenerator and
XMLSerializer could do
	the job.  Handling errors according to the SOAP
standard may
	be a bit difficult, but it seems like these two
components 
	should handle the more straight forward situations.
	
	 
> >               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.
> 
>     Yes. Something like this is on my TODO list at
the moment. I was
>     considering reusing the markup from the xsp tag
lib - did you see any
>     problems with that ?


	You tell me?  I haven't downloaded your client code
yet.  The question
	is whether your approach is too "reader" oriented to
be metamorphosised
	into a transformer.
	

> 
> >       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.
> 
>     How will this actually work for the end user
though ?
>     
>     Lets look at a simple pipeline:
>     
>     <map:match pattern="soap-service">
>       <map:generate type="stream"/>
>       <map:transform type="..."/>
>       <map:serialize type="xml">
>     </map:match>


	You pipeline above is exactly what I'm think of for a
soap-service!


>     
>     So the real work of doing the service is done
during the transform stage,
>     which means the end-user will have to write
their own transformer/s to
>     convert the soap request into a soap response,
manually parsing the
>     input soap document (!)


	Yes, but Cocoon components like SQLTransformer and
XSLTransformer are
	good at this tasks. My biggest concern is that they
are NOT good
	at handling errors, for example if someone sends the
wrong message
	to the wrong port.


>     
>     That could be simplified by writing a
SOAPTransformer that provides a
>     framework for calling a user defined class to do
the work and return the
>     results, but that's actually the same as the
current AxisRPCReader - just
>     that in the case of the reader the explicit
generation and serialization
>     stages are removed from the pipeline.


	Again, see comments about XML-Directed Software.  The
key concept is
	to solve the problem in the framework of a stream of
XML transformer
	components.  Is this new, and is the present
available arsenal of components
	small?  Yes.  But I believe that XML-Directed
Architectures are the future of 
	software.


>     I get the suspicion that the generator and
serializer do more than simply
>     convert between http-post -> sax ->
http-response ? If this is right can
>     you elaborate some more about what they should
do ?


	Sorry, I can't elaborate on your suspicions, I am not
yet that experienced
	with SOAP, but I share your suspicions.  In
particular, I suspect that
	error handling is the main requirement that falls
out-of-bounds with
	the most simple approach as outline above.


>     The benefit the reader has is that it uses Axis
to do all of the work, 
>     just as if your service has been written for
Axis exclusively. You just
>     write your business logic as a normal class and
that's it.
>     
>     If there's a specific need for it, we could move
the reader to a
>     transformer - I couldn't find any reason to do
so at the time when I wrote
>     the reader though - is there some example you
have that needs this ?

	Yes, I feel I do.  Could you outline for me what it
would take to
	wrap a transformer around Axis so that it can behave
as a client
	in a Cocoon Xml pipeline stream?
	
	
	Thanks for all your comments:
	

Steven P. Punte
Candlelight Software
stevep@candlelightsoftware.com
http://www.candlelightsoftware.com

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

---------------------------------------------------------------------
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