17

リバースAJAXがDWR2でいかに簡単に使用できるかを示すIBMによるデモがあります。一方、Scala/LIFTにはリバースAJAX機能が組み込まれています。

  1. 質問：これがSpring MVCで正常に機能する場合、何か経験はありますか？

  2. 質問：最初から始める場合、DWR / SpringMVCよりもScala/LIFTを優先することの長所と短所は何ですか？

  3. 質問：Scala / LIFTでは、セキュリティ処理はSpring Securityと同じくらい洗練されていますか？

4

3 に答える 3

11

Novell がさまざまなテクノロジを評価した後、Pulse 製品を強化するために Lift の Comet Architecture を選択しました。

Lift の Comet 実装は、単一の HTTP 接続を使用して、ページ上の任意の数のコンポーネントへの変更をポーリングします。各コンポーネントにはバージョン番号があります。ロング ポールには、バージョン番号とコンポーネント GUID が含まれます。サーバー側では、長いポーリング要求にリストされているすべての GUID にリスナーがアタッチされます。いずれかのコンポーネントのバージョン番号がより高い場合 (またはロング ポーリングの期間中にバージョン番号が増加した場合)、デルタ (各バージョンからの変更を記述する JavaScript のセット) がクライアントに送信されます。差分が適用され、クライアントのバージョン番号が変更セットの最大のバージョン番号に設定されます。

Lift はロング・ポーリングをセッション管理と統合しているため、ロング・ポーリング中に接続枯渇の原因となるリクエストが同じ URL に着信した場合、ロング・ポーリングは接続枯渇を回避するために終了します (一部のブラウザーでは、名前付きサーバーごとに最大 2 つの HTTP 接続があり、他のものは最大 6 です)。Lift は、ブラウザーの各タブが異なる DNS ワイルドカード サーバーに対してロング ポーリングを実行できるように、ロング ポーリング リクエスト用の DNS ワイルドカード サーバーもサポートします。これにより、接続不足の問題が回避されます。

Lift は、サーブレットが Jetty 6 & 7 および (間もなく) Glassfish で実行されているコンテナーを動的に検出します。Lift はプラットフォームの「継続」実装を使用して、長いポーリング中にスレッドを使用しないようにします。

Lift の JavaScript は、jQuery および YUI の上に置くことができます (また、Prototype/Scriptaculous 上にも置くことができます)。実際のポーリング コードには、接続障害のバックオフや、一時的な接続障害を処理するその他の「適切な」方法が含まれます。

Atmosphere、CometD、Akka (すべて JVM 指向の Comet テクノロジ) を見てきました。ページごとに複数のコンポーネントをサポートしたり、接続不足を回避したりするものはありませんでした (私が評価した時点では)。

Novell はゼロから始めて、Lift to power Pulse を選択しましたが、それにはいくつかの非常に正当な理由があります。

セキュリティに関しては、Lift は Spring + Spring Security を完全に打ち負かしています。http://www.mail-archive.com/liftweb@googlegroups.com/msg13020.htmlを参照してください。

基本的に、Lift のセキュリティはアプリケーションに組み込まれています。Lift アプリは、デフォルトで、一般的な問題 (クロス サイト スクリプティング、リプレイ攻撃、クロス サイト リクエスト フォージェリ) に対して耐性があります。Lift アプリは、デフォルトでパラメーターの改ざんに対して耐性があります。Lift のサイトマップは、サイトのナビゲーションとアクセス制御のルールを定義します。これは、誰かがクリックできないリンクがないことを意味します。アプリとは別に構成する必要がある外部フィルター (Spring Security など) は必要ありません (おっと... ページを移動しましたが、Spring Security XML ファイルが更新されていることを確認するのを忘れていました)。

ああ...テンプレート言語を使用したくない場合は、完全な Lift Comet チャット コンポーネントを次に示します。

class Chat extends CometActor with CometListener {
  private var msgs: List[String] = Nil

  def registerWith = ChatServer

  override def lowPriority = {
    case m: List[String] => msgs = m; reRender(false)
  }

  def render = {
    <div>
    <ul>
    {
      msgs.reverse.map(m => <li>{m}</li>)
    }
    </ul>
    <lift:form>
    {
      SHtml.text("", s => ChatServer ! s)
    }
    <input type="submit" value="Chat"/>
    </lift:form>
    </div>
  }
}

これをページに挿入するには:<lift:comet type="Chat"/>

于 2010-06-28T22:35:27.020 に答える
2
  1. 私の見解では、Spring MVC は AJAXed/COMETed RIA を構築するための非常に悪い選択です。HTML フォームで動作し、ページ全体を一度にレンダリングすることを目的とした ModelAndView コンポーネント、タグ ライブラリ、検証ルーチンはすべて、JSP とテンプレートに基づく昔ながらの開発に適しています。私にとって、AJAX/COMET を Spring MVC にプラグインすることは、常にハックのようなものです。ただし、@MVC (JSON を JavaScript UI と交換する) を使用して RESTful サービスを構築する場合は、うまくいく可能性があります (ただし、これらの問題については、Jersey/JAXB を使用することをお勧めします)。
  2. LIFT はもともと COMET と連携するように設計されているため、より適切な選択となります。LIFT よりもはるかに軽量でテンプレートのないものを選択しますが (私に関しては、Spring MVC と同じ病気に苦しんでいます)。

  3. どちらのセキュリティ システムも基本的なシナリオのみをカバーしており、実際のプロジェクトで使用するには多くのカスタマイズが必要です。

    これは、Scala で COMETed RIA を構築するために使用するものです。

    • Jersey (HTTP/JSON を介して JS UI と通信するための軽量な RESTful サービス) + Atmosphere (COMETed アプリケーションを構築するためのスケーラブルなソリューション) + 任意の JS フレームワーク (jquery、YUI、ext js など)。また、Jersey と Atmosphere の両方に統合されており、慣用的な Scala で RIA Web アプリを構築できるAkka Frameworkも参照してください。Akkaでのpub-sub COMET の例を次に示します。
    • Vaadin + ICEPush . JS で手を汚したくない場合は、非常に快適な組み合わせになります (ただし、ICEpush はまだエンタープライズ対応のソリューションではありません)。
于 2010-06-24T08:26:19.430 に答える
0

純粋な Java (または Scala を含む他の JVM 言語) 中心のもう 1 つの代替手段は、ItsNat Cometです。

于 2011-01-17T14:22:51.963 に答える