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

非同期メッセージ基盤の3つの機能としてあげるのが、CBRです。これは入ってきたメッセージによって処理コンポーネント（サービス）を変えることができる機能です。 よくあるパターンでは、商品や受注の内容によって、外注したり、売上の立て方といった違いをこの機能で吸収します。あるいはインプットデータの中にバージョン番号を含めて、バージョンアップに対する実装を変えるといった進め方をする場合もあります。

[続きを読む →]

ここでいう接続方式とは、Webサービス、MQ（JMS）、SMTP、RESTなどの技術的な手段を表しています。接続方式から、連携元・先を独立させることで連携元・先が変更・増加した場合でも影響を少なくすることができます。 通常、この方式をコネクターのようなもので実装し、何らかの設定ファイルでサービスの実装コンポーネントと結びつけてこの内容を実現します。このようなコネクタの提供およびサービスとの連結を実現ｄけいることが非同期メッセージ連携基盤として重要なことです。

[続きを読む →]

企業システムの全体アーキテクチャには、非同期分散メッセージ基盤を中央に入れてシステム・サブシステム間連携の礎とするべきだと思うようになった。連携先・元の稼働状態（SLA）や変更に対する対応（システムの統廃合による移行も含む）、NxMといった連携本数の増加してしまう問題を考慮に入れるとシステム間には一層、層を設けてその影響範囲を吸収すべきと思う。 そのような分散基盤にどのような機能が必要なのかを考えてみようと思い、このエントリを書きました。しばらく続けますのでよろしくお願いします。 プロキシサービス まず最初にプロキシーサービスを実現できる機能が必要かと思います。システムそのものは、サービスとアプリケーションに分かれます。アプリケーションは自由に作成され、簡単に改廃されますが サービスは業務ルールの変更による改修以外はあまり変更されず、標準的な内容に昇華していきます。そのため、サービスの配置は柔軟にすべきです。しかし、アプリはサービスを利用しているのでプロキシのようなサービスを用いることで、配置を変えても影響しなくなります。UDDIのような技術で配置場所を検索しても実現できますがあとの記事で書こうと思っているシーケンスサービスをプロキシサービスとすることで呼び出すサービスとIDやメッセージ形態の違いを変換するサービスを挟み込むことができるようになるため、このような機能が必要です。

[続きを読む →]