Quantcast

need some advice on "cxf" or "spring-ws"

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

need some advice on "cxf" or "spring-ws"

Babak Vahdat
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Babak Vahdat
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Claus Ibsen-2
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 <[hidden email]> 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Babak Vahdat
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Babak Vahdat
In reply to this post by Claus Ibsen-2
BTW, I also created the ticket you asked me for, see https://issues.apache.org/jira/browse/CAMEL-4275
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

dvaleri
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Babak Vahdat
Hi David,

thanks for the provided information. I'll dig into coding and will let You/Claus know how it's going.

Regards, Babak
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Babak Vahdat
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 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Babak Vahdat
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: need some advice on "cxf" or "spring-ws"

Claus Ibsen-2
In reply to this post by Babak Vahdat
Hi

Thanks for sharing this with the community.


On Wed, Oct 5, 2011 at 11:24 AM, bvahdat <[hidden email]> 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Loading...