SCAが2005年に一般の目にふれるようになってから(source)、多くの人たちがSCAに関する話を聞いてきました。多くのアナリストたちがSCAが良いものであると言っていましたが(source)、全ての意見が良いわけではありませんでした(source)。特に、仕様が閉じられた世界で開発され、標準化の道から離れてゆくように(source)思われたという事実があります。しかしながら、SCAがOASISに提出され(source)、OpenCSAグループが発足し(source)、複数の技術議会がSCAの異なる部分を標準化し始めた2007年に変化がおきました。9月には、OpenCSA の総会と平行して、始めての対面での会議がこれらの議会で開かれました。InfoQでは、SCA/OpenCSAのワーキンググループに属しているメンバーたちと時間をとり、いくつかの質問をしました。
今回のインタビューでは、Mike Edwards氏 (IBM)、Steve Jones氏 (CapGemini)、David Burke氏 (TIBCO)、Sanjay Patil氏 (SAP)、Michael Rowley氏 (BEA)と話をしました。
Michael Rowley氏は、最高技術責任者としてBEAで標準化の作業をしています。彼は、現在、オープンコンポジットサービスアーキテクチャ(OpenCSA)メンバーセクションのOASIS運営委員会で選ばれた7名の一人であり、SCAとSDOの標準化を統括しています。彼は、SCA-J TC(SCAのJava仕様)の共同議長であり、SCAアセンブリとSCA BPELの仕様作成者の一人でもあります。
Steve Jones氏(ブログ・英語)は、現在、CapgeminiのグローバルなアウトソーシングビジネスにおけるSOAとSaaSのリーダーを務めており、最近になってGoogleとのパートナーシップを結んだグローバルなプロダクトディレクターでした。さらに、彼は、初期のJAX-RPCグループ、JBI(1と2)、JavaSE 6などを含む、いくつかのJCPのメンバーでもあり、JCP会員のCapgeminiのエグゼクティブスポンサーです。Steve氏は、Open CSAグループにも所属しています。また、InfoQの書籍「Enterprise SOA Adoption Strategies」(ミニブック・英語)の著者でもあります。
Sanjay Patil氏は、パロアルトにあるSAP Labsのアーキテクトであり、OASIS、WS-I、JCPを含む多くの標準化団体の積極的なメンバーでもあります。彼は、現在、OASIS Webサービス信頼交換(WS-RX)技術委員会とOASISサービスコンポーネントアーキテクチャのBPEL技術委員会の共同議長を務めています。彼の興味分野は、Webサービス、SOA、コンポジット技術、JavaEEなどです。
David Burke氏は、TIBCOソフトウェアのプロダクトマネージャであり、OASIS OpenCSAの運営委員会の作業をし、SOA仕様のSCAとSDO関連を牽引しています。
Mike Edwards氏は、イギリスにあるIBMハースリー研究所でサービスコンポーネントアーキテクチャにおける戦略責任者であり、現在は、OASIS SCA Assembly TCの共同議長でもあります。Mike氏は、25年間にわたりソフトウェア開発に携わり、OS/2プレゼンテーションマネージャー、コンピュータ電話統合のコールパス、Java、Webサービスなどで功績があります。
InfoQ: 何故、SCAの標準化団体が作られれるまでに、これほど時間がかかったのでしょうか？
Mike Edwards氏 (以下、ME): 私は、標準化団体ができるまでに時間がかかったと思っていません。SCAは、 SOAの分野における問題を解決し、チャンスをつかむためにスクラッチから始めました。それは、協力してくれた人たちの手によって発展し、仕様の作成を含むだけでなく仕様をチェックするために平行で実装するということも行いました。そして、有益なフィードバックを得ることができました。仕様が成熟し、それに対する確信を得ることができたので、仕様は非常にしっかりとしたもので、標準化へ前進したことは意味のあることでした。期は熟したと言えます。
Steve Jones氏 (以下、SJ): 私は、それが本当にその長い時間であると考えていません。私はJBIの始まりを記憶していますが、JBI 2.0がJCPで開始されたのとSCAとSDOが開始されたのは同じくらいの時間でした。そして、今、SCAがあることを考えると、それほど長い期間ではないように思います。実際には、OASISに提出される前にBPEL 1.1があったように、SCA 1.0も存在します。
David Burke氏 (以下、DB): 実際、私たちの観点からすると、SCAが標準化団体に提出されたことはまさにタイムリーなことでした。業界で見比べてみると、SOAはかなり最近のものであり、SCAの標準化は非常に早いと言えます。例えば、クエリー言語は1970年代に関心をもたれ、ANSI SQLとして始めて標準化されたのは1986年のことです。さらに興味深いこととして、SCAが相互に協調し競い合うことを始めてから標準化するまでになれたのは、業界全体が成熟してきているからではないかと私は思っています。
InfoQ: なぜW3Cではなく、OASISを選んだのですか？
SJ: OASISは、W3Cよりもビジネスと実装の標準であるからです。SCAはビジネスの標準であり、それに関する実装でもあるので、OASISの方がより理にかなっていると言えます。
ME: 全ての仕様を利用するために標準化団体を選択するということは、非常に難しいものです。しかしながら、SCAはワイヤープロトコルというよりはむしろプログラミングモデルを主としており、私たちは、OASISがその分野において素晴らしい実績を残していると感じています。例えば、WS-BPELの仕様がそうです。さらにOASISは、SCAが必要としている平行して作業する技術委員会のグループに適した仕組みを提供しています。
DB: 2つの組織の中で標準活動を見るとき、OASISはSCAにとってよりフィットします。OASISはWebサービスとビジネスレベルのインターオペラビリティにフォーカスを当てています。そして、それはSCAのゴールにとって十分に適したものです。
InfoQ: JCPに提案してSCA-Jの作業をしないのは何故ですか？
SJ: Capgemini ではそうしたいと思っています。将来のJ2EE仕様の一部としてSCAを含めることは、私たちと私たちのクライアントにとって意味のあることです。明らかに、ベンダー間に政治的な問題がありますが、全ての人が、SCAが成熟したものとなるように動き始めたということは素晴らしいことだと思います。
ME: 概して、SCAはJavaの仕様ではありません。それは、JavaやJavaでない多くの技術の橋渡しをするSOAの仕様です。SCAのJava仕様をその他のSCA仕様と分離することは意味のないことだと思います。そして、Javaグループとその他のグループを結びつけるのはより難しいと思います。 SCAの仕様を一つの中で有効にすれば、ライセンスを理解するのも容易となります。
DB: 多くの場合において、SCA-J ではJavaコードが実行する環境を記述しないようにしています。SCA-Jサービスが動作するための方法に関する問題は、JCPプロセスの一部として議論されるべきものなのかもしれません。SCA-Jでは代わりに、JavaサービスがJavaやそれ以外の言語で書かれた他のサービスによって利用する/利用されるための方法についてフォーカスしています。この作業の一部は、Javaが動く方法と、SCAが・・・そういった観点からすると、 SCA-JチームではJava開発者がSCAサービスを簡単に書けるようにすることが必要となります。しかしながら、作業の大半はJavaにおけるSCA アセンブリやポリシーといった問題の対応に費やされており、そういった点では、SCA-JチームはJavaの記法に依存しない言語について考えていることになり、それらの言語に依存しない記法については、今なお進化しています。よって、個々に分かれたものとしてJavaの仕様を管理するのは可能ですが、 JCPプロセスという単一組織の中でそれ以外の仕様と同等のものとして扱われることは、より意味のあることです。
InfoQ: あなたが2つの文でSCAがこの分野にもたらしたものをまとめるとすれば、それは何ですか？
SJ: 設計とデプロイメントが含められていること。複雑なアプリケーションを作成・パッケージングするための単一のアプローチ。
ME: コンポジットサービスアプリケーションを記述するための言語。サービスコンポーネントの構造への単純なアプローチ、ビジネス機能に集中してインフラの機能をしっかりと分離できる。
DB: 2つの単語で言うとすれば、「デベロッパーマインドシェア」でしょうか。もう少し詳しく言うと、SCAは開発者にコンポジットアプリケーションの開発のための標準化されたアプローチを提供します。
Michael Rowley氏 (MR): 私は、複数の言語や通信プロトコルから形成されるサービスベースのアプリケーションにおける作成、アセンブリ、デプロイの技術について述べたいと思います。私たちが最も重要としている設計の考え方は、技術をできるだけシンプルなものにすることです。それは、たとえ2つの競合するものがあったとしても、単純さのためにいくつかの機能を犠牲にするということを意味しています。
InfoQ: あなたの会社は、何故SCAに関心を持っているのですか？
DB: 次世代の製品であると考えており、SCAのキーコンセプトとしていくつか見え始めているものに対し、TIBCO内部で独自アプローチを始めていたことに気づきました。一度、それを実感すると、標準セットを開発するために他社の人と一緒に作業するという道を通るということが、私たちにとって非常に意味のあることだということが分かりました。明らかに、今なお私たちは、標準化におけるいくつかの点に関心を持っており、私たちの顧客にとって意味のあると思われる仕様の実装のために、自身の製品での対応をいくつか行っています。
MR: BEAは、この業界が純粋なJavaのサーバーサイドアプリケーションから、BPEL、データ統合技術、XPDL、ESBのパイプラインなどのような、様々な高いレベルの技術から作られるアプリケーションのモデルに変わってくると確信しています。さらには、APIやプログラミングによるものよりもXMLのような宣言的に指定するものを利用した技術によってもたらされるコンポジットサービスを、ユーザーが求めるようになると確信しています。SCAにより、複数の技術が混ざり合ったアプリケーションを同じ方法で作成・デプロイができるようになります。さらには、通信するためのトランスポート技術に制限されることなくサービスを実装することができるためのJavaプログラミングモデルを提供します。それが、SCAのアセンブリモデルにフィットしたものとなっている訳です。
ME: 私たちは、ビジネスアプリケーションを構築するために利用するSOAにおいて、SCAが重要な構築要素であると考えています。それは、SOAをより利用しやすいものとし、企業が自身のシステムを構築する上で考えているスキルの共通基盤をつくることができると考えています。
Sanjay Patil氏 (以下、SP): 次に加えたいと考えていることが、JavaEEやOSGiのような既存のランタイムやデプロイメントの統合に適したフレームワークをSCAが提供するということです。
SJ: 私たちは、クライアントのために非常に多くのシステムを構築し、サポートしてきました。SCAのベータ版を始めてリリースしたときにIBMと関連を持ち、今日ではそれをクライアントへ商用利用しています。それは、重要なアプローチであり、SOAを私たちのビジネスの視点から見たときに非常にフィットするものです。
InfoQ: SCAとJBIでオーバーラップするところはあると思いますか？
MR: 技術的には、共通部分がありません。JBIは、ランタイムを作成するためのインフラストラクチャとして利用することができます。そのランタイムは、SCA コンポジットを使用して書かれたアプリケーションのデプロイと実行を行うことが可能です。しかしながら、私の中では少し議論の余地が残っており、JBIが問題を解決する上でのベストな技術であるかどうかということについてはいくつか問題が残されています。JBIは、実行時にノーマライズドメッセージ上でルーティングとプロセスが決められたメッセージパラダイムをベースとしています。しかし、SCAは、デプロイ時に決められたルーティングとバインディングによる効果的なインフラストラクチャを利用することができます。よって、正規化せずにメッセージ通信をおこなうことができ、インフラストラクチャのオーバーヘッドは最小化します。これが私が良く知っている(Fabric3やTuscany)オープンソースのSCAランタイムがJBIをベースとしなかった理由の一つです。
ME: 一言で言えば、「NO」です。 SCAは、非常に広範な技術を利用したエンドユーザーアプリケーションを構築することを第一に考えられたものです。一方JBIは、Javaプラットフォーム上のヘテロジニアスなサービスアプリケーションのインフラを構築することを考慮したものです。SCAはJBIのランタイム上で利用することが可能です。しかし、JBIの無いSCAやSCAの無いJBIを使用することも可能です。
SJ: JBIはエンジンからエンジンというものであり、SCAはエンジンの中のコードをまとめるものです。両者が重複し始めることに対するリスクはあります。しかし、数年間メンバーと共にフィードバックを行ってきて、両者のグループが一緒に作業することは有益であると思います。
DB: SCAでは、設計のタイミングでサービス呼び出しの抽象的な概念を定義します。一方、JBIは実行時のサービス呼び出しのためのAPIを定義します。そのコンセプトは明らかに一直線に並んでおり、オーバーラップしているとしても、それは最小限のものです。
InfoQ: マイクロソフトが持っているSOA技術の中で、SCAに相当するものはありますか？
ME: Windows Communication Framework(WCF)は、SCAサービスコンポーネントモデルの機能をいくつかを持っています。しかし、アプリケーションのコンポジションにおけるSCAアセンブリモデルに相当するものはありません。
InfoQ: SCAが標準化プロセスにある今、進展具合をどのようにして見たら良いのでしょうか?また、SCAは大きく変わるのでしょうか?それとも、今の状態が完成形に近いのでしょうか?
ME: 私たちの予想では、SCAは現在の1.0の仕様から大きく変わらないと考えています。OASIS技術委員会の主なタスクとして、同じステートメントや関連するテストスイートをきちんと作成することです。そして、それらは異なるサプライやが作ったSCAに適合した実装の間において、ポータビリティやインターオペラビリティを保証する上での手助けとなるでしょう。結果、それはエンドユーザーにとって本当に価値のあるものとなるでしょう。
SJ: 私は、始めての標準化を早く目にしたいと思っています。何故なら、私たちが広範な採用により何かをすることが出来るからです。そして、次に来るものについてフォーカスすることもできます。とにかく、SCAは完成していないのです。拡大しうる企業の問題も数多くありますが、広範な仕様が完成するまで待つよりも、仕様を繰り返しながら作成する方が良いと思います。
DB: 現在、6つのTCがOASISにあるので、SCA仕様全体について一般化をすることは難しいです。いくつかの仕様については、他のものより明らかに成熟しています。はっきりとしていることは、企業は顧客のために対処するということです。現在の仕様は1.0レベルで一般公開されているので、願わくば本当の顧客から何の変更が最も重要であるのかということに関するフィードバックを得られれば幸いです。近々で言えば、あるベンダーのツールでシームレスに作業するために、他のベンダーのツールで書かれたSCAコンポジットを利用したいと思う人はいません。つまり、初期のSQLのようにあるデータベース用のSQL文を他のベンダーのツールで書くというようなものです。もちろん、顧客は他のことより重要なこととしてより一層の互換性を強調するでしょう。
MR: 私は、SCAの主要な考えが非常によく練られていると思っているので、それを大きく変えるとするならば非常に驚きます。しかし、OASIS TCが既に作られた設計の部分をそのままの状態にせず、主要な部分を大きく変えるのではないかと考えています。TCはSCA1.0の実装経験をもった OASISのメンバーという利点や、技術に対するテストスイートを作るために得られたフィードバックなども持っているからです。
InfoQ: 早くから公開されたSCAに対する異論の1つとして、それがJEEと競合しているということがあげられます。現在、SunはSCAを採用するといったコメントがありません。それは正しいですか？
ME: SCAを使って作られたアプリケーション全体の中で、JEEコンポーネントやアプリケーションを使用することは全く問題がありません。他のテクノロジーも利用可能です。SCAは、そうするための仕様なのですから。従って、SCAが競合しているのではなく、JEEと一緒に動作するものであると言えます。 SCAは、JEEよりもより一般的なビジネス環境があります。それがまさにSCAの世界の一部なのです。
DB: 当初からあるそういった異論は、SCAに対する十分な理解とその目的が分からなかったことに起因すると考えています。JavaEEはエンタープライズアプリケーションに多くのものを提供しているでしょう。しかし、顧客対顧客のビジネスソリューションという大きな視点で考えるとき、SOAやコンポジットアプリケーションの内容においては、JavaEEが提供するより多くの利便性や可用性といったものが必要になります。そして、それらはJavaEEの範囲外にあるものです。
SP: 私たちはSCAをJava EEへの価値ある追加と見ています。それは開発者とベンダーのためのJava EEへの投資を維持しながら、新しいコンポーネントモデルのプラグインを可能とするフレームワークを提供します。そうするために、私たちはSCAに対する革新的なモデルを作りたいと考えています。それは、Java EEのアプリケーションモデルを拡張したり、新しい実装技術(例えばBPEL)やプロトコルバインディングへのアクセスができるようにすることで、 Java EEがSOAをより使いやすいものにするというものです。SCAの成果物やその他の成果物、あるアセンブリにおいてSCAがサポートする実装技術などによって、Java EEアプリケーションの強化を可能とするモデルを作ることができます。
SJ: 私たちはJ2EEの上でSCAを使いますが、それを言う人々に常に困惑していました。
MR: 私は、JavaEEの部分のいくつかはオーバーラップしているところがあると私は思います。しかし、ほとんどは異なるものです。EJBセッションビーン、 JAX-WS (若しくはJAX-RPC)のサービス、メッセージドリブンビーン、デプロイメントディスクリプタから成るJavaEEのアプリケーションを想像して下さい。それは、SCAのJavaプログラミングモデルを利用したコンポーネント実装を作成し、SCAのコンポジットファイルによりそれらの設定を行うことで、アプリケーションが作成できなければなりません。ランタイムはJMSやJAXのSOAPスタックの一つを利用するかもしれませんが、それらのAPIはデベロッパーからは参照することが出来ません。
プレゼンテーション層(サーブレット、JSPs、JSF、等)もしくはデータ層(JDBC、JPA)に対するJavaEE技術に関しては、オーバーラップする部分がありません。JCAやJMSのような技術は今なお利用されますが、それらのAPIはコンポーネントデベロッパが直接利用することは出来ません。その代わりに、インフラストラクチャは、バックエンドシステム、若しくはメッセージングシステムそれぞれがアクセスできる設定可能なバインディングを提供するための技術を利用します。
InfoQ: SCAに関するその他の分野に関して、OASISへの貢献度はまだ十分なものとは言えないでしょうか?もしそうなら、何をしたら良いでしょうか?
ME: オープンSOAコラボレーションでは、十分とは言えないSCAの部分に関して議論を続けています。いくつかは、直接OASIS技術委員会の議論の一部としています。例えば、Pub/Subやアセンブリ仕様に対するイベントモデルなどがそうです。他には、SCAとファシリティマネジメントの関係や、いくつかのスクリプト言語のためのSCA仕様といったものについては、非常に早くから議論の対象となっていて、きちんと形になるまではOASISの外で議論されるでしょう。
MR: OASIS TCに作業を期待しているその他の分野がありますが、未だインプットとなるドキュメントを提出できていない状況です。例えば、JavaEEアプリケーションとSCAの統合方法に関する仕様などがそうです。しかしながら、私たちはWikiページ上で検討しながらユースケースを記述するなどの作業は行っています。
InfoQ: あなたの会社はSCAデベロッパーですか?ユーザーですか?それともその両方ですか?
MR: BEAは、SCAデベロッパーです。
ME: 私たちは両方です。IBMはSCAを提供していますが、顧客のためにSOAを利用したソリューションを構築するというサービスも行っています。SP: SAPはSCAデベロッパーです。
DB: TIBCOはSCAデベロッパーであり、顧客がSOAベースのソリューションの構築に利用することが可能な製品群を提供しています。
InfoQ: あなたの会社のSOA戦略の中で、SCAが適していると思うところはどこですか?
SP: コンポジットアプリケーションにおける設計とデプロイメントの簡素化は、エンタープライズSOAのメリットを享受するための重要な要素となります。サービスコンポーネントアーキテクチャ(SCA)は、SOAベースのサービスコンポジションの簡素化を行うことを目的としています。さらに、SCAには、エコシステムとして私たちのパートナーや顧客が利用している様々なアプリケーションプログラミングモデルと通信メカニズムを持っている、SAP NetWeaverの拡張を基にした標準を提供するという大きな可能性を秘めています。
SJ: ビジネスSOAに関する技術配信の一部として適しています。それは、設計、実装、デプロイフェーズで適しています。
ME: SCAは、SOAアプリケーションの構築をサポートするコアプロダクトという重要な側面を持ちます。
DB: SCAを見るにつれ、SCAは、現時点でSOAにおける「街中で唯一のゲーム」であると言えます。何故なら、私たちはSOA戦略としてSCAに多大な投資をしているからです。
MR: 私たちは、2つの基本的な分野においてSCAが適していると考えています。1つめは、AquaLogicやWebLogic製品群による複数のBEA技術を利用した、開発、アプリケーションの設定とデプロイを簡素化するための統合技術として適していると言えます。2つめは、新規サービスがJavaで作られ WebLogicサーバーにデプロイされる、新しい簡単なプログラミングモデルを提供するものとして適しています。
InfoQ: 何故、Microsoftは参加しないのでしょうか?SCAは言語にとらわれず、Microsoftも関わってきた多くのWS-*の技術を受け入れているので、彼らのサポートは意味のある標準をつくるのに必要なことだと思いますがどうでしょうか？
ME: Microsoftが、OASIS SCAの活動にいつ参加しても問題はありませんし、私たちは彼らを歓迎するでしょう。SCAは、Microsoftが関わることによって意味のある標準となり、Microsoftが提供しなかったとしてもMicrosoftプラットフォーム上での実装もサポートすることができます。
DB: Microsoftが関わることは、明らかに彼ら自身の利益となりベストなものであると思います。しかし、反論を覚悟で言うならば、Microsoftは自身が持つ同一の環境を構築し、彼らの顧客がその技術に対し多くの投資をしてくれることが一番の優先事項であるのだと思います。しかし、SCAには勢いがあるので、私はMicrosoftが加わり全ての標準化において一定の取り組みをしてくれることを期待しています。
InfoQ: 数あるOpenCSA技術委員会の役割は何ですか?
MR: 私は、SCA-J TCの共同議長で、その他4つのSCAに関連するTCのメンバーでもあります。さらに、海外のOpenCSAの活動の運営委員会のメンバーでもあります。
DB: 私は、OASIS OpenCSAの運営委員会で作業をしており、6つの技術委員会のオブザーバーとして関与しています。
SP: SAPは、SCA-J TCとSCA-BPEL TCの共同議長です。加えて、SAPでは積極的な技術貢献や、仕様策定者などのTCとしての役割を無償で続けていくつもりです。
InfoQ: SCAにおいて、その他の標準化活動を他の場所で共同で作業したり、影響を与えたりすることは考えていますか?
ME: はい。SCAに関連するその他の技術は沢山あります。SCAに影響を与えるものもあるでしょうし、SCAが影響を受けるものもあるでしょう。例えば、 SCAアプリケーションは管理されているので、管理の仕組みに関連する標準などが挙げられるでしょう。それは、アプリケーションのSCA構造を反映する管理インターフェースにとって最も有効なものとなるでしょう。
DB: 内部の経験と顧客の相互関係から見ると、当面は、デプロイメント、セキュリティ、ポリシーといった分野における共同作業や影響として良い機会であると思います。
InfoQ: OpenCSA総会からのアウトプットとして何を期待していますか?
SP: 私たちは、SCA技術の開発と選定をさらに進め検証するために、より広範なOASISの会員がSCAの活動に加わることを期待しています。
DB: 総会と対面での会議において最も重要な効果は、TC全てが幸先の良いスタートを切り、個々が持っているものを進展させてゆくことです。(私が関わっている)6つ全てのTCが1つのイベントを始めることによって、彼らの相互依存性が深まり、TC間での協調が生まれると思います。そして、それがSOAの成功と選定における要素となるでしょう。
ME: Open CSAの総会の間で、6つのSCA技術委員会の発足を見ることができるでしょう。その間のアウトプットとして、来年くらいまでのSCAでの作業の方向が決まると思います。加えて、SCA初心者のために、総会の間は初期の段階から関与しているエキスパートたちから、無料の素晴らしいSCA教育の機会が提供される予定です。
MR: 早いうちに手続き的な問題に対処し、TCメンバーが、仕様のインプットとなるものであると既に気づいている有益な技術的問題のリストを作成し始めようと思っています。私は、対面の会議が効果的な技術進歩となるために、今後の電子会議をベースとした会議が継続できるよう、しっかりと今後につながってゆくことを望んでいます。
原文はこちらです：http://www.infoq.com/articles/sca-opencsa-interview
（このArticleは2007年10月3日に原文が掲載されました）