potential invasion of cocoon and avalon developers... ;-)

[Sam Ruby <ru...@us.ibm.com>]

Cocoon2 supports soap today via SOAP 2.1, and they were looking into adding
support for WSDL.  Based on the thread below, they were starting to look
into adding WSDL2Java support.  I seem to have convinced to see if what is
being created in Axis can be adapted to their needs before they go
reinventing.

All of my prior experiences with the cocoon team have been positive - in
general, they hate to reinvent; but have strong opinions on how to make
things pluggable and scalable.  I think this would be a good thing.  ;-)

- Sam Ruby

---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 09/05/2001
02:05 PM ---------------------------

giacomo <gi...@apache.org> on 09/05/2001 08:50:14 AM

Please respond to cocoon-dev@xml.apache.org

To:   <co...@xml.apache.org>
cc:
Subject:  [RT] Cocoon and WSDL [was Re: AW [LONG]: [C2] Providing and using
      soap services]



On Fri, 11 May 2001, Matthew Langham wrote:

I have some time to give answers and vision on stuff I've marked
as important since weeks.

> Hi Michael,
>
> I have been looking into Cocoon / SOAP for a few weeks now and this is
what
> I have done up to now:
>
> I built a transformer for a specific SOAP service (using Apache SOAP 2.1)
> and integrated that into our Cocoon based platform. So basically Cocoon
acts
> as the SOAP client for that service. Take a look at
> http://sunshine.sundn.de/sunshine/soapbid to see what I did.
>
> Using the SOAP interop stuff the SOAPbuilders have set up I was able to
test
> this against services built with Apache SOAP and also .NET, MS stuff and
> even exotic versions such as EasySoap++ or HP SOAP. There are a few
> interoperability issues between the different SOAP versions - but that is
> more of a theme for the SOAPbuilders mailing list.
>
> Anyway that works fine and means you can uses Cocoon based solutions to
> connect to SOAP services - if you write the corresponding transformer.
>
> A better solution (IMO) would allow you to access the WSDL description of
> the service and generate the connector (transformer, whatever) from that.
> This could be a one time process - done using XSP or XSL - or whatever.
This
> would then give you the Java class for a transformer (we like
transformers
> :-)) that you would then compile and hook into your Cocoon scenario.
>
> Of course a generic component that could access any service based on the
> WSDL would be cool - but at the moment I dont see how that will work if
the
> service needs compound objects (such as an array of objects). Then you
need
> to set up your own serializers inside the SOAP client - and I dont think
> that can be done in a generic fashion (but I maybe wrong on that).
>
> Using Cocoon as a server base for SOAP services is more difficult to
> answer - one way would be to provide a service that accepts requests for
> certain resources in Cocoon. The class then calls the resource inside
Cocoon
> (via http) and sends the response back to the SOAP client. I am currently
> not sure why you would want to do that (you can access the resources
> directly via http).
>
> Using Cocoon as a server that accepts SOAP envelopes and then passes them
on
> to components to be acted on would seem an alternative. However why would
> one then not just use the same "server" to register the SOAP services
> themselves.

This is what I'd like to start soon. Using WSDL as a base description
for Cocoon web services.

The WSDL types section descibes objects which can be generated into java
source code. These sources should be in accordance to the JAXB
architecture (unfortunately the RI so far uses DTD without namespaces
and is not usable for that). This results in marshallable/unmarshallable
and extendable objects usable in the service logic parts and also can
easily put down the pipeline.

The rest of the WSDL (message, portType, binding and service section)
describe different objects. One part are objects I call connector and
responder. Connectors are responsible to accept a request and transform
the input into objects described in the type section and suitable for
the services common to all bindings (SOAP, HTTP, etc.). Thus an ideal
part for actions. Responders on the other side transforms WSDL type
objects into a format suitable to be rendered as responses back to the
requesting clients (to SOAP, HTTP, etc.). Some information can be used
to generate the java interfaces for the services which average java
programmer should be able to implement without knowing additional
techniques from the XML domain. And finally sitemap snippets as well as
XSP logicsheets could be generated because the WSDL contains almost all
information needed for it.

Any comments?
Any intrests in realizing this together?

Giacomo

>
> >>
> I could use some comment right now.
> <<
> There you go (for a start).
>
> Matthew Langham
> Technical Director Open Source Group
> s&n AG, Paderborn, Germany
>
> --
> Open Source Group               sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel: +49-5251-1581-30   [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
>
>
> -----Ursprüngliche Nachricht-----
> Von: Michael Homeijer [mailto:M.Homeijer@devote.nl]
> Gesendet: Freitag, 11. Mai 2001 13:03
> An: 'cocoon-dev@xml.apache.org'
> Betreff: [C2] Providing and using soap services
>
>
> I am in the process of defining a reference architecture for my company
(we
> did a very successful project with C1) for e-business and web publishing
> applications. Cocoon2 will play a role in this architecture.
>
> Until now we planned to use SOAP to access EJB beans, but with the new
> Cocoon2 stuff, I think it would be great to build SOAP services and call
> SOAP services with Cocoon technology. I'd like to implement a prototype
for
> this, but could use some help with it, basically with design decisions,
and
> if anybody is interested, with coding.
> The main question is, how does this fit into the Cocoon architecture?
>
> - Calling soap services
> I think it could be possible to have the syntax of this look like a
standard
> soap envelope and have it parsed by a logic sheet into java code:
>
> (Copied from xmethods.com, weather - temperature services, id = 8)
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/1999/XMLSchema">
> <SOAP-ENV:Body>
> <ns1:getTemp xmlns:ns1="urn:xmethods-Temperature"
> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
> <zipcode xsi:type="xsd:string">94041</zipcode>
> </ns1:getTemp>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
> This should be wrapped in a call tag that defines the service to call,
and
> possible what to do with the response envelope (I cannot find a standard
for
> this tag, so I assume i must define one myself). I don't think the
response
> should automatically be output in XML, because in the case of using
services
> you probably want to add some java processing of the result. Options
could
> be to output the result directly or to store it in a variable.
>
> - Providing soap services
> I am stuck with this one, should I write a soap generator (and if i do,
> could i still use XSP to build the soap service) or should I write a
logic
> sheet that does some processing.
> If cocoon is allready able to handle the soap request, could someone
explain
> this or send me some sample code?
>
> I could use some comment right now.
>
> TIA,
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org