スタートアップ：Ajaxポータルテクノロジー-次世代のエンタープライズポータルに向けて

よくあることですが、 Ajax Portalテクノロジーは、企業Webサイトの「エンジン」を構築する際の2つのエンタープライズポータルとAjaxテクノロジーの統合として偶然登場しました。 その結果、エンタープライズポータルに新たな風を吹き込む可能性のある新しいものが登場しました。



約5年間、私はヨーロッパの主要な関心事であるミンスク部門で働いていました。 仕事の一環として、イントラネットに参加しました（新しいアプリケーションの開発と古いアプリケーションのサポート）。 目標は、異種アプリケーションを単一の情報スペースに統合する何らかの統合ツールを開発することでした。 この作業の特異性は、アプリケーションがさまざまなWebテクノロジーを使用して開発され、物理的に異なるサーバーに配置されたことでした。 技術的な観点からは、これらのアプリケーションを「友達にする」ための唯一の解決策がありました-HTMLフレームを使用することです。 HTMLフレームは、ブラウザウィンドウを複数の部分に分割できるHTMLタグのセットです。各部分では、インターネットサイト、Webアプリケーション、およびWebページを表示できます。 このアプローチのハイライトは、フレームの1つ（ブラウザの独立した部分の1つ）に単純なリストまたはツリー形式のリンクセットが含まれ、他のフレームにインターネットサイト、Webアプリケーション、Webページ、PDFドキュメント、MS Office-ドキュメント（Word、Excel、PowerPointなど）、写真など （以下、コンテンツまたはインターネットリソースと呼びます）。 この場合、表示されたコンテンツとコンテンツのタイプの場所に違いはありませんでした。



外見は次のように見えました。ブラウザウィンドウは2つの不均等な部分（フレーム）に分割されていました。 左側（狭い方）には、リンクがリストまたはツリーの形式で表示され、右側には、左側から選択したリンクに関連するコンテンツが読み込まれました。 したがって、アプリケーションとドキュメントのコンソールが作成され、異なるアプリケーションとドキュメントが単一の情報スペースに結合されました。 コンソールでは、情報を検索、ナビゲート、さらには保護することもできました。



開発したソリューションに基づいて、企業サイトを作成するための製品のリリースを申し出ましたが、経営陣からのサポートは見つかりませんでした。 革新に対する大企業のマネージャーの典型的な反応は、ジャックトラウトの著書「Feeling the Horse」に詳しく説明されています。 ただし、次の2つの会社で働いて新しい製品を作成しようとすることをgiveめませんでした。 同時に、企業ウェブサイトの「エンジン」がますます完璧になりました。



時間が経つにつれて、HTMLフレームの使用はWebアプリケーションの作成において「悪い習慣」と見なされるようになりました。 IFRAME HTMLタグについてのみ例外が作成されました。これにより、Webページの任意の場所に独立したブラウザーウィンドウを追加し、そのコンテンツを表示できます。 その結果、組み込みのリンクツリーとIFRAMEタグを持つページで実験を開始しました。 同時に、ツリー内のリンクがクリックされると、コンテンツはIFRAMEタグ内にロードされました。 当然、ツリーはすぐにJavaScriptに基づいて動的になり、必要に応じてレベルがロードされました。 ツリーが「アイコン」のセットに置き換えられたバージョンもありました。



Ajaxテクノロジーの出現により、Ajaxテクノロジーを使用してHTML / XHTMLコンテンツをロードし、JavaScriptプロパティinnerHTML（一般にDIVタグ）を介してコンテンツを挿入して表示するというアイデアが生まれました。 これは、関連するアプリケーション（同じCSSおよびJavaScriptファイルを使用するアプリケーション）で完全に機能しました。



