Java EE 7 на большом железе - до 140 процессоров и 10 ТБ ОЗУ!

Очень хочу рассказать о том, что уже примерно год доступны все возможности Java EE 7 на большом железе, т.е. на вычислительной платформе, предоставляющей в ваше распоряжение до 140 процессоров и 10 ТБ оперативной памяти. Да, вы правы, речь идет о сервере приложений WebSphere Liberty Profile, работающем на мейнфрейме IBM z13.

• Установка сервера приложений на z/OS
  
  
• Стартовые процедуры для WebSphere Liberty Profile
  
  
• Получение доступа к авторизованным сервисам
  
  
• Подключение к DB2 с помощью JDBC Type 2
  
  
• Подключение к менеджеру очередей IBM MQ с использованием BINDINGS
  
  
• Используем подсистему безопасности z/OS в приложениях Java EE
  
  
• Сквозная аутентификация WebSphere Liberty Profile, z/OS и DB2
  
  
• Интеграция с Workload Manager'ом (WLM)
  
  
• Java EE 7
  
  
• Выводы

Установка сервера приложений на z/OS

Чтобы познакомиться с сервером приложений WebSphere Liberty Profile for z/OS достаточно выполнить несколько простых шагов:

1. Скачать последнюю бета-версию WebSphere Liberty beta for z/OS с сайта WAS Dev, на момент написания статьи актуальна апрельская бета-версия - wlp-beta-zos-2016.4.0.0.pax.
   
   
2. После передачи файла с версией на z/OS, необходимо выполнить команду в OMVS:
   
   
   cat wlp-beta-zos-2016.4.0.0.pax | pax -r -ppx
   
   
   
3. Создать экземпляр сервера приложений, для чего необходимо перейти в подкаталог bin каталога wlp, в который распаковалась версия, и выполнить команду:
   
   server create demoServer
   

Экземпляр сервера приложений успешно создан. По умолчанию, в файле конфигурации экземпляра сервера приложений - server.xml - отсутствует атрибут host="*" у тега httpEndpoint. Необходимо его добавить, чтобы можно было обратиться к серверу с клиентской машины.

Запустить сервер можно из OMVS, выполнив команду server start demoServer, однако в таком режиме не будут доступны все возможности тесной интеграции WebSphere Liberty Profile и операционной системы z/OS, такие как использование подсистемы безопасности SAF для управления аутентификацией и авторизацией пользователей; подключение к СУБД DB2 с помощью JDBC Type 2; подключение к менеджеру очередей IBM MQ с помощью байндинга, а не TCP/IP; интеграция с Workload Manager'ом (WLM) - компонентом z/OS, управляющем нагрузкой во многозадачной среде, позволяющем задавать цели для производительности практически каждого ресурса внутри вашего приложения; оптимизированные локальный адаптеры WOLA, позволяющие настроить взаимодействие между сервером приложений и бизнес-логикой, реализованной в виде пакетного задания или внутри CICS или IMS, с обменом данными через общую память без необходимости осуществлять взаимодействие между приложениями посредством сетевых соединений и тяжелых протоколов обмена, таких как SOAP. Нужно запускать сервер с помощью стартовой процедуры.

Стартовые процедуры для WebSphere Liberty Profile

Среда исполнения сервера приложений WebSphere Liberty Profile в операционной системе z/OS представлена двумя типами процессов: процессом сервера и специальным процессом, называемым ангелом.

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

Ангел - работает в авторизованном ключе и предоставляет возможности процессам сервера загружать и получать защищенный доступ к сервисам операционной системы. Ангел не требует каких-либо файлов конфигурации и работает в системе независимо от процессов сервера. Все экземпляры сервера приложений WebSphere Liberty Profile используют единственный процесс ангела, запущенный на одном образе z/OS вместе с ними. Ангел может быть запущен только с помощью стартовой процедуры.

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

MODIFY [jobname.]identifier,display,servers

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

Чтобы создать стартовую процедуру для процесса сервера, необходимо cкопировать файл bbgzsrv из шаблона wlp/templates/zos/procs в PROCLIB:

cp wlp/templates/zos/procs/bbgzsrv.jcl "//'WASPRF.PROCLIB(WLPZSRV)'"

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

cp wlp/templates/zos/procs/bbgzangl.jcl "//'WASPRF.PROCLIB(WLPZANGL)'"

