BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Jim Marino 氏に聞く - Fabric 1.5 リリース

Jim Marino 氏に聞く - Fabric 1.5 リリース

ブックマーク

原文(投稿日:2010/05/05)へのリンク

Fabric3 - サービスコンポーネントアーキテクチャ(Service Component Architecture,SCA) のオープンソース実装 - のリリース 1.5 が発表された。

今回のリリースは OASIS SCA アセンブリ仕様(Assembly Specification) v1.1 を実装した前回リリース(1.4) をベースに,次のような機能が新たに追加されている。

  • クラスタサポートの改善。複数のクラスタへのデプロイと個別ベースのデプロイの両方を対象とする,デプロイ失敗時のロールバック機能などが追加された。
  • WebLogic 10.3 との密接なインテグレーション。WebLogic クラスタリング,JMS,自己チューニング型スレッド管理,JMX,トランザクション,自動データソース検出などがサポートされた。

InfoQ では今回のリリースについて Jim Marino 氏にインタビューした。氏は Metaform Systems の創業者で,SCA 仕様のコントリビュータでもある。

InfoQ: 最初に SCA の必要性について説明してください。J2EE や .NET,Web サービス,REST,JMS などが存在する中で,さらに別の仕様/実装が必要な理由は何でしょうか。

JM: 簡単に言うと,SCA によって分散アプリケーションの記述が容易になるためです。これまでの技術では実装が非常に困難,あるいは非現実的であった多くの機能が,SCA を用いることで実現可能になります。SCA は分散アプリケーションを実現し,管理するための基盤なのです。この説明では分かりにくいと思いますので,SCA を明確に定義するために,あなたが先程上げられたテクノロジと SCA との関係についてご説明しましょう。

最初に JavaEE との関係ですが,これにはいろいろなファクタがあります。SCA は JPA やサーブレットなど,JavaEE の多くの API に適合しています。Fabric3 を例に取れば,エンティティマネージャインジェクション(entity manager injection) や永続化コンテキスト管理(persistence context management),透過的トランザクションマネージャ統合(transparent transaction manager integration) といった機能を,Hibernate 上に実装して提供しています。Hibernate と JPA は,Fabric3 でリレーショナルデータにアクセスするための,最も一般的な手段です。

プログラムモデルのレベルでは,SCA は EJB やその他のプログラミングモデルの代替手段を提供しています。この2つはどちらも依存性注入(dependency injection) に基づいて設計されているという点で,大きな違いはありません。しかし SCA のプログラミングモデルでは非同期プログラミングが特に重視されていて,リモートサービス呼び出し(remote service invocation) が扱いやすい構成になっています。さらに SCA 仕様策定グループは,イベント処理と pub/sub パターンをプログラミングモデルで直接サポートするための追加作業にも取り組んでいます。この結果として,重要な機能がさらに多く追加されるものと思います。

SCA には JavaEE や他のテクノロジにはない,重要な機能があります - アセンブリ(assembly) とポリシー(policy) です。アセンブリは一連のサービスからアプリケーションを構築するための手段です。対象とするサービスはローカル,リモートを問いません。アプリケーションのパーツを結合する方法である,という点で,アセンブリは Spring のアプリケーションコンテキストに似ているかも知れません。しかしアプリケーションコンテキストとは違って,アセンブリは分散したアプリケーション間の結合も定義できるのです。アセンブリの提供するもうひとつの機能はモジュール化(modularity) です。アセンブリでは,他のサービスを使ってサービスを構成することができます。これを利用して OSGi など下位レベルのモジュールシステム上に,モジュール化されたアプリケーションアーキテクチャを設計することも可能です。

アセンブリはとても強力な機能です。単一のアプリケーション構成のみでなく,非常に粗い粒度から細かな粒度に到るまで,組織内のすべてのサービスを記述することができるのです。Fabric3 では,アセンブリを解析してミドルウェアの要求するサービスを確定し,それに従ってランタイムインフラストラクチャを動的に設定しています。サービスを利用しているクライアントを検索する依存性解析や,SLA(Service Level Agreement) の適合性判定も可能です。分散コンピューティングシステムでは非常に多くのサービスが使用されるようになりますが,アセンブリの情報を活用することで適切な管理ができるのです。

SCA の重要な機能にもうひとつ,クロスアプリケーションポリシー(cross-application policy) があります。SCA ではセキュリティタイプや SLA などのポリシーに関して,複数のアプリケーションで共用できる選択肢のセットを定義することができます。SCA 以外のプログラミングモデルでは通常,エンドポイントごとにポリシーを定義しなければなりません。これは複雑でエラーを起こしやすい,面倒な作業です。これに対して SCA では,一度定義したポリシーを "pull" または "push" 形式で再利用することができるのです。"pull" は Java のアノテーションを使ってポリシーのエイリアス名を参照する仕組みです。push の方は "分散型" 多言語 AOP の一種と考えて頂ければよいでしょう。こちらの仕組みではポリシーと,XPath をベースとした問い合わせ式を定義します。問い合わせ式はアセンブリに対して,ポリシーの適用対象を決定するときに評価されるものです。" デプロイされたすべての web サービスエンドポイントにおいて X.509 認証を有効にする" というような具合に定義します。

