I planned this for Visual Studio 2008 Beta 2, but the Service Factory isn’t available for Beta 2, yet. So, this implementation is still on VS2005. Should be no problem to change it in the future.
Anyway, as I mention in a previous post, Team Architect lets you focus on the system design and the connections between them. With a Top-Down-Design approach you can model your system [system of systems / applicationlandscape] and fine-tune the details during the design without technology details.
In the current versions of Team Architect [VS2005 and VS2008] the lowest model in the Top-Down-Design is the Application Diagram not that low and not low enough for code generation [although I made some extensions to the Application Diagram which made this possible and by default you can implement them with a template]. The Service Factory can fill this gap for the endpoints [service providers].
So, I attached the Service Factory to the "Implement application" feature of the Application Diagram, let a "GatheringService" collects all the information and generate the service models from it. After this developers/ “service modelers” can add extra information to the servicemodel, for example technology specific properties and information / business analysts can add datacontracts to the data model. From there we can generate the code.
A small walkthrough [see image]:
- Design the system [see this walkthrough].
- Model the application diagram and set some additional information.
- Add detailed information about the endpoints in the "WebService Detail" window.
- With the method "Implement Application" generates the service model.
In this model you can set more detailed information about the service. - Let Information Analysts or import XSD's for the Datacontract Model.
This information isn’t available in the Application Diagram only the naming of the contracts. That’s fine, because I think datacontracts are business information and shouldn’t be modeled in an Application Diagram. - Generate code from the Service Factory.
This will conform to the current available Best Practices and implentes Design Patterns! - The last step hasn’t any thing to do with code generation but with visualization.
When I made my first code generation from the Application Diagram, I got allot of comment about the "Box" that has allot of intelligence. So, when I'm able to show people a little more details they are more comfortable it.
Some things to think about.
At first sight it looks great, but there are some challenges to take and some decisions to make.
First Roundtripping. Team Architect has got roundtripping and by using a custom template you lose this functionality, this is not a problem because I don't want roundtripping. And this will bring use by the discision: The highest model is the master. So, the application diagram is the master of the service model and this one is the master of the code.
Second Regeneration of models and code. Because we don't have / want roudntripping and the upper level model is the master, we got the question "what about changes?". For example I change the namespace in the Application Diagram after the service model is generated. What will happen with this model? For sure you don't want to generate it from scratch and lose all the settings that are made in the service model or code.
Third Executing from outside. Because I want the models to be in sync I want to run the code/model generation from time to time. For example you can regenerate everything on the Save event or you can run them during a build. Anyway, I don't think this is possible in VS2008 just because the AD hasn’t got any extension point to this. So, this is going to be a custom action.
Probably more challenges to come ;-)
Some nice thinking about models can be found in this post from Harry Pierson.
How To Customize the "Service Factory Modeling Edition" to work with Visual Studio Team Architect.
I already had made a class structure which collects and holds the information from the application diagram. So I can easily iterate through the applications, endpoints, details and other infromation. The P&P team also made a small extensibility walkthough "Importing Model Elements from an Arbitrary File Format", which made things much easier.
Going for the quickwins, I started with the generation part. Add a custom recipe "ImportADAction" and let the Execute method collects the data from the AD file, iterate the object model and generate the service model. See the P&P walkthrough for the details.
Next step, attach the "ServicesGuidancePackage.vstemplate" template to the application diagram, this can be done in the properties window of a Application Diagram Shape. When you run the "implement application" methode the template wil launch the Guidance Package "CreateSolution" recipe.
During the execution of this recipe a wizard will ask for the modelname. For sure I don't want a dialog to appear during this step. So, I need to change this recipe and collect the model name from the AD... it should be the same name as the shape I clicked.
When you use the IWizard interface a dictionary "replacementsDictionary" is used during the RunStarted() method. The Unfold method of the GAX also uses this. See image. I'm still not able to get the values I want [any help on that would be great]. Meanwhile I'm working with hardcode strings. So I can work on.
Create the service model project. Because Argument Values are collected before the actions execute and the model project is created in the same recipe as where the service model/diagram is created we can't use ValueProviders. We have to collect the data [ModelProject, Store, ...] in the Actions. This was a bit challenging [also because I'm not an expert in DSL's] but after some trial and error [allot of errors] and the DSL book, I managed to create a service contract from scratch by using the "Implement Application" feature.
The first initial steps to create a service contract from the application diagram succeeded. Next is the regenerate functionality... I will post about this later on.
Mean while this post from Jezz Santos and this from Edward Bakker are great for further reading about this.
This is how it looks...
Still alot of work to do, but it's a nice start.