Notification Service: Spring configuration
22 November 2008Lately we have added a number of parts to the Notification Service, including the EmailCourier, the MessageCourierFactory, the DeliveryService, and the Notifier, but we haven’t really talked about the impact that all of these new components has had on the Spring configuration that wires all of these things together. Here is a current copy of the applicationContext.xml file for the Notifier project:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">
<context:property-placeholder location="classpath:jdbc.properties"/>
<tx:annotation-driven/>
<aop:aspectj-autoproxy/>
<aop:config>
<aop:advisor id="managerTx" advice-ref="txAdvice"
pointcut="execution(* *..manager.*Manager.*(..))"/>
</aop:config>
<tx:advice id="txAdvice">
<tx:attributes>
<tx:method name="get*" read-only="true"/>
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
<bean id="noticeTemplateManager"
class="org.restafarian.notify.manager.impl.NoticeTemplateManagerImpl">
<property name="noticeTemplateDao" ref="noticeTemplateDao"/>
</bean>
<bean id="emailCourier" class="org.restafarian.notify.service.impl.EmailCourier">
<property name="smtpHostName" value="localhost"/>
<property name="smtpPort" value="25"/>
<property name="defaultFromAddress" value="no-reply@restafarian.org"/>
</bean>
<bean id="messageCourierFactory"
class="org.restafarian.notify.service.impl.MessageCourierFactoryImpl">
<property name="messageCourierMap">
<map>
<entry>
<key>
<value>email</value>
</key>
<ref bean="emailCourier" />
</entry>
</map>
</property>
</bean>
<bean id="deliveryService" class="org.restafarian.notify.service.impl.DeliveryServiceImpl">
<property name="messageCourierFactory" ref="messageCourierFactory"/>
</bean>
<bean id="notifier" class="org.restafarian.notify.service.impl.NotifierImpl">
<property name="noticeTemplateManager" ref="noticeTemplateManager"/>
<property name="deliveryService" ref="deliveryService"/>
<property name="defaultTemplateContext" value="global"/>
</bean>
</beans>
If you start at the bottom and work your way back up to the top, you can see how all of the pieces fit together. The final entry is the notifier, which represents the service itself, and is what one would invoke to utilize the service. To access the notice templates, it needs the noticeTemplateManager, and to deliver the notices, it needs the deliveryService. The final configurable parameter is the defaultTemplateContext, which is provided to make the template context an optional parameter.
The idea of a template “context” is simply a way to organize groups of templates. A context might represent a department or an application or a region or some other such logical grouping, and placing templates into a specific context allows for the capability to separate tempates for the HR system from templates for the Accounts Payable system for the purposes of security and organization. This is an optional feature, which is why we specify a default context. This way, if you do not have one or cannot afford one, one will be provided for you.
Next up from the bottom is the deliveryService, which is used by the notifier, and uses the messageCourierFactory. The deliveryService simply obtains a message courier from the messageCourierFactory based on the specified delivery method, and then relies on the courier to perform the actual delivery of the message.
The messageCourierFactory is the next item up from the bottom, for it to function it requires a map of all known message couriers. Right now, we have only constructed on message courier (for e-mail delivery), so there is only one item in the map, but the intent it to provide an extensible framework into which you add as many couriers as you need for the various delivery methods that you would like to support. The map is keyed by deliveryMethod, so you will need to provide a message courier to the message courier factory for every delivery method that you intend to support.
Continuing up from the bottom, we come to our sole message courier, the emailCourier. Our e-mail courier is built on top of Apache Commons E-mail, and in order for that to work, it needs information on your mail server, such as name and port number. In order to make the “from” address an optional parameter, it also requires a defaultFromAddress to be configured.
And last in our series of beans is our old friend, the noticeTemplateManager, which has been around for a while, and requires the noticeTemplateDao, which is actually defined in another Spring configuration file, applicationContext-hibernate.xml, which configures the Hibernate persistence.
Leave a reply
You must be logged in to post a comment.