В тексте стартовой процедуры сервера необходимо отредактировать параметры INSTDIR - путь к каталогу с установленным WebSphere Liberty Profile, можно воспринимать эту переменную как WLP_INSTALL_DIR, и USERDIR - путь к области пользователя WLP, если DD WLPUDIR определена, то она по умолчанию ассоциируется с USERDIR. Так же можно раскомментировать определение DD STDENV - путь к файлу или набору данных, содержащему определения переменных окружения, например - JAVA_HOME:

//STDENV DD PATH='&INSTDIR./etc/system.env',PATHOPTS=(ORDONLY)

В тексте стартовой процедуры ангела необходимо отредактировать значение параметра ROOT - указать путь к каталогу с установленным продуктом.

После редактирования стартовых процедур, их необходимо проассоциировать с соответствующими пользователями. Создадим пользователя WLPSERV, под которым будут запускаться процессы сервера, и - WLPANGL для запуска ангела. Ниже приведены соответствующие команды RACF.

ADDGROUP WLPGROUP OMVS(GID(2667))

ADDUSER WLPSERV DFLTGRP(WLPGROUP) OMVS(UID(2778) HOME(/u/wlpserv) 
    PROGRAM(/bin/sh)) NAME('WLP USER') NOPASSWORD NOOIDCARD

ADDUSER WLPANGL DFLTGRP(WLPGROUP) OMVS(UID(2779) HOME(/u/wlpangl) 
    PROGRAM(/bin/sh)) NAME('WLP ANGEL USER') NOPASSWORD NOOIDCARD

RDEFINE STARTED WLPZSRV.* STDATA(USER(WLPSERV) GROUP(WLPGROUP) TRACE(YES))
RDEFINE STARTED WLPZANGL.* STDATA(USER(WLPANGL) GROUP(WLPGROUP) TRACE(YES))
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH

После внесения необходимых изменений в базу RACF можно запускать сервера.

Запуск ангела:

/s wlpzangl

Запуск сервера:

/s wlpzsrv,parms='demoServer'

Получение доступа к авторизованным сервисам

Пользователь, под которым запущен процесс сервера, должен иметь необходимые права на подключение к ангелу. Только в этом случае процесс сервера получает доступ к авторизованным сервисам операционной системы, таким как SAF, RRS, WLM и т.д. Выдать права можно с помощью следующих команд RACF:

RDEFINE SERVER BBG.ANGEL UACC(NONE)
PERMIT BBG.ANGEL CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Далее необходимо выдать общие права на доступ к авторизованным сервисам:

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Подключение к DB2 с помощью JDBC Type 2

В операционной системе z/OS сервер приложений очень часто взаимодействует с запущенной в том же образе операционной системы СУБД с помощью драйверов JDBC Type 2. Данный тип драйвера использует нативные для операционной системы библиотеки и осуществляет взаимодействие с СУБД через механизм т.н. cross-memory service'ов - вызовов специальных машинных инструкций, что освобождает как от необходимости задействовать протокол TCP/IP и loopback интерфейс, так и дорогостоящий стек межпроцессного взаимодействия (IPC).

Восстановление транзакций при использовании JDBC Type 2 осуществляется с помощью механизма z/OS Resource Recovery Services (RRS). Пользователь, под которым запущен процесс сервера WebSphere Liberty Profile, должен иметь соответствующие права для работы с RRS. Выдать права можно с помощью RACF:

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.TXRRS UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM.TXRRS CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Фрагмент файла конфигурации server.xml, отвечающий за подключение к СУБД:

<?xml version="1.0" encoding="UTF-8" ?>
<server description="JDBC Type 2 DataSource definition">
    <featureManager>
        <feature>jdbc-4.1</feature>
        <feature>zosTransaction-1.0</feature>
    </featureManager>

    <nativeTransactionManager shutdownTimeout="20s" 
                              resourceManagerNamePrefix="DEMOS"/>

    <library id="DB2T2LibRef">
        <fileset dir="/usr/lpp/db2b10/jdbc/classes"/>
        <fileset dir="/usr/lpp/db2b10/jdbc/lib"/>
    </library>

    <jdbcDriver id="DB2T2" libraryRef="DB2T2LibRef"/>

    <dataSource id="jdbc/test" jndiName="jdbc/test" jdbcDriverRef="DB2T2" 
                type="javax.sql.ConnectionPoolDataSource">
        <connectionManager maxPoolSize="10" minPoolSize="0" connectionTimeout="10s" />
        <properties.db2.jcc driverType="2" databaseName="DB0A" />
    </dataSource>
