WebSphere Application Server Feature Pack for SCAの理解を深める: Part 1: Service Component Architecture feature packの概要

オープンなService Component Architecture(SCA)の概念とテクノロジーの目的、およびIBM ® WebSphere ® Application Server V7 ユーザーに大きな価値をもたらす、キーとなるインテグレーションのポイントについてご説明します。

Chao M Beck, Software Engineer, IBM

Chao Beck は、Feature Pack for Service Component Architecture(SCA)早期プログラムのテクニカル・リーダーです。彼女はIBM WebSphere Application Server製品群の早期プログラムの実行責任を持つApplication Integration Middleware早期プログラム・チームに長らく携わっています。新製品機能の教育開発と実施、および出荷前(早期)プログラムと出荷後(カスタマー促進)プログラムにおいてお客様サポートを担当しています。



Stephen Kinder, Senior Technical Staff Member, IBM

Stephen Kinder は、シニア・テクニカル・スタッフメンバーで、WebSphere Application ServerのService Component Architectureデリバリーのためのリード・アーキテクトです。彼はIBMに20年勤め、WebSphere製品群に10年間携わっています。



2008年 12月 18日

はじめに

IBMはサービス指向アーキテクチャー(SOA)の価値について長らく述べてきました。SOAを現実のものとする重要な原則の一つとして、(ビジネス・サービスによって構成されている)ビジネス・プロセスは モデル化(model) され、様々な既存・新規サービスから 組み立てられる(assemble) サービスに分けられ、ランタイム実行環境に デプロイ(deploy) され、ITの観点からだけでなく、ビジネス・パフォーマンスの観点からも 管理(manage) されるということがあります。

図1はSOAライフサイクルを表しています。ビジネスに対する外的圧力と、進行中のプロセスを観察しながら施す内的な改良により、プロセスが変化するのに合わせて、このサイクルは繰り返されます。ビジネスとITが支え合いながら共にエンタープライズSOAを構築することにより、ビジネス上の顕著な問題を解決することができるアジャイルなビジネス・アプリケーションが提供されるのです。

図1.SOAライフサイクル
図1.SOAライフサイクル

多くの企業では、SOAに存在する粗い粒度のビジネス・サービス・カタログは、実際にはCOBOL CICS ® アプリケーション、 WebSphere Application Server J2EE ™ アプリケーション、 SAP、 .NET ® などのような無数のテクノロジーから成り立っています。事実、小規模ビジネスにおいてすら、“ビジネス・カタログ”は第三者によるサービスを含み、Webによってユビキタス化しているのです。

アジャイルなSOAにおいて、企業はビジネス・アプリケーションの進化にともない、これらのサービスをお互いに接続し組み立てる必要があります。しかしこれまでのビジネス・プログラマーが対処できるテクノロジーの数には限界があります。企業は、どこに配置されていようとも重要なビジネス・アセットを取り込み、新しいビジネス・サービスに組み込むためのより良い方法を必要としています。またビジネス・プログラマーが対処しなければならないテクノロジーの数も減らす必要があります。

企業はサービスを利用するために必要となる知識が少なくて済む方法を、開発者はサービス実装の詳細を知らなくても粒度の粗いサービスを組み立てられる方法を探しています。Service Component Architecture(SCA)はこのような機能を提供するためにデザインされました。SCAは開発者からサービス接続の詳細を抽出し、関係するサービスのデザイン(インターフェースやセマンティック・コントラクトなど)を、どのベンダーにも理解できるオープンでポータブルなメタデータ形式で記述し、全アプリケーションに今後起こりうるインフラの変化からビジネス・ロジックを分離します。

利用可能なメタデータ形式で表されたアプリケーションからこれらの詳細情報を取り除くことにより、いくつか興味深いことが起こります:

  • サービスのインターフェースやセマンティックスはSOAにおける最前面に置かれます:ここで、アプリケーションは自身がどのようなサービスを提供しているか、どのようなサービスを参照するか、どのセマンティックスを使用するのか、自身の実装テクノロジーによって縛られることのない方法にて宣言します(また他の実装の詳細に縛られることもありません)。
  • ビジネス・ロジックはサービス・コンポジションの変化から切り離され、サービスとコンシュマー間の経路は分離されます。
  • サーキット・ボード・パラダイムを使用してサービスの関係を見ることができ、サービスのデザインを非常に直感的に理解することができます。

SCAの歴史概要

