どちらが重要か？実行時あるいは設計時のSOA統制

作者 Boris Lublinsky , 翻訳者 編集部Ｎ 投稿日 2010年2月9日

セクション

運用/インフラ,

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

SOA ,

クラウドコンピューティング ,

ガバナンス

原文(投稿日：2010/01/27)へのリンク

David Linthicum氏は、最近の 投稿 で、SOAの統制について２つの主要なタイプを定義した:

サービス統制の技術には２タイプある：実行時、すなわち、実行中にサービス・ポリシーを強制する能力、そして、設計時、すなわち、サービス・ポリシーを設計し、実装するのを支援する技術である。サービスにアクセスできる人達とサービスでできることをコントロールするために、ポリシーは、サービスと一体である。

Dave氏の意見では、多くの企業でいち早く、もっとも人気のあるトレンドになった、クラウド技術は、設計時のＳＯＡ統制を事実上死滅させ、実行時のＳＯＡを生かすだろう:

 

... 実行時のサービスを実行することに集中したほうが、ずっと価値を提供できる。既存の実行時のＳＯＡ統制の多くは、設計と実装の能力を十分サポートしており、別個の設計時のツールを必要としない。クラウドコンピュータを利用することが、単純に、実行時のSOA統制に対する要求に、集中することを加速し、遅かれ早かれ、設計時のSOA 統制は、不要になるだろう。

K. Scott Morrison氏もDave氏の意見に同意して、次のように 言っている :

大SOA時代（２００９年１月１日以前）には、設計時のSOA統制が、王様だった。それは、大企業規模のSOAへの取り組みを支える、計画－管理－コントロールの統制にうまく当てはまった。一方、実行時のサービス統制は、しばしば、後まで無視することができるものであると考えられた。クラウドが、この優先度を逆転させた。もし公開されているクラウドに、１つのサービスでもデプロイすれば、実行時のサービス統制を行なわなければならない。

彼の意見では、設計時の統制は、完全にはなくならないが、SOAを実装するサイズが大きくなる場合にのみ、役立つものである（ (私の最近の投稿と比べてみよ ):

結局、クラウドにおける統制の優先度の逆転は、非常に単純な教訓に帰着する。一片の機能をコピーするぐらいで、おそらくクビになることはない；ドアを開けっ放しにして、会社のデータを損なうことになるようであれば、おそらくクビだ。

William Vambenepe氏は、SOA++モデル（サービス中心のIT管理へのアプローチ）を定義し、フレームワーク、API、モデル、プロトコル、ツールを統一して、 この議論を更に進めている :

• ITリソースは、すべて消費されるサービスと考えることができる（ハイパーバイザーによって明らかになる"X86+イーサネットのエミュレーション"、アプリケーションサーバによって明らかになる"JEE-互換 プラットフォーム"、データベースによって見えてくる"RDB サービス"、SOAP あるいは HTTP 上のXML/JSON経由で見えてくるwebサービスなど。）
• 単にサービスプロバイダのAPIに要求を送るだけで、これらは、またサービスとして設定できる。
• サービスとして設定できるだけでなく、よく文書化された（しかもしばしば標準の）インターフェースを介して呼び出せる。
• これらは全て、パフォーマンスメトリックス、SLA、ポリシーを通して、同じようなサービス中心の方法で、管理することができる。
• 統合コードは、３つのカテゴリの全てを処理する必要があるかもしれない（例えば、アプリケーションが遅くなるのをそのアプリケーションの依存性を修正するか、そのインフラを再設定するか、あるいは新しいデプロイを行うかによって解決されるかもしれない）
• 今では、これら全てのカテゴリにおける関係は、組織の境界を跨いだり、おそらく使用量ベースの課金で、外部のプロバイダを巻き込む可能性がある。
• これら全ての結果として、ITオートメーションシステムには、本当に、これらの全ての関係を扱うのに、単純で一貫性がある標準的な方法が必要である。オートメーションは、それが適用される環境を単純化し、標準化した時に、最も効果的に機能する。

このモデルでは、サービス／コンテナは、ポリシーとSLAにより定義された品質要求と明確な運用上の契約を結ぶことを支持する。結果として、それらは、マネージメントのフレームワークを必要とし、これらのポリシーとSLA、共通のセキュリティ・インフラ、測定／課金のフレームワークなどを監視する－成熟した実行時のSOA統制。

すばらしいのは、SOAとクラウドコンピューティングの緊密な関係により、実行時のSOA 統制の重要性を明らかにしていることである。しかし、設計時のSOA統制を犠牲にして、これをやっても上手くいかないようである。結局、 SOAの約束は、なおも、ビジネスとITとをうまく協調させることであり、このことは、 エンタプライズ・ビジネスモデルによってもたらされた分析をもとに、サービスを設計すること無しに不可能である。このことは、設計時の統制は、なおも、あらゆる真のSOAの実装における中心部分であることを意味する。論点は、どちらのSOA統制がより重要か、ではなく、いかに両方共正しく実装できるかである。

• 次へ >