WS-CDL spec brings benefit to software development

[jeff.yuchang]

Hi All,

I am thinking of the WS-CDL is a contract among the participants, it is a high level of WSDL, but it is more than WSDL, it also provides the "Flow" happened in the participants.

I can understand that the WS-CDL will bring us benefit in the top-down approach in the software development, but as we can see that contract first is not that popular in the developers. Take the WSDL for example, many developers still like to have Java code first, and then get the WSDL generated by using the annotation. (contract-last).

I am also a contract-last guy, so I am wondering that right now how can we do that? With the WS-CDL, I am thinking it helps the top-down approach in software development, say, Business Analyst define the contract, generate the contract in such as java code, and then developers code against the generated codes... but in this case, if the contract changed, then you will need to regenerated the all codes again, and do some appropriate updates also.

I don't know how can we do the contract last with the WS-CDL, needs to define a set of annotations? or how do we use the WS-CDL in the software development.

[marklittle]

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.

[objectiser]

Hi Jeff

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.

[marklittle]

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.