What is the best way to expose a WCF service so that it can be easily consumed from Java/CXF?

Question

We've written a WCF service to be used by a Java shop, who is using CXF to generate the adapters. We're not that familiar with Java, but have exposed the service using basicHttpBinding, SSL, and basic authentication. Integration tests show that a .NET client can consume the service just fine. However, the Java shop is having trouble consuming the service. Specifically, they getthe following JAXB error: Two declarations cause a collision in the ObjectFactory class. This is usually caused if 2 operations have the same name and namespace when CXF attempts to create adapter classes.

We can't find any type or operation names that should cause any sort of collision. We have made sure that all custom types specify a namespace, and tempuri.org is not specified anywhere in the WSDL. The Java shop suspects the error is because the generated WSDL contains <xsd:import elements.

So, my questions:

• Is there any better way than CXF for the Java shop consume the WCF service? Project Tango looks interesting, but I don't know enough to tell them to consider using it. Is CXF a defacto standard in Java?
• BasicHttpBinding/SSL/Basic Auth are MS recommended for interop scenarios, but the client still seems to have interop problems. Should we consider other bindings or settings to make this easier to consume?
• Is there a way to configure WCF to always output a single WDSL with no schema imports?

Answer 1

The only way for your java client to talk to a WCF component will be one of the HTTP methods - basicHttpBinding, ws*, etc just as MS recommends. Java can't talk to WCF over TCP or namedPipes or MSMQ, etc.

I'd start with a super simple WCF component - something with a single method that spits out a string. Get that working with Java and then work your way up. Make sure that everything you're exposing is working with base types or well defined [DataContract] objects.

Answer 2

I've developped WCF with Axis2 clients. The authentication methods I've sucessfully uses is BasicHttpBinding/SSL/Basic (Transport) and WS-Security with Username (and MTOM).

The Metro implementation is used by SUN and Microsoft to test the interop : http://weblogs.java.net/blog/haroldcarr/archive/2007/11/metro_web_servi.html

Sorry no clue about the import generated by WCF for the schema definition.

Answer 3

The "Two declarations cause a collision in the ObjectFactory class" error message usually has nothing to do with imports. That's a JAXB error message that is usually caused by having multiple elements or similar that cause the generated field names to be the same. For example, if you have elements like:

<element name="Foo" .../> and <element name="foo" .../>

That can cause that error. Another is using thing like hyphens and underscores and such that are usually eliminated+capped: <element name="doFoo" .../> and <element name="do_foo" .../>

With 2.1.4, you can TRY running the wsdl2java with the -autoNameResolution flag. That SOMETIMES helps with this, but not always. Unfortunately, the information that JAXB gives in these cases is nearly worthless and lots of times it's just trial and error to find the conflicting types. :-(

Answer 4

The problem with xsd:import is very common. Some toolkits or runtimes cannot cope with that. To address this, you can flatten the WSDL that is generated by WCF. Check this post.

Regarding whether CXF is the right Java stack - I have never heard of it? I have used AXIS successfully, as well as JAX-WS. Both have been pretty straightforward.

Answer 5

I am deep into Java & WCF interoperability. As someone else said you need to flatten your WSDL if you are working with file based WSDL. However I use Netbeans 6.5 and if you point to a real url like http://myservice/?wsdl , Netbeans can cope easily with the default wsdl generated by WCF. In real life other things you need to consider is service versioning, optional datamembers (doesn't go well in java, so I suggest to make all datamembers IsRequired=true), order etc.

The real tough thing to get going was security. I had to make mutual certificate authentication working and it still has some issues.

Answer 6

This is a Jaxb issue. I ran into the same issue but used the xmlbeans option instead in wsdl2java client generation. To be honest I seem to prefer the xmlbeans objects more over jaxb as far a consumer to this webservice.