次のステップは、ロードされたHTML / XHTMLドキュメント（コンテンツ）に関連するすべての必要なCSSおよびJavaScriptファイルを抽出し、それらをメインドキュメントに貼り付けるというアイデアでした。 クールなアイデア、一見シンプル。 考えられる状況、ブラウザーの違いなどのほとんどをカバーする前に多くの時間を費やしました。 作業の結果はajax4all JavaScriptライブラリでした。これにより、JavaScriptを使用してほとんどすべてのHTML / XHTMLドキュメント（Webアプリケーション）を別のHTML / XHTMLドキュメント（Webアプリケーション）に挿入し、実質的に問題なく1つともう1つを操作できます（注：もちろん、CSSクラスとJavaScriptメソッドおよびクラスの同じ名前に問題があるかもしれませんが、この問題でさえ、CSSクラスとJavaScriptクラスおよびメソッドの名前を変更することにより、プログラムで解決できます。 ポータルソリューション（JSR-168およびJSR-286標準に基づいたエンタープライズポータル）に別の情熱がなければ、このライブラリはおもちゃになる可能性があります。



そのようなことが起こったので、後でWebLogic Portalに移行されるプロジェクトに取り組んでいたときに、ポータルソリューションに精通しました。 その結果、主なことが起こりました-2つの情熱のアイデアが組み合わされ、その結果、Ajax Portalが登場しました。



ポータルを使用すると、小さな独立したアプリケーションであるポートレットに基づいてページを作成できます。 ポートレットは、数個から数十個のポートレットを含むことができるポータルページに小さな独立したウィンドウとして表示されます。 必要に応じて、ポートレットは互いに通信できます（ポートレット間通信）。 ポートレットを使用すると、モジュール式のソフトウェア開発が可能になります。



また、ポータルを使用すると、単一のポータルページ内の異なるソースからのデータを集約（結合）できます。これにより、複数のアプリケーション間で情報を検索するのではなく、単一のブラウザーページ（必要な場合は複数のページ）内で情報を表示できます。 これにより、意思決定を迅速に行うことができます。



ポータルの次の利点はカスタマイズです-ポータルページをカスタマイズする機能：ポートレットの移動、新しいものの追加、古いものの削除、ポートレットの最小化と拡張が可能になります。 プログラマーを巻き込まずにデスクトップ（ワークスペース）をカスタマイズします。 これにより、情報とその処理を行う際に最高の快適さを提供できます。



Ajaxポータルがエンタープライズポータルの開発者に提供するもの：

1. クライアント側のコンテンツ集約（JavaScriptを使用するブラウザー内）は、JSR-168およびJSR-286標準に基づく従来のサーバー側のコンテンツ集約よりも効率的です。
2. ポータルサーバーの負荷を軽減します。 コンテンツおよびデータは、ポータルサーバーをバイパスして、ポートレットサーバー（ポートレットアプリケーションが実行されているサーバー）からブラウザーに直接送信されます。 トラフィックの削減は約10〜20回発生し、ポータルページ上のポートレットの数に依存します。
3. ポートレットの変更は、新しいページの追加や古いポートレットの削除など、ポータルページ全体をリロードすることなく行われます。 その結果、すべてがより速く動作します。
4. ポートレットは、ポータルページ全体をリロードすることなく、新しいポートレットを開いたり、古いポートレットを閉じたり（ポータルページから削除）できます。
5. 他のポートレットとの簡略化された通信（ポートレット間通信）。 これは、ポータルページのコアを介して、またはポータルまたはポートレットサーバーを介して実行できます。
6. processActionメソッドの必要性はなくなりました。
7. JSR-301およびJSR-329標準に基づいた大きなブリッジをサポートする必要はありません。その結果、コンテンツとリソースをダウンロードするための単一の方法が登場しました。
8. これで、通常のWebアプリケーションをポートレットとして使用できます（マッシュアップの特定の場合、これについては以下のいずれかの記事で説明します）。 さらに、porjax（ポートレット記述子を使用したWebアプリケーション）の使用は特別なケースと見なすことができます。
9. ポートレットとして、比較的低い解像度で画面に表示されるように設計されたモバイルデバイス用のWebアプリケーションのバージョンを使用できます。 これは、そのようなアプリケーションをポートレットに表示するのに理想的です（例えば、モバイル版のOdnoklassnikiソーシャルネットワークアプリケーションやATO.BYジオサービス ）。
10. 特定のAPIの欠如。 結果として、より安価で手頃な熟練労働者（これは管理者または建築家にとってより興味深い）。

