Layer 7のパートナーソリューションアーキテクトであるJaime Ryan氏は、「ESB再考 : SOA Gatewayを用いた簡単で安全、拡張可能なサービスバス」という記事の中で、SOA Gatewayの出現をESBに代わる存続可能な選択肢として論じている。Ryan氏は、典型的なESBの3つのユースケースを中心に、現代のSOA Gatewayの機能的能力に基づき、SOA Gatewayを推奨している。ここで言う3つのユースケースとは、標準ベースのエンドポイントの抽象化、データと移動の仲介、そして、非機能的要求のホストに加えて、Ryan氏が「従来のESBの証明」だと言うメッセージルーティングだ。
InfoQはJaime Ryan氏に話を聞き、様々な推奨事項の背後にある基本的な理由と、これらを推奨する時期について理解を深めた。
InfoQ: ESBの現在の状況の中で、ESBに代わるものが必要だと考えさせるような不都合な点は何ですか?
企業がエンタープライズサービスバスを使うことを決めると、巨大なソフトウェアスィートの複雑さ(とコスト)に捕らえられます。このソフトウェアスィートは、主要なベンダが特定の製品でESBパターンと同等のものを実現するために提供しているものです。これらのスィートは、使う人のために割合総合的なものになっているため、平均的な企業が本当に必要なものよりもずっと多くの機能を提供します。アーキテクチャの目的が機敏であることと顧客のニーズに応える機敏性があることである場合、インストールに1ヶ月かかる解決策がその答えになることはめったにありません。これらは、ヘビーウェイトで利用者次第の解決策であり、有意義なやり方で展開していくには数ヶ月から数年かかります。また、展開しながら、しばしば大量のコードとマッピングプロトコルが必要になります。そして、このようなスィートは、主に接続性に注目しているのでセキュリティは不完全です。SOA Gatewayを利用することに対して最初に興味を持つのは、このような状況に置かれた時です。
企業はセキュリティや管理のためにネットワークの端にSOA Gatewayを配置するのに成功し、同じ目的でイントラネットに移行するのは自然なことでした。セキュリティのくさびとして内部アプリケーション間に配置することで、ESBのニーズの多くは、ライトウェイトでローコストな簡単に使えるSOA Gatewayという選択肢を用いて、様々な成功のもとで実装されてきた従来のESBプラットフォームに合うことを顧客たちは認識し始めました。その時には、要求のエクササイズになります。これらのゲートウェイは私のニーズに合っているでしょうか。もし合っているならば、なぜ私は、同じ最終目的に到達するために、より遅くてコストのかかる面倒な道を通るのでしょうか? SOA Gatewayを使えば、設定がより簡単で、より堅実に拡大し、管理面ではより管理しやすくなります。また、セキュリティアーキテクト、アプリケーションディベロッパ、ネットワークアドミニストレータ、そして、オペレータには価値があります。おそらく最も重要なのは、機敏性と柔軟性によって、ビジネスのボトムラインが上がるのを助けることであり、何よりお財布にひびかないというのは素晴らしいと言えます。
InfoQ: SOA Gatewayを使いながら特定のESBを実装するコンセプトに関して、何が新しいのですか? また、なぜ今そのことに関心を寄せるのでしょうか? ここ10年の初期の頃から、この役割の拡大を私たちは見てきたのではないでしょうか? 例えば、DataPowerをIBMのESBファミリーの製品に組み込み、そのユースケースを扱っているのではないでしょうか?
確かに、ESBとしてSOA Gatewayを使うコンセプトは、ずいぶん前からありました。複数のベンダが約10年間この分野で販売してきています。しかしながら、ESBと接続するアプリケーションやサービスを持ちながら、これらの解決策はより洗練されたものになってきています。サポートするプロトコルやメッセージ形式の数が増えるにつれて、SOA Gatewayはますます総合的になっています。10年前、これらの解決策はHTTPとHTTPSに限られ、ほとんどすべてセキュリティに注目していました。完全な解決策を提供するために接続する必要があるアプリケーションやインターフェースの範囲は、もう一方では非常に幅広いものでした。そのため、SOA Gatewayは、限られた数の大企業のニーズに合うだけでした。
幸運なことに、両方の面で動きがありました。Gatewayの機能が進化し、Gatewayが触れるアプリケーションがより新しいインターフェースを提供するようになるにつれて、顧客のニーズに応える能力は大きく増加しました。市場は、今ではとても小さなカスタマイズや製品の拡張によって、顧客の85-90%のニーズに応えられると言えるでしょう。これは、ほとんどのSOA Gatewayのベンダにとって事実です。そして、サポートする標準に合わないデータ形式やサービスインターフェースがある場合は、顧客がさらに処理を進めるために使う言語に組み込むように、Layer 7 GatewayがカスタムコンポーネントSDKをサポートします。同様に、新しいトランスポートプロトコルは、顧客の需要に応えるように私たちのネットワークレイヤサポートをとても簡単なものにしました。同時に、パッケージアプリケーションのベンダは、インターフェースも現代化しています。つまり、複雑で追加費用がいるアダプタの必要はありません。これは、主要なパッケージアプリケーションベンダ (SAP、JD Edwards、Peoplesoft等) も、数多くの小さなプレーヤーと同様だというのは事実です。Googleで “あなたのパッケージアプリケーションの名前 ウェブサービス” と打ってみましょう。統合するための簡単な手順が見つかることでしょう。
通常の統合サポート以外に、従来のESBへ対するよりライトウェイトでアジャイルな選択肢へ興味が向けられているのは、変化しているビジネス環境と技術プラットフォームのためでしょう。IT関連の店は、より少ないことでより多くのことをして、顧客の要求に素早く答えることを求められています。3年間のサービス契約の時代は、すぐに過去の出来事になり、納期は、年数ではなく、週、または月で測られる必要があります。新しい方法で既存のデータを公開できるコンフィギュレーション駆動型のゲートウェイは、要求が完成する前に変わってしまう長期間のプロジェクトよりも素早く新しい収入を生み出します。これは、携帯電話やクラウド関連の新しい技術に関して特に当てはまります。従来のESBの実装は、クラウド環境に簡単に移植できるものではなく、3年経った技術よりも30年経った昔の技術により多く注目しています。Layer 7 Gatewayは、パブリック、またはプライベートなIaaS/PaaS環境でVMを展開するか、または、Amazon EC2 や vSphere 環境のパブリックな市場のインスタンスとして、クラウドに移植可能です。店舗用のゲートウェイは、簡単なテンプレートを経由して、クラウドの中のSaasアプリケーションに接続できます。そして、OAuthや2要素認証などのクラウドと携帯電話インターフェースで使われる新しい識別とアクセスのコントロールメカニズムをサポートします。
明らかに、SOA Gatewayは全てのことができるわけではなく、すべきでもありません。それは、ESBをターゲットにする製品が全ての人のために全てのことをしようとすべきではないのと同じです。ビジネスロジックのためにコードを書いている時に、アプリケーションサーバで動いている標準プログラミング言語は依然として有効な方法です。ESB自体に複雑なビジネスロジックを入れる理由はありません。複雑なビジネス駆動のルールに取り組んでいる時、そのルールのエンジンは、ビジネスユーザにルールを具体的に表すために使われるべきです。人と相互に影響し、長期間動くタスクを実行している時、BPMの解決策から離れないようにしましょう。
InfoQ: Ryan氏の記事の中で、3つの主要なユースケースに注目しています。「標準ベースのエンドポイントの抽象化、幅広いデータと移動の仲介能力、そして、動的な情報処理能力を持つメッセージルーティング」。機能的要求であるデータの仲介は、エンドポイントの変換コンポーネントにカプセル化するべきだと言う人もいますが、あなたはどう思いますか?
サービス要求やAPIの呼び出しへの実際のビジネスロジックのアプリケーションはエンドポイントに残すのが最適ですが、データ形式の変換をエンドポイントから中央に集めたり、仲介させたりするのにはやむにやまれぬ理由があります。結局は、パフォーマンスやコスト、複雑さに影響されます。
バックエンドアプリケーションのために新しい標準ベースのインターフェースを発表する時に、頼りになる選択肢は、SOAPやRESTサービスで見られるXMLのことが多くあります。自己記述的、かつ、(理論上は)人が読める一方で、XMLはとても冗長で、処理する時はメモリが必要になります。その結果、パースやスキーマ検証、変換は、これらのタスクのために構築されていないソフトウェアソリューションの中で非常に負担が大きくなります。ゲートウェイを持てば、この機能は提供されます。特に、専用のXML加速ハードウェアを持つ機器のフォームファクタでは、アプリケーション自体のオーバーヘッドを減らし、ソリューションの全体のスループットを増やします。
現実世界では、パフォーマンスの影響は、実物のドルと同等です。数多くのレガシープラットフォームは現代化され、独自の新しいインターフェースを提供し始める一方で、このプロセスは遅く、逆効果になっています。例えば、1つの主要なメインフレームのトランザクション製品の最近のバージョンは、「ウェブサービス」のためであると指定され、アプリケーションを定義されたウェブサービスインターフェースにマップして、メインフレーム自体でデータフォーマットの変換を行うための方法が開発されていました。そのため、まず最初に、確実に最新バージョンを動かさなければなりませんが、そのような作業は銀行のような企業にとって簡単ではありません。それから、メインフレームのフォーマットとXMLインターフェースをマップするようなコードを書いて、テストして、展開することに開発リソースを注力しなければなりません。もっとも成功している場合に、すべてが稼働して意図されたように動いていても、メインフレームの処理のオーバーヘッドは増加しています。この変換を分散アーキテクチャにおいて専用のリソースに外部化できるときに追加のコストが必要になるのに、なぜメインフレームにMIPSを追加するのでしょうか?
最後に、すべての変換をエンドポイントに追いやることによって、ITリソースに重い負担がかかります。アプリケーションがRESTインターフェースを提供し、顧客がSOAPベースのウェブサービスの方を好むような簡単な場合であっても、開発チームは、突然、同じ基礎をなすアプリケーションのために複数のインターフェースをサポートしなければなりません。基礎となるデータは同じですが、一顧客をサポートするために追加のコードを書いています。それから、新しいバージョンがリリースされて、同時に古いバージョンをサポートしなければならない場合はどうなるでしょうか? このような場合、突然、開発したり、配備したり、管理したりすることが悪夢のようになります。すべてはそのアプリケーションの中に組み込まれているからです。SOA Gatewayの持つ変換能力によって、簡単な標準ベースの変換をしたり、コードがなくてもHTTP動詞を構成によって操作したりするSOAPからRESTへの新しいマッピングが可能になります。一度に複数のバージョンを実行することをサポートし、ユーザ、名前空間、または、メッセージの内容に基づいて動的に選ばれ、すべて1つのバックエンドインターフェースに接続し、エンドユーザには完全に見えるようになります。
結局、どのようなエンドポイントベースのデータ仲介であっても、簡単さ、拡張性、パフォーマンス、おなじ役割を果たすSOA Gatewayの投資に対する利益を生み出すのはとても難しいのです。
InfoQ: SOA GatewayがESBに取って代わるべきだという、安全なプロトコルのためのOOTBサポートはさておき、非機能的な利点はありますか?
セキュリティは、この能力で使われているSOA Gatewayにとって単なる開始点でしたが、いまだに重要な要素になっています。トランスポートレイヤセキュリティ、メッセージレイヤセキュリティ、スレッド保護、識別とアクセスコントロール等、セキュリティは、最高級の立場にあり、ゲートウェイはそれを証明する証明書を持ちます。専用機器で変換とプロトコル仲介をすることでパフォーマンスの利益があることについては、すでにお話しました。そして、飽和状態に達した時にクラスタの中に新しく適用する能力は、新しいソフトウェアをインストールするのに非常に好ましいものです。実際に、何十もの従来のアプリケーションサーバを、目的に応じて構築された1つの機器に置き換え始めた時に、データセンタ能力、電力消費、管理負荷に関して、環境的にもコスト的にも節約できます。
使いやすさと柔軟性は、おそらく最も重要な強みです。SOA Gatewayは、デジタル署名の検証、スレッド保護、型変換、そして、コンテキストベースのルーティングのような複雑な操作を1行もコードを書かずに実行する方針を作成する能力を提供します。機能的要求は主要な検討事項ですが、SOA Gatewayを本当に望ましい選択肢とするのは非機能的要求なのです。