Afin d'apprendre Spring Integration, j'ai compris l'exemple fourni par Spring Project et je l'ai réimplémenté + arrangé. Cet article est un mémorandum. Je pense donc qu'il y a plusieurs erreurs, mais je vous serais reconnaissant de bien vouloir souligner ce point. L'exemple est enregistré dans le Git suivant. spring-integration-sample
Cette fois à propos de _ ** Gateway ** _ qui est l'un des jms de base. À propos, la version de Spring Integration est `` 4.3.10.RELEASE ''.
Trois fonctions sont implémentées dans JMS, et lorsque la classe Main est exécutée, elle décide de manière interactive quel mode de 1 à 3 essayer. Cette fois, nous n'avons implémenté que la passerelle 1.
Il y a tellement de choses que je ne comprends pas encore, et c'est difficile à comprendre même si je l'implémente d'un côté, donc au lieu de l'implémenter dans le même format, je vais l'implémenter individuellement et le comprendre.
Gateway
Le flux global est probablement le suivant. (Veuillez préciser si vous faites une erreur)
Entrée standard(stdin) -> stdintojmsoutchannel -> requestqueue -> serviceactivator -> requestchannel -> replyqueue -> replychannel ->Sortie standard(stdout)
Outbound-gateway emballe la valeur entrée depuis la console dans la file d'attente (RequestQueue```) via stdin-channel-adapter```. Ensuite, ```inbound-gateway``` obtient la valeur de RequestQueue``` et la traite avec `ServiceActivator``` et l'envoie à` RequestChannel```. De plus, ```outbound-gateway``` l'obtient de `` ReplyQueue cette fois, le relaie vers` `` `ReplyChannel, et fait enfin la sortie standard.
Outbound-gateway dans Reference Manual Dans l'explication, ReplyQueue '' (attribut reply-destination '') ne peut pas être spécifié, sinon TemporaryQueue '' sera utilisé. Comme il n'est pas spécifié dans cet exemple, il semble que la valeur soit envoyée de TemporaryQueue '' à `` ReplyChannel ''.
Cet exemple se compose de 3 configurations: common.xml, outboundGateway.xml et inboundGateway.xml. Celui que j'ai implémenté est une réutilisation de l'exemple de projet de base, mais j'ai omis toutes les descriptions qui semblent inutiles pour la compréhension.
Ici, les paramètres requis pour l'agrégation, channelAdapter et d'autres fonctions sont définis comme des paramètres communs, mais cette fois, seuls les paramètres requis pour la passerelle sont conservés.
Les paramètres suivants sont requis pour l'application Gateway. La `connectionFactory` '' de 1 est requise en interne par la classe` `JmsOutboundGateway '' pour créer une connexion. 2 semble être nécessaire pour stdin-channel-adapter '' pour interroger l'entrée standard.
Et puisque `` requestQueue '' est utilisé à la fois par outboundGateway et inboundGateway, il doit être défini. Ici, la file d'attente OSS ActiveMQ est spécifiée comme classe d'implémentation.
D'autres paramètres semblaient inutiles cette fois, je les ai donc supprimés.
<!-- 1 -->
<bean id="connectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory">
<property name="targetConnectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="vm://localhost"/>
</bean>
</property>
<property name="sessionCacheSize" value="10"/>
</bean>
<!-- 2 -->
<bean id="requestQueue" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg value="queue.demo"/>
</bean>
<!-- 3 -->
<integration:poller id="poller" default="true" fixed-delay="1000"/>
Seuls les paramètres minimaux nécessaires sont également conservés ici. Il y avait aussi un paramètre d'informations de profil pour le test, mais je l'ai supprimé car il est d'abord inutile.
Ici, la classe JmsOutboundGateway '' joue un rôle de relais de divers flux de traitement comme son nom l'indique, donc les paramètres requis pour le relais sont décrits. Où 1 et 3 définissent les entrées et les sorties vers la console. 2 transmet les informations d'entrée obtenues à partir de l'attribut request-channel '' à la méthode send``` de la` `requestQueue (MessageChannel)` `. La valeur de retour va dans le TemporaryQueue '' qui est omis cette fois, il semble donc qu'il est configuré pour le transmettre en interne à l'objet avec l'attribut `` reply-channel ''
<!-- 1 -->
<stream:stdin-channel-adapter id="stdin" channel="stdinToJmsoutChannel"/>
<channel id="stdinToJmsoutChannel"/>
<!-- 2 -->
<jms:outbound-gateway request-channel="stdinToJmsoutChannel"
request-destination="requestQueue"
reply-channel="jmsReplyChannel"/>
<!-- 3 -->
<channel id="jmsReplyChannel" />
<stream:stdout-channel-adapter channel="jmsReplyChannel" append-newline="true"/>
À la fin, il s'agira d'un paramètre entrant, mais à l'origine il y avait un paramètre de `` ServiceActivator```, mais il a également été implémenté dans l'article de Hello World J'ai donc décidé de l'implémenter avec des annotations. En utilisant des annotations, il est devenu plus facile de comprendre ce que vous voulez faire avec xml. (Puisque Spring Integration a tendance à être compliqué en xml, j'ai pensé un instant qu'il serait préférable de l'implémenter principalement avec JavaConfig ou des annotations, mais à mesure que l'échelle de l'application grandit, je pense que le code source devient soudainement difficile à suivre. . Il semble être plus difficile d'ajuster la cuillère que le système Web.)
Revenant au sujet principal, 1 effectue un balayage des composants. Cela élimine le besoin de définition de bean pour les classes qui implémentent ServiceActivator ''. Ensuite, 2 définit le flux de traitement interne avec la balise ```inbound-gateway```. Contrairement à outbound, la valeur est acquise à partir de l'attribut request-destination '' et propagée à l'attribut `` request-channel ''.
<!-- 1 -->
<context:component-scan base-package="org.ek.sample.jms.gateway"/>
<!-- 2 -->
<jms:inbound-gateway id="jmsin"
request-destination="requestQueue"
request-channel="requestChannel"/>
<channel id="requestChannel"/>
ServiceActivator
Comme mentionné ci-dessus, ServiceActivator '' utilisait des annotations. À cette fin, l'annotation (1) @ EnableIntegration '' et (2) l'annotation @ MessageEndpoint '' sont utilisées. Si vous utilisez @ ServiceActivator '' sans utiliser (1), vous obtiendrez une erreur comme la destination d'expédition est introuvable. Je viens de faire une simple reconnaissance qu'il est nécessaire d'ajouter des annotations ensemble pour utiliser des annotations dans des objets de type Endpoint. J'aimerais voir le contenu un peu plus tard, mais pour l'instant je vais le supporter et continuer.
(2) est une annotation destinée simplement à être une cible d'analyse de composant. C'est la même chose que @ Controller '' ou @ Service '' sur le Web.
(3) vient de remplacer la définition du bean.
@EnableIntegration // (1)
@MessageEndpoint // (2)
public class GatewayEndpoint {
// (3)
@ServiceActivator(inputChannel="requestChannel")
public String upperCase(String input) {
return "JMS response: " + input.toUpperCase();
}
}
Le code de la classe Main est le suivant. Définissez simplement xml comme un tableau et chargez-le en tant qu'instance d'ApplicationContext. Avec cela seul, l'interaction entre la console et l'application peut être réalisée.
private final static String[] configFilesGatewayDemo = {
"/META-INF/spring/integration/common/common.xml",
"/META-INF/spring/integration/gateway/inboundGateway.xml",
"/META-INF/spring/integration/gateway/outboundGateway.xml"
};
@SuppressWarnings("resource")
public static void main(String[] args) {
new ClassPathXmlApplicationContext(configFilesGatewayDemo,GatewayMain.class);
}
Cette fois, j'ai traité de la passerelle entrante et de la passerelle sortante, mais je pensais que ce serait assez facile à utiliser car ils font de bons échanges entrants et sortants à l'arrière. Après cela, personnellement, je ne peux pas lire de manière sensuelle xml, j'ai donc eu l'impression que je l'oublierais plus tard même si je l'implémentais moi-même, à moins que je ne réfléchisse à comment améliorer la lisibilité.
Cliquez-ici pour le code. Exemple Jms modifié
Recommended Posts