Ali and Dmitriy - Early Demo of Distributed System Designers (Part 1)

The Discussion

• 

  I watched it, and am still not exactly clear on what it does ...

• 

  Yeh, it looks nice, but what does it actually *do*?
  
  I'd guess that after you've set up your connections you can generate VS projects that have all the right instances and method stubs set up for talking to various services. In which case, great it saves some typing, but if I want to change stuff later will it update all the projects without losing changes I've made? 
  
  It's a bit worrying when someone says "and we ask the user here to check and confirm because it's really difficult to undo this operation". Do you have to go and delete the generated project yourself and then set the thingy in the designer somehow back to it's original state or is it more complex/easier to change?
  

• 

  I've asked Ali to post some additional context here for the demo. He should have that up soon.  

• 

  In the meantime, for more information on the Visual Studio Team System Architect features check out this page:
  http://lab.msdn.microsoft.com/teamsystem/teamcenters/architect/default.aspx
  
  Building complex service-oriented solutions requires several architectural considerations including services and contract design, communications security, operations manageability and provisioning, and so on. Add to this, the time-honored issues architectural teams are mired with—architecting upfront with deployment in mind, ensuring design changes are propagated to code and vice versa, establishing seamless communication between design and development teams and design and operations teams.

  Visual Studio 2005 Team Architect Edition addresses exactly these problems at the core with a set of Distributed System Designers that help reduce the complexity of developing and deploying service-oriented applications. A core deliverable of the Dynamic Systems Initiative (DS), these designers, leveraging the System Definition Model (SDM), allow senior developers and architects to define service-oriented applications that will be configured into systems for deployment. While application architects can visualize their service-oriented applications, developers can work with the generated code while keeping the code-changes synchronized with the visual design. In addition, the Distributed System Designers can be used to create diagrams or interconnected hosts that represent the logical structure of a data center for the purpose of communicating important information to the developer about the target deployment environment. The Distributed System Designers can also bind applications to these logical servers and validate them against the constraints of the application/data center prior to actual deployment.
  

• 

  Now what would be really cool in next version is to have the objects actually "hooked up" to the services in some out-of-band way.  Then be able to see a message flow into and out of each object or queue and check its values/transformations via debugger.  Talk about a killer demo you could do of your app while also having much debug value.  Once that is done, you have everything you need to display some cool performance graphs of what objects or network links are slow/fast, etc.  Maybe some hooks in the CLR would allow almost all of that or maybe all that is already there.
  --
  William

• 

  Good questions.
  
  This demo was not created to show the value of the Application Designer in isolation. It was meant to show the value of the Distributed system Designers as a whole, and without part 2 (which is now up on the site) I can understand why you have this question.
  
  In isolation, the Application Designer adds value by:
  
  1. Visualizing Web services/Web references and Database connections. Information that is otherwise hidden in your config file.
  2. The Application Designer also visualizes interactions of the solution with external systems.
  
  Due to these visualizations, application reuse and web service substitution is greatly simplified.
  
  3. Specification vs. Implementation. This allows you to specify a system prior to implementing any code. Therefore, this is a starting point for whiteboarding an application design.
  
  This becomes more important when you can validate the whiteboarded design with the datacenter (part 2).
  
  4. The Application Designer is always in sync with your Solution. Therefore, any changes made to the project(s) will be immediately reflected in the diagram. Likewise, any changes made through the designer will be reflected in the projects (if the application is implemented)
  5. Through the Settings and Contraints Editor (not really shown in this part) we give the user an easy editing experience over the config file.
  6. Through "Conform to WSDL" we offer the opportunity to start designing your Web service based on an agreed upon Contract (WSDL File)
  7. The designer also allows you to create predefined application prototypes as a starting point for new distributed systems. This allows you to define application patterns for reuse.
  
  Now to your questions:
  1. After you change stuff 'later', your projects will be updated and you will not lose any of the changes that you have made.
  2. What happens after you implement the application is that the undo stack gets flushed. The application can not go back to the unimplemented state. However, you can still delete the application through the designer. Any changes made through the designer will now be reflected in the project itself.

• 

  Great comment William,
  
  We are already started investigating whether our designers can be leveraged in the way that you mention. However, this doesn't seem like something that we can do anytime soon (if at all), i.e. in V1.
  
  With a V1 product, there is so much that we can do and the directions that we can take. I myself am eager to see what our application looks like in V2/V3 when it is very much possible that we do something like what you've mentioned.
  
  Cheers,
  
  Ali

• 

  You're describing what BizTalk's BAM and BAS already do. You can tap into defined events in a service's orchestration and show that data via SharePOint/Excel in graphical ways. The BizTalk debugger will allow some XML inspection as well depending on how the orchestration is designed. 

• 

  rpipkin wrote:

  You're describing what BizTalk's BAM and BAS already do. You can tap into defined events in a service's orchestration and show that data via SharePOint/Excel in graphical ways. The BizTalk debugger will allow some XML inspection as well depending on how the orchestration is designed. 

  
  
  Yeah, I am trying to fabricate the logical reason why BizTalk is not mentioned in this part of the presentation. I keep coming up with what I can only describe as (I need to watch my language).