Hi,
>>
I thought of starting a separate project for that because parts of it
are not tightly bound to Cocoon2. They can be use in general (XML-Schema
-> java source according to JAXB). If some Axis people will join we can
build up a toolset that satisfies all (and now my Avalon bias mind sees
pluggable generator components :).
<<
we would be interested in getting in on this - so count us in. Ovidiu and
the HP team are using Cocoon for SOAP in their middleware - so they may be
interested in this as well.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [[EMAIL PROTECTED] - http://www.sundn.de]
=================================================================
-----Ursprüngliche Nachricht-----
Von: giacomo [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 5. September 2001 14:50
An: [EMAIL PROTECTED]
Betreff: [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 [[EMAIL PROTECTED] - http://www.sundn.de]
> =================================================================
>
>
> -----Ursprüngliche Nachricht-----
> Von: Michael Homeijer [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 11. Mai 2001 13:03
> An: '[EMAIL PROTECTED]'
> 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
