Рабочее место архитектора проекта, основные функции и возможности, связь с разработчиками проекта

Конечные точки

Приложения взаимодействуют через конечные точки. Чтобы связать два приложения, необходимо с одной стороны соединения определить конечную точку провайдера, а с другой - конечную точку потребителя. Дополнительные конечные точки провайдера можно добавить прямо в приложение, перетащив их с панели инструментов или щелкнув приложение правой кнопкой мыши и выбрав команду Add New (Добавить новую). Однако нужно последить за тем, чтобы выбираемые конечные точки были подходящего типа. Для создания пользовательской конечной точки соедините приложение с конечной точкой провайдера. В результате вы получите готовую конечную точку требуемого типа с заданным для нее URL. (Подробнее об этом рассказывается в следующем подразделе.)

Существует четыре вида конечных точек приложений, каждая из которых имеет две формы: провайдерскую и потребительскую.

• WebServiceEndpoint — конечная точка веб-сервиса на базе SOAP. Такие конечные точки автоматически создаются для внешних веб-сервисов и могут применяться с приложениями любых пользовательских типов, поддерживающих технологию соединения по принципу веб-сервисов, в частности с базами данных SQL Server 2005.
• WebContentEndpoint — конечная точка веб-контента, доступного по протоколу HTTP. Точки данного вида предназначены для доступа к файлам, которые не предоставляются через веб-сервисы.
• DatabaseEndpoint — конечная точка для подключения к базе данных.
• GenericEndpoint — конечная точка, для которой протокол не определен.

Пользовательские прототипы приложений

Проектируя и конфигурируя приложения, вы, возможно, захотите использовать какие-то из них и в других решениях. К примеру, если определена стандартная конфигурация приложения ASP.NET или стандартный набор операций, выполняемых любыми веб-сервисами, то имеет смысл создать собственные прототипы приложений и разместить их кнопки на панели инструментов. Visual Studio сохранит описание выбранных приложений в файле прототипа конструктора приложений ( .adprototype ), попросив задать для этого файла имя и путь. На панели инструментов можно сохранять прототипы следующих объектов:

• приложения;
• группы приложений;
• конечной точки;
• группы конечных точек.

Тест на развертывание

Большая часть проверок на возможность развертывания будет производиться по мере формирования его схемы. Например, при попытке разместить приложение, для которого требуется обеспечить взаимодействие по протоколу HTTP, на хосте, не имеющем такой конечной точки, конструктор не позволит это сделать — указатель мыши над данным хостом примет форму знака запрета (перечеркнутой окружности). Более сложные нарушения ограничений могут быть неочевидными до тех пор, пока конструктор не выполнит анализ построенной вами схемы развертывания.

Отдельные элементы в диаграммах можно снабдить ограничениями, препятствующими развертыванию тех или иных приложений на конкретных хостах. Нарушения этих ограничений не проявляются, когда вы перетаскиваете элементы из одной диаграммы в другую, но они будут обнаружены позднее, на этапе анализа схемы развертывания.

В процессе анализа просматриваются все документы, связанные с процедурой развертывания, и выводятся сообщения об ошибках и предупреждения. Их отсутствие означает, что тест на развертывание пройден успешно.

Создание отчета о развертывании

Отчет о развертывании (Приложение М) генерируется конструктором развертывания в виде XML - и HTML -документов, который можно использовать для разных целей. В частности, он может служить входным документом для других процессов, например для составления сценария развертывания. В отчете содержится следующая информация:

• перечень всех систем с указанием их имен и типов;
• список ресурсов каждой системы, включая сборки, исполняемые файлы, каталоги, файлы ресурсов, конечные точки и файлы web.config ;
• параметры серверов, в том числе информация о версиях, контроллерах домена, терминальных серверах, установках IIS, пулах приложений, версиях .NET и установках GAC ;
• встроенные диаграммы (не обязательно).

Данный отчет может использоваться группой развертывания в качестве контрольного списка компонентов.

Два документа, в XML и HTML форматах, генерируются на основе диаграммы развертывания, созданной в соответствующем конструкторе. Перед его формированием Team System дает вам возможность определить несколько параметров, например, указать на необходимость включения в отчет диаграмм, информации о владельцах двоичных файлов, исходного кода и других файлов проекта. При формировании отчета все эти файлы копируются в заданную папку. Если нужно разрешить те или иные проблемы, то можно сгенерировать отчет, попросив включить в него только информацию об ошибках.

Все элементы, созданные и измененные архитектором, первоначально хранятся на локальном компьютере. Но, как только файлы будут считаться готовыми для публикации на сервере, архитектор вписывает их на сервере (Check-in), и с этих пор они становятся доступными с любого компьютера, имеющего доступ к данному проекту на сервере Team Foundation. Все файлы архитектуры можно увидеть через пункт Source Control Explorer, отображаемый в Team Explorer. Файлы отчетности архитектор публикует на портале проекта либо через Team Explorer, создав необходимый для его отчетов каталог, либо непосредственно на портале через веб-браузер.