Hi Jeff. There's no single right approach to service development. Contract-first is good for more than business analysts though! Plus, a good service contract has to be much more than just WSDL (or its equivalent). Contract last development works on an individual service basis but has problems scaling, and particularly if you don't control the lifecycle for all of the services involved in the deployment.
But the aim should be to allow the CDL aspect of the contract to be applied to existing service deployments. As I said in another forum posting: that's what SOA is about after all, leveraging existing investments.
Furthermore, the way we're looking to use CDL is not just a static design-time aspect: it's for runtime.
I think in large scale projects, having a 'blueprint' to follow and aid the construction of a large number of services can only be a good thing. It ensures that each service, although developed independently, probably by many different teams (possibly globally distributed), can be assured of working together when it comes to integration testing. Hence the benefit of contract driven development for large scale projects.
However, as time goes on, most organisations will have existing services that they wish to reuse. Therefore even in a contract driven approach, we would still need to be able to accomodate existing services. This may result in the choreography needing to adapt to the behaviour of the existing service, or the existing service be changed to meet the new requirements of the choreography. By having an understanding of the required behaviour, against the existing behaviour, it enables us to make an informed decision about how the project should proceed, what the cost of each approach may be, etc.
So in this situation, we would ideally need to be able to abstract a behavioural description from the existing services, to compare against what is required. This is a very difficult thing to do with services developed with general programming languages - although not as difficult if a structured language such as BPEL is used.
With the conversation based ESB actions, the aim is to provide some structure that would enable the behaviour to be derived. Therefore in the context of the situation above, if services are developed using the conversation based ESB actions, then it would be possible to check that they conform to the required behaviour of one or more choreographies, after the fact - i.e. contract last.
There is also a third option, where a number of existing services have been developed (lets assume using a structured approach to enable behaviour to be derived - such as BPEL or conversation based ESB actions), then it may be possible to reverse engineer a choreography from a set of service (behavioural) descriptions. At present this has only been discussed at a theoretical level, and would probably require user intervention to help with some decisions, but could be largely automated.
Hope this helps.
I think the approach we have currently is the right first step. At present the "contract last" approach with no programmer assistance to verify deployments is what everyone provides. This is a positive differentiator. Sure, developers may have to go through a few hoops, but this is not typical distributed system development. SOA is more than just technology: it's a change in the way you think and work. This is one such change.