Auto-generated services okay in model-driven SOA

There's been an interesting industry give-and-take around the "generated services" debate that we've had going at this blogsite. A number of industry observers say that automatically generated services (a "code-first" versus a "contract-first" approach) have hooks too deep in legacy systems or specific languages to be made available for reuse across an SOA. (Ronan Bradley started the whole thing with this post.)

Paul Kiel weighed in on the discussion, pointing out that taking a "model-first" approach takes away the distinctions between code-first and contract-first services:

"Auto-generating services does not invalidate reuse or SOA. The secret sauce and key IP for businesses is the data/business models. If you can get to the point where the models drive everything (generate services, slice, dice, etc) then you can still reuse because the models reflect this. The reuse can lay in the models and not just in the instantiation of the services."

MarkG also weighed in on the discussion, noting that basically, "all the tool sets do the auto-generation (Some better than others). It's up to the architects and developers to understand what they are putting together." He adds that "the .NET folks will have the hardest time with contract first development, they are use to 'auto everything.'"

Mark also talks about JAX-WS at his blogsite, and dissects its auto-generation capabilities within the open-source IONA Celtix Enterprise tool. Importantly, he observes, WSDLs are written first, then generated as implementation interfaces. "I think the generally accepted best practice is to develop the WSDL and XML Schemas first," he observes. Hopefully following that approach will lead to a less brittle interface that has the right granularity. It should also help reduce the potential number of interoperability issues that can arise from auto-generation of Web services from existing code."

Finally, another reader of this blog, Bazzzzzzz, says the whole argument is mute if you take out the reuse aspect of SOA. "If one assumes SOA is only about reuse then the point is a valid one," he says. "Since SOA isn't only about reuse the point is a distraction."