News

Web Service Software Factory v3 now supports DSLs for designing Contracts

Posted by Hartmut Wilms on Apr 11, 2007 08:46 AM

Community: .NET
Topics: Web Services ,; Domain Specific Languages
Tags: Software Factories ,; Visual Studio ,; WCF

Don Smith announces the first community drop of the Web Service Software Factory (WSSF) v3. The factory supports a model-driven approach for designing and implementing web services. WCF service contracts and data contracts can now be modeled in a visual Domain-Specific Language (DSL).

The model-driven approach is a huge improvement over the wizard-based approach of the current v2 release. Today the factory allows designing a contract by adding members or operations within wizards. When finishing a wizard appropriate code will be generated. The downside of this approach is that all information concerning the service contract or data contract model are lost. For instance if you want to add members to a data contract you will have to start the wizard process all over again and finally generated code based on a complete new model.

The v3 alpha includes designers for modeling contracts already. All model information are stored, which allows to easily extend or change contracts and generate appropriate code at any time. In addition the designers provide a visual representation of your services and data contracts and their relations.

Don Smith summarizes these new features along with other improvements as follows:

Now Visual Studio has a memory about your decisions. In v2 you place your decisions in wizards. In addition to models, there are still wizards, but it's the model that "remembers" so you can generate code anytime you like.

Now you have a visualization of the application you are building. The designers provide this. Right now there are 2 designers/models. The first screen shot below shows the one for service contracts and the one after that shows data contracts.

Now you can delay the platform decision (WCF/ASMX/etc) and the language decision (C#/VB/etc) until as late as you like (way after you define all the service, message, and data interfaces.

With this version there is also no assumption that you have already defined the service contract before you start using the factory. You can either approach the solution from a capability perspective (dropping operations on the service contract designer) or from a data perspective (dropping data contracts on its designer).

The contract designers are an important and necessary feature. The process of designing a contract in the wizard-based approach is a very time-consuming endeavor. In addition the fact that you have to repeat the whole wizard process in order to apply (minor) changes is annoying, to say the least.