> -----Original Message-----
> From: giacomo [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 08, 2002 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Dispatcher/Adapter
>
>
> On Thu, 7 Feb 2002, DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) wrote:
>
> > Hi,
> > I feel that the tension of release is over, and we can return to the
> > discussion on my proposal. I propose to add to the Cocoon project
> > Dispatcher/Adapter concept. This set of interfaces and
> basic abstraction
> > allows building pluggable extensions in a more standardized
> way. The real
> > life example of such extension is our HP-SOAP Server. (You
> can download it
> > from http://www.hpmiddleware.com/download.) But it is just
> one example, the
> > imagination can bring much more.
>
> I still have your previous mails marked as "important to answer" in my
> mailbox, so expect some comments.
>
> > To refresh your memory the proposal, demo , patches and
> additions can be
> > found at:
> > http://soap.bluestone.com/proposal. The real HP-SOAP server
> in action can be
> > accessed by:
> > http://soap.bluestone.com/hpws.
> > Please note the combination of Cocoon publishing
> techniques, XSP pages used
> > as client forms to access SOAP services, with processing
> capabilities.
>
> This is exactly what I like Cocoon to be able: Act as a SOAP server as
> well as an (Web)App Server and a publishing system and all parts can
> communicate together. It doesn't make sense to me to have an isolated
> SOAP Server built into Cocoon which from an XSP has to be called via
> HTTP (you better deploy Axis for that solution).
>
> I've looked at Axis since a while. What I like best is their client
> infrastructure (WSDL2Java, custom transports, etc.). Thus I'd really
> like to know what your answers to Sam's question about
> interoperability
> is with your Cocoon SOAP implementation.
The interoperability for axis client is quite good - one item is failing and
we cannot reproduce it.
When we sent exactly this same request it is working fine (?)
The Apache soap client does not interoperate well but it looks like Apache
client problem, not implementation of the soap, if the benchmark is axis...
>
> What I don't like is the server side architecture (from a Cocooners
> point of view). If you look at the picture in
> AXIS_HOME/java/docs/MessageServerPath.jpg you are likely to
> see a cocoon
> pipeline from the Request to the Response. Axis calls them
> Input/Output
> Chain of Handlers. But those Handlers don't have anything to
> do with SAX
> ContentHandler (Axis hides SAX handling deep inside by a few calsses).
> And thus I still cannot see how to integrate Axis into the Cocoon
> architecture as I think they differ too much to be worth refactoring
> Axis parts as much to make an Axis Server fit into Cocoon.
>
> I'd also like to hear Dims and Berin (as they should know quite a bid
> more than I do about Axis) if you guys see how to integrate it.
>
I like to make clear that my first step proposal is a base which can be
expanded. We did expand it and created SOAP server, but the value of this
abstractions is the ability to be expanded. The fact that the SOAP server
can be done on top of Cocoon is the showing the power of it.
> Giacomo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
