This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
It definetly is - we are doing it where I'm working. We are using jaxb2 for marshalling/unmarshalling.
You still can have issues however with things like namespaces in nested schemas, etc but in general it's possible.
The fact that you're using Spring-WS for your web service is completely transparent to the client - this is because of the contract-first approach favored by Spring-WS.
So with Spring-WS, you create your WSDL independent from the Spring-WS framework. I assume you're using the .NET WSDL code generator, so as long as your WSDL is correct, you'll have no problems, you can use any type defined by the WSDL and XSD specifications.
On the server-side, it's then up to you to determine how you handle the XML payload of the incoming SOAP request and how you construct the XML payload of the outgoing SOAP response.
This involves a little more than typical code-first approaches, but it also absolutely makes the question of "Can I invoke a web service published by ABC framework within a C# client?" go away. You'll never have to worry about that with Spring-WS's contract-first approach.
Just a couple of follow up comments here.
We have run into a few issues, but they are not because we are using spring-ws. As stated above, the contract first nature of spring-ws means you have control over the data you return rather than mechanisms that use reflection (such as the axis model). Of course you must ensure the wsdl matches what you return!
The issues we have had however seem to be on the .net side. For one thing, using datasets to process the returned information has been problematic with nested schemas (when there are multiple namespaces involved in a complicated schema the .net code has had errors). Also, programatically calling a web service and logging in with basic authentication (rather than popping up a form for a user to type in) has had issues because the .net code doesn't seem to follow the standard for doing this correctly (so we have to make a call in a try catch to log in, and then call again to call the service).
The bottom line from my perspective is the issues we have had are not related to the spring platform, but there may still be issues needing resolution because of differences in the platform (probably as stated - moreso if you don't follow the WS-I spec completely (which is probably true for using datasets on the .net side)).