Рекомендации по обеспечению интеграции API

Question

Есть ли какие-либо рекомендации, лучшие практики или хорошие статьи по предоставлению интеграционных хуков?
Допустим, я занимаюсь разработкой системы заказов через Интернет. В конце концов я бы хотел, чтобы мой клиент мог написать некоторый код, упаковать его в jar-файл, сбросить его в путь к классам, и это изменило бы поведение программного обеспечения.
Например, если поступит заказ, код
1. может отправить электронное письмо или смс
2. может записать некоторые дополнительные данные в базу данных
3. может изменить данные в базе данных или решить, что заказ не должен быть сохранен в базе данных (отменить сохранение данных)

Точка 3 довольно опасна, поскольку слишком сильно мешает целостности данных, но если мы хотим, чтобы интеграция была настолько гибкой, это выполнимо?

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

Мы используем Struts2, если это имеет значение.
Эта интеграция должна быть способна обнаруживать «изменение состояния», а не только «конечное состояние» после выполнения действия ядра.
Например, если заказ меняет состояние с «Выполняется» на «Платно», он что-то делает, но если он меняется с «Черновик» на «Платно», он ничего не должен делать.
Основным действием в этом случае будет загрузка объекта заказа. из базы данных, изменив состояние на Платное и сохранив его снова (или выполнив обновление sql).

Answer 1

Множество опций, в том числе:

• Инструмент рабочего процесса
• АОП
• Сообщения
• крючки слоя DB

Самым простым (для меня в то время) был подход, основанный на сообщениях. Я сделал что-то особенное, используя перехватчики Struts 2, но более чистый подход - использование Spring и / или JMS.

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

Если вы хотите, чтобы это работало без перезапусков системы, другим вариантом будет реализация обработчиков на динамическом языке (например, Groovy). Функциональность может храниться в БД. Использование фабрики Spring делает это довольно забавным и снижает сложность подхода, основанного на сообщениях.

Одна проблема с синхронным подходом, однако, заключается в том, что обработчик блокируется или занимает много времени; это может как минимум повлиять на этот поток или на систему в целом при некоторых обстоятельствах.