1. はじめ
に 現在、各企業は生産効率を向上させる方法を模索しており、IT 資産の再編も積極的に検討しています。 IT 組織は、サービス指向アーキテクチャ (SOA) テクノロジを活用してこれらの問題の克服にある程度の進歩を遂げてきましたが、ほとんどの場合、IT サービス ポートフォリオ全体のほんの一部しか実装されていません。現在、この分野におけるほとんどの取り組みは、SOA 導入の「十分な」状態を達成するだけであり、アプリケーションを構築する能力を向上させ、アプリケーションをより速く、より良く、より安価に市場に統合するというものです。そして、私たちが学んだように、これらの目標を達成することは言うは易く行うは難しです。
2. 従来のミドルウェアベースの複合アプリケーション
既存の事実として、SOA は一種のミドルウェアであり、従来の場合、ミドルウェアはデータを消費者に優しい状態に変換するためにより多くのミドルウェアに依存することがよくあります。 SOA テクノロジを組み込んだ複合アプリケーションを構築するには、ポータル (ミドルウェア) の使用が必要なだけでなく、それを調整するために BPEL エンジン (またはミドルウェア) の使用も必要になる可能性があることが最終的に理解できれば、当然のことながら、とてもがっかりしました。さらに悪いことに、UDDI レジストリを公開し、多数の Web サービスを登録する組織内で働いている可能性があります。残念ながら、ほとんどの場合、これらのサービスを実際に利用するアプリケーションはほとんどありません。
これらの SOA サービスを使用するアプリケーションを構築できないということは、ビジネス コンテンツ開発者にとって SOA サービスを直接使用するアプリケーションを構築することが難しすぎるためであると結論付ける必要があるのでしょうか
?
このようなアプリケーションの作成を他の IT 組織に依存することは、SOA ガバナンス構造の欠如によって妨げられているのでしょうか? 上記すべてに対する答えは「はい」だと思います。そして、非常に顕著な理由があります。IT 組織によって公開されているこのような SOA サービスをビジネス開発者だけが利用して利用するのは非常に難しいのです。実際、本当の問題は、SOA インターフェイスを追加する簡単な方法がないことです。これが、AJAX テクノロジーと SOA を組み合わせる利点です。
通常、SOA サービスは、ビジネス機能をカプセル化して公開する疎結合 Web サービスとして実装されます。これは非常に簡単に聞こえるかもしれませんが、実装は非常に複雑で困難です。開発者は、SOA サービスの開発粒度についてよく議論しますが、現在、ほとんどの開発者は、「ビジネス レベル」の開発粒度が最も適切であることに同意しています。ただし、これには依然として多数の関連分野の専門家が参加し、ビジネス コンテンツと協力してこれらのサービスの規模を最終決定する必要があります。
3. SOA の復活
幸いなことに、人々は最近 SOA に深い関心を抱くようになりました。おそらく企業は、SOA が実際に非常に役立つことにようやく気づき始めているのでしょう。おそらくこれは、Amazon、Yahoo、eBay が推進する開発ツールと Web サービスの向上によるものでしょう。おそらくそれは AJAX なのでしょうか? はい、それが私がこの記事を書いている理由です。正直なところ、AJAX は、特に今日のさまざまな新しいテクノロジのハイブリッド アプリケーション分野において、SOA に対する人々の理解を新たにする重要な原動力になっていると思います。しかし、より大きな力を発揮するには、これら 2 つのまったく異なるテクノロジをどのように組み合わせて接続すればよいでしょうか。まず、Wikipedia による現在の AJAX テクノロジの定義を見てみましょう。 Web ページは関係していますが、SOA についてはまったく言及されていません。説明は次のとおりです。
「AJAX は、「Asynchronous JavaScript+XML」の略で、インタラクティブな Web アプリケーションを作成するための Web 開発テクノロジです。その目的は、サーバーと少量のデータを交換することで、フロントエンド Web ページを簡単にすることです。そのため、ユーザーが変更を加えるたびに Web ページ全体をリロードする必要がなくなります。最終的な目標は、Web ページの対話性、応答性、使いやすさをさらに向上させることです。
初期の AJAX アプリケーションはページの機能と使いやすさの向上に重点を置いていたため、この定義では SOA について言及されていません。これは、Google マップ、Flickr、Yahoo Mail などの多くのアプリケーションで証明されています。しかし、AJAX の可能性に私が興奮するのは、これらの消費者向けアプリケーションではなく、AJAX の利点を実際に活用する企業のファイアウォールの背後で実行されるビジネス アプリケーションです。なぜなら、AJAX には 2 つの重要な特性があるからです。 1 つはクライアントです。 -側のプログラミング モデル、もう 1 つはサーバーへの非同期呼び出しの簡単な実装です。これら 2 つの主要な機能 (クライアント (ブラウザ) にロジックを適用する機能と、Web ページを中断せずにサーバー データにアクセスする機能) により、プログラムの非常に多くの可能性のある新しい Web 2.0 エンタープライズ アプリケーションの構築への扉が開かれます。 。
先ほど、SOA にはインターフェースがないことを述べました。ここで AJAX が登場します。AJAX は SOA に適切な外観を追加します。ここで、もう少し説明させてください。 SOA サービスがオンラインに登場したらどうなるかを考えてみたほうがよいでしょうか? このようなサービスは通常、(運が良ければ) レジストリまたはウェアハウスに登録する必要があり、その後使用できるようになります。たとえば、StrikeIron Web サイト ( www.StrikeIron.com ) で利用できるものを見てみましょう。 StrikeIron は、一般向けの「Web サービス マーケットプレイス」を作成することに成功しました。一見すると、StrikeIron のディレクトリ メカニズムは、小規模ビジネス アプリケーションで提供されるリストによく似ています。しかし、後になって、これらは単なるアプリケーションではなく、実際には Web サービスであることがわかります。単一の企業が WSDL/REST Web サービスを幅広い消費者に提供するという概念には、多くの意味があります。しかし今は、この会社が何を販売しているかを見てみましょう。 StrikeIron (これらのサービスへのアクセスを提供する) が提供する情報によると、同社が提供する最も人気のある Web サービスには以下が含まれます:
· 米国住所検証
· グローバル SMS サービス
· 売上税および使用税
· 電子メール検証
· 電話逆引き
何も間違いなく、すべてこれらの Web サービスは非常に便利で、さまざまな分野で使用できます。しかし同時に、それらはあまりにも「商品」でもあります。言い換えれば、誰がサービスを提供しているかは気にせず、ただ自分が欲しい情報を入手したいだけなのかもしれません。一方、Web サービスを使用して、現在の口座から普通預金口座に現金を移すだけでしょうか? 私ならそうしません。まずこのサービスに対する信頼を確立する必要があるため、サービスを提供するベンダーと一定の関係を確立する必要があります。私 (消費者) とサービスプロバイダーの間に存在するこの「信頼の輪」は、企業とそのパートナー内の関係も表しています。
4. AJAX + SOA テクノロジーの組み合わせ
上記と同じ方法を企業が採用して、Web サービスをより広範なユーザー ベースに提供することもできます。 Web サービス マーケットを通じて、企業はさまざまな Web サービスを登録できます。これらの Web サービスは通常、企業内またはパートナーのみが利用できます。市場ベンダーは明らかにこれが実現することを望んでいますが、より重要なのは、AJAX+SOA テクノロジを適用して新しいクラスの Web 2.0 ビジネス アプリケーションを推進する機会があると考えていることです。
人々は初めて、アプリケーション開発と SOA がついに統合されつつあると感じ始めました。 SOA サービスという再利用可能な形式で記述されたビジネス機能があります。私たちはユビキタスな接続、つまりウェブを持っています。新しいアプリケーション コンテナであることが証明されているブラウザがあります。このタイプのアプリケーション コンテナ/ブラウザには、JavaScript というプログラミング モデルがあります。そして、それらはすべてオープンスタンダードを使用しています。実際、他に何を求めるのでしょうか?
私が特に望んでいるのは、上記のテクノロジーすべてに基づいてアプリケーションをより迅速に開発する方法、つまり SOA サービスと統合されたミドルウェアに依存せずにアプリケーションを構築する方法です。これはまさに私が Web アプリケーションに求めている機能、つまり「SOA への直接接続」です。この「SOA への直接接続」は、従来のポータルの障壁や重量のあるプロセス エンジンをバイパスして、SOA サービスに直接 (少なくとも概念的には、これについては後で詳しく説明します) アクセスできる必要があります。これは単に Web サービスを意味するのではなく、BPEL オーケストレーション サービス、粗粒度の POJO サービス、RSS フィード、または「サービス」として公開できるその他のあらゆるものを意味する場合もあります。もちろん、インターフェイスはオープン標準を使用して公開される必要があります。
この新しい開発およびランタイム モデルは、アプリケーション駆動型の複合アプリケーションを構築する新しい方法を作成します。従来の重量級クライアント/サーバーのような重荷のないクライアント/サーバー タイプの魅力があります。ブラウザ側で実行され、特定の要件に応じて実装できます。
5. ユーザーベースの複合アプリケーション
ここ数年、誰もが「複合アプリケーション」という概念を聞いたことがあるでしょう。しかし、ほとんどのベンダーは、ホスト サービスを他のより便利なサービスやポータル アプリケーションに再構築する方法として、「複合サービス」について話しています。さらに説明するために、たとえ話をしてみましょう。
この記事で取り上げる架空のグリッド コンピューティング ベンダーである AcmeGrid は、アプリケーションをサービスとして実行できるサービス (グリッド コンピューティング) を提供します。同社の顧客は、多くのサービスを大まかなサービスに統合する方法が欲しいと同社に語った。したがって、当然のことながら、AcmeGrid は Eclipse ベースの AcmeGrid Composite Application Builder (CAB) をリリースしました。興味深いことに、CAB は BPEL デザイナーによく似ていますが、AcmeGrid が公開するサービスとより緊密に統合されています。しかし、これは非常に美しいですが、実際のアプリケーションではなく、せいぜい単なるサービスです。本質的に、CAB はサービス ビルダーに似ています。しかし、アプリケーションを構築しようとするときに、誰がサービス ビルダーを必要とするでしょうか? 間もなく、別の架空のベンダー (AcmePortal と呼びます) が、Portal Composite Application Builder (PCAB) を発表しました。また、Eclipse ベースのデザイナーも付属しています。見た目も操作性も BPEL デザイナーと似ていますが、このプログラムはポータルの構築方法を「知っています」。多くの場合、ポータルはアプリケーションと同様に機能します。ただし、ポータルをアプリケーションに変換することに固執しても無駄になります。
実際、私はミドルウェアベースの複合アプリケーションではなく、ユーザーベースの複合アプリケーションを実装したいと考えています。これを行うには、AJAX と SOA を使用できるだけでなく、両方を管理できる開発およびランタイム プラットフォームが必要でした。一部のベンダーは、AJAX アプリケーションの概念をさらに一歩進めて、WSDL ベースの Web サービスをブラウザから直接呼び出します。これは本質的には SOAP 呼び出しです。このアプローチには「クライアント/SOA」という名前も付いています。これは、単純な非エンタープライズまたはコンシューマー アプリケーションには問題ありませんが、真のエンタープライズ プログラムには適していません。その理由は、ブラウザから Web サービスを直接呼び出すと、監視機能がブラウザに引き渡されることと同じであるためです。これは、単に監視の問題がまったくないことを意味します。図 1 は、監視されていない Web サービスの利用のブロック図を示しています。私は自社のサービスを取り締まらない企業に会ったことがありませんし、当社が技術的に非常に効率的であるという理由だけで、企業がこのようなことを許すはずはないと思います。私の話を信じない人は、企業が HTTP と SSL 以外のアプリケーションに対してファイアウォールを決して開いていないことを覚えておいてください。システム管理者をいくら説得しても、他のポートは開きません。
6. 新しいタイプのプラットフォームが必要である
上記からわかるように、私たちが議論しているのは AJAX や SOA テクノロジーだけではありません。実際、本当に必要なのは、AJAX と SOA が企業内で共存するために必要な監視機能を提供できるプラットフォームです。このプラットフォームは、クライアントの観点から SOA サービスを利用する機能も提供し、サービスの利用を監視することもできます。図 2 は、サービス ゲートウェイを通じて Web サービスを管理する方法を示しています。サービス ゲートウェイは実際には、クライアントに代わってサービス アクセスを監視および制御するサーバー側の抽象化です。先ほど説明したケースでは、ブラウザ ベースの AJAX アプリケーションです。サービス ゲートウェイを使用する利点は、企業内で実行されているサービスのみへのアクセスに制限されないことです。このサービス ゲートウェイは、企業内に登録されているあらゆるサービスを監視できます。 WSDL ベースの Web サービスでは、企業が WSDL を登録し、WSDL は実行時にサービスへのバインディングを提供します。これは企業のデータ センターで実行されているサービスである可能性がありますが、パートナーシップのデータ センターで実行されているサービスであることも簡単に考えられます。企業が (規制を通じて) アプリケーションがサービスにアクセスすることを許可している場合、それらのサービスがどこで実行されているかは問題ではありません。
7. 結論
この記事を読んで、AJAX と SOA を統合することの威力、特に 2 つがどのように共存して、エンタープライズ サービス アプリケーションに必要な規制機能を備えた新しいタイプの Web ベース アプリケーションを実現できるかについて理解していただけたでしょうか。 。私たちは、素晴らしいチャンスに満ちた新時代の前夜にいることを強く信じています。 Web 2.0 時代には、ソーシャル ネットワーク、画像共有、さまざまなアノテーション テクノロジが素晴らしいですが、本当に影響力があるのは、企業に対する Web 2.0 の対応です。