Hi Steven,
Interesting proposal - it reminds me of what I was thinking about a
month ago :-) Comments are below:
> 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 ?
> 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.
> 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 ?
> 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>
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 (!)
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.
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 ?
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 ?
Cheers,
Marcus
> 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.
>
> 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.
>
>
> SHORT-CIRCUIT: NEEEEED INPUT!
>
>
>
> Steven P. Punte
> Candlelight Software
> [EMAIL PROTECTED]
> 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: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
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]>
