Дипломная работа: Автоматизированная система управления документооборотом центральной заводской лаборатории. Подсистема регистрации и сопровождения заказов на испытания

1.2.3.3 Служба каталогов

Служба каталогов организует доступ к динамическому списку ресурсов всего предприятия. Когда пользователь или клиентское приложение формирует запрос, служба каталогов обрабатывает его и сообщает клиенту, каким образом взаимодействовать с соответствующим ресурсом. Для того, чтобы объект можно было найти в системе, тот должен быть зарегистрирован, как DCOM‑объект. При этом это дает требуемую гибкость, характерную для трехзвенных систем – мы просто указываем объект, и – в соответствии с каталогом представляется тот компьютер, на котором будет исполняться код. В результате такой гибкости становится возможной и балансировка загрузки – можно предоставить тот компьютер, который в данный момент меньше всего загружен работой.

1.2.3.4 Сервис безопасности

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

1.2.3.5 Служба управления приложениями

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

1.2.3.6 Интерфейс приложений

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

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

Для того чтобы разработчик мог использовать программные инструменты от различных производителей (например, Java, C++, Delphi и т.п.) для определения интерфейсов распределенных объектов применяется специальный язык определения интерфейсов IDL. Для разных стандартов (CORBA, DCOM, DCE) этот язык несколько отличается, но главный его смысл – он нужен для однозначного определения интерфейса взаимодействия модулей между собой.

1.2.3.7 Гранулированность информационной системы

За высокую гранулированность в системе приходится платить производительностью (динамическое связывание объектов требует затрат процессорного времени), а если система разбита на слишком крупные гранулы, уменьшается степень повторного использования кода, что нежелательно. CORBA, DCOM, DCE подталкивают разработчика к разбиению системы на мелкие гранулы (или объекты, что более правильный термин). Приложения серверного слоя также могут дополнительно разбиваться на гранулы-объекты, статически связываемые в период проектирования (компилирование приложения). Как правило, продукт от каждого производителя ориентирован на соответствующую архитектуру объектов (CORBA, DCOM, DCE), так Entera ориентирована на DCE, MIDAS – на DCOM, ORBIX – на CORBA.

Объектные трехзвенные архитектуры DCE, CORBA, DCOM предлагают реально действующие стандарты для построения трехзвенных приложений. Существующие серверы приложений, которые не поддерживают этих архитектур, предлагают свои внутренние механизмы для построения трехзвенной архитектуры. Перед тем, как выбрать, в какой архитектуре строить свою информационную систему, корпоративный разработчик обязан ясно представлять себе, какую цену он заплатит за соответствие архитектуре, то есть необходимо хорошо представлять себе не только плюсы соответствующей архитектуры, но и ее минусы.

1.2.3.8 Минусы трехзвенных архитектур

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

– непроработанность архитектуры;

- тяжелые в реальности решения;

- несоответствие с уже имеющимися технологиями;

- неустойчивость версий стандартов, а, следовательно, потенциальная несовместимость;

- недоразвитость инструментов (неудобство, ошибки);

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

Рассмотрим два основных вида объектных архитектур DCE и DCOM. DCE – это распределенная архитектура появившаяся раньше DCOM.

Исходная UNIX-ориентированность технологии DCE, ее некоторая громоздкость, ее ориентированность только на язык С, отсутствие системы управления приложениями – это очевидные минусы.

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

DCOM – закрытая архитектура с закрытым протоколом. Может использоваться только в рамках данной реализации, соотношения между объектными сервисами обладают очевидными недостатками. Производителем DCOM является компания Microsoft.

Но недостатки архитектуры так же, как и в случае DCE, можно исправить удачно сделанными продуктами. Inprise MIDAS вносит необходимую гибкость в архитектуру, снабжая ее необходимым инструментарием и утилитами.

1.2.3.9 Тонкие и толстые клиенты

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

Тонким клиентом называют также и стандартные internet‑клиенты, которые в интрасетях действительно занимаются только отображением / представлением данных, хотя и не являются объектами, соответствующими архитектурам DCE, CORBA, DCOM. Эти два типа клиентов различаются не столько по объему кода, сколько по способу их применения в течение жизни информационной системы. Трехзвенная архитектура предназначена для того, чтобы внести расширяемость и масштабируемость в информационные системы. Системы, которым нужны эти качества, никогда не бывают полностью завершены, и в течение жизненного цикла всегда подвергаются изменениям. Тонкие клиенты первого типа также подвергаются изменениям с изменениями системы и, должны время от времени заменяться новыми, более модифицированными версиями. Тонкие клиенты второго типа (ультратонкие) могут не заменяться в течение жизненного цикла системы, поэтому обслуживание интранет-системы несравненно проще трехзвенной системы, построенной без применения стандартных тонких клиентов. В принципе, никакого противоречия тут нет, и можно было бы построить ультратонкого клиента и для DCE, CORBA, DCOM.