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

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

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

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

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

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

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

プロキシサービス

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

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

移行というと、レガシーシステムから利用しているデータを抽出して、新システムへデータを投入する「データ移行」が代表的です。

データ移行は、既存システムのデータスキーマ（抽出するデータフォーマット）と新システムのデータスキーマの形式・意味上の差異を把握し、その変換をおこなうことが主たる表の作業となります。

表と書いたのには理由があって、いわゆるデータクレジングという地道な作業が裏の作業としてあります。抽出したデータが矛盾のない、整合性のある、同じデータが複数ない（名寄せ）といった状態にして、移行プログラムで移行します。（既存、新システムとも止められないとなるとその差分の移行中のトランザクションデータをどうするといった問題もあったり、移行は一発でうまくいかないといったいろいろな問題もありますが、主たるという意味では上記のようにとらえることができます。）

どうしても、データ移行に意識がいきがちな移行ですが、新システムを使った新しい業務がスムーズに実行できるように考える業務移行というのも一つの移行ですし、システム化計画を考える場合には、システムがどう移行させていくかという観点の「システム移行」が大事になります。システム移行は、システムをリプレースされていく中で安全にリプレースできる仕掛けを用意することを考える必要があります。システム間が複雑に関連しあっている場合にビッグバンでやらずに一部だけを置き換えて他のシステムに影響与えないように、一層、層を設けて影響をその層で吸収するように工夫します。

移行は難しいですね。

Cloudera Distribution for Hadoopのインストール方法を拝見した。

コンフィグレーションを管理サイトで登録して、コンフィグレーション済みのパッケージングされたソフトをRPMとしてダウンロードしてインストールする。

Hadoopだからということではなく、コンフィグレーション管理のサービスが生まれ、クラウド上にカスタマイズされたソフトウェアをダウンロードしてクラウド上のノードで実行する。クラウドを移設することも可能になるだろうし、発展すれば、コンフィグレーションがプロファイルのようなものになり、どこで実行するのかはクラウドの価格やリソースなどで動的に変更できる。（データ移行もあるのでそう簡単ではないが）

そういう新しい時代のソフトウェア管理方法を見たような気がして、はっとさせられた。もちろん、HPC的なクラウドも、ガｰトナーの言うところの、CDA（Context Deliver Achitecture）のコンテキスト情報を扱う上で、重要な要素であることは間違えないのでおろそかにできないのだが、今日は別のことを感じた。

Amazon.comからKindleを買いました。洋書用で買ったのですが日本語を表示するHackがあったのでそれを導入したところ、日本語が読めました！

Hackを紹介していたBlogのYoshiさんありがとうございます。PDFを変換して日本語のPDFも読めるようになったので、手持ちの資料の持ち歩きたいものは入れておこう。

ITILを考える上で青本（サービスサポート）ばかりを見ていたので、ちょっと反省し赤本（サービスデリバリ）について考えてみる。
まず、なぜ赤本を見なかったかを振り返ってみると、サービスレベル管理・IT財務管理あたりが話が大きくなりすぎている感を受けているからだった。

確かに話が大きいが、全体方針がないところで部分を考えても仕方がない面があるので確認するとサービスデリバリに沿って計画された内容を運用管理・運用オペレーションをおこない、その結果が反している場合、あるいは利用者から問合せ（クレーム、要望なども含む）があった場合にサービスサポートのプロセスを利用するという理解をした。

その流れを図にしたら以下のようになった。

ITILの概要図