Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a システム間連携を担うSpring Integrationのエンタープライズ開発での活用
Semelhante a システム間連携を担うSpring Integrationのエンタープライズ開発での活用 (20)
Mais de apkiban
システム間連携を担うSpring Integrationのエンタープライズ開発での活用
- 1. © 2019 NTT DATA Corporation 2019年12月18日 NTTデータ 技術革新統括本部 システム技術本部 生産技術部 インテグレーション技術センタ 太田浩介 システム間連携を担うSpring Integrationのエンタープライズ開発での活用
- 2. © 2019 NTT DATA Corporation 2 自己紹介 太田浩介 株式会社NTTデータ 技術革新統括本部システム技術本部生産技術部インテグレーション技術センタ(長い) 一年目 Javaをゴリゴリ勉強中 最近ハマっていること 自宅のスマートホーム化
- 3. © 2019 NTT DATA Corporation 3 やっていたこと(大学) Python+flask+Bootstrapでwebアプリ開発 – ロボット操作デスクトップアプリをwebアプリに移行 – レスポンシブデザインの適用 今やっていること 公共系システムのTERASOLUNAフレームワーク への移行支援 – Struts ⇒Spring Framework – Pythonとの違いに苦戦 自己紹介
- 4. © 2019 NTT DATA Corporation 4 所属組織の活動
- 5. © 2019 NTT DATA Corporation 5 エンタープライズ利用における当社知見をベースに、 Springを最大限活用したフレームワーク Spring Boot Dependencies Spring Security Spring MVC JPA MyBatis 1. OSSを組み合わせ、独自部分を極小化 2. OSSの機能を最大限に活かして開発す るためのベストプラクティスを提供するこ とに注力 開発ガイドライン http://terasolunaorg.github.io/ TERASOLUNAフレームワークの開発
- 6. © 2019 NTT DATA Corporation 6 Springイベントのスポンサーおよび講演 Springの当社プレゼンスを向上するため 積極的に講演活動およびイベントスポンサーに取り組む 2015年より毎年、世界最大のSpringプロジェクトイベント 「SpringOne Platform」のスポンサーとして協賛 SpringOne Platform 2019 参加レポート 「VMwareとPivotalの今後の関係、開発者が直面するクラウドネイティブの複雑さと、それを扱うための考え方」 https://codezine.jp/article/detail/11805
- 7. © 2019 NTT DATA Corporation 7 「Spring Integration」をテーマにしたきっかけ • DXの中で、既存システム活用のためのシステム間連携技術 が脚光を浴びている • Spring Integrationを既に社内で活用していたが、 積極的に外部発信していなかった • 個人的に知見を高めたい
- 8. © 2019 NTT DATA Corporation 8 今日お話しする内容 • システム連携の背景 • Spring Integrationについて • 実際に使ってみる • 実案件での適用 • 概要 • 工夫と苦労
- 9. © 2019 NTT DATA Corporation 9 システム連携の背景 • システム連携の背景 • Spring Integrationについて • 実際に使ってみる • 実案件での適用 概要 工夫と苦労
- 10. © 2019 NTT DATA Corporation 10 昨今のシステム連携事情 全く異なる仕様・ハードウェア・アーキテクチャを持ったシステム間の連携 は昔からの大きな課題 近年はオンプレ×クラウドの連携も増加 クラウド、オンプレ、etc…クラウド、オンプレ、etc… 疎結合な連携が 求められる Primary System Subsystem DB Primary System
- 11. © 2019 NTT DATA Corporation 11 Enterprise Integration Patterns(以下EIP) • Gregor Hohpe氏によってまとめられた企業システム連携手法の ベストプラクティス • (邦訳は出版されていない) • 連携パターンは4つ紹介されている 公式サイトでは各パターンの概要が公開されている enterpriseintegrationpatterns.com Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions 著者：Gregor Hohpe,Bobby Woolf 出版元: Addison-Wesley Professional 2003年10月３日初版 ISBN-13: 978-0321200686 ISBN-10: 9780321200686
- 12. © 2019 NTT DATA Corporation 12 ファイル転送 データベース共有 リモート手続き呼び出し 非同期メッセージング EIPが挙げる連携パターン 共有データ アプリケー ションA アプリケー ションB アプリケー ションA アプリケー ションB アプリケー ションC import export アプリケー ションA アプリケー ションB ス タ ブ ス ケ ル ト ン Invoke Result アプリケー ションA アプリケー ションB アプリケー ションC Message Bus 共通DB
- 13. © 2019 NTT DATA Corporation 13 ファイル転送 データベース共有 リモート手続き呼び出し 非同期メッセージング EIPが挙げる連携パターン 共有データ アプリケー ションA アプリケー ションB アプリケー ションA アプリケー ションB アプリケー ションC import export アプリケー ションA アプリケー ションB ス タ ブ ス ケ ル ト ン Invoke Result アプリケー ションA アプリケー ションB アプリケー ションC Message Bus 共通DB インターフェースに依存した 入出力の実装が必要 アプリケーションがDBの 実装に依存 処理の待機時間あり メソッドの熟知が必要
- 14. © 2019 NTT DATA Corporation 14 非同期メッセージング 非同期メッセージングとは • 受け取った情報を「Message」 という単位に抽象化 • Messageは「Message Bus」を通じて、 他のアプリケーションに送信される アプリケー ションA アプリケー ションB アプリケー ションC Message Bus メッセージ メッセージ メッセージ
- 15. © 2019 NTT DATA Corporation 15 非同期メッセージング メリット • アーキテクチャの差異を吸収 • 送信側の待機が無い • 受信側の状態に影響されない • 多対多の連携が可能 非同期メッセージングは疎結合なシステム連携を実現する アプリケー ションA アプリケー ションB アプリケー ションC Message Bus メッセージ メッセージ メッセージ
- 16. © 2019 NTT DATA Corporation 16 じゃあどうやって実装するの？
- 17. © 2019 NTT DATA Corporation 17 EIPはあくまでインテグレーションのカタログ ⇒各環境でどのように実装するかは書かれていない EIPをSpringで実現したのがSpring Integration
- 18. © 2019 NTT DATA Corporation 18 Spring Integrationについて • システム連携の背景 • Spring Integrationについて • 実際に使ってみる • 実案件での適用 概要 工夫と苦労
- 19. © 2019 NTT DATA Corporation 19 Spring Integrationのゴール • エンタープライズなシステム連携を実現する実装手段を提供 • Springベースで非同期メッセージングを実現 • Spring Frameworkとの高い親和性
- 20. © 2019 NTT DATA Corporation 20 連携元 Application End point Spring Integrationのメッセージフロー ① 連携元ApplicationがEndpointにデータを送信する ② Endpointは受け取ったデータをMessageに変換する ③ MessageはChannelを通り、指定された別のEndpointに送られる ④ 様々な処理を行い、送信用のEndpointに送られる ⑤ EndpointがMessageを適切な形式に変換し、連携先Applicationに送信する Endpoint 連携先 Application ChannelChannel Message End point ① ⑤② ③ ④
- 21. © 2019 NTT DATA Corporation 21 Message • システム間で送受信する最小単位 • 実体はジェネリクス型のクラス • HeaderとPayloadから構成される • Headerはメッセージの受け渡しに 必要なメタデータ、 Payloadは連携する情報を格納 Message ID , TimeStamp ... • xml • json • java.lang.String • java.io.file etc… Header Payload
- 22. © 2019 NTT DATA Corporation 22 Channel • 各コンポーネント間を繋ぐパイプの役割 • Messageの流通方式や受信方式を決定する 流通方式の一例 受信方式の一例 • Messageの生成、変換等には関与しない Channel 受動的に受信 バッファリング不可 能動的に受信 バッファリング可 Point-to-Point Pub/Sub Subscribable Pollable
- 23. © 2019 NTT DATA Corporation 23 DirectChannel Messageを単一スレッドで処理する る 最も基本的なChannel PublishSubscribeChannel 受信したMessageをすべての後続の のEndpointに送信する QueueChannel メッセージをFIFO(先入れ先出し)で扱 で扱う。 PriorityChannel 基本的にQueueChannelと同じだが、 が、メッセージの優先順位を制御でき できる Channel Channelの主な実装クラス Point-to-Point Point-to-Point Point-to-Point Pub/Sub Subscribable Subscribable Pollable Pollable
- 24. © 2019 NTT DATA Corporation 24 Endpoint Endpointは大きく2種類 ①始点・終点で使うEndpoint アプリケーションと連携しMessageを生成・出力 ②メッセージフローの内部で使うEndpoint Messageの加工・ルーティング等 Endpoint
- 25. © 2019 NTT DATA Corporation 25 ①始点・終点で使うEndpoint(1/2) • Adapter アプリケーションから任意のプロトコルで受け取り、メッセージを生成 Channelに対し、Messageの入出力操作を行う⇒一方通行 • Gateway Adapterと異なり、接続先からのレスポンスを待機する⇒双方向 Application Adapter Adapter Application GatewayApplication ApplicationGateway
- 26. © 2019 NTT DATA Corporation 26 ①始点・終点で使うEndpoint(2/2) Adapter, Gatewayごとに違いはあるが、以下のプロトコルやサービスに 対応している • HTTP • ローカルファイル • FTP/FTPS • JDBC • JPA • MQTT • RMI • SFTP • STOMP • TCP/UDP etc… https://docs.spring.io/spring-integration/docs/5.2.1.RELEASE/ reference/html/endpoint-summary.html#spring-integration-endpoints
- 27. © 2019 NTT DATA Corporation 27 ②メッセージフローの内部で使うEndpoint(1/3) • Transformer Messageのヘッダ、ペイロードの値や型・形式を変換する処理を行う。 Javaの Object・MapやXML・JSON等、良く用いられる形式の 変換処理を提供 Transformer 変換処理 Channel Channel json xml
- 28. © 2019 NTT DATA Corporation 28 ②メッセージフローの内部で使うEndpoint(2/3) • Router Channelから受け取ったMessageの内容に応じて、 適切なChannelへ割り振りを行う • Filter Messageを後続のChannelに送信するかどうかの制御を行う • Splitter Messageを分割してChannelに送る
- 29. © 2019 NTT DATA Corporation 29 ②メッセージフローの内部で使うEndpoint(3/3) • Service Activator Channelから受け取ったMessageのヘッダやペイロードを引数として、 独自に実装したメソッドを実行する 独自 メソッド Service Activator Channel Channel
- 30. © 2019 NTT DATA Corporation 30 実際に使ってみる • システム連携の背景 • Spring Integrationについて • 実際に使ってみる • 実案件での適用 概要 工夫と苦労
- 31. © 2019 NTT DATA Corporation 31 実際に使ってみる どんなアプリケーション? toUpperCase メソッド ローカルファイル End point Endpoint (Service Activator) ChannelChannel Message End point 連携先 ディレクトリ ローカルから受け取ったテキストファイルの中身を大文字に変換し、別のディレクトリに配置 aaa.txt bbb.txt ccc.txt aaa.txt bbb.txt ccc.txt aaa.txt 通常の英文が記された txtファイル 全てのアルファベットが大文字に 置き換えられたtxtファイル
- 32. © 2019 NTT DATA Corporation 32 実際に使ってみる ① pom.xmlに依存ライブラリを記述 ② mainメソッドでspring-integration.xml読み込み ③ ChannelとAdapterを spring-integration.xmlにBeanとして記述(※) ④ ServiceActivatorは spring-integration.xmlとJavaのクラスとして実装 ※EndpointはJava Configとxmlのどちらでも記述可能 作成ステップ
- 33. © 2019 NTT DATA Corporation 33 ①pom.xml pom.xml spring-integration-coreは必須の依存関係 サポートしたいプロトコルによって、spring-integration-http, xml, mail, jdbcなどが必要 <dependency> <groupId>org.springframework.integration</groupId> <artifactId>spring-integration-core</artifactId> </dependency> <dependency> <groupId>org.springframework.integration</groupId> <artifactId>spring-integration-file</artifactId> </dependency>
- 34. © 2019 NTT DATA Corporation 34 public class SpringIntegrationDemoApplication { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("META-INF/spring/spring-integration.xml"); } } ②mainメソッド SpringIntegrationDemoApplication.java mainメソッドでspring-integration.xmlを呼び出し
- 35. © 2019 NTT DATA Corporation 35 ③ChannelとAdapterの定義 spring-intergration.xml BeanとしてChannelとAdapterを作成 3秒ごとにtxtファイルをポーリングし、ファイルがあれば1つずつ Messageに格納しChannelに流す <!-- Channel --> <int:channel id="localFileInputChannel" /> <int:channel id="outputFileInputChannel" /> <!-- Adaptor --> <int-file:inbound-channel-adapter id="localFileInbound" directory="file:src/main/resources/input" channel="localFileInputChannel"> <int:poller fixed-delay="3000" /> </int-file:inbound-channel-adapter> <int-file:outbound-channel-adapter id="localFileOutbound" channel="outputFileInputChannel" directory="file:src/main/resources/output" />
- 36. © 2019 NTT DATA Corporation 36 ④ServiceActivatorの定義(1/2) ChannelとAdapterに続き、ServiceActivatorを定義する ref、method属性で実行するクラスのメソッドを指定する <!-- ServiceActivator --> <int:service-activator input-channel="localFileInputChannel" output-channel="outputFileInputChannel" ref="toUpperCaseService" method="toUpperCase" /> <bean id="toUpperCaseService" class="com.example.demo.integration.endpoint.service.ToUpperCaseService" /> spring-intergration.xml
- 37. © 2019 NTT DATA Corporation 37 ④ServiceActivatorの定義(2/2) 受け取ったMessageのpayloadをFileとして受け取り、 大文字に変換した後ServiceActivatorに返すメソッド ToUpperCaseService.java public class ToUpperCaseService { public String toUpperCase(File file) throws IOException { StringBuilder input = new StringBuilder(); FileReader fileReader = new FileReader(file); //省略：ファイルの内容をinputに読み込む処理 String output = input.toString().toUpperCase(); return output; } }
- 38. © 2019 NTT DATA Corporation 38 実際に使ってみる アプリケーションを通して変換処理されたテキストファイルがされる ローカルファイル SpringIntegrationDemo アプリケーション 連携先 ディレクトリ The Merchant of Venice is one of William Shakespeare's best-known plays, written sometime between 1596 and 1598. …… THE MERCHANT OF VENICE IS ONE OF WILLIAM SHAKESPEARE'S BEST-KNOWN PLAYS, WRITTEN SOMETIME BETWEEN 1596 AND 1598. …… aaa.txt bbb.txt ccc.txt aaa.txt bbb.txt ccc.txt
- 39. © 2019 NTT DATA Corporation 39 実際に使ってみた所感 • 今回使用しなかったが、Spring Initialzrに対応しているので簡単に 雛形を作成可能 • ChannelやEndpointなどの各要素は、xmlで簡単に記述可能 (もちろん@Beanでもok) • 日本語のドキュメントはまだまだ少ない ⇒公式リファレンス熟読が王道かつ近道
- 40. © 2019 NTT DATA Corporation 40 実案件での適用 ～概要～ • システム連携の背景 • Spring Integrationについて • HelloWorld • 実案件での適用 概要 工夫と苦労
- 41. © 2019 NTT DATA Corporation 41 決済中継システム 決済中継システムの概要 決済 システムA 金融機関 システム1 アーキテクチャの差異 を吸収 決済 システムB 決済 システムC 金融機関 システム2 金融機関 システム3 ・ ・ ・ ・ ・ ・ 決済システムと金融機関を繋ぐ大規模システム ⇒将来決済中継システムと接続するシステムが増加する可能性が高い システムごとのアーキテクチャに依存しない設計が必要
- 42. © 2019 NTT DATA Corporation 42 連携元 Application End point Spring Integrationのメッセージフロー(再掲) 1. 連携元ApplicationがEndpointにデータを送信する 2. Endpopintは受け取ったデータをMessageに変換する 3. MessageはChannelを通り、指定された別のEndpointに送られる 4. 同様にChannelを通り、送信用のEndpointに送られる 5. EndpointがMessageを適切な形式に変換し、連携先Applicationに送信する Endpoint 連携先 Application ChannelChannel End point MessageAdaptor,Gateway Transformer,Router ServiceActivator etc… Adaptor,Gateway
- 43. © 2019 NTT DATA Corporation 43 決済中継システムに適用すると… 決済中継システムにおける最小構成 • Gateway: 外部システムと様々な方法で接続 • Transformer: 業務処理に応じてMessageを加工・変換 • ServiceActivator: Spring Integrationに関与しない業務特有の処理 決済 システム 金融機関 システム 業務 処理 TransformerGateway Service Activator Transformer Gateway
- 44. © 2019 NTT DATA Corporation 44 実案件での適用 ～工夫と苦労～ • システム連携の背景 • Spring Integrationについて • HelloWorld • 実案件での適用 概要 工夫と苦労
- 45. © 2019 NTT DATA Corporation 45 Spring Integrationはシステム連携に有効 エンタープライズな場面で使おうとすると課題があるのも事実 実案件への適用 その一方で… 課題 ① 連携するシステム数に応じてコンポーネントが増える ② 自由度が高い反面、実装が無秩序に ③ ログ出力時にメッセージフローが複雑化 ④ ServiceActivatorに毎回同じ処理を書くのは面倒
- 46. © 2019 NTT DATA Corporation 46 NTTデータでは、このような課題に対し、様々な工夫を行っている 実案件への適用 課題 解決策 連携するシステム数に応じてコンポーネントが増える ① コンポーネントの再利用 自由度が高い反面、実装が無秩序に ② 処理の標準化 ログ出力時にメッセージフローが複雑化 ③ Interceptorによるログ出力 ServiceActivatorに毎回同じ処理を書くのは面倒 ④ ServiceActivatorの拡張
- 47. © 2019 NTT DATA Corporation 47 中継アプリケーション ①コンポーネントの再利用 決済 システムA 金融機関 システム1 業務処理 決済 システムB 金融機関 システム2 業務処理 業務処理 業務処理 必要なコンポーネントは(連携元)×(連携先) TransformerGateway TransformerGateway TransformerGateway TransformerGateway Transformer Gateway Transformer Gateway Transformer Gateway Transformer Gateway Spring Integrationをそのまま利用した場合 ⇒ 多対多の連携は現実的ではない
- 48. © 2019 NTT DATA Corporation 48 ①コンポーネントの再利用 再利用性を考慮し、処理をパーツ化した場合 決済 システムA 金融機関 システム1 データ変換 A⇒1 決済 システムB 金融機関 システム2 データの入出力から業務処理までを1セットとして再利用 必要なコンポーネントは(連携元)+(連携先) データ変換 A⇒2 データ変換 B⇒1 データ変換 B⇒2 TransformerGateway 業務処理 TransformerGateway 業務処理 Transformer Gateway業務処理 Transformer Gateway業務処理 パーツ化
- 49. © 2019 NTT DATA Corporation 49 ②処理の標準化 決済 システムA 金融機関 システム1 データ変換 A⇒1 決済 システムB 金融機関 システム2 各システムと接続する一連の処理を、内部の実装も含めて 「サービスコネクタ」として標準化 データ変換 A⇒2 データ変換 B⇒1 データ変換 B⇒2 TransformerGateway 業務処理 Transformer Gateway業務処理 Transformer Gateway業務処理 TransformerGateway 業務処理 サービスコネクタA 自由度が高い反面、 実装が無秩序に…
- 50. © 2019 NTT DATA Corporation 50 REST channel channel Spring Integration SpringMVC リクエストログ interceptor Gateway gateway 例外分岐 router 例外発生時 レスポンス生成 transformer REST 送受信 controller レスポンスログ interceptor リクエスト送信 業務処理 ServiceActivator レスポンス受信 業務処理 ServiceActivator リクエスト メッセージ変換 transformer レスポンス メッセージ変換 transformer バリデーション ServiceActivator サービスコネクタAの実装例(RESTの場合) ②処理の標準化
- 51. © 2019 NTT DATA Corporation 51 REST channel channel Spring Integration SpringMVC リクエストログ interceptor Gateway gateway 例外分岐 router 例外発生時 レスポンス生成 transformer REST 送受信 controller レスポンスログ interceptor リクエスト送信 業務処理 ServiceActivator レスポンス受信 業務処理 ServiceActivator リクエスト メッセージ変換 transformer レスポンス メッセージ変換 transformer バリデーション ServiceActivator サービスコネクタAの実装例(RESTの場合) ②処理の標準化 RESTの受け取り Message生成 HibernateValidator実装 単項目・相関チェック実行 ログ出力 ServiceActivatorを拡張 送信・受信を分けて実装 catchした例外に応じて分岐 例外ごとのレスポンスを 業務処理へ返却
- 52. © 2019 NTT DATA Corporation 52 REST channel channel リクエストログ interceptor Gateway gateway 例外分岐 router 例外発生時 レスポンス生成 transformer REST 送受信 controller レスポンスログ interceptor リクエスト送信 業務処理 ServiceActivator レスポンス受信 業務処理 ServiceActivator リクエスト メッセージ変換 transformer レスポンス メッセージ変換 transformer バリデーション ServiceActivator ③Interceptorによるログ出力
- 53. © 2019 NTT DATA Corporation 53 ③Interceptorによるログ出力 • エラー発生時にどこで発生したか把握することは必須の要件 • 業務処理で毎回実装した場合、エンドポイントが増えてしまい メッセージフローが複雑化する そこで、メッセージフローに割り込みが可能な「Interceptor」を ログ出力のために利用している
- 54. © 2019 NTT DATA Corporation 54 ③Interceptorによるログ出力 • InterceptorはSpring Integrationの機能(ChannelでもEndpointでもない) • MessageがChannelを通る際に割り込んで処理行う • Endpointではないので、新たなメッセージ経路を用意必要がない • Messageを別のChannelに送信することが可能 ログ 出力 Gateway gateway リクエスト メッセージ変 換 transformer Channel ServiceActivatorで実装 ログ出力機能 interceptor Gateway gateway リクエスト メッセージ変 換 transformer Channel Interceptorを利用 Channel Interceptorとは？使うメリットは？ Service Activator
- 55. © 2019 NTT DATA Corporation 55 Interceptorのインタフェース インターフェースを実装すれば、あとはbeanに記述するだけで呼び出し可能 定義一つで、ログの出力を簡単に実現 ③Interceptorによるログ出力 spring-Integration.xml public interface ChannelInterceptor { Message<?> preSend(Message<?> message, MessageChannel channel); void postSend(Message<?> message, MessageChannel channel, boolean sent); void afterSendCompletion(Message<?> message, MessageChannel channel, boolean sent, Exception ex); boolean preReceive(MessageChannel channel); Message<?> postReceive(Message<?> message, MessageChannel channel); void afterReceiveCompletion(Message<?> message, MessageChannel channel, Exception ex); } <!-- Interceptor --> <int:channel id="exampleChannel"> <int:interceptors> <ref bean="trafficMonitoringInterceptor" /> </int:interceptors> </int:channel>
- 56. © 2019 NTT DATA Corporation 56 ④ServiceActivatorの拡張 REST channel channel リクエストログ interceptor Gateway gateway 例外分岐 router 例外発生時 レスポンス生成 transformer REST 送受信 controller レスポンスログ interceptor リクエスト送信 業務処理 ServiceActivator レスポンス受信 業務処理 ServiceActivator リクエスト メッセージ変換 transformer レスポンス メッセージ変換 transformer バリデーション ServiceActivator
- 57. © 2019 NTT DATA Corporation 57 ④ServiceActivatorの拡張 エンタープライズの一般的な要件 • TraceIdのようなメタ情報を予め用意したい • DBなどを参照して行う複合チェックは、業務処理の中で行いたい ServiceActivatorで呼び出すクラスはPOJO 毎回同じ処理を書かなければならない public class SampleService { public String handle(String payload) { // 業務処理 return null; } } ServiceActivatorで呼び出すクラス
- 58. © 2019 NTT DATA Corporation 58 ④ServiceActivatorの拡張 ServiceActivatorを拡張したクラスでは、引数として必要な入出力や、 業務に依存する複合チェックの例外処理があらかじめ用意されている ため、業務処理で毎回書く手間が省かれている 拡張クラス Service Activator 業務処理 業務処理 業務処理 Service Activator POJO 例外処理 メタ情報 POJO 例外処理 メタ情報 POJO 例外処理 メタ情報 例外処理 メタ情報 業務処理をPOJOで実装した場合 拡張クラスを用意した場合
- 59. © 2019 NTT DATA Corporation 59 実案件への適用 課題 解決策 連携するシステム数に応じてコンポーネントが増える える ① コンポーネントの再利用 自由度が高い反面、実装が無秩序に ② 処理の標準化 ログ出力時にメッセージフローが複雑化 ③ Interceptorによるログ出力 ServiceActivatorに毎回同じ処理を書くのは面倒 ④ ServiceActivatorの拡張
- 60. © 2019 NTT DATA Corporation 60 まとめ • Spring Integrationは、連携先システムのアーキテクチャや プロトコルの差異を非同期メッセージングによって解決 • 弱点もあるが、提供されている機能の活用や独自の拡張によって、 エンタープライズ開発でも実用的なシステム連携が可能
- 61. © 2019 NTT DATA Corporation 「TERASOLUNA」及びそのロゴは、日本及び中国における株式会社NTTデータの商標または登録商標です。 その他、記載されている会社名、商品名、サービス名は各社の登録商標または商標です。
Notas do Editor
- システム間連携を担うSpring Integrationのエンタープライズ開発での活用と題しまして、 株式会社NTTデータ 技術革新統括本部の太田から発表させていただきたいと思います。
- ではまず軽く自己紹介から始めさせていただこうかと思います。 株式会社NTTデータ 技術革新統括本部システム技術本部生産技術部インテグレーション技術センタに所属しています。 加えて、私のバックグラウンドについても少々お話しさせてください。
- 今お伝えした通り、私の所属するインテグレーション技術センタでは、TERASOLUNAと呼ばれるフレームワークを用いて開発を行っています。 ご存じのかたも多くいらっしゃると思いますが、TERASOLUNAとは弊社が提供しているもので、バージョンアップを通してより良いフレームワークへと進化しています。 最新のバージョン5系では、Springを中心とした「フレームワーク」、弊社のノウハウを生かした「開発プロセス」と「プロジェクト管理」といったものが詰まっている開発ガイドラインで構成されています。 フレームワーク部分ではOSSを組み合わせ、独自に拡張するといったことを最小限に抑えており、OSSの機能を最大限に発揮するベストプラクティスを提供することに注力しています。
- TERASOLUNAのベースはSpringFrameworkですので、Springイベントでは積極的にスポンサーおよび講演を行っています。 SpringOne Platformのスポンサーとして協賛しており、2015年から毎年参加し続けています。 スポンサーだけでなく、レポートの執筆も行っており、私は直接参加できませんでしたが、今年のSpringOne Platform 2019で行われた講演が 翔泳社様のCodezineというサイトに掲載されていますので、興味がある方はぜひ覗いてみてください。
- ここまでが軽い組織紹介 今回お話しするSpring Integrationですが、なぜSpringIntegrationを今回お話しするかと言いますと、 声高に叫ばれているDXが一つの理由でもあります。システムをクラウドネイティブで一から構築することも増えているとは思いますが、 簡単には丸ごと移行できない既存システムも多く存在します。そのため、新旧全く異なるシステムを繋ぐといった、システム間連携技術が脚光を浴びているというのが背景にあります。 また、弊社の中でも既にSpring Integrationを活用しているプロジェクトが増えてきている状況ですが、TERASOLUNAと比較すると積極的に外部発信していなかったのも理由 別の観点でいえば、Spring Integrationに関する自身の知見をどこまで高められるのかという個人的な理由も含まれています。
- ではそろそろ本題に入ってこうと思いますが、このような流れで紹介していきたいと思います。 まず今きっかけでもお話ししたシステム連携についての背景を少し深堀していきます。 それを踏まえて、Spring Integrationとは何なのか、どのような仕組みで動いているのかをご紹介します。 そのあと、私がHelloWorldのような何かを作ってみましたので、ソースコードレベルでSpring Integrationの簡単な使い方をお見せします。 簡単な使い方をおさらいした後、弊社で実際にどのように用いられているか、(まだ公開されていないところも多く抽象的な説明になってしまうが) 概要と工夫苦労をご紹介します。
- システム連携といったものは実は昔からの大きな課題でして、最初は全く連携など考えていなかったシステム同士、 全く異なる仕様・ハードウェア・アーキテクチャをもつシステム間を連携することは大きな労力を伴っていました。 近年では、先程ご紹介した通り、クラウドネイティブにパブリッククラウド上に構築するのも当たり前になってきています。 そしてそのようなシステムが旧来のオンプレミスなシステムと連携するといったシチュエーションも増えてきています。 そういったときに大切になってくるのが疎結合な連携です。 疎結合とは、個々のコンポーネント同士が緩やかで、独立性を保ったままつながることを指しますが、 DXを進める必要がある現代では、必須ともいえる要件ではないかと思います。 そして、システム間の疎結合な連携を考えるときに外せない鉄板の書籍があります。
- EIPとは、その名の通り企業システムにおける連携手法をカタログ化したもので、システム連携のベストプラクティスと言えるものです。 もう初版から15年以上経つ書籍ですが、今もこのパターンに基づいて検討されるシステムも多いです。 書籍ではありますが、基本的な紹介部分は公式サイトにも公開されているので、一度覗いてみるとよいかと思います。 ちなみに、書籍も公式サイトもすべて英語ですので、苦手な方は頑張ってください。 EIPの中ではシステムの連携を行う際に、4つの手法があると定められています。
- では、その4種類にどのようなものがあるか紹介します。 ファイル転送は連携したい内容をFileの形式にして連携したいシステムに送るのもので、一番メジャーな連携方法と言えます。 DB共有は各アプリケーションに共通のDBを用意しておき、各システムがDBにアクセスすることで、データの共有を実現します。 リモート手続き呼び出しというのは連携元のシステムが、連携先のシステムの手続き、javaでいえばメソッドを呼び出すことでデータを取得する方法です。 非同期メッセージングとは、MessageBusと呼ばれるものを通してデータの共有を行います。 それぞれメリットとデメリットがあるのですが、
- 例えばファイル転送であれば、インターフェースに依存した入出力の実装が必要であったり、 データベース共有では、連携するそれぞれのアプリケーションがDB接続するための実装が必要になります。 リモート手続き呼び出しの場合は、連携に手続きを用いているので、連携先を呼び出した後にレスポンスが帰ってくるまで元のアプリケーションは処理を待機する必要があります。 また、互いの手続きを呼び出すわけですから、メソッドを熟知している必要があります。 このように様々な連携手法があるわけですが、EIPではこれらの課題を解決する手段として、非同期メッセージングを使うことを推奨しています。 この後紹介される連携手法は、この非同期メッセージングをベースとしています。 それでは、その非同期メッセージングの詳細を見ていきたいと思います。
- 疎結合なシステム連携を実現するうえで達成したい要素が全て入っている 非同期メッセージングは疎結合なインテグレーションを実現する EIPに記された非同期メッセージングが
- SpringFrameworkのDIからさらに進み、messagingを用いてコンポーネントの疎結合を促進し、モジュール化とテスト容易性を向上させる。
- ここまでで、SpringIntegrationとその各要素の使い方をソースコードレベルで紹介しました
- では、ここからは、実際の案件にSpringIntegrationを用いたときの話に移っていきたいと思います。 まずはどのようなシステムなのかという概要を紹介します。
- 今回ご紹介するシステムは様々な決済システムと金融機関のシステムをつなぐ大規模なシステムになります。 決済システムというのは、例えばクレジットカード会社が銀行に引き落としの処理をしたり、QRコード決済で銀行に引き落としの処理をしたりと、色々考えられます。 これをSpringIntegrationで実現しているわけですが、先ほどのメッセージフローを一度振り返ってみますと
- これは各要素を説明するための例ですので、決済中継システムにこのフローを当てはめるとどうなるかといいますと、
- このようになります。 特性上、処理が完了したかしていないのかを連携元のシステムが把握する必要があるため、両端のEndpointではAdapterではなくGatewayを使用しています。 そのあと、transformerで業務処理に応じた変換処理と、 真ん中に業務処理があるのがわかると思います。 これが、SpringIntegraionを利用した決済中継システムのメッセージフローになります。
- 各システムの出入り口の切り口を揃え、API化するようなイメージ 想定問答 Spring MVCで似たようなことはできないの？ ⇒Springではないが、Java EEにJMSというAPIがある(有名?) Spring Integrationはその実装の一つだし、他にもApache ActiveMQ、RabbitMQといったミドルウェアもある。 Spring MVCにJMSを実装すれば可能だが、メッセージングに最適化されたライブラリによって、 JMS APIをそのまま使用する場合に比べて記述が容易といったメリットが多いことから、Spring Integrationをお勧めしたい。 メリット⇒プロトコルの対応が多いから 処理の流れに即してコンポーネントが用意されているから
- 次に処理の標準化です。 先程の再利用性のスライドでは詳細に説明しませんでしたが、各システムの切り口を揃えるときに赤枠で示した部分を実装するとお伝えしました。 エンタープライズなシステムではこの中に様々処理が増えることが想定されますが、Spring Integrationではどんなシステムのときはこんな風に設計していくと良いといった開発論までは詳細に説明されていません。 また、これまで話してきたように、Spring Integrationはエンドポイントやチャネルといった要素を組み合わせることで、いかようにも拡張することができてしまいます。(メリットがデメリットになってしまうことも考えられる) このような状態だと、実装がバラけてしまったり、保守性が悪くなってしまうことも考えられます。 そこで社内では、各システムと接続する一連の処理を、サービスコネクタというパーツとして捉え、 サービスコネクタ内部の実装を標準化することで、処理の体裁を統一しています。 これによって、開発の生産性向上を図っています。 では、サービスコネクタの中身をどのように標準化しているのかを見ていきます
- このサービスコネクタはRESTを用いてシステムと連携する場合の実装例です。連携元と接続するサービスコネクタなので、 図の右側にデータ変換や連携先と接続したサービスコネクタが待ち受けているといった状態です。 標準化はSpring MVCと組み合わせて実現しており、先程のシンプルな例と比較して、赤字で示した部分にEndpointが増えたり、先程少し触れたInterceptorと呼ばれるものが増えています。 各要素について、軽く触れたいと思います。
- 今回はRESTの例ですので、まずSpringMVCのControllerがRESTを受け取り、それをgatewayに送信します GatewayはRESTを受け取るとMessageを生成し、リクエストメッセージ変換と呼ばれるTransformerに送信されます。 この過程でinterceptorによってログの取得が行われます。詳細は後述したいと思います。 その後、HibernateValidatorを実装したServiceActivatorでバリデーションを行い、続いて業務処理を行うという流れになっています。 そのあと、先程の図を思い出していただきたいのですが、このサービスコネクタを出た後に、データの変換処理を行い、金融システム側のサービスコネクタを通ってメッセージフローが戻ってきます。 レスポンスが帰ってくると、レスポンス用の業務処理や変換を行い、支払い処理が完了したことが元の決済システムに返却される、というのが一連の正常な流れになります。 もしこのサービスコネクタ内でエラーが発生した場合は、Gatewayでキャッチして下側の例外分岐に遷移した後エラー用のレスポンスを返却しますので、 レスポンスが帰ってこないといったことがないような仕組みになっていることがお分かりいただけるかと思います。 interceptor Gatewayは先程から説明している通り、RESTで受け取った情報からMessageを生成して、channelを通して変換処理を担うtransformerへ送信されます。 ここで注目してほしいのが、Interceptと呼ばれるものを用いてログを残している点です。Spring Integrationの一機能ですが、ここが一つ目の工夫点になりますので、後ほど詳細を紹介します。 transformer Gatewayでpayloadに格納されたメッセージはそのまま突っ込んだだけの状態なので、アプリケーション内で利用しやすい形に変換します。 validation ここのバリデーションはSpringMVCでもよく使われるHibernateValidatorを実装したものです。 ここでは単項目チェックと相関チェックを行います。 bizlogic Bizlogicは初めて出てきたEndpointですが、これは業務処理を実行するためのService Activatorを独自に拡張したものです。 なぜSAをそのまま使わずに拡張しているのかについては、工夫点として後述させていただきます。 ここまでがサービスコネクタ内の処理で、右端のchannelを通してデータ変換の後に金融機関側のサービスコネクタに送信されます。 金融機関側のサービスコネクタで問題なく処理が完了すると、データの受け渡しが完了したというレスポンスが帰ってきます。 このレスポンスが連携元の決済システムにRESTで送信されるという一連の処理が、わずかな時間に行われています。 例外 もしサービスコネクタ内で例外をキャッチした場合は、routerを用いて例外ごとのレスポンスを生成して受信処理に送信し、「エラーが発生した」というレスポンスが必ず帰ってくるという流れになっています。 想定問答 Gatewayはinterfaceだがどうやってcatchするのか ⇒エラーチャネル定義? 要件 ログを変改する前に取得したい
- 単項目チェック 外部リソースを直接参照せず、単一入力項目をチェックする。 依存ライブラリ（Hibernate Validator）とSINCAで提供しているアノテーションを使って、入力チェックで実施する。 相関チェック 外部リソースを直接参照せずに、２つ以上の入力項目の相関性をチェックする。 Bean Validationをカスタマイズして、中間メッセージの項目相関性チェックを実施する。 複合チェック 外部リソースを直接参照し、入力項目をチェックする。 業務仕様に則って、BizLogic でチェックを実施する。
- ここまでが弊社がSpringIntegrationを利用する際に工夫している点になります。 エンタープライズな場面で使うときに問題になる点やその対処について少しでもお伝えできたかなと思います。 それでは、本セッションのまとめとなりますが、
- 以上になります。 ご清聴頂きありがとうございました。