開発のCMMIにいくつかのプロセスエリアが追加された運用プロセスのCMMIがある。運用を考える上でのベースといえばITILでしたが、このCMMI for Servicesもその対象となりそう。 参考となる本として CMMI for Services: Guidelines for Superior Service (SEI Series in Software Engineering) 著者／訳者：Eileen C. Forrester Brandon L. Buteau Sandy Shrum 出版社：Addison-Wesley Professional( 2009-11-09 ) ハードカバー ( 720 ページ ) があります。追加された知識エリアを書いていこうと思っています。
2010年02月25日のエントリー
ESBのパフォーマンス
2010年02月25日 · コメント（0） · 非同期分散メッセージ基盤
ESBがオーバーヘッドであることは間違いありませんが、データなしに語るのもどうかと思い見つけたのが以下の資料。 http://wso2.org/library/1721 この資料でESBのｵｰﾊﾞヘッドが評価できます。このデータでサービス呼び出しまでのｵｰﾊﾞヘッドを積み上げられるので、後はサービスの処理そのもののレスポンスと画面系のレスポンスを積み上げれば概算はできます。（あくまでも概算で、性能は計測してなんぼなので）
タグ :
可用性と拡張性が担保できる
2010年02月25日 · コメント（0） · 非同期分散メッセージ基盤
システム連携基盤としてのESBの意義を書いてきましたが、意義が大きくなればなるほど停止時の被害は大きくなります。そのため、冗長性をもつ構成となることが必須条件となります。また負荷が高くなった場合にスケールアウトできる構成となる拡張性を持たせることも重要になります。メッセージによって振り分けがされる分散も必要です。 その意味でESBの拡張性として ・リプリケートされた複数ノード ・メッセージの分担が決定されている複数ノード に分かれます。後者の場合は振り分けをしてくれるノードも必要となります。
タグ :
メッセージ変換ができる
2010年02月25日 · コメント（0） · 非同期分散メッセージ基盤
mediateできるにも通じますが、そのフローの中でメッセージの変換ができると言うのも重要な機能になります。サービスの呼び出し側と受け側でＩＦを統一するにはＮｘＭ（呼び出し側Ｎ種類、呼び出し先Ｍ種類）の数だけＩＦが必要になってしまいます。そこでそれぞれＮ個とＭ個のＩＦを定義して、ＮｘＭ個の変換をＥＳＢ側に持たせることで対応することで、各システムはその知識を必要としないことが可能となります。 当然、その知識がＥＳＢ側に移動するだけですが、変換の知識だけなので同じような内容を毎回作成する必要もなくなりますし、影響範囲をＥＳＢ内にとどめることもでき、バージョン管理もCBRを利用して可能なため、システム側にあるよりもESB側にあるほうがふさわしいと考えることができます。デメリットとしてはESBの負荷が高まるというのがありますが、スケールアウトできる構成であれば負荷をどこに置くかという問題にすり替わるので問題ないと考えています。
タグ :
mediateできる
2010年02月25日 · コメント（0） · 非同期分散メッセージ基盤
いくつかのサービスを束ねて一つのサービスと見せることができる。 サービスの粒度を柔軟に変更するために必要な機能でデータサービスのレベルからビジネスとして価値を生み出す業務サービスまでの粒度の違いを吸収します。同期・非同期の変換もこの中でやるとよいでしょう。 但し、 ＢＰＥＬが守備範囲とするような業務フローレベルでのｍｅｄｉａｔｅは守備範囲外とみた方がよく、人間系の含まないレベルの統合がＥＳＢにおけるmediateの範囲とみた方が良いと思います。
タグ :