</server>

В данном фрагменте интересны следующие элементы:

Компоненты jdbc-4.1 содержащий определение базовых интерфейсов спецификации JDBC 4.1, являющейся частью Java EE 7, и zosTransaction-1.0, реализующий взаимодействие с RRS и необходимый при использовании JDBC Type 2.

nativeTransactionManager - управляет регистрацией и разрегистрацией ресурсов, задействованных сервером, в RRS. Атрибут shutdownTimeout задает время ожидания сервером завершения активных транзакций при его выключении или при деактивации компонента zosTransaction-1.0. Атрибут resourceManagerNamePrefix задает часть имени ресурса, под которым менеджер ресурсов, созданный сервером, регистрируется в RRS. Только авторизованные пользователи могут выполнять работы над транзакциями (нормальная обработка или восстановление), вовлекая ресурсы RRS, соответственно пользователь, под которым запущен процесс сервера, должен иметь соответствующие права:

RDEFINE SERVER BBG.RMNAME.DEMOS.RRS UACC(NONE)
PERMIT BBG.RMNAME.DEMOS.RRS CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

library - определение библиотеки, содержащей драйвер для доступа к DB2 for z/OS. Поскольку будет использован драйвер JDBC Type 2, то в определение необходимо добавить путь к нативным компонентам.

jdbcDriver - определение драйвера для доступа к DB2 for z/OS.

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

Подключение к менеджеру очередей IBM MQ с использованием BINDINGS

Менеджер очередей IBM MQ поддерживает два типа транспорта - CLIENT, используется клиентами, работающими на удаленных машинах и осуществляющими взаимодействие с менеджером посредством канала, и - BINDINGS, используется клиентами, работающими на том же образе операционной системы и осуществляющими взаимодействие с менеджером через общую память. Ниже приведен фрагмент файла конфигурации server.xml, содержащий настройки подключения к IBM MQ с использованием BINDINGS.

<?xml version="1.0" encoding="UTF-8" ?>
<server description="JMS MQ configuration">
    <featureManager>
        <feature>wmqJmsClient-2.0</feature>
        <feature>jndi-1.0</feature>
    </featureManager>

    <variable name="wmqJmsClient.rar.location"
              value="/u/pavel/java/wlp/lib/mq/wmq.jmsra.rar"/>

    <wmqJmsClient nativeLibraryPath="/usr/lpp/mq/java/lib"/>    

    <jmsConnectionFactory jndiName="jms/mqzos-connection-factory">
        <properties.wmqJms transportType="BINDINGS" 
                           queueManager="QMSP"/>

        <connectionManager maxPoolSize="10"/>
    </jmsConnectionFactory>

    <jmsQueue id="CICSQueue" jndiName="jms/cicsqueue">
        <properties.wmqJms baseQueueName="CICS01.INITQ"
                           baseQueueManagerName="QMSP"/>
    </jmsQueue>

    <jmsActivationSpec id="sync-to-os-thread-demo-1.0-SNAPSHOT/MessageListenerActivationSpec">
        <properties.wmqJms
            destinationRef="CICSQueue"
            transportType="BINDINGS"
            queueManager="QMSP"/>
    </jmsActivationSpec>
</server>

В данном фрагменте интересны следующие элементы:

Компоненты wmqJmsClient-2.0, необходимый для подключения к менеджеру очередей IBM MQ, и jndi-1.0, необходимый для регистрации фабрики соединений, очереди и спецификации активации в реестре JNDI. Для работы приложения, cодержащего управляемые сообщениями компоненты - MDB, необходимо так же активировать ejbLite-3.2 и jmsMdb-3.2.

JCA 1.7-адаптер wmqJmsClient.rar необходим для подключения к менеджеру очередей IBM MQ, версию адаптера 8.x, поддерживающую спецификацию JMS 2.0, можно скачать с сайта FixCentral.

wmqJmsClient - путь к нативным библиотекам клиента IBM MQ, необходим для подключения к менеджеру очередей в режиме BINDINGS.

