非常に多くのブロガーたちが、サービスコンポーネントアーキテクチャ(SCA)の標準化の取り組みについて、あれこれと思いを巡らしています。
SCAの選ばれた仕様により、SCAの世界の中で道に迷うことは容易です。何故なら、コミュニティでSCAを使用した経験がほとんどないので、詳細な仕様に関する多くの部分が未だ調査中であるか、まださわったことさえない状態だからです。
まず初めに、読者はSCAがJavaの世界での(新たな)革命であると考えるような、簡単なミスリードをおかしてしまうかもしれません。しかし、これは2 つの点で間違いがあります。まず、Javaに由来するものの場合、関心の大部分がJavaに集中してしまいますが、SCAはJavaの世界だけではありません。C++、COBOL、PHP、BPELに対する仕様もあります。私たちが注目したいことは、そもそもSCAが(Java EEやOSGIのように)既存の環境を置き換えるというものではなく、アプリケーションがそれぞれの環境の中の異なるプログラミングモデルの間で、境界を越えて協調できる基盤を作るためのものです。如何にしてSCAが既存の技術と統合するかに関する詳細については、公開されているSCAの仕様の一覧からは欠けている部分です。これらの環境の全てのレイヤーにおける詳細を理解するために、すべきことはまだ沢山あります。
技術の統合は困難です。興味深い技術が、その使用において制限されるべきではありません。そして、SCAは、結局のところ様々な技術の統合であると言えます。
SCAには将来性があるように思います。とても興味深いプロトタイプが、一般のカンファレンスを含めた様々な場所で公開されています。
- Oracleデベロッパーは、独自のメディエーションコンポーネント、ワークフローコンポーネント、イベントエージェントなどを利用した、BPELプロセスのコンポジションを実演しました。(こちら(PDF・英語)を参照)
- SAPデベロッパーは、JavaEEアプリケーションパッケージと、JavaEEアプリケーションによるドメインレベルのアセンブリによるBPELプロセスを利用した、JavaEEコンポーネントのコンポジションを実演しました。(JavaOne 2007のセッションはこちら(source)を参照)
- ApacheのTuscany project (サイト・英語)では、スクリプト言語コンポーネントとJavaコンポーネントの組み合わせで、コンポジションを実行することができます。
- Fabric3(サイト・英語) のSCA実装は、分散されたランタイム環境と様々なプログラム技術によって実装されたサービスネットワークをアセンブリする方法を提示しています。
私たちがこれらの例から学ぶことができるものをまとめてみることにしましょう。
SCAはコンポーネントと接続を抽象化したプログラミングモデルの提供に関するフレームワークを強化しています。そのようなフレームワークが標準で提供されていますが、SAPシステムのリモートファンクションコール(RFC)、独自のメディエーションやスクリプティングコンポーネント、SQLストアドプロシージャなどのような独自の技術のようにも見えます。SCAは、多くのメリットを実現するためのフレームワークとして統合されたアセンブリ言語を定義しています。以下では、様々なメリットについて詳しく説明していきたいと思います。ここで言いたいことは次のとおりです。
- SCAは既存技術との結合をサポートしています。これが、おそらく主要な利用ケースとなると思います。
- SCAの基本となる価値は、様々な技術のプログラミングモデルの統合、分散されたデプロイメントやアセンブリのための基盤が提供されているところにあります。
- SCAは、実装者が一貫性のあるしっかりとした方法で、独自技術を提供することができます。それは、開発者とベンダーの両方にとって良いことです。
既存の環境との統合
どちらかと言えば、SCAは既存技術を統合したものです。それは、SCAを設計する際になんらかの仕様を再利用しているというわけではありません。それとは全く異なるものです。仕様は、SCAモデルを利用した統合の方法に関して深く記述されていると言えるでしょう。osoa.orgのSCAのホワイトペーパー(source) や、(上記で挙げた)プロトタイプの結果を参照すればそれが分かります。その考えは、どこで特定のテクノロジーが良いとしても、SCAの利用をスケールアウトすることで、その価値を高めることさえ可能であるというのものです。既存のテクノロジーの統合は、異なる方法によりいくつかの層でおこなわれるかもしれません。スクリプト言語に関して言えば、実装の型定義をすることが自然な選択です。メッセージング、リモートプロトコル、バインディングといったサービス呼び出し技術は、統合の手法といえます。デプロイメントモデルを提供する JavaEEやコンポーネントモデルなどのランタイム環境に関しては、統合は複数のレイヤーで発生するかもしれません。
与えられた環境によるSCAアセンブリの統合は、すべてのランタイムを一つの「より高度な」共通ランタイムモデルにラップしようとする抽象概念によって、悪いモデルの影響を低減します。
例えば、時間があるなら、WSDLのインターフェースと一般的なXML形式のWS-*の機能をもつランタイムでのサービス呼び出しの実装によって、全てのサービスを抽象化するということはよい考えのように思います。高い場所から見るとそれは良い考えのように思いますが、サービスデベロッパーやサービスコンシューマの視点からはずっと興味の少ないものに思われます。: あなたがどの立場であっても、ネーミング、トランザクションのハンドリング、セキュリティを含んだ異なる技術から技術への変換により、統合されていないことのインピーダンスミスマッチの重荷を被ることになります。
その一方で、SCAの統合により本来のアーティファクトの解釈を提供しようとしており、以前利用していたものを使用しないのであれば、すぐにアセンブリ定義を参照し修正される必要があります。
技術が交差するプログラミングモデルの統合
SCAは、インプリメンテーションタイプの抽象的な概念を導入しています。インプリメンテーションタイプは、SCAアセンブリの側面からコンポーネントの形を説明しています。言い換えると、コンポーネントがどのようなサービスのエンドポイントを提供しているのか、それが何を参照しているのか、そして、与えられたコンポーネントに対しどんなコンフィギュレーションプロパティが設定できるのかということです。そういった意味で、インプリメンテーションタイプは、コンポーネント実装の技術から独立した表現を与えているのです。
それはSFのようにも聞こえますが、既に聞いていることです。しかし、SCAはそれ自身の言語でコンポーネントとそのインタラクションのすべての側面を捕えようとしません。たとえば、SCAはそれ自身でインターフェース記述言語を定義しておらず、それらをJavaや WSDLに委ねています。他のインターフェース言語は、必要に応じて開発者によってサポートされるかもしれません。同じ考えに基づいて、SCAがポリシーフレームワークを定める間は、適用できるところにおいてWS-Policyの定義を再利用します。
インプリメンテーションタイプが既にあるなら、例えばそれがfooだとして、foo型のコンポーネントを結合する方法の定義としてSCAアセンブリを指定することができます。それは、BPELプロセス、JavaのPOJO、EJBのセッションビーンといったいずれの環境を選んだとしてもサポートされるでしょう。
ベンダーからすると、実施を提供したり、ユーザに対し技術を教えるための限界費用を下げる側面があります。それはユーザにとっても、SCAが実装とそれに結びつく技術の利用により、限界費用を下げることを意味します。
Java EEのケースにおいて、私たちは実際にSAPで研究をしました。私たちはSCAランタイムとBPELエンジンをJava EE 5環境（SAP Netweaver）と統合して、Java EEコンポーネントとライフサイクルモデルによるBPELのシームレスなインテグレーションをおこないました。結果、何が得られたのかを見てみます。私たちが十分なアプリケーションローカルのアセンブリメタデータをもっているので、ローカルのBPELとJava(逆もしかり)の呼び出しは、(参照渡しでは無いにも関わらず)実際にローカルでおこないました。具体的に言うと、BPELプロセスがSCAのワイヤーを通してセッションビーンを呼び出し、同一トランザクション内でローカルにあるべきインターフェースとして公開しているWebサービスにより隠蔽した情報を外に出すことなく、Java Persistence API (JPA)を使用して永続化データの更新をおこないます。この場合、SCAのワイヤーは、BPELで実装されたコンポーネント側にWSDLインターフェースによって定義された一端をもっていて、セッションビーンのビジネスインターフェースであるJavaインターフェースによってもう一端が定義されています。
もう一つの側からそれをとると、BPELのようなオーケストレーション言語のサポートを提供すると、できるだけシームレスに既存資産を再利用できるようにする必要があります。SCAはそれをローカルで使用が可能となるように支援します(通常、この場所で)。
Java で類似した統合をC++コードに期待することが合理的でない(しかし、...誰が知っているのか)間は、BPELがあり同一ライン上で統合することが可能であるエンタープライズサービスバス(ESB)やエンタープライズアプリケーションインテグレーション(EAI)からの多くのプログラミングモデルがあります。
分散されたデプロイメントとアセンブリ
SCAは特定のデプロイメントフォーマットを記述しないので、デプロイメントに関しては少しだけ定義することがあります。具体的には、「SCAドメインへのコントリビューション」の考えを決めます。これは、SCAの別の重要なコンセプトです。
私たちは、コントリビューションに関して議論することができ（デプロイ可能性について考えます）、単一のコントリビューションを超え、アセンブリに関して話すことができます。そして、それは正にSCAでのドメインレベルのアセンブリです。ドメインはコントリビューションからのコンポジット群を含んだコンポジットとして視覚化されます。つまり、ローカルで作った同じアセンブリ言語を使用し、コントリビューションを超えたアセンブリリレーションシップを表現することができるのです。
ドメインの概念によって可能となった分散したアセンブリは、プログラミングレベルの様々な技術統合に論理的に対応するものです。実際は、ビジネスアプリケーションはアプリケーションパッケージ全体で統合され、しばしばプログラミングレベルの統合が妥当ではない非常に異なった技術において、システム全体にわたり統合されなければなりません。
幸いにも、ドメインは一つ以上のシステムで複数のシステムに相互接続するかもしれません。そういう意味では、ドメインレベルのアセンブリは、システムからシステムへの物理的なエンドポイントの設定からドメイン構成を成す定義へ移る、接続の抽象化を提供します。
それはドメイン内のエンドポイントアドレスの抽象化というだけではありません。それに加えて、アセンブリ情報は、実際に使用するトランスポートプロトコルが何であるかを指定することもなく、ドメインの不均一性に従い、ドメイン管理者またはランタイム実行でさえその決定を委ねるかもしれません。
エンタープライズサービスバス(ESB)の観点からすると、今日の話の傾向は、「ESBの機能からESBの優位性へ」ということを言っています。それは、プログラミングモデルの統合(上記参照)により、私たちがビジネスアプリケーションのロジックを自由にミックスした状態で機能的な統合を実現することができるということです。ドメインにより、サービスバス上でプログラミングをするといったESBの接続形態の詳細を抽象化します。
独自の技術とSCA
重要な議論は既におこないました。プロバイダとユーザに対し、新しいプログラミングモデルによる限界費用を低下するということ。それは簡単なwin-winの状況と言えます。
ベンダーは、昔から、開発者とツールを利用できるようにすることを含んだ多くの労力を伴うので、新しいプログラミングモデルを導入するのをためらいます。新しいデプロイメントモデル、管理ツール、ツールスイートがBPELのような新しいプログラミング言語を導入するために出されることはよくあることです。しかし、それは理にかなっているでしょうか？
同様にして、開発者の暮らしを楽にすることを支援するのに最も必要なものより、学習の必要性に直面していることに満足しなければならないのでしょうか？
独自の技術について言えば、ベンダーは、より速く、より少ない労力で新しい、もしくは独自の技術の利用を提供するためにSCAを使うことができると言えます。ユーザは、ドメイン固有の技術の導入に対する壁をより低いものにしなければならないでしょう。
要約
この記事から得られることは、まず第一に、SCAがあなたの大好きな技術を置き換えたり、革命を起こす試みではないということです。それは、必要に応じて利用可能なアセンブリの抽象概念を持つものです。SOAに関して言うと、SOAが接続の詳細を抽象化し、様々なトランスポートプロトコルや、統合とアプリケーション開発のプログラミングモデルを巧みに操ることができるものであると言うならば、SCAはSOA開発を単純化するものだと言えます。
現在OASISでは、Open Composite Services Architecture（OpenCSA）と呼ばれるところで、SCAの公開での開発が続けられるでしょう。このあとも是非楽しんでください！
参考:
- InfoQでのSCAの議論はこちら: http://www.infoq.com/jp/news/2007/10/sca-debate
- InfoQでのSCAのインタビューはこちら: http://www.infoq.com/jp/articles/sca-opencsa-interview
- OSOA.orgのSCAホームページはこちら(英語): http://www.osoa.org/display/Main/Service+Component+Architecture+Home
- OASISのSCA(英語): OpenCSA http://www.oasis-opencsa.org/
- SCA 1.0 の仕様(英語): http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
- JavaOne 2007でのセッション「SCA meets Java EE presentation」(英語): http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-41500&yr=2007&track=3
- SCA OASIS のチュートリアル(part 1)(英語): http://www.osoa.org/download/attachments/250/SCA_OASIS_Tutorial_part1.pdf
- Fabric3(英語): http://fabric3.codehaus.org/
- Apache Tuscany(英語): http://incubator.apache.org/tuscany/
- Open CSA 全プログラム(英語): http://www.oasis-opencsa.org/node/51
- コンポーネントスクエア オープンSOAセミナー ～SOA時代の最新技術をご紹介～: http://www.c-sq.com/modules/article/article124.html
（このArticleは2007年10月18日に原文が掲載されました）