Partición de soluciones de sistemas distribuidos para su implementación

Actualización: noviembre 2007

Cuando los equipos de desarrollo están listos para implementar las definiciones de aplicación del diagrama de aplicaciones que admiten implementación, el jefe de desarrollo puede generar proyectos para esas definiciones en Visual Studio. Estos proyectos aparecen en el Explorador de soluciones junto con otros elementos dentro de la misma solución. Sin embargo, podrían existir escenarios en los que se desea particionar la solución en soluciones más pequeñas. Crear soluciones más pequeñas que contienen sólo un subconjunto de las aplicaciones es una forma flexible de organizar los proyectos para su desarrollo. Visual Studio permite incluir los proyectos en un número cualquiera de soluciones; de ese modo, se pueden crear soluciones que contienen un subconjunto de los proyectos. Además, podría resultar útil conservar la solución original como solución "principal", lo cual permite conciliar cambios en todo el ámbito original de la solución y crear sistemas y definir la implementación dentro de ese ámbito.

Nota:

Los enfoques y la orientación que se ofrecen en este tema suponen el uso del control del código fuente. Para obtener más información, vea Documentos del modelo de definición del sistema (SDM) bajo el control del código fuente. Al particionar las soluciones, se recomienda que utilice los puertos estáticos en aplicaciones ASP.NET basadas en sistema de archivos, que utilizan de forma predeterminada los puertos dinámicos. Los puertos dinámicos en una aplicación ASP.NET pueden causar el cambio de los números de puerto en cualquiera de sus servicios Web, lo que hace que se desconecten las referencias Web correspondientes. Para obtener más información, vea Información general sobre aplicaciones ASP.NET en diagramas de aplicaciones.

Las secciones siguientes contienen más información sobre cómo particionar soluciones:

• Soluciones particionadas desde una solución principal

• Conservar la solución original como solución principal

• Actualizar la solución principal con los cambios de las soluciones particionadas

Soluciones particionadas desde una solución principal

En escenarios donde las definiciones de aplicación para un sistema de aplicaciones grande y complejo residen en una única solución, podría resultar más aconsejable dividir la solución en soluciones más pequeñas para implementar las aplicaciones. Cada solución particionada contendría un subconjunto de definiciones de aplicación y sus correspondientes proyectos, incluidos archivos de código, archivos de configuración y archivos .sdm, que contienen la información del Modelo de definición del sistema (SDM) para las definiciones de aplicación asociadas.

Puede emplear diversas estrategias para particionar una solución. Por ejemplo, si el sistema global consta de una serie de sistemas miembro claramente definidos, podría optar por crear soluciones basadas en los límites de cada sistema en la solución. Cada solución contendría entonces los proyectos para las definiciones de aplicación a las que hace referencia un sistema. Dependiendo de la complejidad de cada sistema, esas soluciones particionadas podrían dividirse a su vez en soluciones más pequeñas. También podría particionar las soluciones hasta el nivel de desarrollador, de modo que la solución de cada desarrollador contenga sólo aquellas partes del sistema para las que el desarrollador tiene responsabilidad. También puede compartir proyectos mediante el control del código fuente. Sin embargo, deberá tener en cuenta ciertos problemas que se pueden presentar cuando se comparten proyectos. Para obtener más información, vea Desprotección y cambios simultáneos en documentos del modelo de definición del sistema (SDM).

Nota:
Aunque los límites de sistema podrían proporcionar una base lógica para dividir las definiciones de aplicación y sus proyectos de una única solución en soluciones más pequeñas, no es obligatorio hacerlo de este modo. En escenarios donde los sistemas se superponen (usan la misma definición de aplicación), este enfoque es menos práctico.

Contenido de las soluciones particionadas

Puede agregar un diagrama de aplicaciones a cada solución particionada, lo cual hace que las definiciones de aplicación aparezcan en el diagrama según los archivos de definición de aplicación (.sdm) de los proyectos de esa solución. Después del proceso de partición, cualquier nuevo proyecto agregado a la solución se somete a ingeniería inversa en el diagrama de aplicaciones, si procede. Cada solución particionada también podría contener diagramas de sistemas para poder revisar los sistemas que hacen uso de esas definiciones. Por ejemplo, para proporcionar contexto, una solución particionada puede incluir diagramas de sistemas que comparten referencias a una definición de aplicación. Puede utilizar el diagrama de aplicaciones o agregar diagramas de sistemas a una solución particionada si desea evaluar la implementación o generar informes de implementación mediante los Diseñadores de sistemas distribuidos. Si desea utilizar soluciones particionadas sólo para el desarrollo de proyectos, no hay necesidad de incluir diagramas de sistemas distribuidos en esas soluciones.

Nota:

