On Compiled Contract
I finally published compiled contract over at Web Cohesion. It's quite a formal document; I wanted to make sure I tied up all the loose ends. But I thought I'd take a more informal approach here.
The whole idea sprang from frustration with the only two Web service development models. Contract-first development was too painful, but code-first development suffered from a lack of interoperability (which is kind of the whole purpose for Web services in the first place).
The debate has been active for years. It seems to me that most people agree that in order to ensure interoperability, you need a contract-first approach. Until recently, I probably would have agreed with this. However, I think the latest tools and specifications in Web service development are pushing that position farther into doubt, as developers are better able to tweak the contract from source code.
But just because the developer can ensure interoperability, doesn't mean that he will, or even that he knows how. That's why I think a whole new Web service development model is needed. One that allows developers to write a Web service API in source code, but to not have to worry about interoperability.
Enter compiled contract. The developer can maintain the Web service API in source code, where the entry barrier is low, the learning curve is gentle, and where she can use her favorite IDE. But she doesn't have to know anything about WSDL, XML-Schema, or the WS-I Basic Profile because the contract is compiled and interoperability is enforced before any executables are even runnable.
This isn't a new concept. We've been working with compilers for years. Nobody who programs in Java, for example, has to know about the internals of Java bytecode. To impose that requirement in order to ensure interoperability between platforms would be ridiculous: the bytecode specification is too complex and esoteric.
By the same token, Web service developers shouldn't be required to understand the details of WSDL: it's too complex and esoteric. There is no reason why the knowledge of the heavy Web service specifications couldn't be consolidated with the few of us who are masochistic enough to specialize in them, much the same way that knowledge of bytecode is specialized with the people who write compilers.
Well, as I'm almost ready to cut an open source release of the first contract compiler, I can say with confidence that compiled contract is more than just a good theory. It really works. It ensures interoperability better than contract-first, and it streamlines the development process better than code-first.
I'm really excited about it.
The whole idea sprang from frustration with the only two Web service development models. Contract-first development was too painful, but code-first development suffered from a lack of interoperability (which is kind of the whole purpose for Web services in the first place).
The debate has been active for years. It seems to me that most people agree that in order to ensure interoperability, you need a contract-first approach. Until recently, I probably would have agreed with this. However, I think the latest tools and specifications in Web service development are pushing that position farther into doubt, as developers are better able to tweak the contract from source code.
But just because the developer can ensure interoperability, doesn't mean that he will, or even that he knows how. That's why I think a whole new Web service development model is needed. One that allows developers to write a Web service API in source code, but to not have to worry about interoperability.
Enter compiled contract. The developer can maintain the Web service API in source code, where the entry barrier is low, the learning curve is gentle, and where she can use her favorite IDE. But she doesn't have to know anything about WSDL, XML-Schema, or the WS-I Basic Profile because the contract is compiled and interoperability is enforced before any executables are even runnable.
This isn't a new concept. We've been working with compilers for years. Nobody who programs in Java, for example, has to know about the internals of Java bytecode. To impose that requirement in order to ensure interoperability between platforms would be ridiculous: the bytecode specification is too complex and esoteric.
By the same token, Web service developers shouldn't be required to understand the details of WSDL: it's too complex and esoteric. There is no reason why the knowledge of the heavy Web service specifications couldn't be consolidated with the few of us who are masochistic enough to specialize in them, much the same way that knowledge of bytecode is specialized with the people who write compilers.
Well, as I'm almost ready to cut an open source release of the first contract compiler, I can say with confidence that compiled contract is more than just a good theory. It really works. It ensures interoperability better than contract-first, and it streamlines the development process better than code-first.
I'm really excited about it.
posted by Ryan at 3:53 PM
1 comments