SCAは新しい話ではないと知って驚くかもしれませんが、IBM WebSphere Process ServerがSCAのパイオニアであり、バージョン6のリリースがオープン版SCAの先駆けとなったのです。IBMが使用したこの先駆的テクノロジーを弊社ではクラシックSCAと呼んでいますが、これが元になって、複数ベンダーからなる Open Service Oriented Architecture (OSOA)組織に認定されたオープンSCA仕様が生まれました。SCAはIBM SOA Foundationのプログラミング・モデルの代表であり、IBMのアプリケーション・サーバーとビジネス・プロセス・マネジメント・ソフトウェアのポートフォリオとなる戦略的テクノロジーです。

OSOA組織は、SOAを使用してアプリケーションやシステムを構築するための言語中立モデルを記述した仕様のコアセットを定義するために設立されました。

また、OSOAはプログラミング言語に固有となる仕様についても定義しており、Java ™ 、BPEL、C++や、EJB ™ コンポーネントのようなJava EEテクノロジーといった、サービスを実装するための他のアプローチについても拡張・補完しています。SCAは他にもWebサービスのようなオープン・スタンダードにも基づいています。

SCAは他の細かな粒度のサービス実装言語やフレームワークの競合になるものではなく、むしろ補完的で包括的なテクノロジーといえます。

仕様策定と平行して、この仕様の実装を開発しているオープン・ソース・コミュニティがいくつか出てきています。WebSphere Application Server V7.0はSCAランタイムのコアを提供するために、オープン・ソースApacheプロジェクト Tuscany を採用し、WebSphere Application Serverが元々持っているワールドクラスのエンタープライズ・アプリケーション・サーバー機能と統合しています。

2007年後半、OSOAのベンダーは、これらの仕様、知識と情熱をOASISに持ち込みました。そこでの正式な標準化プロセスと、一般に利用可能なコンプライアンス・テスト・スイートの作成により、SCAは更に向上しました。この標準化への取り組みは2009年に完了する予定です。


SCAテクノロジー概観

SCAコンポジット

名前からも分かるように、Service Component Architectureはコンポーネント・モデルです。サービス指向の粗い粒度のビルディング・ブロックが コンポーネント(component) として表されています。コンポーネントは提供する サービス(service) 、依存するサービスや リファレンス(reference) を示しています。また、コンポーネントはサービスの 実装(implementation) を提供するコードも指し示しています。コンポーネントは ワイヤー(wire) を通じて接続されています。コンポーネントは構成可能な プロパティー(property) を公開することで動作を調整することが可能です。ポリシーとサービス品質のインテントはサービスやリファレンス( 相互アクション・インテント )とコンポーネント( 実装インテント )を定義するためにあり、SCAランタイムによって提供される付加的なセマンティックスを構成することができます。

図2.SCAコンポジット
図2.SCAコンポジット

コンポーネントの集合はきちんと組み立てられることで コンポジット(composite) になります。コンポジットはコンポーネントとワイヤーのセットで、サービスの集合体(アセンブリー)です。コンポジットはコンポーネントに対してローカルの境界を定義するスコーピング・メカニズム(有効範囲の指定機能)を提供しており、更には、コンポーネントが提供するサービスを、他のSOAアプリケーションに対して隠すこともできます。コンポジットは一度定義されると再利用ができるようになり、ネスト形式で他のコンポーネントのための実装を提供します。コンポーネント、アセンブリー、内部ワイヤー、サービスやリファレンス定義はService Component Definition Language(SCDL)と呼ばれるオープンなXML言語で記述されます。サービスとリファレンスは バインディング(binding) を使用することにより特定のプロトコル(Webサービスなど)に結合されます。バインディングはSCDL定義の一部なので、ビジネス・ロジック(実装部分)がこの詳細情報により影響を受けることはありません。

注意事項として、SCAは様々なアプリケーション環境で実現可能な言語中立の仕様を網羅するものであるということがあります。各アプリケーション環境は実装セット、バインディングと、その環境に適合したポリシー特性を提供しています。例えば、WebSphere Application Server Feature Pack for Service Component Architecture V1.0では、Javaや他のSCAコンポジットによって実装されたコンポーネントをサポートしていますが、厳密にはCおよびC++言語によって実装されたコンポーネントのデプロイをサポートしていません。

SCAコントリビューション