以上から言えるのは,SCA では既存のテクノロジが多数利用されている,ということです。例えば,相互運用性を確保するために Web サービス (特に WS-*) が使用されています。.NET などで記述された外部クライアントに機能を提供する SCA サービスにとって,これは重要な意味があります。サービス間の通信には JMS が使用できます。信頼性のある通信が必要な場合にはこちらが重要です。さらに Fabric3 では,SCA アプリケーションに RESTful なファサードを提供するために,JAX-RS も使用しています。

.NET に関する説明を最後に持ってきたのは,SCA との関連において,潜在的にもっとも興味深い部分があるからです。SCA は Java EE とは違い,多言語を前提に設計されています。.NET のサービスベースのプログラミングモデルである Windows Communication Foundation (WCF) もまた,SCA と同じ要求から出発しています。Microsoft が .NET で目指したのは,サービスベースの分散アプリケーション構築の要件に応え得るような,シンプルなプログラミングモデルでした。WCF サービスと SCA コンポーネントを比較すれば,非常に似通っていると思うことでしょう。実際この2つのモデルは,中心となるコンセプトの大部分を直接対応付けできるのです。

しかし .NET には,さらに特定するならば WCF には,SCA のアセンブリに相当するものがありません。現時点では,WCF のサービスは個別に生成,設定,デプロイされる,非常に "自立的(autonomous)" な形式を持っています。SCA のアセンブリは,この WCF サービスを構造化するためにも利用できるのです。実を言うと私は,SCA をすでにサポートしている Java ベースのベンダよりも Microsoft の方が,SCA に関してはよい位置にいると考えても間違いではない,と思っているのです。Microsoft の CLR は,JVM にはない多言語対応をすでに実現しています。さらに .NET という,アプリケーション開発全般に対して非常に統一性のあるプラットフォームも存在しています。SCA の .NET バージョンが実現すれば,Java ベースよりも統合的で完全なものになる,と期待してもよいでしょう。

別の見方をすれば,現在の .NET の機能を越えたイノベーションの代表例が SCA のアセンブリなのです。Microsoft がこれにどう対応するか,興味の持たれるところです。

InfoQ: Fabric3 がサポートしている SCA の仕様と,今後の予定について説明してください。

JM: そうですね,Fabric3 では現在,SCA のアセンブリ,ポリシー,Java,Web サービスバインディング,HTTP バインディング,それから JMS 仕様がサポートされています。

次のリリースに向けて作業を進めている機能が2つあります。イベンティグ(publisher/subscriber 通信) と Spring です。イベンティングは,SCA によってイベントベースのアーキテクチャを作成可能にするものです。アプリケーションに複雑なイベント処理を,容易に組み込めるようになります。金融関連サービスに携わっているユーザの多くが,マーケット情報を解析する目的で,この機能の利用を希望しているのです。また Spring をサポートすることで,SCM による Spring beans とリモートサービスの結合が可能になります。

仮想環境やクラウドベース環境の利点を取り入れたランタイムアーキテクチャの設計にも,多くの投資をしています。ただし,既存のミドルウェアをこれらの環境に当てはめようとは思っていません。この点は "レガシー" なミドルウェアベンダたちと違うところです。私たちは前に進んで,メッセージベースのサービスだけではなく,非マルチキャストベースのクラスタに関しても,SQS(Simple Queue Service) など Amazon EC2 機能との統合を検討しているのです。

InfoQ: Fabric3 の提供する機能で,SCA の範囲外のものは何でしょうか。それらを選択した理由も教えてください。

JM: Fabric3 は,一般的なミドルウェア製品にあるような機能も数多く提供しています。例えば,

  • クラスタリング。F3 のクラスタ機能は設定が容易で,マルチクラスタのトポロジー,アプリケーションやランタイムリソースのノードへの自動設定(automatic provisioning)などをサポートします。
  • 信頼性。F3 は XA トランザクションとリカバリ (これには Atomikos を使用しています。大変優れた製品で,強く推奨します),補償(compensation)/memento モデルに基づく高信頼性デプロイメントをサポートします。
  • 可搬性。F3 には Tomcat を始めとする各種のアプリケーションサーバ上で実行可能な,フットプリント(メモリ使用量)の小さいスタンドアロン型サーバが用意されています。また最新のリリースは WebLogic サーバをサポートしているので,スレッド管理のセルフチューニングやクラスタコミュニケーションなど,WebLogic サーバの高度な機能を利用できます。さらに Fabric3 には Ant や Maven のランタイムも組み込まれています。これらすべての環境に対して,アプリケーション修正の必要なくデプロイ可能にすることが目標です。