上記で挙げたすべてのことは、最終的にはソフトウェアの作成が安くなり、メンテナンスの固定費が安くなることを意味します。 これはすべて、基本的にajax4allライブラリを使用して実現されます。 彼女はAjaxポータルの中心です。



ajax4allライブラリを作成するとき、画像、スタイル、およびスクリプトへのすべての相対リンクを絶対リンクに変換する必要に直面しました。 それ以外の場合、ポータルページにアクセスすると、各相対リンクの実際のアドレスが、ポータルページのアドレスを基準にしてブラウザによって計算され始めました。 唯一の深刻な問題は、JavaScriptコードで「配線された」相対アドレスです。 この場合の解決策は、Webアプリケーションを適合させることだけです（ポートレットとして使用されることになっているWebアプリケーションのベストプラクティスを紹介します）。



ajax4allライブラリを作成する2番目のタスクは、通常のハイパーテキストリンクをAjax要求呼び出しに変換し、続いてポートレットウィンドウのコンテンツを置き換えることでした。



ほとんどのWebアプリケーションは、まだHTMLフォームを使用しています。 ポートレットとして使用されるWebアプリケーションのコンテンツを単に「分離」して、ポートレットページに貼り付けるだけでは不十分であることが判明しました。 HTMLフォームの相対リンクも変更する必要がありました。 次に、フォーム自体の機能をどうするかという疑問が生じました。 –送信ボタンまたはJavaScriptを使用してHTMLフォームを送信すると、通常、ポートレットウィンドウのコンテンツをリロードする代わりに、すべてのポータルページがリロードされます。



事実上の標準となったAjax Submitパターンを使用することで解決策が見つかりました。 このパターンの本質は、通常の送信HTMLフォームをAjaxを使用したリクエストに置き換えてから、標準のサーバーレスポンスを受信し、それを変換して、ポートレットウィンドウ内のポータルページに挿入することです。 簡単に聞こえますが、許容可能なアーキテクチャソリューションを見つけるには数か月かかりました。 タスクの複雑さは、ブラウザーのDOMモデルの大きな違いでした。 さらに、JavaScriptを記述するときの最も不機嫌なブラウザーは、通常信じられているように、SafariではなくInternet Explorerであることが判明しました。



最初は、クライアント側（JavaScriptを使用するブラウザー）とサーバー側（ポータルサーバー）の古典的なアプローチの両方のタイプの集約をサポートするつもりでした。 慣例により、従来のWebアプリケーションを使用するアプローチは非常に優れており、サーバー側の集約をサポートするブランチは廃止されました。 たぶん私は彼女に戻りますが、後で...



従来のJava Portlet API（JSR-168およびJSR-286標準と100％互換）を失ったことで、私は主なことを達成しました。AjaxPortalはHTML、CSS、およびJavaScriptに基づいて構築されています。 これは、ポータルのサーバー部分のプラットフォーム（プログラミング言語を含む）に依存しないことを意味します。 その結果、Ajax Portalはクロスプラットフォームソリューションと見なすことができます。 Java Webアプリケーションの開発は、JSPタグライブラリを介してサポートされていました。 ライブラリが安定し、新しいタグ属性が表示されなくなると、JSFコンポーネントライブラリを作成できるようになります。 今年（2011年）の6月に、.NETのライブラリを作成した.NET開発者が参加しました。 PHPバージョンの登場により、Ajax Portalは絶対にクロスプラットフォームのソリューションであると誇らしげに宣言することが可能になります。 Perl用のライブラリを作成するというアイデアがありますが、これは遠い見通しです。



JavaのPortlet APIの代替として、プロジェクトはMicroServlet Java MVCフレームワークを提供する場合があります。 これはJavaに関する私の本の例であり、1つのクラス（HttpServletに基づく）に基づいて文字通り本格的なWebアプリケーションを構築できます。 このフレームワークは、BeanフォームとJSPページをサポートしています。 広く使用されているJavaアノテーション。 これは、1つまたは2つのメソッドのみを持つことができるポートレットを作成するための完璧なソリューションです。 ユーザーは、「彼になろうとなかろうと」と答えます。 私はそれが好きです。 MicroServletフレームワークは、Spring MVCにますます近づいています。 これが良いか悪いかはまだわかりません。 最新のトレンドは、MicroServletフレームワークに基づいた新しいPortlet APIです。 ユーザーにとって都合が良いかどうかがわかります。