コンポジットが定義されると、次に、関連するコンポーネント実装の成果物と共にランタイムにデプロイする必要があります。SCAコントリビューションとは、このような全ての成果物を包含するパッケージのことを指します。 コントリビューション ・ドキュメント(sca-contribution.xml)と呼ばれる特別なXMLドキュメントは、コンポジットがどのようにデプロイされるかを表しており、またコントリビューションが実行する成果物(共有XMLスキーマやJavaユーティリティー・クラスなど)を含む依存性(つまり他のコントリビューション)についても定義します。

図3.SCAコントリビューション
図3.SCAコントリビューション

コントリビューションはSCA ドメイン にデプロイされます。SCAドメインとは管理スコーピング・メカニズムのことですが、SCAランタイムによって使用されるサービス・カタログも提供し、SCAコンポーネントのワイヤリングを簡潔化しています。SCAドメインにデプロイされたサービスは、SCA デフォルト・バインディング を通して使用することができ、他のバインディングのケースと同じように、リファレンス・ターゲットはエンドポイント構成の詳細を指定することなく、論理的なドメイン内で有効な名前によって特定することができます。そして、SCAランタイムに従ってサービスへの最適なパスを探すことができるようになります。Feature Pack for SCAのために、SCAドメインとセルは同じスコープを持ち、SCAドメインにデプロイされたサービスは、デフォルト・バインディングを通してWebSphereセル内のどこからでも使用することができます。


SCA Javaプログラミング・モデル

SCAはJava EE 5のアノテーションが提供する開発生産性の向上と、制御の反転(inversion of control)や依存性注入をサポートする最新のコンテナー・デザインを採用しています。SCA Java実装には、アノテーションを使用してコンポーネント定義の宣言ができるという利点があり、SCAコンテナーによってSCAサービス・リファレンス、ポリシーやプロパティーがコードに注入されます。このパターンを使用する実装はコンテナーやフレームワークAPIの詳細から分離されるだけでなく、エンドポイント構成からも分離されることになります。SCAアーキテクチャーでは、アプリケーション・アセンブラーがメタデータと共にコードに記述されたアノテーションをオーバーライドすることができます。これにより開発作業はシンプルになり、また、エンタープライズ・デプロイにおいてサービス・ポリシーと構成に関する厳格なコントロールが可能となります。


なぜSCAか

SCAプログラミング・モデルの主なユースケースは、ビジネス機能を疎結合のサービスに抽象化する機能が中心になります。これらのサービスは、粗い粒度のコンポーネント、細かな粒度のコンポーネント、そして粗い粒度のコンポジションから実装されています。SCAは、リファレンスによるコンポジション、および、実装によるコンポジションという2つの軸を元にコンポジションを提供しています。SCAコンポーネントは、サービスがどこでどのようにデプロイされるかに依存しないシングル呼び出しのプログラミング・モデルを通して、これらのサービスの呼び出しパターンを構成することでサービスを組み立てることができます。またSCAは、粗い粒度のコンポーネントの実装と同様に、より細かい粒度のコンポーネントを組み合わせる実装を行うことで、コンポジションを提供することもできます。細かな粒度のコンポーネントは実装によるコンポジションの葉に存在し、粗い粒度のコンポーネントは根に存在するといった形になります。

表1は 細かな、または粗い粒度のコンポーネント・モデル の使用の観点から、様々なコンポーネント・テクノロジーを一般的に分類したものです。この表は、粒度に最も影響を与える要素にフォーカスしています。つまり抽象化、データ・フォーマット、伝送プロトコルからの独立性、相互アクション・パターン、メディエーションといった項目です。

表1.コンポーネント・モデル比較
コンポーネント・モデル細かな粒度(Fine-grained)粗い粒度(Coarse-grained)
POJO
  • 強いローカル色
  • 限定された抽象化
  • 限定されたコンポジション
  • オブジェクト・グラフ・データ
  • Getter/Setter・パターンが一般的
  • リモーティングなし
  • メディエーションなし
EJB 3
  • 強いローカル色だが、アノテーションは不整合
  • 限定された抽象化
  • オブジェクト・グラフ・データ
  • 限定された伝送の独立性
  • ドキュメント型のデータは受け渡し可能
  • 宣言的QoS
  • メディエーションなし
Spring
  • EJB 3と同様
  • リモーティングなし
  • ドキュメント型のデータは受け渡し可能
EJB2.0&以降のステートレス・セッションBean
  • ローカル色は最適化されていない、ローカル/リモート透過性
  • 限定された抽象化
  • オブジェクト・グラフ・データ
  • 限定された伝送の独立性
  • メディエーションは困難
  • 非同期呼び出しなし
