InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

OSGi、SCA、BPEL、Springで管理容易性を強化

作者 Jean-Jacques Dubray , 翻訳者 編集部 投稿日 2008年3月8日

セクション
エンタープライズ・アーキテクチャ
トピック
SOA ,
SOAプラットフォーム
タグ
OSGi ,
マネジメント ,
Service Component Architecture ,
Spring ,
BPEL

OpenSOAイニシアティブが「Power Combination, SCA, OSGi and Spring(source)」(OSGi、SCA、Springの強力な組合せ)という表題のホワイトペーパーを発表して以来、これら3技術の組合せは話題を呼んできた。インフラの商用実装(source)でさえ存在する。Spring Dynamic Module(source)はすでにSpringとOGSiを結合しており、他方、Spring BeanはSCAコンポーネントの実装(source)として使える。最近、TuscanyのJava実装がApacheのOSGiフレームワークFelix上(source)に構築された。

William Vambenepeがこの新種のインフラを認める用意がある(source)なら、次のようになるだろう。

  • 「柔軟性」(OSGiのおかげ)

  • 「テスト容易性」(Springのおかげ)

  •  「再使用可能性」(SCAのおかげ)

Vambenepeは以下の点で、ホワイトペーパーの著者に同意するのをややためらっている。

  • 「簡潔性」 ...3つすべてと関わりのある少数派に属さない限り、該当しないでしょう。

  • 「管理容易性」は「管理容易潜在性」と呼んで、親しい付き合いを続けましょう。

管理容易性はSOAの重要側面である。シアトルに本拠を置く大手保険会社でBusiness Architecture部長を務めるBrian Cowan氏は、私信で次のように指摘している。

SOAはマネージメントとオペレーションにモノリシック・アプリケーションモデルの複雑性を押しつけているように思われます。独立したソリューションの実装やデプロイ、スケール、確保を手に入れる能力に対する代償です。

Williamは過去の投稿(source)ですでに、管理容易性に対するSCAの影響について意見を述べている。    

 SCAにもう1つ利点があります。アプリケーション管理とサービス管理で役立つ粒度レベルで、コンポジット・アプリケーションのロジックが機械で読み込み可能な記述になっていることです。

[同様に] SCAのように、BPELは管理容易性を目的に設計されたわけではありません。生産性、ポータビリティ、柔軟性の向上を意図していました。[中略]アプリケーション管理に非常に有用なメタデータも提供します。アプリケーション・フローをハイライトすること(アクティビティを通して)と、依存性と関連ポリシーを明白にすること(パートナーリンクを通して)の両方の点から見て、です。

SCA、OGSi、Springはそのギャップを埋めるのにも役立ちます。アプリケーションメタデータをさらに提供し、アプリケーション管理ツールがそのメタデータを活用して、管理タスクにさらに多くのアプリケーションコンテキストを提供できます。

OSGiを広く紹介している(PDF・英語)このホワイトペーパーで、著者は次のように書いている。

OSGiサービスプラットフォームは、無人状態、もしくはプラットフォームオペレーターの管理下で稼働可能な装置向けに特に設計されています。リモート管理を必要とする装置です。

装置のリモート管理にはプロトコルが必要です。SNMP、CMISE、CIM、OMA DMなど、多数の選択肢があるため、適切なプロトコルの選択は難しいのです。

OSGi Allianceは、1つのプロトコルが全ケースに適合することはないという理由から、他より好ましい管理プロトコルは存在しえないと決定しました。そのためOSGi Allianceはアーキテクチャを選択しましたが、このアーキテクチャが認定バンドルによって使用される管理APIを提供します。この認定バンドルは次に、管理バンドル役を務めることができ、API呼び出しへのプロトコルをこのバンドルがマップするのです。

事実、スペインのマドリード工科大学(サイト・英語)(UPM)情報通信工学部(サイト・英語)(DIT)は、OSGiサービスプラットフォーム向けのJMXベースの管理エージェントを開発した。その名をJMood(サイト・英語)という。

Williamは警告で締めくくっている。

すべて胸躍るような出来事ですが、こうした規格をがんじがらめに結合してしまう危険を冒すには、あまりに時期尚早ではないかと訝しむ自分も存在します。「開発途中の規格をひとまとめにしたものが、一体となって正確に動作し、世界の全ニーズに対応する」というような、「標準フレームワーク」的性質を謳うPowerPointのスライドを、これまで余りにもたくさん見てきましたから。

原文はこちらです:http://www.infoq.com/news/2008/02/manageability-oss

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。