Реализация. Инсталляция и конфигурирование рабочих систем

7.1 Инфраструктура системы

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

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

Архитектура позволяет использовать для каждого компонента один или несколько серверов или объединять компоненты, используя меньшее число серверов. Связи с серверами, которые мы будем устанавливать, показаны на рис. 7.1.

увеличить изображение
Рис. 7.1. Размещение процесса RequestExternalReport в конфигурации портативного компьютера с использованием VMware

Создаваемая конфигурация, показанная на рис. 7.1, будет работать на одной рабочей станции, но ее легко можно преобразовать для работы на нескольких станциях. В конфигурации для одного портативного компьютера мы используем VMware для запуска WebSphere Business Integration Server Foundation на разных виртуальных хостах изо всех остальных компонентов. Это разделение означает, что большая часть взаимодействий протекает через соединения виртуальной сети, не являющейся локальной для виртуальных хостов. Такая система во многом напоминает размещение в готовой рабочей среде. Решение также создавалось на четырех процессорах IBM Netfinity xSeries .

7.1.1 Конфигурация мобильного компьютера

Решение работало на компьютере IBM T42p Thinkpad с 2 Гб виртуальной памяти, 60 Гб на диске и с процессором Pentium M 1.99ГГц. Мы использовали VMware Workstation версии 4.5.2 build-8848. Были сконфигурированы два хоста VMware с 640 Мб памяти каждый, с равномерным распределением памяти между физическим хостом и двумя виртуальными машинами. Виртуальные машины запускались с жесткого диска IBM Portable 40GB USB Hard Drive P/N 09N4257 или со второго жесткого диска, монтируемого в IBM Thinkpad Ultrabay. Между этими вариантами не наблюдалось существенной разницы в производительности. Обратите внимание, что производительности USB 1.1 недостаточно для работы решения.

Из соображений удобства использования весь инструментарий Eclipse запускался на физической машине, а размещение .ear-файлов, потоки сообщений и наборы сообщений осуществлялись через сетевые соединения с виртуальными машинами.

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

1. Была сделана реализация одной системы оценщика в виде EJB и размещена на SAH414A вместе с другими прикладными EJB. Это позволило оставить вторую виртуальную машину для оценщика или для запуска второго сервера приложений на одной из существующих виртуальных машин.
2. Мы не реализовывали демилитаризованную зону (DMZ) и шлюз Web-служб, поэтому потоки проходили напрямую от брокера к оценщикам и в обратном направлении.
3. Мы сконфигурировали только два менеджера очередей WebSphere MQ, по одному для каждой виртуальной машины. Мы могли бы использовать четыре менеджера очереди (по одному для рабочего потока, сервера приложений, брокера и Server Foundation) с тремя менеджерами очереди, запущенными на SAH414A. Это упростило бы повторное размещение решения на нескольких серверах, поскольку менеджеры очередей были бы связаны с узлами промежуточного ПО. Нагрузка на SAH414A оказалась бы существенно больше, поэтому мы решили создать по одному менеджеру очереди для каждой виртуальной машины. Однако переразместить решение становится значительно проще, если определить все очереди как кластерные очереди и относить все новые менеджеры очередей к одному кластеру. Имена очередей, известные приложениям, при этом не изменяются.

7.1.2 Реализация коммуникаций

Архитектура системы требует, чтобы во всех коммуникациях между службами использовались Web-службы. Существует только одно исключение – это связь между WebSphere MQ Workflow и WebSphere Business Integration Server Foundation, где используется решение на основе XML через JMS, предлагаемое в WA0D supportpac.

Архитектура также требует, чтобы надежная реализация Web-служб преобразовала существующую в LGI основу обмена сообщениями WebSphere MQ в сервисную шину. Однако из-за того, что реализацию SOAP/JMS в масштабах всей платформы WebSphere непросто сконфигурировать так, чтобы она поддерживала данную архитектуру, архитектор решения переработал систему так, чтобы она использовала SOAP/http, для чего все длительные взаимодействия были заменены несколькими односторонними SOAP-сообщениями, что позволило повысить надежность решения.

WebSphere Business Integration Message Broker поддерживает как SOAP/Http, так и SOAP/JMS, поэтому в основном инфраструктуру LGI изменять не пришлось. Будет достаточно просто заново разместить систему с использованием SOAP/JMS, для чего нужно изменить несколько SOAP-привязок и изменить несколько входных узлов и потоков сообщений в брокере. Это можно сделать при переводе инфраструктуры на версию 6 продуктов WebSphere и при использовании WebSphere Platform Messaging для соединения узлов семейства WebSphere. См. раздел 13.2, "Изменение инструментария и промежуточного ПО".