このような機能は,企業ソフトウェアからの要請に基づくもの,と言ってよいでしょう。Fabric3 はその他にも,たくさんの革新的機能を持っています。例えば,ワイアリングとポリシーの動的変更(dynamic wiring and policy) によって,アプリケーションのサービスを中断することなく,ワイアリングの更新やアップデートが可能になります。SLA などのポリシーをデプロイ後に "追加" することもできるのです。

Fabric3 は,アプリケーションの必要に対応して,ランタイムエクステンションを自動セットアップするように設定できます。例えば,いくつかのサービスが Hibernate を使用していることを検出して,サービスのデプロイ時に Hibernate ランタイムエクステンションをクラスタノードに自動セットアップするようなことが可能です。処理はすべて動的に実行されますので,リスタートの必要はありません。アプリケーションがアンデプロイされる場合も同じように,ノードで使用されなくなったエクステンションが自動的に削除されます。

私の気に入っている機能のひとつがランタイム拡張性(runtime extensibility) です。Fabric3 はモジュール化されたカーネルを中心として,リモートトランスポートやトランザクションなどのサポートを拡張機能として追加するように設計されています。拡張性について面白いと思うのは,これが実は SCA 仕様の "範囲を越えて" いない,という点です。実はランタイム自体,SCA サービスのセットで構成されているのです。Fabric3 には小規模なブートストラップがあって,これが SCA アセンブリを読み込み,ランタイム構築に必要なサービスを結合していきます。つまりランタイムの拡張は,SCA "アプリケーション" を特別なランタイムドメインにデプロイすることで実現されているのです。これによってランタイムも,エクステンションによって動的に更新することが可能になっています。エンドユーザアプリケーションのデプロイと実質的に同じなのです。

イベンティングのサポートが完了したら (暫定実装はFabric3 ソースのトランク(trunk)にあります),ランタイムの作成とイベントストリームの強化に取り掛かる予定です。そうすればランタイムイベントの複雑なイベント操作のようなオペレーションの実行や,Fabric3 クラスタをいろいろな実行環境向けに調整することが可能になります。

InfoQ: Fabric3 を他の一般的な SCA 実装,例えば Tuscany などと比較して頂けますか。

JM: Tuscany プロジェクトは,SCA 普及の上で重要な役割を果たしていると思います。また,ひとつの標準に対して複数の - 特にオープンソースの - 実装が存在することは,選択肢を提供し,競争によってイノベーションを促進する点で望ましいことです。

そうではありますが,私は Fabric3 にたくさんの利点があると確信しています。その中心となるのはこれまでに説明したエンタープライズ機能,拡張性,動的ワイアリング,それと使いやすさです。Tuscany は IBM が主導していますので,ビジネスモデル的には高額商品を購入する顧客,オープンソース上で企業向け機能を提供する製品を指向しています。彼らの目標と私たちの目標は違うのです。進展していく方向もおのずと異なるでしょう。

InfoQ: Fabric3 では BPEL エンジンとの統合は実現されるのでしょうか。SCA と BPEL との関連についての考えを聞かせてください。

JM: そうですね,BPEL 製品の SCA プラットフォームとして Fabric3 を使用しているビジネスパートナーは存在します。Apache ODE と Fabric3 の統合作業を行っている開発者が他にいますが,こちらはまだ開発途上で,ダウンロード公開には至っていません。

もっと広範に,SCA と BPEL の連携について言うならば,BPEL を用いたサービス生成を SCA で可能にする,ということになります。この2つを統合することには,注目に値する利点がたくさんあります。まず SCA 側から見れば,プロセス指向のサービス実装に BPEL 言語を活用できます。BPEL 側からは,SCA を使うことによって,Java のような従来型の言語に適したアプリケーション部品を容易に記述できるようになります。例えば BPEL から Java コードをアクセスするには,SCA がなければ Web サービスを用いるか,あるいは特定のベンダが提供するプロプライエタリな統合機構を利用しなければなりません。SCA を用いれば標準化された方法で,Web サービスに伴うオーバーヘッドや複雑な処理の必要もなく,簡単に Java にアクセスできるのです。さらに,BPEL と Java のコンポーネントを単一ユニットとしてデプロイすることも可能になります。

InfoQ: 自動デプロイを行うために,Fabric3 にはどのような機能が用意されていますか。

