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

Это, в частности, следующие аспекты:

• отделение бизнес-процесса от реализации компонентов,

• наличие архитектуры, ориентированной на безопасность,

• наличие архитектуры, основанной на политиках,

• унифицированная среда информации и данных (уже представленная как SID),

• прозрачность распределения.

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

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

Существующие системы поддержки операционной деятельности — OSS — обычно создаются для узко специализированного применения в соответствии с потребностями конкретного предприятия. Напротив, OSS, которые включают в себя системы управления на основе политик (policy - based), учитывают более широкий комплекс требований. Функциональность OSS, управляемых с помощью политик (policy-managed), будет ограничивать­ся в зависимости от требований конкретного пользователя в соответствии с политиками, заложенными в систему.

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

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

• Для корреляции управленческих операций необходимо иметь одну или несколько специальных координирующих систем.

• Одна система управления не может решать весь комплекс уникальных для каждого компонента проблем в рамках распределенной системы.

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

В системах, которые демонстрируют один (или более) из перечисленных признаков, отказы более вероятны, потому что в них нет никакого резерв­ного механизма управления на случай отказа основной системы управле­ния. Системы управления, основанные на политиках (policy-based), изна­чально предназначались для решения проблем из приведенного выше списка. К тому же они имеют еще два преимущества. Во-первых, они расширяют возможности повторного использования систем управления. Во-вторых, они повышают общий уровень эксплуатационной готовности систем и подсистем.

Так, в систему (приложение) NGOSS необходимо встраивать ту или иную форму политики. Это можно сделать или просто путем добавления полити­ки (моделирование политики) или с помощью некой совокупности правил, определяемых пользователем.

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