В данной заметке описано как настроить JCA-адаптеры Oracle SOA Suite для обеспечения гарантированного порядка обработки сообщений в кластерном окружении.
При интеграции информационных систем, особенно унаследованных, часто приходится обеспечивать взаимодействие с ними через базу данных. В состав Oracle SOA Suite входят адаптеры, реализованные с помощью технологии JCA, позволяющие считывать события из базы данных. Примерами таких адаптеров являются DB- и AQ-адаптеры.
При этом считывать и обрабатывать события иногда важно в том же порядке, в котором они были сгенерированы в системе и, соответственно, записаны в базу данных. Рассмотрим пример: в информационной системе создается объект, например некое начисление на абонента. Затем данный объект модифицируется, а после этого удаляется (начисление было сделано по ошибке). Очевидно, что сообщение об удалении объекта ни в коем случае не должно быть передано в систему-приемник раньше, чем сообщение о его создании, т.к. в данном случае будет нарушена целостность данных.
Для обеспечения гарантированного порядка считывания сообщений необходимо сделать так, чтобы JCA-адаптер работал в один поток и присутствовал в кластере в единственном экземпляре. Для управления количеством потоков, в которые происходит считывание записей из базы, служит параметр NumberOfThreads. По-умолчанию его значение равно единице, т.е. каждый экземпляр адаптера работает в один поток. Для управления количеством экземпляров, запущенных на одном WebLogic-сервере, служит параметр activationInstances. По-умолчанию значение данного параметра так же равно единице: на каждом сервере создается один экземпляр адаптера. Таким образом для обеспечения гарантированного порядка считывания сообщений в среде с одним сервером приложений достаточно использовать значения параметров по-умолчанию, однако в кластерном окружении на каждом сервере будет запущен свой экземпляр адаптера, что может привести к нарушению порядка считывания сообщений, т.к. каждый экземпляр сервера приложений в кластере работает независимо от других. Для того, чтобы адаптер работал только на одном сервере, необходимо выставить для него значение параметра singleton в true.
При этом, в случае аварийного либо планового прекращения работы данного сервера, будет осуществлена миграция адаптера на другой сервер кластера.
На рисунке выше видно, что цифра в старшем разряде Instance ID изменилась, что свидетельствует о создании экземпляров композита другим сервером.
Важно! При миграции экземпляра адаптера на другой сервер возможна ситуация, когда адаптер сначала запустится на новом сервере, а лишь затем перестанет работать на останавливаемом. Т.е. некоторое время работать будут два экземпляра адаптера, что может привести к повторной обработке некоторых записей. Чтобы избежать повторной обработки записей необходимо включить распределенный режим полинга (Distributed Polling).
Для обеспечения гарантированного порядка обработки сообщений необходимо настроить адаптер таким образом, чтобы он считывал следующее сообщение только после завершения обработки предыдущего. Для этого в DB-адаптере существует режим синхронной отправки сообщений на обработку. Включается данный режим с помощью галочки Do Synchronous Post to BPEL (Allow In-Order Delivery).
Суть данного режима заключается в том, что DB-адаптер после считывания сообщения и передачи его на обработку будет ожидать ответ от обработчика, например - BPEL-процесса, и только потом осуществит считывание следующего сообщения. Отправить ответ из BPEL-процесса можно с помощью операции Reply.
Следует так же заметить, что режим единственного экземпляра адаптера на кластер (т.н. environment singleton) считается плохим тоном и может свидетельствовать о проблемах в архитектуре интеграционного решения. Дело в том, что данный режим снижает коэффициент использования имеющихся в кластере мощностей. Экспериментальные данные показывают, что с помощью DB-адаптера, работающего на двух серверах WebLogic, размещенных даже на одной физической машине, можно добиться роста производительности в 1.5 раза по сравнению с адаптером, работающим только на одном сервере. Но все же бывают ситуации, когда гарантированный порядок обработки сообщений обязателен. Потери производительности при этом можно компенсировать, заставив работать на простаивающих мощностях экземпляры других адаптеров.
Понравилось сообщение - подпишитесь на блог и Twitter
При интеграции информационных систем, особенно унаследованных, часто приходится обеспечивать взаимодействие с ними через базу данных. В состав Oracle SOA Suite входят адаптеры, реализованные с помощью технологии JCA, позволяющие считывать события из базы данных. Примерами таких адаптеров являются DB- и AQ-адаптеры.
При этом считывать и обрабатывать события иногда важно в том же порядке, в котором они были сгенерированы в системе и, соответственно, записаны в базу данных. Рассмотрим пример: в информационной системе создается объект, например некое начисление на абонента. Затем данный объект модифицируется, а после этого удаляется (начисление было сделано по ошибке). Очевидно, что сообщение об удалении объекта ни в коем случае не должно быть передано в систему-приемник раньше, чем сообщение о его создании, т.к. в данном случае будет нарушена целостность данных.
Для обеспечения гарантированного порядка считывания сообщений необходимо сделать так, чтобы JCA-адаптер работал в один поток и присутствовал в кластере в единственном экземпляре. Для управления количеством потоков, в которые происходит считывание записей из базы, служит параметр NumberOfThreads. По-умолчанию его значение равно единице, т.е. каждый экземпляр адаптера работает в один поток. Для управления количеством экземпляров, запущенных на одном WebLogic-сервере, служит параметр activationInstances. По-умолчанию значение данного параметра так же равно единице: на каждом сервере создается один экземпляр адаптера. Таким образом для обеспечения гарантированного порядка считывания сообщений в среде с одним сервером приложений достаточно использовать значения параметров по-умолчанию, однако в кластерном окружении на каждом сервере будет запущен свой экземпляр адаптера, что может привести к нарушению порядка считывания сообщений, т.к. каждый экземпляр сервера приложений в кластере работает независимо от других. Для того, чтобы адаптер работал только на одном сервере, необходимо выставить для него значение параметра singleton в true.
При этом, в случае аварийного либо планового прекращения работы данного сервера, будет осуществлена миграция адаптера на другой сервер кластера.
На рисунке выше видно, что цифра в старшем разряде Instance ID изменилась, что свидетельствует о создании экземпляров композита другим сервером.
Важно! При миграции экземпляра адаптера на другой сервер возможна ситуация, когда адаптер сначала запустится на новом сервере, а лишь затем перестанет работать на останавливаемом. Т.е. некоторое время работать будут два экземпляра адаптера, что может привести к повторной обработке некоторых записей. Чтобы избежать повторной обработки записей необходимо включить распределенный режим полинга (Distributed Polling).
Для обеспечения гарантированного порядка обработки сообщений необходимо настроить адаптер таким образом, чтобы он считывал следующее сообщение только после завершения обработки предыдущего. Для этого в DB-адаптере существует режим синхронной отправки сообщений на обработку. Включается данный режим с помощью галочки Do Synchronous Post to BPEL (Allow In-Order Delivery).
Суть данного режима заключается в том, что DB-адаптер после считывания сообщения и передачи его на обработку будет ожидать ответ от обработчика, например - BPEL-процесса, и только потом осуществит считывание следующего сообщения. Отправить ответ из BPEL-процесса можно с помощью операции Reply.
Следует так же заметить, что режим единственного экземпляра адаптера на кластер (т.н. environment singleton) считается плохим тоном и может свидетельствовать о проблемах в архитектуре интеграционного решения. Дело в том, что данный режим снижает коэффициент использования имеющихся в кластере мощностей. Экспериментальные данные показывают, что с помощью DB-адаптера, работающего на двух серверах WebLogic, размещенных даже на одной физической машине, можно добиться роста производительности в 1.5 раза по сравнению с адаптером, работающим только на одном сервере. Но все же бывают ситуации, когда гарантированный порядок обработки сообщений обязателен. Потери производительности при этом можно компенсировать, заставив работать на простаивающих мощностях экземпляры других адаптеров.
Понравилось сообщение - подпишитесь на блог и Twitter
2 комментария:
Добрый день.
При работе с IBM WebSphere кластером, данная политика работает по умолчанию
Хм, интересно.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!