views:

172

answers:

2

I have two webapps: a web-service client and a server (both CXF-based, using the Simple Front-End approach).

This is the server definition:

<simple:server id="server" bindingId="http://schemas.xmlsoap.org/soap/"
    address="/thingy" transportId="http://schemas.xmlsoap.org/soap/"
    serviceName="cs:thingyService"
    serviceClass="com.mycompany.thingy.api.service.ThingyService"
    endpointName="cs:thingyServicePort">
        <simple:serviceBean>
            <bean class="com.mycompany.thingy.server.service.ThingyServiceDelegate">
                <property name="thingyService" ref="thingyService"></property>
            </bean>
        </simple:serviceBean>

        <simple:dataBinding>
            <bean class="org.apache.cxf.aegis.databinding.AegisDatabinding" />
        </simple:dataBinding>
        <simple:binding>
            <soap:soapBinding version="1.1" mtomEnabled="true" />
        </simple:binding>
</simple:server>

And here the client:

<http-conf:conduit name="*.http-conduit">
    <http-conf:client AllowChunking="false" />
</http-conf:conduit>

<simple:client id="thingyService" wsdlLocation="${wsdl.url}?wsdl"
    serviceName="cs:thingyService"
    endpointName="cs:thingyServicePort"
    transportId="http://schemas.xmlsoap.org/soap/"
    address="${wsdl.url}"
    bindingId="http://schemas.xmlsoap.org/soap/"
    serviceClass="com.mycompany.thingy.api.service.ThingyService">
        <simple:dataBinding>
            <bean class="org.apache.cxf.aegis.databinding.AegisDatabinding" />
        </simple:dataBinding>
        <simple:binding>
            <soap:soapBinding mtomEnabled="true" version="1.1" />
        </simple:binding>
</simple:client>

I have an interface called ThingyService (the names have been changed ...) that is known to both client and server and the above client definition creates a proxy client that can be injected using this interface.

Everything works beautifully when both webapps are running, specifically when I deploy the server first and then the client. But when the server webapps does not start correctly, the client webapp hangs in an infinite loop trying to create the proxy from the non-existent WSDL.

Basically what I'd like is a proxy around the service proxy that lets the calls pass through when the service is available and throws an adequate exception when the service is down, which I can catch and show a "sorry, we're offline" page in the gui and resumes service when the web service is available again. I have access to the WSDL in static form through the build process (generated automatically through cxf maven plugins), so I could use this for the initial configuration, so from that point of view I am independent of the server.

Does anybody have any pointers in how to implement this functionality? The server is tomcat. The webapps may or may not be deployed onto the same server during production. The backend uses spring / jpa / cxf, the front end uses spring / wicket.

+1  A: 

Instead of generating a proxy at runtime, it sounds like you want to create the web service proxy / client code offline.

I'm not sure how this is handled with CXF but you can use tools like wsdl2java to generate the web service client code for a given wsdl document.

As an alternative approach, the client bean could be pointed at a static wsdl file, rather than one located on a remote server.

matt b
? I don't see the difference between the third paragraph and the rest. But yes, I agree, this is probably the way to go. The huge downside however, is that (correct me if I'm wrong) this ties my webapp to one particular server. In my previous scenario, I could deploy the server anywhere I wanted and just change a system property on the client. But if I build the client against a WSDL statically, there is no clean way to change the server info.
seanizer
@seanizer, assuming you are referring to the fact that the client code will be generated to call services on a specific URL, that's not true. The generated code will likely *default* to invoking the services against the URL contained in the WSDL, but this is overridable in every web service client code generator I've ever seen at runtime - for example when you instantiate the client proxy you pass the URL to use into it.
matt b
@matt that sounds good. I'll try it tomorrow and check the CXF docs to see how it's done there. Thanks. (+1, btw)
seanizer
A: 

Although the static wsdl creation approach was promising, I chose a different one (mainly because the cxf maven code generation is buggy).

I wrapped another factoryBean around the existing one, and I attached it to a service provider object that regularly pings the wsdl URL for availability. I keep a service proxy in a cache inside the factory bean, once it is created, and delete it as soon as the service provider ping fails.

If the service is currently not available, my FactoryBean throws a ServiceNotAvailableException. My front end catches this and shows a nice "Service currently unavailable" page.

Additionally, an AspectJ aspect catches all writing calls to the service and re-schedules them when the service is available again.

Here is an excerpt from my spring config:

<bean id="outerFactoryBean">
    <property name="innerFactory">
        <bean class="org.apache.cxf.frontend.ClientProxyFactoryBean">
             <!-- translation of spring:client definition from question -->
        </bean>
    </property>
    <property name="serviceProvider" ref="serviceProvider" />
</bean>
<bean id="serviceProvider" class="de.mytoys.shop.coupons.web.client.ServiceProvider">
    <property name="wsdlUrl" value="${wsdl.url}?wsdl" />
    <property name="connectionFactory">
        <bean class="org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl" />
    </property>
</bean>

<task:scheduled-tasks>
    <task:scheduled ref="serviceProvider" method="checkAvailability"
        fixed-delay="1000" />
</task:scheduled-tasks>

<task:scheduler id="scheduler" pool-size="1" />
seanizer