jmsConnectionFactory - определение фабрики соединений. Фабрика регистрируется в JNDI под заданным именем. Определение фабрики содержит два вложенных свойства: properties.wmqJms задает используемый тип транспорта и имя менеджера очередей, а свойство connectionManager - настройки пула соединений с менеджером очередей, в данном примере будет создан пул, содержащий до 10-ти соединений.

jmsQueue - определение очереди, очередь регистрируется в JNDI под заданным именем. Определение содержит вложенное свойство, задающее название очереди MQ, которая будет доступна приложениям, и имя менеджера соединений.

jmsActivationSpec - определение спецификации активации, необходимой для работы управляемого сообщениями компонента (MDB). Идентификатор спецификации должен совпадать с именем компонента, в данном случае это - полное наименование WAR-модуля, в котором содержится компонент, и имя самого компонента, заданное в качестве параметра name аннотации @MessageDriven. Определение спецификации активации содержит свойство, задающее ссылку на очередь, которая будет прослушиваться, тип используемого транспорта для подключения к менеджеру очередей и имя этого менеджера очередей.

Используем подсистему безопасности z/OS в приложениях Java EE

System authorization facility (SAF) - интерфейс, определенный в операционной системе z/OS, разрешающий программам использовать системные сервисы авторизации для управления доступа к ресурсам, таким как данные и команды операционной системы. SAF обрабатывает запросы на авторизацию самостоятельно или использует RACF или другой сервер безопасности для обслуживания таких запросов.

WebSphere Liberty Profile может использовать SAF как механизм аутентификации и авторизации пользователей, в таком случае становятся доступны такие возможности, как распространение данных о пользователе из сервера приложений в другие приложения, запущенные в том же образе z/OS, например СУБД DB2, или в саму операционную систему. Что это значит на практике? Пользователь, заполнив форму, содержащую логин и пароль, аутентифицируется, а затем авторизуется в приложении. Если на странице приложения выполняется запрос в DB2, то этот запрос, при правильных настройках сервера приложений, будет выполнен под именем данного пользователя, аналогично запрос к операционной системе на чтение/запись файла или запуск пакетного задания (JOB), так же будет выполнен под именем данного пользователя.

Поскольку SAF - это авторизованный сервис z/OS, то для доступа к нему процесс сервера должен иметь соответствующие права:

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.SAFCRED UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM.SAFCRED CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Для включения безопасности приложений в WebSphere Liberty Profile необходимо активировать в файле конфигурации server.xml следующие компоненты: appSecurity-2.0 и zosSecurity-1.0.

Аутентификация

В файле конфигурации server.xml должен быть определен реестр пользователей SAF, делается это с помощью элемента safRegistry.

Чтобы пользователь мог аутентифицироваться в WebSphere Liberty Profile, он должен иметь право на чтение из некоторого ресурса в классе APPL. По умолчанию этот ресурс называется BBGZDFLT, но его можно изменить, указав нужное значение атрибута profilePrefix элемента safCredentials файла конфигурации server.xml. Неаутентифицированный пользователь - пользователь по умолчанию, например WSGUEST - так же должен иметь соответствующие права. Права выдаются с помощью следующих команд RACF:

// Определяем CBS390 APPLID в RACF.
RDEFINE APPL CBS390 UACC(NONE)

// Активируем APPL класс
// Если не активирован, то домен не защищен, любой пользователь может аутентифицироваться 
SETROPTS CLASSACT(APPL)

// Все пользователи, которым нужно аутентифицироваться, должны иметь право READ
// на APPLID в классе APPL:
PERMIT CBS390 CLASS(APPL) ACCESS(READ) ID(<serverUserId>)

// Неаутентифицированный пользователь так же требует права READ
// на APPLID в классе APPL:
PERMIT CBS390 CLASS(APPL) ACCESS(READ) ID(WSGUEST)

SETROPTS RACLIST(APPL) REFRESH

Поскольку пользователь аутентифицируется в z/OS, используя централизованный компонент, то само приложение, через которое пользователь делает это, должно иметь права аутентифицировать кого-то в системе. Для этого пользователь, под которым запущен процесс сервера WebSphere Liberty Profile, должен иметь право READ на ресурс BBG.SECPFX.<APPLID> в классе SERVER:

RDEFINE SERVER BBG.SECPFX.CBS390 UACC(NONE)
PERMIT BBG.SECPFX.CBS390 CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Авторизация

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

<safAuthorization id="saf"/>

