Event-Driven Development в Spring. Часть 2

Механизм рассылки event-ов в контексте Spring реализован одним интерфейсом org.springframework.context.event.ApplicationEventMulticaster. Именно ему и будут делегироваться все добавления, удаления listener-ов, а также публикация event-ов для них. По-умолчанию, в качестве реализации такого интерфейса будет использоваться объект класса org.springframework.context.event.SimpleApplicationEventMulticaster. В самом же контексте данный bean регистрируется под именем applicationEventMulticaster. Однако, если под таким именем bean уже существует и реализует нужный интерфейс, то будет использоваться именно он.

Необоходимость создания своего ApplicationEventMulticaster-а может возникнуть, например, чтобы рассылать event-ы по spring-контекстам целого кластера. Именно этот случай и реализован в моем примере. Сам механизм коммуникации между нодами обеспечивается фреймворком JGroups, который рассылает сообщения по сети multicast-ом через UDP-протокол. Объект com.blogspot.nkoksharov.springevents.jgroups.JGroupsMulticaster переопределяет метод void multicastEvent(ApplicationEvent event) и рассылает по сети лишь те экземпляры event-ов, классы которых являются подклассами com.blogspot.nkoksharov.springevents.jgroups.JGroupsEvent. А вот и сам код JGroupsMulticaster-а:

package com.blogspot.nkoksharov.springevents.jgroups;

import org.jgroups.*;
import org.slf4j.*;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.context.ApplicationEvent;
import org.springframework.context.event.SimpleApplicationEventMulticaster;

/**
 * Alternative multicaster to org.springframework.context.event.SimpleApplicationEventMulticaster
 *
 * @author nkoksharov
 *
 */
public class JGroupsMulticaster extends SimpleApplicationEventMulticaster    implements InitializingBean, DisposableBean, LocalEventMulticaster {

   private final Logger logger = LoggerFactory.getLogger(getClass());
   private JChannel jchannel;
   private JGroupsReceiver receiver = new JGroupsReceiver();
   private String configFile;
   private String clusterName;

   public void multicastEvent(ApplicationEvent event) {
      if (event instanceof JGroupsEvent) {
          try {
             jchannel.send(new Message(null, null, event));
          } catch (ChannelNotConnectedException e) {
             logger.error("channel not connected", e);
          } catch (ChannelClosedException e) {
             logger.error("channel closed", e);
          }
      } else {
          super.multicastEvent(event);
      }
   }

   public void localMulticastEvent(JGroupsEvent event) {
      super.multicastEvent(event);
   }

   public void afterPropertiesSet() throws Exception {
      jchannel = new JChannel(configFile);
      receiver.setLocalMulticater(this);
      jchannel.setReceiver(receiver);
      jchannel.connect(clusterName);
   }

   public void destroy() throws Exception {
      jchannel.close();
   }
   public void setConfigFile(String configFile) {
      this.configFile = configFile;
   }
   public void setClusterName(String clusterName) {
      this.clusterName = clusterName;
   }
}

Рассылка же абсолютно всех event-ов, в частности системных, может привести к некорректной работе всего spring-контекста.

Проект собирается с помощью Maven-а и запускается командой:

mvn compile exec:java

Каждый запуск - это новый контекст, т.е. можно запустить приложение на разных компьютерах в локальной сети и наблюдать появление сообщений в консоли о получении event-ов. Также можно запустить несколько экземпляров приложения на одном компьютере, все должно работать.

Скачать исходники
Event-Driven Development в Spring. Часть 1

Event-Driven Development в Spring. Часть 1

Еще в Spring 1.2 была возможность посылать различные event-ы через весь контекст приложения. Я считаю этот вид коммуникации в некоторых местах приложения единственным верным решением.

Опишу кратко как работает этот механизм. Базовым классом для event-а должен быть org.springframework.context.ApplicationEvent, для рассылки которого используется метод org.springframework.context.ApplicationContext.publishEvent(event). Ну а получать event-ы будут те bean-ы, которые реализуют интерфейс org.springframework.context.ApplicationListener с единственным методом onApplicationEvent(event).

Допустим, что у нас есть логика, после выполнения которой другим сервисам необоходимо также сделать какие-то действия. Стандартный вариант решения такой задачи предполагает использование IoC:

public class BussinesServiceImpl implements BussinesService {

    @Autowired
    private EmailService emailService;
    @Autowired
    private LoggingService logService;
    
    public void doAction() {
        
        ...
        
        emailService.sendEmail(email, body);
        logService.recordLog(data);
    }
}

Также можно использовать и аспекты. Только вот получать параметры, которые пришли не через аргументы метода, advice-ам будет сложно. Реализовать такой случай с помощью event-ов можно так:

public class BussinesServiceImpl implements BussinesService, ApplicationContextAware {

    private ApplicationContext context;
    
    public void doAction() {
        
        ...
        
        ActionEvent event = new ActionEvent();
        event.setEmail(email);
        event.setEmailBody(body);
        event.setData(data);
        context.publishEvent(event);
    }

    public void setApplicationContext(ApplicationContext value) {
        context = value;
    }
}

Соответственно сами сервисы будут выглядеть так:

public class EmailServiceImpl implements EmailService, ApplicationListener {

    ...

    public void onApplicationEvent(ApplicationEvent event) {
        if (!(event instanceof ActionEvent)) {
            return;
        }

        ActionEvent actionEvent = (ActionEvent) event;
        sendEmail(actionEvent.getEmail(), actionEvent.getEmailBody());
    }
}

public class LoggingServiceImpl implements LoggingService, ApplicationListener {

    ...

    public void onApplicationEvent(ApplicationEvent event) {
        if (!(event instanceof ActionEvent)) {
            return;
        }

        ActionEvent actionEvent = (ActionEvent) event;
        recordLog(actionEvent.getData());
    }
}

Какое преимущество дает такой подход? Изоляцию сервиса, от лишних зависимостей. Такая изоляция дает возможность выносить сервисы типа BussinesService в отдельные модули, которые не потребуют в дальнейшем модификации, если понадобится добавить вызов какого-либо сервиса.