Whitehorse Service Designer
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.
Comments
Anonymous
March 16, 2004
What about MSMQ?Anonymous
March 16, 2004
I'd like te respond to '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.'.
Doesn't this make Whitehorse very hard to use in enterprise projects? I do projects for big enterprises and there is usually a seperate team of architects and 'functional' designers. They make a logical design which is then given to the developmentteam for implementation. As I read it, the whiteboard in Whitehorse allows this too, but then when I go to version 2.0 of my application. What happens to changes made in the design, surely they cannot lead to immediate changes in code?Anonymous
March 17, 2004
The comment has been removedAnonymous
March 18, 2004
Keith, what about messaging endpoint/transports like MQ-Series & Tibco-RV (the BUS vendors)? That would simplify heterogenous interop issues for the Whitehorse team quite a bit, as intra/inter-process communications are already on the wire...Anonymous
March 18, 2004
The comment has been removedAnonymous
March 18, 2004
To Hal: Yes I have seen Pat's blog. We're buddies and talk pretty often. You'll note a difference between Pat's recomendation for using "application" and "system" and the text I used in the posting. As I said, we are still thinking about vocabulary and terminology, and currently are thinking that the evryday usage of these terms is about the least confusing option. We're very interested in feedback from you guys though.Anonymous
March 18, 2004
Keith, to my previous point, I've referenced a Gartner report that does a more elegant job than I, of defining the BUS-Interop potential for Whitehorse:
http://www4.gartner.com/DisplayDocument?id=419593&ref=g_search
Regards,
GlennAnonymous
March 18, 2004
To Glenn: Thanks for the interesting Gartner article. We know we should support extensibility to allow customers to define protocols other than Web services, but as I mentioned to Stefan, above, I don't want to commit to the feature set we'll have in time for Whidbey. We certainly uderstand the requirement. Thanks for your comments.Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=keith-short-s-blog-whitehorse-service-designerAnonymous
June 13, 2009
PingBack from http://quickdietsite.info/story.php?id=3311Anonymous
June 15, 2009
PingBack from http://einternetmarketingtools.info/story.php?id=6815