Обновление FileNet P8 с версии 3.5 на 4.0: Архитектурные перемены

Обеспечение высокой готовности, масштабируемости и разработки приложений

Новая версия IBM® FileNet® P8 4.0 принесла с собой значительные архитектурные перемены в платформе и инфраструктуре. Поэтому пользователи, желающие перейти на последнюю версию, должны понимать ключевые различия между новой и предыдущей версиями. В этой статье автор обсуждает вопросы архитектуры, готовности, масштабируемости и разработки, которые необходимо учесть при обновлении своей среды с версии 3.5 на 4.0.

Марк Гроссе, менеджер по техническим альянсам, IBM

Фотография Марка ГроссеМарк Гроссе (Marc Grosse) - менеджер по техническим альянсам в команде Global Technical Sales компании Enterprise Content Management (ECM), входящей в подразделение IBM Information Management. В настоящее время Марк работает с Accenture в области развития партнерского бизнеса, подбора решений и передачи навыков. Раньше он отвечал за техническую поддержку при наборе бизнес-партнеров и передачу навыков по набору продуктов OmniFind. Марк 3 года работает с IBM и имеет глубокие знания набора продуктов ECM. До поступления в IBM Марк 6 лет работал в области управления проектами, создавая совместно с поставщиками программного обеспечения пользовательские решения в области управления корпоративным контентом и управления бизнес-процессами. Марк имеет диплом технического специалиста по продажам решений для управления контентом и поиска контента. С ним можно связаться по адресу: mgrosse@us.ibm.com.



05.03.2011

Введение

В течение последних нескольких лет в проекте IBM FileNet Enterprise Content Management (ECM) были сделаны стратегические инвестиции в модернизацию предыдущей платформы FileNet ECM Panagon с целью улучшения масштабируемости и производительности и использования преимуществ стандартов J2EE. Новая версия IBM FileNet P8 4.0 разработана как платформа продуктов и решений, которые можно гибко применять в различных сценариях развертывания, включая операционные системы, серверы приложений, системы географически распределенных серверов и конечных пользователей. Эти усовершенствования сопровождаются значительными изменениями по сравнению с предыдущими версиями, которые были ограничены платформой Windows® и не приспособлены для использования стандартов J2EE.

Версия P8 4.0 включает более 75 новых функций, предназначенных для улучшения развертывания и разработки платформы. Учитывая это, в данной статье автор намеревается представить некоторые функции, к которым необходимо будет обращаться партнерам при переводе своих приложений и среды от предыдущей версии P8 3.5.2 к 4.0. Приведены конкретные инструкции и подробности, относящиеся к этим ключевым концепциям, со ссылками на документацию P8 4.0 или подробные технические статьи.


Обсуждение архитектуры

