オープンソースSOAソリューションに対する偏見の再考

作者 Dilip Krishnan , 翻訳者 渡嘉敷 満理子 投稿日 2010年3月18日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント,

エンタープライズ・アーキテクチャ

トピック

SOA ,

オープンソース

タグ

Adoption

原文(投稿日：2010/03/11)へのリンク

ZapThinkのシニア・アナリスト、Ronald Schmelzer氏は、エンタープライズ向けのオープンソースSOAソリューションの適性に関してよくある誤解や偏見について再考し、「極めて多くのIT組織において、SOAを実装する上でオープンソース・ソフトウェア(OSS)を時期尚早に切り捨てているのはなぜか？」という疑問を呈している。

ZapThinkはこの問題を完全に解決するにあたり、OSSスタックを支持するすべてのベンダ・ソリューションを除外してよいと言っているわけではありません。しかし業界が成熟していく中で、最新の経済および技術環境により、OSSソリューションの信頼性、実現可能性、費用対効果、および影響力はさらに増すと確信しています。

氏は、ウィキペディアに準じ、フリー・ソフトウェアとオープンソース・ソフトウェアの微妙な違いを注意深く指摘しながら、オープンソース・ソフトウェアの定義を始めた。

オープンソースという言葉は、必ずしもそうとは限りませんが、通常はフリー・ソフトウェアの概念とともに使用されます。この用語において、フリーとは、ライセンスの取得に全く費用がかからないことを意味する場合もありますが、それはフリーソフトウェア財団(FSF)が定義する内容とは少々異なります。FSFは、フリー・ソフトウェアおよびオープンソース・ソフトウェア(F/OSSまたはFOSS)では、ソフトウェアのコピーおよび再利用を自由にできると定義しています。[…]これは、FOSSライセンスでは、ユーザにコピー、修正、共有、再配布、あるいはテクノロジの発展に貢献する権利が与えられていることを意味しますが、必ずしもすべての費用に関して定義しているわけではありません。

また、オープンソース・ソフトウェアには、商用的なもの(COSS)も登場している。COSSでは、「コミュニティはソフトウェアの修正、共有および拡張における特定の局面に対して権利を所有するが、それ以外の権利ついては企業が所有する」とされているが、これにより利用可能な多くのオープンソース・ライセンスの法律用語が一人歩きし、オープンソース・ソリューションの採用をめぐるFUD(Fear(不安)、Uncertainty(疑念)、Doubt(不信)の略)の一因となっている。

では、まず疑念から始めることにします。SOAの観点から考えると、OSSに対する大きな疑念は、2つの主要な問題に基づいています。その2点とは、SOA実装に必要な範囲をカバーするOSSオファリングが十分に存在するか、また、それらのOSSプロジェクトの品質がわれわれのニーズを十分に満たすか、ということです。

氏は続けて、次のように質問に答えている。

個人および企業は、これらの[OSS]ツールに何万時間という開発時間や維持費を注ぎ込んでいます。[…] 多くのオープンソース・ツールは、商用オファリングを既に使用したことのあるユーザの経験に基づいており、それらのソリューションの機能やパフォーマンスに倣うことや改善することを目標としています。

さらに氏は、ベンダ・ツールの多くは買収製品(場合によっては、一連の買収製品)であるため、商用/ベンダ・ソリューションは、製品ポートフォリオにおけるロードマップや他製品との統合に関して"明確に定義されていない"ことが多々ある」と指摘している。続けて氏は、ソリューション分野のさまざまな部分で利用可能な数多くのソリューションを分類し、以下のようにリストアップしている。

[…]Enterprise Service Bus(ESB)機能には、多くのオープンソース・ソリューションがあります。企業は、Mule ESB、Apache Axis2、Apache SynapseおよびApache ServiceMixの実装で成功を収めています。

SOA開発では、Swordfish SOA frameworkやEquinox OSGiフレームワークなど[…]OSSの選択肢は多種多様です。

オープンソースSOAの登録および管理ソリューションには、Mule Galaxy、SOPERA、WSO2のオープンソース登録オファリング、およびMembrane SOA Managementツールなどがあります。

OSSのBusiness Process Management(BPM)およびBPELランタイム・エンジンには、ActiveBPEL、Apache ODE、Orchestraや、その他にも多くのソリューションが存在します。

氏は、OSSソリューションのサポートへの懸念には根拠がないと主張しており、ほとんどのOSSプロジェクトには、有償サポートを提供する営利企業が存在する点について触れている。

多くの優れたOSSソリューションには、レスポンス・タイムを実現し、必須事項を配慮する上で有償サポートが必要となるのは事実ですが、費用は有効に使われていると言ってよいでしょう。OSSオファリングのサポートを提供する営利企業の場合、両者の長所(コミュニティによる低コストまたは無償での開発、テスト、拡張および時間と価値が既知数である本格的なサポート)を生かすことができます。商用ベンダを選択したとしても、いずれにせよ、サポートに対して費用がかかることになります。

さらに氏は、買収、コスト削減、あるいは合併という形でIT業界に変動が生じた結果、各製品および製品ラインが終了することがあるが、OSSではこのリスクが軽減されることを示唆している。

コードはコミュニティで公開されおり、誰でも入手できるため、OSSではリスクが軽減されます。SOAの観点から考えると、可能な限りインフラストラクチャや1つのベンダ・ソリューションへの依存は避けることが望ましいでしょう。そのような意味でも、多くの者にとってOSSは、全く理にかなっています。

続いて氏は、BlueStar Energyの例を挙げ、OSSソリューションに完全に準拠したSOA実装を使用し、5年で2400万ドルの削減を視野に入れている背景について説明している。

ケーススタディを読むと、設計方針には明らかに非ベンダへの偏見があったことがわかります。彼らは環境の管理を望んでいました。これは、実装の中立性を要する仕様作成を意味します。[…]彼らのビジネス統合スイートは、Enterprise Service Bus、ビジネス・プロセス管理システム、メッセージング・ファブリックなど、分散されたスケーラブルで信頼性のあるオープンソースのコンポーネントで構成されています。

氏はアーキテクトに向けて、実装にとらわれずベンダに中立的な方法でアーキテクチャを定義し、対象となるソリューション(オープンソース・ソリューションかベンダ・ソリューションかを問わず)の適正を評価するよう勧めている。氏は次のように、エンタープライズおけるSOA実装に向けたOSSの実行可能性を支持する言葉で記事を締めくくっている。

FUDを事前に確認してください。そして、SOAインフラストラクチャの混合環境からOSSを時期尚早に排除してしまうことで、優位性を失わないようにしてください。

• 次へ >