マイクロサービスの機能を再整理する
エンジン型を採用していると、独自に実装を行っている部分もEAIエンジンでの連携コンポーネントにしてさらなる再利用性を高めるとよりメリットが多くなります。その理由として、1つのマイクロサービスが提供しているサービスの全体構成自体の再整理が可能になるためです。
再構成の例
第1回では、今でも業務システムはマイクロサービスよりも統合型システムの方が管理しやすいということを紹介しました。その理由が各機能毎が密結合できず、状態を把握しにくいからという点を説明しました。
しかし、このEAIエンジンを内包し、かつ、それぞれの機能をコンポーネント化することで、より機能自体が再配置しやすくなり、マイクロサービス化も、統合型システム化もしやすくなります。
例えば、図11のように、当初「顧客管理」と「注文管理」をするマイクロサービスが2つあり、そこから顧客属性と注文履歴に応じてレコメンデーション機能を追加することになったとします。
つまり、新たな機能は「顧客管理」と「注文管理」の一部分の機能を共に必要としてしまいます。このとき、例えば、図11の（1）のように「注文管理」をするマイクロサービスの拡張としてレコメンデーション機能を追加したとします。
ここで、各独自機能がコンポーネント化できていれば顧客情報の参照機能も同様に簡単にコピーが可能です。そして、新たにレコメンド機能だけを追加すればよくなります。
そして、さらに事業が成長し、今度は、まだ顧客になっていない人にもこれまでの顧客属性を参考にレコメンデーションを出したいという要望が出てきたとします。そのときには、再度、必要なコンポーネントだけを取り出し、（2）のように新たにマイクロサービス化が可能になります。
もちろん、これらをすべて1つの場所に置けば統合型システムということになります。このように規模やセキュリティ要件、運用上の特徴により機能自体が再配置できるようになるため、同じような機能を要望する事業を横展開する必要性が生じた時にもすばやく立ち上げることが可能になります。
汎用コンポーネントの設計ヒント
このように機能をコンポーネント化し、それをEAIエンジンに自由に配置できるようになると、より汎用的な機能をコンポーネント化して、再配置可能な部品として作成できると便利です。
しかし、実際に汎用的なコンポーネントを作成しようとしても、なかなかどうすればよいかわかりません。また、そのような経験談も聞くことはあまりないかと思います。
そこで今回は弊社が提供しているPDFソリューションであるQuick2PDF内部で動いているPDFコンポーネントが出来るまでの経験を踏まえ一例としてして紹介したいと思います。
入力の順番と取得方法を再考する
プログラムで自動的にPDF帳票を作ろうとすると一般的には図12のように、（1）PDFの作成開始、そして、（2）レイアウトに構造の作成、（3）実データの設定、（4）PDFへの書き出しのような流れで作成していきます。
この（1）〜（4）までの手順は一連の流れであり分割できない処理になってしまっています。従って、この構造のままPDF化をコンポーネント化しようとしてレイアウトが固定されたコンポーネント化になってしまいます。
一方、一般的にWordやエクセルなどを使ってPDFを作成する場合では、図13のように作成者がもっとも扱いやすいフォーマット上で作成したあとに、その後、フォーマットをPDFとしてエクスポートします。
このようにフォーマット変換という形であれば、PDF化のコンポーネントを作ってもさまざまな用途に使えそうです。また、帳票のレイアウトや実データの設定という部分での固有実装は残りますが、WebシステムにおいてはHTMLを作るということは他の機能に比べて非常に効率化できるはずです。
そして、最終的にできあがったPDFコンポーネントの構造が図14のようになっています。
つまり、これで当初の「月次レポート」の全体の処理が図15のようにEAIエンジンの中ですべて動かせるようになったということです。
ただし、その弊害としては「月次レポート」のためのデータ収集やレイアウト作成が一連の流れから完全に疎結合になってしまうことです。疎結合になるということは技術的には好ましいことではありますが、一方で運用を把握する上ではわかりにくくなる原因の1つでもあります。
特にWebシステムだけを見た時に誰からアクセスされているのかわからない「月次レポート」という画面が存在することになってしまいますので、その部分はドキュメントなどで関係を管理する必要性が生じます。