Версия FileNet P8 4.0 принесла с собой значительные архитектурные сдвиги в платформе и инфраструктуре. Хотя в механизме исполнения приложений (application engine - AE) архитектурных изменений нет, механизм содержимого (content engine - CE) претерпел существенные перемены. Данный компонент, который раньше был приложением C++, работающим как сервис Microsoft Windows, теперь реализован на Java™ и работает в среде сервера приложений J2EE. В результате CE может быть развернут в контейнере J2EE, который поддерживается соответствующими серверами приложений (полную информацию о совместимости см. в матрице поддержки оборудования и программного обеспечения). Теперь он независим от платформы и может работать во многих операционных системах (Windows, Linux®, UNIX®). Вдобавок новый J2EE CE может теперь использовать ресурсы, управляемые сервером приложений, такие как пулы соединений, EJB и Java connection architecture (JCA). Раньше эти компоненты должны были разрабатываться и управляться внутри CE. Для новых инсталляций конфигурация и развертывание CE остаются открытыми; однако при переходе от версии 3.5.2 CE к 4.0 CE необходимо учесть ряд важных соображений, в том числе следующие:

  • База данных глобальных конфигураций (Global Configuration Database - GCD), ранее хранившаяся в системе локальных файлов, переформатирована в XML-схему и хранится в базе данных, используемой CE. Это устраняет необходимость делать резервные копии GCD вручную, теперь ее можно включить в стандартные сценарии резервного копирования базы данных.
  • В то время как CE может работать на различных платформах, FileNet Enterprise Manager может работать только в среде Windows. Поэтому во время перехода необходимо выделить для среды 4.0 отдельную машину под Windows для администрирования механизмов содержимого и процессов. (Позже в этой статье будет дана ссылка на рассмотрение архитектуры механизма процессов (Process Engine - PE).
  • В версии 3.5.2 AE и CE сообщаются через протокол SOAP и порт 8008, установленный по умолчанию. В версии 4.0 эти механизмы могут взаимодействовать через установленный по умолчанию транспорт EJB либо через транспорт Web-сервисов. В большинстве развертываний эти два механизма будут разделены брандмауэром. Поэтому очень важно, чтобы в брандмауэре был настроен открытый порт под это взаимодействие.

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

Наконец, архитектура PE была изменена с целью использования взаимодействий CORBA ORB между компонентами серверов PE и CE. В частности, маршрутизаторы процессов (Process Routers) из версии 3.5 были заменены точками стыковки. Эти точки стыковки больше не являются процессами, протекающими под компонентом FileNet P8; теперь они хранятся в CE GCD и могут управляться из Enterprise Manager. В результате больше не требуется запуск и остановка маршрутизаторов процессов как сервисов в Windows Management Content, что упрощает ежедневное администрирование среды P8.


Масштабируемость и высокая готовность

В версии P8 4.0 появилась возможность реализации серверных комплексов и конфигураций с высокой готовностью для каждого из сервисов платформы (CE, AE, PE). В версии 3.5.2 компоненты CE и PE требовали кластерной конфигурации активный/пассивный. Хотя это решение рассматривалось как решение с высокой готовностью, оно не обладало масшабируемостью, так как запросы клиентов не могли быть распределены на несколько машин. Теперь CE не содержит отдельных сервисов Object и FileStore. Эти сервисы теперь расположены в приложении CE, развернутом на сервере приложений. Вдобавок множество CE, заключенных во множестве экземпляров J2EE-серверов, теперь могут быть расположены на одном физическом сервере. Фактически CE может поддерживать в сценариях множественного развертывания и горизонтальную кластеризацию, и высокую масшабируемость. Два ограничения для конфигураций с действительно высокой готовностью состоят в том, что в каждом серверном комплексе соответствующие операционные системы должны быть одинаковыми, и одинаковые серверы приложений J2EE должны быть одной версии.

Возможности вертикального и горизонтального масштабирования сервиса AE, который использовал спецификацию J2EE уже в версии 3.5.2, не изменились.

Несмотря на то, что PE в не является полностью J2EE-совместимым приложением, у него есть возможность горизонтального масштабирования, что устраняет необходимость использования кластеризацию активный/пассивный для этого компонента. Чтобы увеличить производительность и достигнуть большой готовности и быстродействия серверного комплекса с PE, перед комплексом можно разместить программную или аппаратную систему выравнивания нагрузки. При этом можно в любое время увеличивать или уменьшать количество серверов в комплексе при работающем PE. Более того, администрирование комплекса возможно с любого из серверов.


Соображения по разработке приложений

При переводе приложений с набора продуктов версии 3.5 на версию 4.0 партнерам нужно получить представление о доступных вариантах до того, как начинать модернизация. Механизм CE теперь содержит API 4.0 .NET и Java, а также следующие функции и возможности:

  • Поддержка сложных документов
  • Расширенная поддержка управления пакетами, запросами и транзакциями
  • Интеграция с JAAS
  • Коммуникации, использующие транспорт Web-сервисов, либо собственный EJB транспорт

Существующие приложения, использующие программные интерфейсы приложений Java и Web-сервисов из версии 3.5, которым не требуется использовать эти новые функции, могут просто работать в режиме обратной совместимости, обеспечиваемом уровнями совместимости, встроенными в архитектуру 4.0. Возможным эффектом такого подхода может быть то, что вызовы от API версии 3.5 сначала будут передаваться в API версии 4.0 и только затем в CE, что будет медленнее, чем вызов API версии 4.0 напрямую. Ущерб для производительности может быть минимальным и фактически зависящим от интенсивности транзакций.

Приложения, использующие COM API версии 3.x, могут воспользоваться обратной совместимостью, однако могут потребоваться дополнительные изменения в коде, так как некоторые методы и объекты не были удалены. Главное, что эти COM-приложения, которые выполняют запросы к базе данных CE с использованием ADO и провайдера OLEDB, должны будут перейти на API .NET или Java, так как эти функции не были расширены в слое совместимости. Поэтому API COM будет самым медленным интерфейсом в версии 4.0, так как эти вызовы переводятся в вызовы .NET, которые используют для сообщения со слоем CE EJB дополнительный компонент - приемник Web Services.

При миграции приложений, когда требуются новые функции версии 4.0, возможны два различных подхода. API Java укомплектованы таким образом, что партнеры могут параллельно использовать и 3.5 и 4.0. Приложение может продолжать использовать объектную модель версии 3.5 и обращаться к объектной модели версии 4.0 только для использования новых функций. Такой подход уменьшает как время разработки, так и время миграции. Другой подход заключается в полном переписывании приложения для использования Java API версии 4.0. Преимущество этого подхода в том, что Java API использует транспорт EJB - самый быстрый протокол связи для взаимодействия с CE. В общем рекомендуется, чтобы приложения, от которых требуется максимальная производительность, использовали собственный Java API версии 4.0 вместо слоев обратной совместимости.

При разработке клиентских приложений для платформы P8 партнеры могут иметь специальные модули, использующие имеющиеся в платформе возможности настройки. Версия P8 3.5 предоставляла возможность использовать ActiveScript для написания настроек Event Action для CE. В версии P8 4.0 эта возможность больше не поддерживается. Новая оболочка Event Action позволяет партнерам только регистрировать программы Java, связанные с событиями, выдаваемыми CE. Так как поддерживаются только модули Java, данные настройки должны быть переписаны на Java. Несмотря на это крупное изменение, использование JavaScript все еще поддерживается для операций, предшествующих установке, следующих за установкой, и импорта. Существующие программы на VBscript, написанные для платформы 3.5, должны быть переписаны на JavaScript.


Реализация безопасности в версии 4.0

Предыдущие версии P8 в большой степени полагались на передачу имени пользователя и пароля для идентификации и в CE, и в PE. Благодаря архитектурным изменениям в CE теперь доступно гораздо больше возможностей идентификации. Поддерживаемые сегодня два стандарта идентификации включают Java Authentication and Authorization Service (JAAS) и его аналог из Web Services - WS-Security.

JAAS, подключаемая инфраструктура J2EE, позволяет поставщикам серверов приложений и провайдерам идентификации реализовать пакеты идентификации для использования всеми J2EE-приложениями и клиентами. Теперь, так как CE развернут как приложение J2EE, он может использовать встроенные JAAS-модули, предоставленные поставщиком сервера приложений, чтобы передавать удостоверяющую информацию между существующим клиентским приложением и CE. Раньше и CE, и PE содержали код приложения для управления этими действиями по идентификации. В качестве дальнейшего расширения идентификации JAAS PE теперь не требует передавать удостоверяющую информацию от CE. Теперь PE полностью передоверяет идентификацию CE. Если JAAS идентифицировал запрос пользователя и передал его, то в PE передается идентификационная метка из CE для совершения любых требуемых для процесса транзакций.

Стандарты JAAS и WS-Security также влияют на реализацию заказчиками решений для единой регистрации в P8 версии 3.5. В связи с изменением архитектуры в версии 4.0 соответствующие специальные модули, разработанные в Extensible Authentication Framework (EAF), после обновления работать не будут. Следует провести анализ расхождений, сравнив специализированное решение SSO в версии 3.5 с модулем регистрации JAAS, предоставленным текущим поставщиком решения SSO, чтобы определить, содержит ли модуль JAAS SSO функциональность, применяемая для интеграции в конкретном решении SSO. Для приложений, использующих Web Services API, P8 4.0 предоставляет инфраструктуру Web Services Extensible Authentication Network (WS-EAF) для реализации решений SSO для типов идентификационных данных, которые не поддерживаются готовыми средствами. Дополнительную информацию по WS-EAF можно найти в онлайновой справке P8 4.0.

Инфраструктура EAF в P8 версии 3.5 также позволяла реализовать DLL-библиотеку со стороны клиента для использования SSO с интеграцией P8-Office. К сожалению, не существует общего подхода к обновлению с сохранением данной функциональности. Рекомендуется проанализировать WS-EAF, чтобы определить, можно ли перенести существующую функциональность с помощью данной инфраструктуры.


Заключение

Цель данной статьи - подчеркнуть технические аспекты, которые должны учитывать партнеры при переводе приложений или пользовательской среды с версии P8 3.5 на 4.0. Эти ключевые аспекты включают следующее:

  • Механизм содержимого P8 - J2EE-приложение, содержащееся в сервере приложений
  • Горизонтальное и вертикальное масштабирование механизма содержимого и механизма процессов
  • Реализация кэширования содержимого
  • Интеграция AAS и WS-Security
  • Расширенный слой совместимости для предыдущих приложений
  • Совместимость с Java в Event Action Framework

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=630821
ArticleTitle=Обновление FileNet P8 с версии 3.5 на 4.0: Архитектурные перемены
publish-date=03052011