При авторизации происходит сопоставление аутентифицированного пользователя с заданной в настройках приложения ролью, для которой разрешен доступ к запрашиваемому ресурсу. Роль приложения отображается на SAF-профиль в классе EJBROLE с помощью SAF role mapper. По умолчанию, имя SAF-профиля генерируется по следующему шаблону: {profilePrefix}.{resource}.{role}. Если аутентифицированный пользователь имеет право доступа READ на соответствующий профиль, то авторизация осуществляется успешно.

Рассмотрим пример:
- в элементе safCredentials прописан profilePrefix="BBGZDFLT";
- имя ресурса приложения, например имя самого приложения, задано как "MYAPP";
- имя роли, определенной в приложении, равно "ADMIN"

тогда пользователь должен иметь право READ на профиль BBGZDFLT.MYAPP.ADMIN, определенный в классе EJBROLE.

Чтобы сервер приложений мог запрашивать проверки прав доступа на профили в классе EJBROLE, пользователь, под которым запущен процесс сервера, должен иметь право READ на ресурс BBG.SECPFX.<HLQ> в классе SERVER. HLQ в данном случае - первый квалификатор (до первой точки) профиля в классе EJBROLE, доступ к которому проверяется. Если данный квалификатор совпадает с квалификатором по умолчанию - BBGZDFLT, то получается что права сервера на осуществление как аутентификации, так и авторизации управляются одним и тем же ресурсом BBG.SECPFX.BBGZDFLT.

Попробуем собрать все знания воедино:

<?xml version="1.0" encoding="UTF-8" ?>
<server description="SAF security definition">
    <featureManager>
        <feature>appSecurity-2.0</feature>
        <feature>zosSecurity-1.0</feature>
    </featureManager>

    <safRegistry id="saf" />

    <safAuthorization id="saffer"/>

    <!-- trying to use WAS Classic permissions -->
    <safCredentials unauthenticatedUser="CZGUEST" profilePrefix="CBS390"/>

Мэпинг ролей

Если заданное по умолчанию правило мэпинга ролей приложений на профили в классе EJBROLE по каким-то причинам не устраивает, то можно изменить правило, определив в файле конфигурации server.xml элемент safRoleMapper, имеющий два атрибута: profilePattern - задает правило мэпинга, может содержать как строковые константы, так и переменные %role% - роль приложения, %resource% - название ресурса, например название приложения, %profilePrefix% - определенный в элементе safCredentials префикс. Атрибут toUpperCase задает требование к мэперу конвертировать все значения в заглавные буквы, соответственно, если его значение выставлено в true, то в RACF необходимо определять профили заглавными буквами.

<safRoleMapper profilePattern="myprofile.%resource%.%role%" 
               toUpperCase="true" />

В RACF необходимо раздать права пользователям на доступ к профилю MYPROFILE.SYNC-TO-THREAD.PRIVATEZONE (sync-to-thread - название приложения, privatezone - имя роли, upper case включен). Сделать это можно следующими командами:

RDEFINE EJBROLE MYPROFILE.SYNC-TO-THREAD.PRIVATEZONE UACC(NONE)
PERMIT MYPROFILE.SYNC-TO-THREAD.PRIVATEZONE CLASS(EJBROLE) ID(ROOT) ACCESS(READ)
SETROPTS RACLIST(EJBROLE) GENERIC(EJBROLE) REFRESH

Сквозная аутентификация WebSphere Liberty Profile, z/OS и DB2

