4

私の会社は大手電気通信会社のソフトウェア ソリューション プロバイダーです。この環境は現在、EJB サービスを提供するバックエンド WebSphere Application Server のクラスターと通信するフロントエンド IBM Portal サーバーを備えた IBM WebSphere ベースです。一部のポートレットは独自の MVC パターンを使用し、一部は JSF で記述されています。

最近、バックエンド サーバー上の EJB と直接通信するリッチ/シック クライアント アプリケーションの概念実証を行いました。NetBeans プラットフォームを使用して作成され、WebSphere アプリケーション クライアント ライブラリを使用して EJB との通信を確立します。

本当に苦労したのは、クライアントに安全な JAAS/SSL 通信を使用させることでした。しかし、それが解決された後、リッチ クライアントには、慣れ親しんだ Web ベースのポータル クライアント アプリケーションよりも多くの利点があることがわかりました。

  • 非常に優れたパフォーマンス (CORBA と HTTP の比較、Portal Server の仲介者を排除)
  • NetBeans のビジュアル デザイナーと Swing の一般的に堅牢なアーキテクチャを使用することで、開発が簡素化され、高速化されます。
  • クライアント アプリケーションをテスト サーバーにデプロイする必要がないため、デバッグ サイクルが短縮されます。
  • Web ベースの開発のような技術の寄せ集め (Struts、JSF、JQuery、HTML、JSTL など) はありません。

しばらくの間、Web ベースの開発 (JSF でさえも) の苦痛に耐えた後、私は次の結論に達しました。その場合、NetBeans Platform や Eclipse RCP を考慮しないのはおかしいでしょう。

リッチ クライアントと Web クライアントに関するコメントや経験はありますか?

4

2 に答える 2

3

利点の 1 つは、多くの計算/検証をクライアント側で実行できることです。これにより、各クライアントがアプリケーション全体の処理負荷を共有できるようになります。

シック クライアントのもう 1 つの利点は、クライアントで状態を保持できることです。これにより、サーバーがステートレスになり、スケーリングが大幅に向上するだけでなく、フォールト トレランスが容易になります。

私たちの場合、アプリにハードウェアへのインターフェイスがあり、スキャナーはワークステーションへのシリアル ポートにあります。また、アプリケーションから印刷ジョブのアプリケーション制御ができるように、プリンターに JNI レイヤーを実装しました。（請求書印刷）

新しいソフトウェアの起動と配布のために、ローカル システムのファイルをサーバーに展開された日付と照合して、ローカル システムが最新かどうかを確認する更新 jar を実行します。システムが古い場合は、必要な jar ファイルをダウンロードしてからアプリを起動します。これにより、ユーザーは Web ページに移動する必要がなくなります。

また、新しい Java EE に関連するサーバー サイド パターンについても、この本をお勧めします。

于 2010-04-29T13:36:25.833 に答える
1

デプロイメントに Java Web Start を使用している限り、私は必ずしも同意しません。IT における Web アプリケーションのポイントは、バージョン X がサポートされなくなったときに、全員をバージョン Y に更新しようとするリモート展開の混乱を避けることです。

これは、webapps を使用して無料で入手できます。

于 2010-04-29T13:36:04.427 に答える