You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by giacomo <gi...@apache.org> on 2001/09/05 14:50:14 UTC

[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


Re: [RT] Cocoon and WSDL [was Re: AW [LONG]: [C2] Providing and using soap services]

Posted by Davanum Srinivas <di...@yahoo.com>.
Giacomo,

Am all for it. I need it for the next project we are thinking about starting (@work). Am also
waiting for the SOAP Tag library that Ovidiu spoke about. Have not heard from him yet.

Thanks,
dims

--- giacomo <gi...@apache.org> wrote:
> 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
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

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


Re: AW: [RT] Cocoon and WSDL [was Re: AW [LONG]: [C2] Providing and using soap services]

Posted by Davanum Srinivas <di...@yahoo.com>.
Please count me in too. Though i might not be very active at the beginning.

Thanks,
dims

--- Matthew Langham <ml...@sundn.de> wrote:
> 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�� [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
> 
> 
> -----Urspr�ngliche Nachricht-----
> Von: giacomo [mailto:giacomo@apache.org]
> Gesendet: Mittwoch, 5. September 2001 14:50
> An: cocoon-dev@xml.apache.org
> 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�� [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
> >
> 
=== message truncated ===


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

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


Re: AW: [RT] Cocoon and WSDL [was Re: AW [LONG]: [C2] Providing and using soap services]

Posted by Davanum Srinivas <di...@yahoo.com>.
Please count me in too. Though i might not be very active at the beginning.

Thanks,
dims

--- Matthew Langham <ml...@sundn.de> wrote:
> 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�� [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
> 
> 
> -----Urspr�ngliche Nachricht-----
> Von: giacomo [mailto:giacomo@apache.org]
> Gesendet: Mittwoch, 5. September 2001 14:50
> An: cocoon-dev@xml.apache.org
> 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�� [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
> >
> 
=== message truncated ===


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

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


AW: [RT] Cocoon and WSDL [was Re: AW [LONG]: [C2] Providing and using soap services]

Posted by Matthew Langham <ml...@sundn.de>.
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   [mlangham@sundn.de - http://www.sundn.de]
=================================================================


-----Ursprüngliche Nachricht-----
Von: giacomo [mailto:giacomo@apache.org]
Gesendet: Mittwoch, 5. September 2001 14:50
An: cocoon-dev@xml.apache.org
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   [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


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