Calling Soapservices using SoapDataFormat

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Calling Soapservices using SoapDataFormat

fitzgerald
Hallo

The intention of our developing issue was to call, a soap webservice from camel via the producertemplate.
As base of our researching we used this site.
http://camel.apache.org/soap.html
Proxy code generation with wsdl to code generators, should not be used, instead a kind of codeless proxy which we thougt is provided by camel and was done in the following way by setting
the endpoint wsdlurd,portname and servicename

Like in the sample contained in the link we used SoapJaxbDataFormat
SoapJaxbDataFormat soapDF = new SoapJaxbDataFormat("com.siemens.zcsisuint");
soapDF.setElementNameStrategy(new ServiceInterfaceStrategy(xx.class)

The producertemplate sends data in following way
prodtemp.sendBody("direct:start",ExchangePattern.InOut, xxmessagepojo);

So far it works fine.

But then in the next iteration we tried to become to live without the proxyclasses and changed the soapdataformatbinding to (to be able to get away from the proxyclasses)

QName elementName = new QName("http://www.example.com/ZCSISUINT/", "NewOperation");
                                 QNameStrategy strategy = new QNameStrategy(elementName);
                                 SoapJaxbDataFormat soapDF = new SoapJaxbDataFormat();
                                 soapDF.setElementNameStrategy(strategy);

The result is marshalling doesn't work anymore.A bulk of exceptions is thrown.
The important one seems to be
Caused by: javax.xml.bind.JAXBException: org.xmlsoap.schemas.soap.envelope.Envelope is not known to this context.

I think it isn't possible to marshal data from a producer to a external soapwebservice without generated proxy classes (only using a wsdl file, without proxy code)!

Is that right ?

Cheers
Fitzgerald



Reply | Threaded
Open this post in threaded view
|

AW: Calling Soapservices using SoapDataFormat

Schneider Christian
Hi Fitzgerald,

the Soap Dataformat only works if you generate code for the wsdl. Internally the dataformat analyzes the generated classes and does the mapping to soap using these.

Honestly I don´t understand how this should work without the generated classes. Do you still want to call the route with a java object like before? If yes how should camel know how to serialize it?

If you want to use xml instead you do not need the soap dataformat. Instead you can simply use a http endpoint.

Best Regards

Christian



Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching

Tel : +49-(0)721-63-15482

EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ­ HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier


-----Ursprüngliche Nachricht-----
Von: fitzgerald [mailto:[hidden email]]
Gesendet: Mittwoch, 20. Oktober 2010 15:16
An: [hidden email]
Betreff: Calling Soapservices using SoapDataFormat


Hallo

The intention of our developing issue was to call, a soap webservice from
camel via the producertemplate.
As base of our researching we used this site.
http://camel.apache.org/soap.html http://camel.apache.org/soap.html 
Proxy code generation with wsdl to code generators, should not be used,
instead a kind of codeless proxy which we thougt is provided by camel and
was done in the following way by setting
the endpoint wsdlurd,portname and servicename

Like in the sample contained in the link we used SoapJaxbDataFormat
SoapJaxbDataFormat soapDF = new SoapJaxbDataFormat("com.siemens.zcsisuint");
soapDF.setElementNameStrategy(new ServiceInterfaceStrategy(xx.class)

The producertemplate sends data in following way
prodtemp.sendBody("direct:start",ExchangePattern.InOut, xxmessagepojo);

So far it works fine.

But then in the next iteration we tried to become to live without the
proxyclasses and changed the soapdataformatbinding to (to be able to get
away from the proxyclasses)

QName elementName = new QName("http://www.example.com/ZCSISUINT/",
"NewOperation");
                                 QNameStrategy strategy = new QNameStrategy(elementName);
                                 SoapJaxbDataFormat soapDF = new SoapJaxbDataFormat();
                                 soapDF.setElementNameStrategy(strategy);

The result is marshalling doesn't work anymore.A bulk of exceptions is
thrown.
The important one seems to be
Caused by: javax.xml.bind.JAXBException:
org.xmlsoap.schemas.soap.envelope.Envelope is not known to this context.

I think it isn't possible to marshal data from a producer to a external
soapwebservice without generated proxy classes (only using a wsdl file,
without proxy code)!

Is that right ?

Cheers
Fitzgerald




--
View this message in context: http://camel.465427.n5.nabble.com/Calling-Soapservices-using-SoapDataFormat-tp3228535p3228535.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Calling Soapservices using SoapDataFormat

Willem.Jiang
Administrator
In reply to this post by fitzgerald
Yeah, the SoapDataFormat is based on the JAXB which is need to use the
generated classes to do  marshal and unmarshal work.
If you already has the generate soap message you can consider to use
camel-http component to do the proxy job.


On 10/20/10 9:16 PM, fitzgerald wrote:

>
> Hallo
>
> The intention of our developing issue was to call, a soap webservice from
> camel via the producertemplate.
> As base of our researching we used this site.
> http://camel.apache.org/soap.html http://camel.apache.org/soap.html
> Proxy code generation with wsdl to code generators, should not be used,
> instead a kind of codeless proxy which we thougt is provided by camel and
> was done in the following way by setting
> the endpoint wsdlurd,portname and servicename
>
> Like in the sample contained in the link we used SoapJaxbDataFormat
> SoapJaxbDataFormat soapDF = new SoapJaxbDataFormat("com.siemens.zcsisuint");
> soapDF.setElementNameStrategy(new ServiceInterfaceStrategy(xx.class)
>
> The producertemplate sends data in following way
> prodtemp.sendBody("direct:start",ExchangePattern.InOut, xxmessagepojo);
>
> So far it works fine.
>
> But then in the next iteration we tried to become to live without the
> proxyclasses and changed the soapdataformatbinding to (to be able to get
> away from the proxyclasses)
>
> QName elementName = new QName("http://www.example.com/ZCSISUINT/",
> "NewOperation");
>         QNameStrategy strategy = new QNameStrategy(elementName);
>         SoapJaxbDataFormat soapDF = new SoapJaxbDataFormat();
>         soapDF.setElementNameStrategy(strategy);
>
> The result is marshalling doesn't work anymore.A bulk of exceptions is
> thrown.
> The important one seems to be
> Caused by: javax.xml.bind.JAXBException:
> org.xmlsoap.schemas.soap.envelope.Envelope is not known to this context.
>
> I think it isn't possible to marshal data from a producer to a external
> soapwebservice without generated proxy classes (only using a wsdl file,
> without proxy code)!
>
> Is that right ?
>
> Cheers
> Fitzgerald
>
>
>
>


--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Reply | Threaded
Open this post in threaded view
|

Re: AW: Calling Soapservices using SoapDataFormat

fitzgerald
In reply to this post by Schneider Christian
Hallo Christian

Thanks for your answer.
During some days of debugging through camel, I got the same opinion like you descibed in your answer.
I wanted to be sure, not to have overseen something.

Thanks
Fitzgerald
Reply | Threaded
Open this post in threaded view
|

Re: Calling Soapservices using SoapDataFormat

fitzgerald
In reply to this post by Willem.Jiang
Hallo Willem

I also had that possibility in mind, but for me it only makes sense when there are only a small number of such webservices, and the passed data won't be changed so excessive.
The most pragmatic and error preventing way is, to use the client classes und Clienthelper classes itself.

Cheers
Fitzgerald
Reply | Threaded
Open this post in threaded view
|

AW: AW: Calling Soapservices using SoapDataFormat

Schneider Christian
In reply to this post by fitzgerald
Is there any reason why you wanted to get rid of the code generation?

Thanks

Christian

Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching

Tel : +49-(0)721-63-15482

EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ­ HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier


-----Ursprüngliche Nachricht-----
Von: fitzgerald [mailto:[hidden email]]
Gesendet: Mittwoch, 20. Oktober 2010 15:37
An: [hidden email]
Betreff: Re: AW: Calling Soapservices using SoapDataFormat


Hallo Christian

Thanks for your answer.
During some days of debugging through camel, I got the same opinion like you
descibed in your answer.
I wanted to be sure, not to have overseen something.

Thanks
Fitzgerald
--
View this message in context: http://camel.465427.n5.nabble.com/Calling-Soapservices-using-SoapDataFormat-tp3228535p3228572.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: Calling Soapservices using SoapDataFormat

fitzgerald
Hi

We wanted to integrate with scala-akka and there is the possiblity to extend from a producer trait and deliver the uri. That works of course fine for jms and file, so my collegues wanted the same for soap, but without code generation(direct wsdl usage instead of this).
Without the need of referencing the generated classes, we would get a kind of generic loosly coupled component. And I was the nerd, who should do, what can't be done in this way, what I have ever supposed. Thanks for your answers.

Cheers
Fitzgerald
Reply | Threaded
Open this post in threaded view
|

AW: AW: AW: Calling Soapservices using SoapDataFormat

Schneider Christian
So I guess it worked for jms and file because the data is serialized using java serialization. Is that true?
 
Theoretically you could manually annotate the classes to be serialized with jaxb annotations. In this case you would not need code generation. Currently the soap data format does not try to use defaults when an annotation is missing so you have to manually make sure all necessary annotations are present. Besides this scheme only works with one way services. That means you will not be able to receive a response.

Best Regards

Christian




Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching

Tel : +49-(0)721-63-15482

EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ­ HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier


-----Ursprüngliche Nachricht-----
Von: fitzgerald [mailto:[hidden email]]
Gesendet: Mittwoch, 20. Oktober 2010 16:00
An: [hidden email]
Betreff: Re: AW: AW: Calling Soapservices using SoapDataFormat


Hi

We wanted to integrate with scala-akka and there is the possiblity to extend
from a producer trait and deliver the uri. That works of course fine for jms
and file, so my collegues wanted the same for soap, but without code
generation(direct wsdl usage instead of this).
Without the need of referencing the generated classes, we would get a kind
of generic loosly coupled component. And I was the nerd, who should do, what
can't be done in this way, what I have ever supposed. Thanks for your
answers.

Cheers
Fitzgerald
--
View this message in context: http://camel.465427.n5.nabble.com/Calling-Soapservices-using-SoapDataFormat-tp3228535p3228651.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: Calling Soapservices using SoapDataFormat

fitzgerald
Hallo Christian

You guessed right in case of jms and file !
Thanks for your additional hints.
We have to rethink about this issue.

Best Regards
Fitzgerald