Posting the screen shot of the Whitehorse Class Designer last week gave us some useful feedback and generated some discussion. I thought today I’d post a screen shot of another of the Whitehorse Designers – the one currently known as the Distributed Service Designer (DSD). It is here. In other postings, I’ve given a pointer to the MSDN article that shows the role this tool has in the Design for Operations scenario. In that scenario, we use two DSLs - the one behind the DSD and another one used for describing the constraints of a virtual view of a data center – the deployment constraints. By validating application metadata from design against metadata from deployment, we can detect many configuration errors early in the development cycle – a key win for most Enterprises.


But independently of the Design for Operations scenario, we think the DSD is a useful tool in its own right to help a developer see the overall connectivity between services in a Service Oriented design.


We’ve been re-thinking the vocabulary of this Designer, and do not know for certain what name it will have when we finally get to Whidbey! We think of the boxes in the picture as representing applications, and the port-like small boxes represent an endpoint through which a service is provided to other applications (white boxes) or an endpoint through which services of others are consumed (dark boxes).  Lines between these represent the messages that flow between endpoints. For Whidbey, these concepts shown in this particular concrete (graphical) syntax, are implemented using ASP.Net Web service technology. The designer infrastructure therefore manages the generation of the correct project structure, asmx files, wsdl files, CLR class files and config files, and keeps all these synchronized with the “model”.  The model has become a first class artifact in the solution. But as with the Class Designer, a developer could choose to not use this tool, but we hope he/she will find that it can add considerable value to the task of building service oriented applications. For example, it’s often quite difficult to detect connectivity between applications by just reading source code for all these different artifacts in a solution.


We also support a mode in which the design surface can be used as a whiteboard – allowing an architect or developer to structure the services without causing the artifacts to be generated. Once they are generated, they are always synchronized.


As I’ve said, this diagram shows the connectivity between a set of service oriented applications.  We have another closely related designer that allows the applications defined in this one to be bundled and configured as a system. Ultimately it is systems that get reused, deployed and constitute the elements of a connected system architecture.


In speaking to developers, we have come across two different schools of thought as to how connected systems should be designed. Some like to do “code-first” – build up the definition of the web methods, describing parameters using the type system of code, and have wsdl and other Web service specification artifacts built from these. Others prefer to do “contract-first” – define the service endpoint as a set of incoming and outgoing messages, often using XML documents as payload, and have the Web service implementation artifacts (asmx, etc.) built from them. We hope to support both of these approaches but I’d be interested to hear from readers who fall into one or other (or both) camps to gauge reaction. Please feel free to pass this request around friends and colleagues who might take a stand on these two approaches.