You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by bvahdat <ba...@swissonline.ch> on 2011/07/28 16:55:31 UTC
need some advice on "cxf" or "spring-ws"
Hi,
In my previous project I had a routing logic where I had to kick a
webservice in my routes along with the usage of "camel-jpa", "camel-jms"
components, etc. For that purpose I used the inOut("spring-ws:http://...")
in Java-DSL for the webservice-call which worked out-of-box for me without
any extra customization, see [1]
However in my new project I'll have to simply kick a webservice which
requires strong-authentication (client-certificate), and that's all! so no
routing-logic etc. For that I think a ProducerTemplate is good enough, but:
- Is there any contra/pros using "cxf" or "spring-ws", which one would make
a better sense in my case?
- Do you think the TLS-Configuration utility [2] would make sense in my
case, where I've to configure the keystore/truststore stuff for the
SSL-Handshake of the webservice call?
[1]
http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-8-0-tp4584312p4593321.html
[2] http://camel.apache.org/camel-configuration-utilities.html
Regards, Babak
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4643001.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need some advice on "cxf" or "spring-ws"
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Thanks for sharing this with the community.
On Wed, Oct 5, 2011 at 11:24 AM, bvahdat <ba...@swissonline.ch> wrote:
> Hi,
>
> in my previous post in August by this thread I promised to give a status
> update how the things worked out using camel-spring-ws to implement a
> webservice
> client calling a webservice (through HTTP-Proxy to Extranet) expecting a
> strong authentication (client-certificate). All in one, it simply worked
> like a charm!
>
> As I feel myself owing a lot to the apache camel community, I would like to
> give some hints to other community user about the way I went for it but by
> no
> means this should be understood as the only and the best way to go for it.
> Please also apologize me for my poor English.
>
> At the end of the day, it came out that *no* extra spring
> customization/configuration was required concerning the
> HTTP-Connection-Setup (see David Valeri
> comments on this thread), as the default implementation of
> org.springframework.ws.transport.WebServiceMessageSender invoked (that's
> org.springframework.ws.transport.http.HttpUrlConnectionMessageSender)
> was simply good enough for a succesful SSL-Handshake with the server. The
> reason for that is pretty simple as it uses
>
> java.net.URLConnection.openConnection();
>
> which is smart enough to return a matching/meaningful extension of
> java.net.URLConnection under SUN-JDK, that's
> sun.net.www.protocol.https.DelegateHttpsURLConnection
> which is capable of initiating the SSL-Handshake. See also this screenshot
> http://camel.465427.n5.nabble.com/file/n4872087/debug.jpeg debug.jpeg
>
> As the camel-spring-ws doesn't yet support the camel's own TLS-Configuration
> (see Claus comments on this thread), I went for plain old java style to
> configure
> the keystore/truststore etc. For that I used the spring's own SpEL in my
> setup, something like this:
>
> <bean
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> <property name="location" value="file:config/egris.properties" />
> </bean>
>
> <bean id="systemPropertiesSetter"
> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
> <property name="targetObject" value="#{systemProperties}" />
> <property name="targetMethod" value="putAll" />
> <property name="arguments">
> <util:properties>
> <prop key="https.proxyHost">${https.proxyHost}</prop>
> <prop key="https.proxyPort">${https.proxyPort}</prop>
> <prop key="javax.net.debug">${javax.net.debug}</prop>
> <prop key="javax.net.ssl.keyStore">${javax.net.ssl.keyStore}</prop>
> <prop
> key="javax.net.ssl.keyStorePassword">${javax.net.ssl.keyStorePassword}</prop>
> <prop key="javax.net.ssl.trustStore">${javax.net.ssl.trustStore}</prop>
> <prop
> key="javax.net.ssl.trustStorePassword">${javax.net.ssl.trustStorePassword}</prop>
> ...
> ...
> </util:properties>
> </property>
> </bean>
>
> The application is a one-single-shot-application, by that I mean that it
> get's kicked-off by some external processes causing it to assemble the input
> and make
> the call and finally shutdown the JVM. For this purpose I made use of
> camel's spring-Main [1], however as I had to shutdown the VM in *all* cases,
> I did stop the
> camel context in a *finally* block, as otherwise if something goes wrong
> while calling the webservice through ProducerTemplate the Exception catched
> through camel
> itself (while routing) will be rethrown wrapped by CamelExecutionException
> to the caller (that's me). On the other hand as there're camel's own
> ThreadPools created
> at runtime through JDK-API containing *non-daemon-threads* the process will
> simply *hang*. To make it clear here some code:
>
> void start() throws Exception {
> main.start(); // this main is org.apache.camel.spring.Main
> template = main.getApplicationContext().getBean("producerTemplate",
> ProducerTemplate.class);
> }
>
> Object request(final EgrisServiceChoice serviceChoice, final Object
> payload) {
> return template.requestBodyAndHeader(EGRIS_ROUTE_URI, payload,
> SERVICE_CHOICE_HEADER_NAME, serviceChoice);
> }
>
> void stop() throws Exception {
> main.stop();
> }
>
> public static void main(final String[] args) throws Exception {
> ...
> ...
> final Main main = new Main(); // this Main is the application's own
> Main wrapping org.apache.camel.spring.Main, having the 3 methods above
> main.start();
> ...
> ...
> boolean failed = false;
> try {
> final Object response = main.request(serviceChoice, request);
> final String convertedResponse =
> main.getCamelContext().getTypeConverter().mandatoryConvertTo(String.class,
> response);
> LOGGER.info("received the terravis webservice response: {}",
> convertedResponse);
> } catch (final Exception exp) {
> LOGGER.error("invocation of the terravis webservice failed: " +
> exp.getMessage(), exp);
> failed = true;
> } finally {
> main.stop();
> System.exit(failed ? 1 : 0);
> }
>
> // not reached
> }
>
> As you see stopping of the camel context is to be done in a *finally* block
> for the reason explained before.
>
> I hope these explanations will be helpful for other community users willing
> to use camel-spring-ws.
>
> [1]
> http://camel.apache.org/running-camel-standalone-and-have-it-keep-running.html
>
> Regards, Babak
> PS: I also thank David/Claus alot for their help.
> PS2: The application was developed under SUN/Oracle JDK1.6 *and*
> successfully deployed under IBM JDK1.6.
> PS3: This information could be also important regarding TLS/SSL security
> hole:
> http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4872087.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: need some advice on "cxf" or "spring-ws"
Posted by bvahdat <ba...@swissonline.ch>.
Hi again,
I did a typo by my previous post, by the line:
java.net.URLConnection.openConnection();
I meant:
java.net.URL.openConnection();
which returns an instance of the abstract class:
java.net.URLConnection
For the complete code see
org.springframework.ws.transport.http.HttpUrlConnectionMessageSender
Regards, Babak
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4872163.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need some advice on "cxf" or "spring-ws"
Posted by bvahdat <ba...@swissonline.ch>.
Hi,
in my previous post in August by this thread I promised to give a status
update how the things worked out using camel-spring-ws to implement a
webservice
client calling a webservice (through HTTP-Proxy to Extranet) expecting a
strong authentication (client-certificate). All in one, it simply worked
like a charm!
As I feel myself owing a lot to the apache camel community, I would like to
give some hints to other community user about the way I went for it but by
no
means this should be understood as the only and the best way to go for it.
Please also apologize me for my poor English.
At the end of the day, it came out that *no* extra spring
customization/configuration was required concerning the
HTTP-Connection-Setup (see David Valeri
comments on this thread), as the default implementation of
org.springframework.ws.transport.WebServiceMessageSender invoked (that's
org.springframework.ws.transport.http.HttpUrlConnectionMessageSender)
was simply good enough for a succesful SSL-Handshake with the server. The
reason for that is pretty simple as it uses
java.net.URLConnection.openConnection();
which is smart enough to return a matching/meaningful extension of
java.net.URLConnection under SUN-JDK, that's
sun.net.www.protocol.https.DelegateHttpsURLConnection
which is capable of initiating the SSL-Handshake. See also this screenshot
http://camel.465427.n5.nabble.com/file/n4872087/debug.jpeg debug.jpeg
As the camel-spring-ws doesn't yet support the camel's own TLS-Configuration
(see Claus comments on this thread), I went for plain old java style to
configure
the keystore/truststore etc. For that I used the spring's own SpEL in my
setup, something like this:
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="file:config/egris.properties" />
</bean>
<bean id="systemPropertiesSetter"
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetObject" value="#{systemProperties}" />
<property name="targetMethod" value="putAll" />
<property name="arguments">
<util:properties>
<prop key="https.proxyHost">${https.proxyHost}</prop>
<prop key="https.proxyPort">${https.proxyPort}</prop>
<prop key="javax.net.debug">${javax.net.debug}</prop>
<prop key="javax.net.ssl.keyStore">${javax.net.ssl.keyStore}</prop>
<prop
key="javax.net.ssl.keyStorePassword">${javax.net.ssl.keyStorePassword}</prop>
<prop key="javax.net.ssl.trustStore">${javax.net.ssl.trustStore}</prop>
<prop
key="javax.net.ssl.trustStorePassword">${javax.net.ssl.trustStorePassword}</prop>
...
...
</util:properties>
</property>
</bean>
The application is a one-single-shot-application, by that I mean that it
get's kicked-off by some external processes causing it to assemble the input
and make
the call and finally shutdown the JVM. For this purpose I made use of
camel's spring-Main [1], however as I had to shutdown the VM in *all* cases,
I did stop the
camel context in a *finally* block, as otherwise if something goes wrong
while calling the webservice through ProducerTemplate the Exception catched
through camel
itself (while routing) will be rethrown wrapped by CamelExecutionException
to the caller (that's me). On the other hand as there're camel's own
ThreadPools created
at runtime through JDK-API containing *non-daemon-threads* the process will
simply *hang*. To make it clear here some code:
void start() throws Exception {
main.start(); // this main is org.apache.camel.spring.Main
template = main.getApplicationContext().getBean("producerTemplate",
ProducerTemplate.class);
}
Object request(final EgrisServiceChoice serviceChoice, final Object
payload) {
return template.requestBodyAndHeader(EGRIS_ROUTE_URI, payload,
SERVICE_CHOICE_HEADER_NAME, serviceChoice);
}
void stop() throws Exception {
main.stop();
}
public static void main(final String[] args) throws Exception {
...
...
final Main main = new Main(); // this Main is the application's own
Main wrapping org.apache.camel.spring.Main, having the 3 methods above
main.start();
...
...
boolean failed = false;
try {
final Object response = main.request(serviceChoice, request);
final String convertedResponse =
main.getCamelContext().getTypeConverter().mandatoryConvertTo(String.class,
response);
LOGGER.info("received the terravis webservice response: {}",
convertedResponse);
} catch (final Exception exp) {
LOGGER.error("invocation of the terravis webservice failed: " +
exp.getMessage(), exp);
failed = true;
} finally {
main.stop();
System.exit(failed ? 1 : 0);
}
// not reached
}
As you see stopping of the camel context is to be done in a *finally* block
for the reason explained before.
I hope these explanations will be helpful for other community users willing
to use camel-spring-ws.
[1]
http://camel.apache.org/running-camel-standalone-and-have-it-keep-running.html
Regards, Babak
PS: I also thank David/Claus alot for their help.
PS2: The application was developed under SUN/Oracle JDK1.6 *and*
successfully deployed under IBM JDK1.6.
PS3: This information could be also important regarding TLS/SSL security
hole:
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4872087.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need some advice on "cxf" or "spring-ws"
Posted by bvahdat <ba...@swissonline.ch>.
Hi David,
thanks for the provided information. I'll dig into coding and will let
You/Claus know how it's going.
Regards, Babak
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4657725.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need some advice on "cxf" or "spring-ws"
Posted by David Valeri <dv...@apache.org>.
Based on your original post, I am assuming that you are looking to use
the component as a producer. I took a cursory look through the Spring
WS API docs and found two classes of interest:
org.springframework.ws.transport.http.CommonsHttpMessageSender [1] and
org.springframework.ws.transport.http.HttpsUrlConnectionMessageSender
[2].
If your SSL and client transport configuration needs are simple, you
can stick to using HttpsUrlConnectionMessageSender. If your needs are
more complex (client-auth, etc), I would recommend going with
CommonsHttpMessageSender. If you choose to use
CommonsHttpMessageSender, Camel 2.8 does have support for configuring
Commons HTTP 3.x with the JSSE configuration utility, albeit in an
indirect manner. The Camel HTTP Component also uses HTTP 3.x and
provides some level of support for the JSSE configuration utility
[3][4]. Unfortunately, Commons HTTP 3.x makes it pretty difficult for
Camel to manage TLS settings cleanly so we created a helper class that
allows you to inject configuration from the JSSE configuration utility
into the global Commons HTTP configuration. You should be able to use
the SSLContextParametersSecureProtocolSocketFactory class from the
Camel HTTP Component to hand an SSLContextParameters instance to
Commons HTTP 3.x and then use the CommonsHttpMessageSender to make
Spring WS use the Commons HTTP library.
Buyer beware: I haven't tried any of this yet so this is all just
supposition based on the documentation.
[1] http://static.springsource.org/spring-ws/sites/2.0/apidocs/org/springframework/ws/transport/http/CommonsHttpMessageSender.html
[2] http://static.springsource.org/spring-ws/sites/2.0/apidocs/org/springframework/ws/transport/http/HttpsUrlConnectionMessageSender.html
[3] http://camel.apache.org/http.html
[4] http://hc.apache.org/httpclient-3.x/sslguide.html
On Fri, Jul 29, 2011 at 4:03 PM, bvahdat <ba...@swissonline.ch> wrote:
>
> BTW, I also created the ticket you asked me for, see
> https://issues.apache.org/jira/browse/CAMEL-4275
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4648181.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
David Valeri
-------------------
Twitter: DavidValeri
Blog: http://davidvaleri.wordpress.com/
FuseSource: http://fusesource.com
Re: need some advice on "cxf" or "spring-ws"
Posted by bvahdat <ba...@swissonline.ch>.
BTW, I also created the ticket you asked me for, see
https://issues.apache.org/jira/browse/CAMEL-4275
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4648181.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need some advice on "cxf" or "spring-ws"
Posted by bvahdat <ba...@swissonline.ch>.
Hi Claus,
Thanks for creating the ticket.
Indeed my preference is using camel's spring-ws component rather than cxf as
spring-webservices beyond others provides a great mocking support both on
the client & server side since 2.0 release, see:
http://blog.springsource.com/2011/01/11/spring-web-services-2-0-released
Am really happy to see that camel 2.8.0 sticks already to the newest version
of spring-webservices (2.0.2.RELEASE).
Regards, Babak
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4647558.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need some advice on "cxf" or "spring-ws"
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I created a ticket to see if its possible to add the new TLS stuff to spring-ws
https://issues.apache.org/jira/browse/CAMEL-4279
On Thu, Jul 28, 2011 at 8:02 PM, bvahdat <ba...@swissonline.ch> wrote:
> Hi,
>
> according to the WIKI [1] just realized that TLS-Configuration utility isn't
> supported by spring-ws yet. In my case does it mean that if I stick to
> spring-ws then I should use the java system proerties für SSL-handshake
> stuff. The ones I'm aware of are:
>
> javax.net.ssl.keyStore
> javax.net.ssl.keyStorePassword
> javax.net.ssl.trustStore
> javax.net.ssl.trustStorePassword
>
> [1] http://camel.apache.org/camel-configuration-utilities.html
>
> Regards, Babak
> PS: I'm just a newbie with webservice stuff, so that I would appreciate any
> advice of the riders.
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4643583.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: need some advice on "cxf" or "spring-ws"
Posted by bvahdat <ba...@swissonline.ch>.
Hi,
according to the WIKI [1] just realized that TLS-Configuration utility isn't
supported by spring-ws yet. In my case does it mean that if I stick to
spring-ws then I should use the java system proerties für SSL-handshake
stuff. The ones I'm aware of are:
javax.net.ssl.keyStore
javax.net.ssl.keyStorePassword
javax.net.ssl.trustStore
javax.net.ssl.trustStorePassword
[1] http://camel.apache.org/camel-configuration-utilities.html
Regards, Babak
PS: I'm just a newbie with webservice stuff, so that I would appreciate any
advice of the riders.
--
View this message in context: http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4643583.html
Sent from the Camel - Users mailing list archive at Nabble.com.