TAKAが試したこと考えたこと

InfoQからの引用

アーキテクチャドキュメントには、システムのコンテキスト、機能構造、デプロイメント環境、情報構造、運用環境などを定義して、非機能要件がどのように満たされるのか説明しておく必要があります。

ESBがオーバーヘッドであることは間違いありませんが、データなしに語るのもどうかと思い見つけたのが以下の資料。

http://wso2.org/library/1721

この資料でESBのｵｰﾊﾞヘッドが評価できます。このデータでサービス呼び出しまでのｵｰﾊﾞヘッドを積み上げられるので、後はサービスの処理そのもののレスポンスと画面系のレスポンスを積み上げれば概算はできます。（あくまでも概算で、性能は計測してなんぼなので）

システム連携基盤としてのESBの意義を書いてきましたが、意義が大きくなればなるほど停止時の被害は大きくなります。そのため、冗長性をもつ構成となることが必須条件となります。また負荷が高くなった場合にスケールアウトできる構成となる拡張性を持たせることも重要になります。メッセージによって振り分けがされる分散も必要です。

その意味でESBの拡張性として
・リプリケートされた複数ノード
・メッセージの分担が決定されている複数ノード
に分かれます。後者の場合は振り分けをしてくれるノードも必要となります。

mediateできるにも通じますが、そのフローの中でメッセージの変換ができると言うのも重要な機能になります。サービスの呼び出し側と受け側でＩＦを統一するにはＮｘＭ（呼び出し側Ｎ種類、呼び出し先Ｍ種類）の数だけＩＦが必要になってしまいます。そこでそれぞれＮ個とＭ個のＩＦを定義して、ＮｘＭ個の変換をＥＳＢ側に持たせることで対応することで、各システムはその知識を必要としないことが可能となります。

当然、その知識がＥＳＢ側に移動するだけですが、変換の知識だけなので同じような内容を毎回作成する必要もなくなりますし、影響範囲をＥＳＢ内にとどめることもでき、バージョン管理もCBRを利用して可能なため、システム側にあるよりもESB側にあるほうがふさわしいと考えることができます。デメリットとしてはESBの負荷が高まるというのがありますが、スケールアウトできる構成であれば負荷をどこに置くかという問題にすり替わるので問題ないと考えています。

いくつかのサービスを束ねて一つのサービスと見せることができる。

サービスの粒度を柔軟に変更するために必要な機能でデータサービスのレベルからビジネスとして価値を生み出す業務サービスまでの粒度の違いを吸収します。同期・非同期の変換もこの中でやるとよいでしょう。

但し、 ＢＰＥＬが守備範囲とするような業務フローレベルでのｍｅｄｉａｔｅは守備範囲外とみた方がよく、人間系の含まないレベルの統合がＥＳＢにおけるmediateの範囲とみた方が良いと思います。

非同期メッセージ基盤の3つの機能としてあげるのが、CBRです。これは入ってきたメッセージによって処理コンポーネント（サービス）を変えることができる機能です。

よくあるパターンでは、商品や受注の内容によって、外注したり、売上の立て方といった違いをこの機能で吸収します。あるいはインプットデータの中にバージョン番号を含めて、バージョンアップに対する実装を変えるといった進め方をする場合もあります。

ここでいう接続方式とは、Webサービス、MQ（JMS）、SMTP、RESTなどの技術的な手段を表しています。接続方式から、連携元・先を独立させることで連携元・先が変更・増加した場合でも影響を少なくすることができます。

通常、この方式をコネクターのようなもので実装し、何らかの設定ファイルでサービスの実装コンポーネントと結びつけてこの内容を実現します。このようなコネクタの提供およびサービスとの連結を実現ｄけいることが非同期メッセージ連携基盤として重要なことです。

企業システムの全体アーキテクチャには、非同期分散メッセージ基盤を中央に入れてシステム・サブシステム間連携の礎とするべきだと思うようになった。連携先・元の稼働状態（SLA）や変更に対する対応（システムの統廃合による移行も含む）、NxMといった連携本数の増加してしまう問題を考慮に入れるとシステム間には一層、層を設けてその影響範囲を吸収すべきと思う。

そのような分散基盤にどのような機能が必要なのかを考えてみようと思い、このエントリを書きました。しばらく続けますのでよろしくお願いします。

プロキシサービス

まず最初にプロキシーサービスを実現できる機能が必要かと思います。システムそのものは、サービスとアプリケーションに分かれます。アプリケーションは自由に作成され、簡単に改廃されますが

サービスは業務ルールの変更による改修以外はあまり変更されず、標準的な内容に昇華していきます。そのため、サービスの配置は柔軟にすべきです。しかし、アプリはサービスを利用しているのでプロキシのようなサービスを用いることで、配置を変えても影響しなくなります。UDDIのような技術で配置場所を検索しても実現できますがあとの記事で書こうと思っているシーケンスサービスをプロキシサービスとすることで呼び出すサービスとIDやメッセージ形態の違いを変換するサービスを挟み込むことができるようになるため、このような機能が必要です。