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