Here is a note from Eric on his thoughts regarding this subject:
I've been reading the differing opinions on the subject out there from various people, and I'm starting to think that pure WSDL-first is going to be overkill for Kuali. It also doesn't fit well with our general philosophy on the Rice project since one of the main goals of the project is to speed up the development process. From looking through various WSDLs and reading about the experiences that others have with this approach I can't imagine that being the case. Also, because of the frequent turnover inherent in the way our projects are staffed, I don't see us being able to assign a single person to act as the WSDL expert (notwithstanding that code ownership is something I'm not a big fan of).
So, that said, I'm wondering if we can consider an alternate approach. In one conversation I read what the author referred to as "code-first contract-aware". Meaning essentially (from what I gathered) that the contract is defined in code, but it is written in such away that the author is aware that they are coding to a contract that will eventually be published out to a WSDL. I think this is actually the approach we are already taking on the Kuali Rice project, so it would fit well with what we are used to.
The one difference from my perspective is that we would need to establish some improved governance processes surrounding changes to our contracts as well as some rules surrounding when we need to actually reversion the code. I think that regardless of a code-first or contract-first approach we are going to need to do this anyway. It's just a matter of whether the wsdl is locked down or the code contracts from which the wsdl is generated are locked down.
What I've been thinking about is a setup like the following, let me know what you think:
1) All service "contracts" are defined as Java interfaces, using JAX-WS to annotate appropriately for the wsdl generation
2) When generating WSDLs through Apache CXF, we will use the Aegis binding.
3) All of the operations defined on these contracts will use simple data transfer objects which use types that are supported by default by the Aegis binding (or can be JAX-WS'd appropriately)
4) DTOs will have no logic in them whatsoever and will simply be used as a wsdl-friendly data representation (we should already be doing this anyway)
5) All of these contracts and DTOs will be included in a dedicated maven module (this is currently our api module in rice).
6) The api module can then fall under the governance that we will establish to ensure the proper level of review for suggested or desired changes to the contracts.
7) All wsdls will be generated statically and included in the Rice jars as well as being published at standard wsdl urls from the application (via the KSBDispatcherServlet). Note that this is one of the main differences between what I'm proposing and what we are doing currently. Right now the wsdl is generated dynamically when it is requested.