> 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...
Please elaborate more here. I've only written one
action
component so far, that is used to set a sitemap
variable.
How would an action component take the place of a
generator component.
>
> > 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.
This is an interesting question. I have a sneaky
feeling that
SOAP, especially originating from M$, has additional
implied
requirements than simply XML (i.e. setting HTTP
parameters).
It is just a suspicion at this point in time, and I'm
hoping
some more experience developers can comment here.
But using
>
>
> > 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.
Where can I find out more about flowscript?
> >
> > 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 tan generator it
could set sitemap
> parameters, or fail.
An alternate strategy is to require certain xml
fragment(s), like an
error structure, be propagated forward from the
generator to the
serializer. Both strategies seem to require some
participation on
the user. I'm wondering if there is a more robust
strategy.
> >
> > 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.
The drawback to chaining transformers is that how
does the original
soap document specify which soap request is to be
executed by
which soap transformer. Seems messy.
How would an aggregator work here?
Steve
__________________________________________________
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]>