多くの場合、ポータルソリューションはCMSに関連付けられています。 CMSの独自の実装を作成することは絶対にお勧めできません。 多くのスタートアップがすでに混雑しているニッチを占有しようとしています。 商用および無料のオープンソースの両方の十分なソリューションがあります。 一方、Ajax Portalのアーキテクチャを使用すると、機能を制限したCMSとしてポータルを使用できます。 これについては別の記事を書く必要があると思います。



私は別の興味深い事実に出会いました-実際のアプリケーションを作成するとき、潜在的な顧客は企業ですでに使用されている承認および認証システムに開発を使用したいです。 したがって、セキュリティモジュールの実装に関する質問はまだ公開されていません。



Ajax Portalの各バージョンは、ajax4allライブラリとMicroServletフレームワークに基づくPortlet APIに加えて、いくつかの革新をもたらします。 バージョン1.0の場合、*、このような革新は、領域（ポータルページのポートレットコンテナ）の動的な変換です。 状態パターンが適用されました。 変換はCSSを使用して行われます。 CSSマーカーはマーカーとして使用されます。 HTML / XHTMLコードの同じ構造で、マーカーに応じて、リージョンとポートレットの表現が変わります。 領域は、標準ビュー（各ポートレットは小さなウィンドウに表示されます）からアコーディオンまたはブックマークシステムに変換できます。 さらに、ポーレットを強調せずに、領域全体を単一のウィンドウとして表示することもできます。 また、ポートレットとリージョンの全面的な装飾がないビューもあります。



過去数年にわたって、多くの企業がポータルソリューション市場を去りました。 多くのスタートアップやオープンソースソリューションは放棄されています。 私の意見では、主な理由は、JSR-286標準がAjaxテクノロジーの可能性を実現できなかったことです。 Ajaxの導入後にリリースされたJSR-286標準は、実際にはJSR-168の機能を拡張しただけで、新しいものは何ももたらしませんでした。 ajax4allライブラリーが解決するように設計されているのは、これらの問題です。



最新のファッショントレンドは、ポータルソリューションのマッシュアップへのスムーズな移行です。 これは別の記事のトピックだと思います。 Ajax Portalは、エンタープライズポータルとマッシュアップの間のニッチにあります。 その結果、カスタマイズとパーソナライズをサポートする、クロスブラウザのクロスプラットフォームWeb 2.0ポータル/マッシュアップが作成されます。



スタートアップにとっての主な質問は、その類似物です。 私は長い間検索してよく検索しましたが、まだ見つかりませんでした。 この記事の読者がそれらを知っていれば、私にそれらを示したら私は非常に感謝します。 次のことに注意してください。

1. HTML IFrameタグの代替とそれをAjaxリクエストに置き換えることについて、
2. 特別な準備（オフライン）なしで標準WebアプリケーションのAjax Submitパターンを実装します。

そして、通常生じる2番目の質問と、なぜこれが以前に行われなかったのか？ -以前は、現在のドメインの外部にAjaxリクエストを送信する機能を指定する「 クロスオリジンリソース共有 」標準はありませんでした。 リモートポートレット用のAjaxポータルもプロキシをサポートしています。



私はiGoogleを含む多くの一般的なソリューションを「分析」し、それらすべてが基本的にIFrame HTMLタグを使用していることを発見しました。 したがって、ajax4allライブラリは、リモートポートレット用のHTML IFrameタグで知っている唯一の選択肢です。 Ajaxポータルでajax4allを使用する場合、選択した領域をコンテンツで自然に塗りつぶし、それに比例して垂直方向に引き伸ばすことが可能になります。これは、HTML IFrameタグでは実現できません。



継続：

http://habrahabr.ru/blogs/AJAX/125568/