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

Конструктор логического центра данных

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

• типы серверов (хостов приложений);
• коммуникационные соединения хостов (серверные конечные точки);
• типы коммуникационных границ (зоны);
• конечные точки коммуникаций (конечные точки зон);
• типы доступных сервисов;
• конфигурацию сервисов приложений;
• параметры логических серверов и конечных точек.

Создание диаграмм логического центра данных

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

В данную диаграмму можно добавлять следующие объекты:

Зоны (Zone) - ограниченные тем или иным образом сферы действия параметров безопасности, такие как домены, интрасети и т. п.;

Конечные точки (Endpoint) - входные и выходные "ворота" логических серверов и зон, в том числе клиентские и серверные ( Website, HTTP, Database, Generic );

Хосты (Host) - разнообразные хосты приложений ( HSWeb, Database, Windows, Generic ).

Зоны

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

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

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

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

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

Если сервер уже установлен, и есть возможность связи с ним, то в конструкторе существует возможность импортировать настройки уже работающего сервера [1]. При этом пропадает необходимость вручную настраивать логический сервер, что ускоряет работу архитектора и при этом дает гарантию совместимости модели с реально существующей инфраструктурой.

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

Клиенты и серверы

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

• DatabaseServer - сервер для размещения базы данных;
• IlSWebServer - веб-сервер, где функционируют веб-приложения;
• WindowsClient - настольный компьютер с клиентскими приложениями для конечного пользователя;
• GenericServer - сервер, тип которого не определен. Данный прототип предназначен для представления серверов пользовательских типов.

Соединение конечных точек

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

• DatabaseClientEndpoint — потребитель соединения с базой данных;
• GenericClientEndpoint — потребитель произвольного соединения;
• GenericServerEndpoint — провайдер произвольного соединения;
• HTTPCHentEndpoint — потребитель HTTP -соединения;
• WebSiteEndpoint — провайдер/сервер НТТР -соединения;
• ZoneEndpoint — коммуникационная конечная точка границы зоны.

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

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

Конструктор приложений

Основной задачей архитектора приложений является разработка прикладной архитектуры, включающей приложения, сервисы и их коммуникационные соединения. Используя конструктор приложений Visual Studio, архитектор определяет метаданные и конфигурационные установки. В частности, он должен задать:

• типы приложений (точнее, приложений, сервисов и баз данных);
• коммуникационные соединения приложений (соединения и конечные точки);
• ограничения и установки.

Основным назначением описываемого конструктора является разработка SOA -приложений. Это означает, что с его помощью моделируются преимущественно веб-сервисы ASP.NET и приложения, являющиеся их потребителями.

Создание диаграммы приложений

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

Приведем список объектов, которые можно добавить в диаграмму:

• приложение (application) — приложения Windows, Microsoft Office, веб-приложения ASP.NET и произвольные пользовательские приложения;
• сервисы (service) — веб-сервисы ASP.NET, BizTalk и пользовательские;
• база данных (database) — внешняя база данных;
• конечная точка (endpoint) — конечная точка веб-приложения, веб-сервиса или пользовательская.

В веб-сервисах есть возможность определять различные операции – процедуры и функции, и их свойства. Полученная таким образом операция генерируется в коде страницы, ссылка на которую будет находиться в приложении, данные с которой будут обрабатываться. В дальнейшем при передаче разработчику будет видно, что необходимо добавить в приложение.

Приложения, сервисы и базы данных

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

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

Приложения некоторых типов, в частности приложения Windows и ASP.NET, синхронизируются с программным кодом. Иными словами, при проектировании приложения в конструкторе на основе получившейся диаграммы генерируете код, а когда вносите в данный код изменения, они автоматически отражаются в диаграмме. Эта функция Team System особенно полезна, когда архитектор и разработчик — два разных человека, сидящих каждый за своим компьютером. Обратная связь поддерживается и для конфигурации. В данном случае обратный разбор производится аналогично обратному разбору кода, с тем лишь отличием, что изменения вносятся не в программные файлы, а в файл web.config. Первоначально такой файл в вашем проекте может отсутствовать: он генерируется, когда в конструкторе приложений задаются какие-либо конфигурационные установки, например, определяются параметры защиты. Но вы можете добавить данный файл в проект и вручную, после чего вносимые в него изменения будут отражаться на SDM -свойствах в конструкторе приложений и наоборот.