JM: Fabric3 は先進的なデプロイ機能を数多く持っています。すでに説明したように,F3 には複数のクラスタに分散するノード群に対して,アプリケーションアーカイブを自動的にセットアップする機能があります。間接的な依存関係も適切に処理します。ランタイムも SCA を使用して構築されていますので,必要なランタイムエクステンション(と,それが参照するアーカイブ)を,アプリケーションの時と同じ機構を用いて設定できるのです。

1.5 リリースで追加された機能で面白いものがもうひとつあります。補償(compensation)ベースのデプロイ機構です。デプロイに失敗した場合,ノードを実行前の状態にロールバックする必要があります。Java EE では通常,デプロイするユニットが独立したアーカイブですので,この問題の解決はさほど難しいことではありません。しかし SCA では,アプリケーションのサービスが他のアプリケーションのサービスと結合されている場合があるため,ランタイムの一貫性を維持するのがとても難しくなります。例えば,アプリケーションのデプロイが失敗した場合には,動的ワイアリングなど,他アプリケーションのサービスに対する変更もすべて取り消さなければなりません。このような変更の取り消しに対して,Fabric3 では memento パターンに基づく補償的アプローチを採用してます。その結果として,ランタイムの一貫性が常に保たれるのです。

InfoQ: ロードバランシングやフェールオーバに対しては,どのようなアプローチを取っているのでしょうか。

JM: Fabric3 のロードバランシングはトランスポート層で処理されています。WebサービスやPOX(Plain Old XML) のレベルでは,F3 は HTTP ロードバランサに依存しているのです。またメッセージングに関しては,JMS などのメッセージングプロバイダを利用しています。

ステートレスなサービスのフェイルオーバは単純です。Fabric3 がそれをクラスタリングしますので,高度な処理は何も必要ありません。私たちが現在取り組んでいるもののひとつに,クラスタ化されたシングルトンサービスのサポートがあります。アノテーションとカスタム SCA スコープを使用して,クラスタ化されたシングルトンを参照可能にすることが目標です。

対話サービス (Conversational services) の方が間違いなく複雑です。私たちが使用している BPEL の実装では,リプリケート状態を管理するのにデータベースを使用しています。Java ベースの対話サービス用のフェールオーバはまだ実装できていませんが,いずれは対応するつもりです。

InfoQ: Fabric3 ではどのようなバージョン管理がサポートされていますか。

JM: Fabric3 は SCA のインポート/エクスポート機構を利用して生成物のバージョン管理を行います。この機構の一部は OSGi がベースになっています。Java コードに関しては,OSGi のバージョン区分のサポートが SCA にあります。WSDL や XSD など XML ベースの出力には,SCA ではネームスペースのインポートとエクスポートにアーカイブ (コントリビューション/contribution と呼びます) が使用可能です。コントリビューションがネームスペースをインポートするときには,同じネームスペースをエクスポートする別のコントリビューションが存在します。エクスポートされたコントリビューションのネームスペースの内容が,インポートする側のコントリビューションで利用できるのです。XML コードをバージョニングする場合は,バージョンをネームスペース定義内でエンコードしなければなりません。このように,SCA のインポート/エクスポート機構は,OSGi のインポート/エクスポート機能の上位セットになっているのです。

サービスのバージョン管理に関しては,Fabric3 では,サービスを複数のエンドポイントにデプロイすることが可能です。また,ESB(Enterprise Service Bus) メディエーション形式を導入することもできます。これは単一のエンドポイントが,サービスの複数のバージョンに対するプロキシとなるものです。このアプローチに関する取り組みはまだ日が浅いのですが,F3 のアーキテクチャではすでにサポートされています。

InfoQ: Fabric3 ではどのようなツールを提供しているのでしょうか。

JM: 直接的にはありません。しかし Eclipse STP プロジェクトのモデラが現在,Fabric3 拡張シンタックスをサポートしています。ポリシー定義に関連しても,彼らと緊密な関係を持って作業する予定です。

IntelliJ に SCA XML アセンブリ用の優れたリファクタ機能が実装されていることも紹介しておきましょう。クラス名やパッケージを変更した場合に,自動的に XML をリネームするようなことが可能です。ただしこれは " 結果的に利用可能" といった機能であって,JetBrains が SCA との統合を念頭においていたかどうかは分かりません。おそらくはエレガントで汎用性を持った IDE 設計のなせる業なのでしょう。

InfoQ: Fabric3 を経験してみたいと考えている読者に対して,アドバイスをお願いします。

JM: まずは私たちのサンプルと,ユーザリスト へポストすることから始めてみてください。私たちの目標は,Fabric3 を使用するための,有用で親しみやすい雰囲気を作り出すことなのです。

この記事に星をつける

おすすめ度
スタイル

BT