По умолчанию, команды операционной системы из приложений, развернутых на сервере WebSphere Liberty Profile for z/OS, выполняются от имени пользователя, под которым запущен процесс сервера. Под этим же пользователем осуществляется соединение с базами данных, например DB2 или IMS с использованием JDBC Type 2. Но можно настроить сервер приложений таким образом, чтобы обеспечить сквозную аутентификацию: пользователь вашего приложения аутентифицируется на сервере и под этим же именем соединяется с базой данных и выполняет команды в операционной системе: создает файлы в USS (например с логами), работает с наборами данных, а также запускает на выполнение пакетные задания (JOB'ы). Официально данная возможность называется SyncToOSThread.

SyncToOSThread для Type 2 J2C соединений

Речь идет о подключениях к СУБД или другим приложениям с использованием JCA-адаптеров.

В файле конфигурации server.xml должны быть активированы компоненты appSecurity-2.0 и zosSecurity-1.0. В конфигурацию сервера приложений должен быть добавлен элемент syncToOSThread с атрибутом j2cEnabled="true".

SyncToOSThread для приложений

Включение SyncToOSThread для приложений позволяет запускать процессы в операционной системе, а также работать с файлами и наборами данных от имени аутентифицированного пользоватьеля. Для включения этой возможности в файле конфигурации server.xml должны быть активированы компоненты appSecurity-2.0 и zosSecurity-1.0. В конфигурацию сервера приложений должен быть добавлен элемент syncToOSThread с атрибутом appEnabled="true".

В дескрипторе развертывания web.xml приложения должны присутствовать следующие строки:

<env-entry>
    <env-entry-name>com.ibm.websphere.security.SyncToOSThread</env-entry-name>
    <env-entry-type>java.lang.Boolean</env-entry-type>
    <env-entry-value>true</env-entry-value>
</env-entry>

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

Вариант 1:

RDEFINE FACILITY BBG.SYNC.<profilePrefix> UACC(NONE)
PERMIT BBG.SYNC.<profilePrefix> ID(<serverUserId>) ACCESS(CONTROL) CLASS(FACILITY)
SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH

Данные права позволяют серверу синхронизировать информацию с операционной системой для всех пользователей.

Вариант 2:

RDEFINE FACILITY BBG.SYNC.<profilePrefix> UACC(NONE)
PERMIT BBG.SYNC.<profilePrefix> ID(<serverUserId>) ACCESS(READ) CLASS(FACILITY)
SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH

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

RDEFINE SURROGAT BBG.SYNC.<runAsUserId> UACC(NONE)
PERMIT BBG.SYNC.<runAsUserId> ID(<serverUserId>) ACCESS(READ) CLASS(SURROGAT)
SETROPTS RACLIST(SURROGAT) GENERIC(SURROGAT) REFRESH

Здесь profilePrefix - значение атрибута profilePrefix элемента safCredentials файла конфигурации server.xml, по умолчанию - BBGZDFLT.

Подробно про настройку сквозной аутентификации для WebSphere Application Server Classic я писал ранее.

Интеграция с Workload Manager'ом (WLM)

Современные мейнфреймы могут содержать до 140 процессоров, десяток терабайт оперативной памяти и множество каналов ввода-вывода. При этом на мейнфреймах исполняются сотни и тысячи приложений, каждое из которых имеет свое назначение (продуктивное приложение, тестовое, на отладке), режим исполнения (пакетное задание или транзакционная обработка), профиль нагрузки, требования к ресурсам и критичность для бизнеса. Компонент операционной системы z/OS под названием Workload Manager (WLM) предоставляет механизм по разделению всего потока работ на классы. Для каждого класса можно задать свой набор целей по достижению требуемой производительности. WLM будет автоматически распределять ресурсы мейнфрейма между исполняющимися задачами для того, чтобы заданные цели были достигнуты.

Поскольку WLM - это авторизованный сервис z/OS, то для доступа к нему процесс сервера приложений WebSphere Liberty Profile должен иметь соответствующие права, т.к. операционная система не может позволить любому пользователю выполнять классификацию работ, вмешиваясь в один из своих основных компонентов. Выдать эти права можно с помощью следующих команд RACF:

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.ZOSWLM UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM.ZOSWLM ID(<serverUserId>) ACCESS(READ) CLASS(SERVER)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Для использования WLM в файле конфигурации server.xml должен быть активирован компонент zoswlm-1.0.

Все ресурсы, развернутые на сервере приложений, доступны для классификации, т.е. для назначения соответствующего сервисного класса. Правила классификации описываются тут же в файле server.xml, в элементе wlmClassification.

<?xml version="1.0" encoding="UTF-8" ?>
<server description="WLM configuration">
    <featureManager>
        <feature>zoswlm-1.0</feature>
    </featureManager>

    <wlmClassification>
        <httpClassification transactionClass="DBMTRAT2" resource="/sync-to-thread/dbtest/t2" />
        <httpClassification transactionClass="DBMTRAT4" resource="/sync-to-thread/dbtest/t4" />
        <httpClassification transactionClass="DBMDTRAN" />
    </wlmClassification>

    <zosWorkloadManager collectionName="CZSR01" />
</server>

Если необходимо назначить, например для протокола HTTP, класс по умолчанию, т.е. класс, присваиваемый ресурсам, для которых не нашлось более подходящего класса, то последним правилом в wmlClassification добавляется соответствующий тег (для HTTP - httpClassification) без указания ресурса или виртуального хоста, имени сервера или порта, вообще любых классификационных признаков.

В классификации запросов на подсистему CB - WebSphere Application Server - участвует также параметр, называемый collection name. Для WebSphere Classic это - короткое имя кластера, в который входит экземпляр сервера, обрабатывающий нагрузку. Для WebSphere Liberty Profile, по умолчанию, collection name - это имя каталога, в котором содержится файл конфигурации server.xml, при этом, если это имя длиннее восьми символов, то очень сложно грамотно настроить WLM - придется задавать вложенные правила, каждое из которых выбирает свои очередные восемь символов из имени сервера. Однако, можно явно определить collection name для сервера, добавив в файл конфигурации server.xml элемент zosWorkloadManager, у которого определить значение для атрибута collectionName.

Если классификация настроена правильно и все необходимые права доступа пользователям предоставлены, то для подсистемы CB будут создаваться энклавы:

Можно проверить, правильно ли назначаются сервисные классы данным энклавам.

Java EE 7

А что же с Java EE 7? Для проверки соответствия сервера приложений данной спецификации воспользуемся небольшим приложением, разработанным Адамом Бином - известным евангелистом Java EE. Server Smoke представляет собой небольшое JSF 2.2 - приложение, активно использующее EJB и CDI, а также JAX-RS сервис. Архив с собранным приложением можно скачать по ссылке и поместить в каталог apps сервера приложений. Затем - зарегистрировать в файле конфигурации server.xml:

<application context-root="server-smoke" type="war" id="server-smoke" 
             location="server-smoke.war" 
             name="server-smoke"/>

Для корректной работы приложения необходимо активировать следующие компоненты, входящие в Java EE 7 WebProfile: cdi-1.2, jaxrs-2.0, jsonp-1.0, jsf-2.2. После этого, сервер сможет сказать нам, что он не курит:

Выводы

Прошли те времена, когда мейнфреймы IBM могли исполнять только программы, написанные на COBOL, PL/1 или ASSEMBLER. Современные мейнфреймы - это вычислительная платформа, обеспечивающая беспрецедентные характеристики производительности и высокой доступности для ваших приложений, написанных на Java 8 и использующих все преимущества Java EE 7.

Так же стоит отметить, что WebSphere Liberty Profile не требует несколько гигабайт места на DASD для своей установки и развертывания, не нужно создавать профили, регистрировать менеджеры узлов, разворачивать приложения с помощью WAS Admin или консоли администрирования и выполнять другие затратные с точки зрения человеческих ресурсов операции. Архив с сервером приложений в версии для z/OS весит буквально 160 Мб, что объясняется лишь тем, что в данную версию включены практически все компоненты, предоставляемые продуктом, в том числе и специфичные для операционной системы. Во время исполнения достаточно лишь активировать те компоненты, которые нужны для работы именно ваших приложений, что позволяет существенно, в десятки раз, снизить время запуска сервера и объем потребляемой памяти. Конечно, можно вспомнить о доступных на мейнфрейме 10 Тб ОЗУ, но и им можно найти лучшее применение, нежели держать классы сервера приложений, никем не используемые.

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

При этом интеграция с операционной системой осталась на том же высочайшем уровне, что и у "большого брата". Все уникальные возможности z/OS, такие как аутентификация и авторизация с помощью SAF; размещение данных (СУБД) и механизмов их обработки (сервер приложений) вместе (collocation) и использование JDBC Type 2 и, соответственно, cross-memory service'ов для доступа к данным; классификация огромного потока задач и управление ими с целью достижения заданной производительности с помощью WLM доступны и для WebSphere Liberty Profile.

Не рассмотренной в статье осталась тема использования высокопроизводительных, оптимизированных локальных адаптеров (WOLA) для доступа из сервера приложений к бизнес-логике, реализованной в виде пакетных заданий и программ на CICS или IMS, а также такой относительно новый продукт IBM как z/OS Connect, открывающий ваши традиционные приложения современному и динамичному миру мобильных вычислений с помощью RESTful API и JSON. Оставайтесь на связи!

Понравилось сообщение - подпишитесь на блог