Partitioning of Distributed System Solutions for Implementation
When development teams are ready to implement application definitions on the application diagram that support implementation, the development lead can generate projects for those definitions in Visual Studio. These projects appear in Solution Explorer along with other items within the same solution. However, there might be scenarios in which you want to partition the solution into smaller solutions. Creating smaller solutions that contain only a subset of applications is a flexible way to organize projects for development. Visual Studio makes it possible to include projects in any number of solutions so that you can create solutions that contain a subset of projects. In addition, it might be useful to keep the original solution as a "master" solution, which makes it possible to reconcile changes across the original scope of the solution and to create systems and define deployment within that scope.
The approaches and guidance in this topic assume the use of source code control. For more information, seeand or . When partitioning solutions, it is recommended that you use static ports on file system-based ASP.NET applications, which use dynamic ports by default. Dynamic ports on an ASP.NET application might cause the port numbers to change on any of its Web services, which causes the corresponding Web references to become disconnected. For more information, see .
The following sections contain more information about partitioning solutions:
Solutions Partitioned from a Master Solution
In scenarios where application definitions for a large complex application system are created in a single solution, it might be more manageable to divide the solution into smaller solutions for implementing applications. Each partitioned solution would contain a subset of application definitions and their corresponding projects, including code files, configuration files, and .sdm files, which contain the System Definition Model (SDM) information for the associated application definitions.
You can employ various strategies in partitioning a solution. For example, if the overall system consists of clearly delineated member systems, you might choose to create solutions based on the boundaries of each system in the solution. Each solution would then contain the projects for the application definitions referenced by a system. Depending on the complexity of each system, those partitioned solutions might be further divided into even smaller solutions. You could also partition solutions to the level of individual developers such that each developer's solution contains only those parts of the system for which each developer has responsibility. You can also share projects using source code control. However, be aware of certain issues when sharing projects. For more information, see.
Even though system boundaries would provide a logical basis for dividing application definitions and their projects from a single solution into smaller solutions, there is no requirement to divide a solution in this manner. In scenarios where systems overlap (contain uses of the same application definition), this approach is less practical.
Contents of Partitioned Solutions
You can add an application diagram to each partitioned solution, causing application definitions to appear on the diagram based on application definition (.sdm) files in the projects of that solution. After the partitioning process, any new projects added to the solution are reverse-engineered on the application diagram, if appropriate. Each partitioned solution might also contain any system diagrams so that individuals can review the systems that contain uses of those definitions. For example, system diagrams that share references to an application definition can be included in a partitioned solution to provide context. You can use the application diagram or add system diagrams to a partitioned solution if you want to evaluate deployment or generate deployment reports using Distributed System Designers. If you want to use partitioned solutions for project development only, there is no requirement that any distributed system diagrams be present in those solutions.
If you delete an .sdm file while the application diagram is closed, the .sdm file will be regenerated the next time you open the application diagram in a solution that contains that project. However, this regenerated .sdm file contains only information that can be recreated from another source. Any information that was stored solely in the deleted .sdm file will be lost. In addition, references to the associated definition might be broken. For more information, see. If a shared application definition is not present in a partitioned solution, uses of that definition on the system diagrams that are included in the solution will appear broken. Attempts to define or evaluate deployment for systems that reference a missing application definition will not be possible or successful. For more information, see . An application diagram must exist in the solution if any system diagrams are added.
Retaining the Original Solution as the Master Solution
After partitioning a solution into smaller solutions, you might also keep the original solution as a "master" solution. This approach makes it possible to view and review the entire system on an occasional basis. In addition, there is no requirement to use the application diagram in each partitioned solution if a master solution exists and contains its own application diagram.
There is no requirement to keep or maintain a master solution. For example, if system boundaries can be clearly divided based on connections between Web services, then it might be sufficient to manage each partitioned solution separately and represent the interactions between them as connections to external Web services. External Web services are added automatically to the application diagram in each partitioned solution where Web service references cross solution boundaries. For more information, see. However, if you want to design higher-level systems that reference systems created in lower-level partitioned solutions, you can create system definitions that include only the required lower-level system definitions. However, in order to define and evaluate deployment for these systems, make sure that the solution contains all the referenced applications.
For example, suppose a development team consists of three developers working on three individual solutions, each a partitioned solution containing projects associated with application definitions. These three solutions are part of a larger partitioned solution that encompasses the boundaries of a single application system. In turn, the partitioned solution is one of many other partitioned solutions that describe other application systems, which comprise an overall system that exists within the scope of a master solution.
As development teams work on partitioned solutions, they will check in their changes to source code control. The development lead can then update the master solution from source code control by checking out the appropriate diagrams and files. This action synchronizes changes to code and configuration files with the appropriate diagrams. For more information, seeand .
Updating the Master Solution with Changes to Partitioned Solutions
Application architects, development leads, or those responsible for the architecture of a system can periodically update and validate the master solution with changes made to the partitioned solutions. This person can check out a partitioned solution containing those projects that have been divided amongst development teams, who might be working on these projects directly within the partitioned solution or in further partitioned solutions.
This is useful for reviewing the overall system if architectural changes were made, for validating that the overall system design will still deploy correctly, and for propagating changes between solutions. Periodic updating and reviewing of the master solution is also important if the solution contains the only application diagram across all the solutions and is the only location in which systems are being maintained.
When the application diagram is opened in the master solution after refreshing its projects from source code control, an application architect or development lead can review the impact that changes to those projects have made on the diagram. To see the exact changes, the architect or development lead can review the list of changes that have been checked in or compare the differences in the code files. The architect or development lead can then synchronize the application diagram with the project code or resolve any synchronization warnings by checking out the necessary projects so that any changes that need to be made can propagate across application definitions and their uses in system definitions.
If the architect or development lead is satisfied with changes to these projects, these changes can be checked into the solution. Otherwise, the architect or development lead should work with development teams to resolve any conflicts so that the code can synchronize with the diagram.