SCA
  • Java仕様はローカル色が強い
  • ローカルのオブジェクト・グラフ・データ
  • 非同期あり
  • 優れた抽象化と、言語からの独立性
  • 優れた伝送
  • 非同期あり
  • ドキュメント型でリモート呼び出し可能
  • メディエーション可能なアセンブリー仕様
Java API for XML Web services (JAX-WS)
  • ローカル色なし
  • 限定された抽象化
  • 限定された伝送の非依存性
  • 非同期あり
  • ドキュメント型
  • メディエーション可能

WebSphere Application Serverへの価値

IBM WebSphere Application Serverは、SCAコンテナーの基盤として、Apacheのオープンソースを採用しています。Tuscanyは、実装や、データとプロトコルのバインディングといった、SCAアーキテクチャーにおける様々な機能をプラグインするメカニズムを提供しています。WebSphere Application Server製品ドキュメントで特に明記していないかぎり、Tuscany独自の機能はサポートされていません。

SCAコントリビューションのデプロイはWebSphere Application Serverのアプリケーション管理に統合されています。これはV7の新機能であるビジネス・レベル・アプリケーションのサポートを活用しており、これによりSCAコントリビューションはJava EEパッケージングの必要なくデプロイが可能になります。このコントリビューションにデプロイされたサービスはWebSphere Application Serverのセル・レベルのSCAドメインに追加され、セル内のほかのSCAアプリケーションからSCAデフォルト・バインディングが使用できるようになります。これにより、SCAコンポーネントのワイヤリングが簡潔になります。

SCAコントリビューションに対するサービス品質インテントとポリシーはWebSphere Application Serverのセキュリティー、トランザクションおよびWebサービス・ポリシーセット管理とともに統合されており、SCAアプリケーションにエンタープライズ・クラスのサービス品質をもたらします。

WebSphere Application ServerにデプロイされたSCAサービスは、Network DeploymentのHA構成においても使用可能で、これによりWebSphere のアプリケーションに期待されるクラスタリング・テクノロジーをSCAコントリビューションにおいても活用することができます。

テクノロジーとしてのSCAは、ミドルウェア製品にとっての実現テクノロジーでもあり、柔軟なコンポーネントと、製品特有の機能に直接関連したアセンブリー・サポートを提供しています。例えば、WebSphere Application ServerはSCAを用いてSOAアプリケーションのためのサービスを組み立て、ビジネス・ロジックを構築するための堅牢でエンタープライズ・ワイドなソリューションを提供することに焦点を当てています。その一方で、例えばWebSphere Enterprise Service BusはSCAを使用してファースト・クラスのメディエーション・フレームワークを提供し、仮想的なサービス・エンドポイントを公開することにより、分散テクノロジーに接続するための柔軟性を提供します。たとえ複数の製品が共通のテクノロジーを使っていたとしても、どのようにツールを使うかによって、特定のSOAソリューションを開発するためにはどの製品が最適であるかを決定することができるでしょう。


まとめ

Feature Pack for SCAはWebSphere Application Server V7に簡素化されたSOAプログラミング体験をもたらしてくれます。この最初のデリバリーとなるSCAテクノロジーは、アジャイルで柔軟かつオープンなメタデータ・ドリブンのメカニズムを通じて、粗い粒度のサービスを組み立てるためのフレームワークを提供しています。このFeature Packは、

  • どのようにサービスを実装するかということと対比して、何のサービスであるかということに焦点を置いたSOAアプリケーションを組み立てるために、 サービス指向 の、サーキット・ボード・アセンブリー・パラダイムを提供しています。
  • 利用するサービスの詳細や、サービスを利用するための経路を分離することで、SOAビジネス・ロジック開発者に、適切な「 関心の分離 」( separation of concern )を提供します。
  • WebサービスとEJBコンポーネントを通じて既存の資産への接続性を提供することによって、 既存サービスを包括 することができます。
  • 依存性注入や、ワイヤリングを簡潔にする簡単なSCAバインディングを通して、 粗い粒度のサービス作成を簡単 にします。
  • 実装に関する特定の知識や配置されている環境に関する知識がなくても 粗い粒度のサービスを再利用 できます。

この記事は新規・既存のテクノロジーを様々な観点から掘り下げるシリーズの第一回目です。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=371485
ArticleTitle=WebSphere Application Server Feature Pack for SCAの理解を深める: Part 1: Service Component Architecture feature packの概要
publish-date=12182008