Screaming Penguin

Lots of people are sticking to an outdated mentality in terms of WS development, IMO. I still hear tons of people proclaim that they have interoperability problems if they do not start from schema, or that they actually want to "pass around the XML snippet." Most still say things have to be done "contract first." I disagree. With modern languages and annotations, you can specify just about anything you need in code. I am a strong "code first" advocate. This lets you stick to writing code, an interface, using an IDE, etc. Then when you are ready you can "burn" your component into a Web Service. Actually at the office we have a framework that we wrote, that is pretty simple, that does this. Under the hood we are still using SOAP frameworks like Axis and Xfire, as plugins to our framework, and the result is our code has no dependencies on anything special, just our very small framework (which invokes a plugin at build time to enable SOAPability). Developers that use it, write code, and then use the framework to create a web service. The WSDL and schema is generated from the code. This has worked fairly well for us, and it is "interoperable." We have .NET clients using our services, as well as Cold Fusion shops, PHP, and Java. It does take some forethought when building your interface, use composition over inheritance, make sure your types are serializable by the underlying tools, etc - but it can be done without too much headache. (It is not perfect mind you, but not too bad. And yes, I have also used the "contract first" approach where we start by writing schema and then generating code - this has it's own host of problems that are far worse in my opinion, and requires schema writers, rather than coders.) The "next steps" we had planned were to abstract things even a bit further, by using JAX-WS and JSR-181 and getting rid of our "framework" altogether. Let the compile/build step do the work. The concept is to start from a component that works standalone, say a JAR, etc, and then burn/wrap it into a SOAP service without affecting the component itself. Well it turns out, we are not the only ones on the planet thinking along these lines. Enter Ryan Heaton, and Compiled Contract. Ryan has obviously put a lot more thought (and actual effort) into it than I have at the office. His document about Compiled Contract is very compelling, and the project based on Enunciate looks downright phenomenal (burns SOAP and REST and JSON endpoints, makes the JavaDoc into a site doc, and much more - really impressive). I have not yet used Enunciate, but damn, looks uber-cool, and it will be going for a spin in our "Enterprise" very soon.