Si elimina un archivo .sdm mientras el diagrama de aplicaciones está cerrado, el archivo .sdm se volverá a generar la próxima vez que abra el diagrama de aplicaciones en una solución que contenga ese proyecto. Sin embargo, esto archivo .sdm generado de nuevo sólo contiene información que se puede volver a crear desde otro origen. Cualquier información almacenada únicamente en el archivo .sdm eliminado se perderá. Además, las referencias a la definición asociada podrían quedar rotas. Para obtener más información, vea Solucionar problemas de diagramas de aplicaciones. Si en una solución particionada no existe una definición de aplicación compartida, los usos de esa definición en los diagramas de sistemas incluidos en la solución aparecerán rotos. Los intentos de definir o evaluar la implementación para sistemas que hacen referencia a una definición de aplicación que falta no producirán un resultado satisfactorio. Para obtener más información, vea Sincronización entre los documentos del modelo de definición del sistema (SDM). Para poder agregar diagramas de sistemas, debe existir un diagrama de aplicaciones en la solución.

Conservar la solución original como solución principal

Después de particionar una solución en soluciones más pequeñas, podría desear mantener la solución original como solución "principal". Este enfoque permite ver y revisar el sistema completo ocasionalmente. Además, no existe obligación de utilizar el diagrama de aplicaciones en cada solución particionada si existe una solución principal que contiene su propio diagrama de aplicaciones.

Nota:

No existe obligación de mantener una solución principal. Por ejemplo, si es posible dividir claramente los límites de sistema en función de las conexiones entre servicios Web, podría resultar suficiente con administrar independientemente cada solución particionada y representar las interacciones entre ellas como conexiones a servicios Web externos. Se agregan automáticamente servicios Web externos al diagrama de aplicaciones de cada solución particionada donde las referencias a servicios Web atraviesan los límites de la solución. Para obtener más información, vea Tipos y prototipos de aplicaciones para la definición de aplicaciones. Sin embargo, si desea diseñar sistemas de alto nivel que hacen referencia a sistemas creados en soluciones particionadas de nivel inferior, puede crear definiciones de sistema que incluyan sólo las definiciones de nivel inferior. No obstante, para poder definir y evaluar la implementación para estos sistemas, asegúrese de que la solución contiene todas las aplicaciones a las que se hace referencia.

Por ejemplo, suponga que un equipo de desarrollo consta de tres desarrolladores que trabajan en tres soluciones individuales, cada una de la cuales es una solución particionada que contiene proyectos asociados con definiciones de aplicación. Estas tres soluciones forman parte de una solución particionada mayor que engloba los límites de un único sistema de aplicación. A su vez, la solución particionada es una de muchas otras soluciones particionadas que describen otros sistemas de aplicación y que componen un sistema global que existe dentro del ámbito de una solución principal.

Los equipos de desarrollo trabajan en las soluciones particionadas e incorporan sus cambios en el control del código fuente. El jefe de desarrollo puede entonces actualizar la solución principal desde el control del código fuente extrayendo los diagramas y archivos adecuados. Esta acción sincroniza los cambios en los archivos de código y de configuración con los diagramas adecuados. Para obtener más información, vea Información general sobre el modelo de definición del sistema (SDM) y Relaciones entre los documentos del modelo de definición del sistema (SDM).

Actualizar la solución principal con los cambios de las soluciones particionadas

Los arquitectos de aplicaciones, jefes de desarrollo o responsables de la arquitectura de un sistema pueden actualizar y validar periódicamente la solución principal con los cambios realizados en las soluciones particionadas. Estas personas pueden desproteger una solución particionada que contenga los proyectos que se han dividido entre varios equipos desarrollo, lo cuales podrían estar trabajando en estos proyectos directamente dentro de la solución particionada o en soluciones particionadas a su vez.

Esto resulta útil para revisar el sistema global si se han realizado cambios en la arquitectura, para validar que el diseño del sistema global se implementará correctamente y para propagar cambios entre soluciones. La actualización y revisión periódica de la solución principal también resulta importante si la solución contiene el único diagrama de aplicaciones de todas las soluciones y si es la única ubicación en la cual se mantienen los sistemas.

Cuando se abre el diagrama de aplicaciones en la solución principal después de actualizar sus proyectos desde el control del código fuente, un arquitecto de aplicaciones o un jefe de desarrollo puede revisar las consecuencias que los cambios en esos proyectos han producido en el diagrama. Para ver los cambios exactos, el arquitecto o jefe de desarrollo puede revisar la lista de cambios que se han incorporado en el control del código fuente o comparar las diferencias en los archivos de código. El arquitecto o jefe de desarrollo puede entonces sincronizar el diagrama de aplicaciones con el código del proyecto o resolver las posibles advertencias de sincronización desprotegiendo en el control del código fuente los proyectos necesarios de modo que los cambios que se deban hacer puedan propagarse por las definiciones de aplicación y sus usos en las definiciones de sistema.

Si el arquitecto o el jefe de desarrollo está satisfecho con los cambios en los proyectos, estos cambios se pueden incorporar en la solución. De lo contrario, el arquitecto o jefe de desarrollo debería trabajar con los equipos de desarrollo para resolver los posibles conflictos y que el código pueda sincronizarse con el diagrama.

Vea también

Tareas

Cómo: Resolver conflictos en los documentos del modelo de definición del sistema (SDM)

Referencia

Desprotección y cambios simultáneos en documentos del modelo de definición del sistema (SDM)

Otros recursos

Diseñadores de sistemas distribuidos en entornos de trabajo en equipo