コミュニティに役立つことを期待して、いくつかの情報を共有するだけです。
さまざまなブラウザーがプラグインのサポートを停止したため、アプレットの使いやすさが低下しました。Google は NPAPI プラグインのサポートを中止することを決定しました。EDGE はプラグインをサポートしていません。Firefox もプラグインの使用を推奨していません。Mozilla はこのスイートに従う可能性があります。
私たちが開発したアプリケーションの 1 つは、次の理由でアプレットを使用する必要がありました。
- コンピューティング デバイスに接続されたポートおよび周辺機器にアクセスする機能
- Web アプリケーションとの情報交換機能 (JavaScript 経由)
- インストールとメンテナンスにシステム管理者が関与しない
- アプリケーションはブラウザ内から起動する必要がありました
前述の状況により、私たちは Java Web Start (JWS) テクノロジをアプレットの潜在的な代替手段と考えるようになりました。しかし、JWS は Web アプリケーションと通信できないため、独自の一連の課題に直面しました。
用意したソリューション (アプレット) は、Web アプリケーションから一意の識別子を取得します。シリアル ポート経由でデータを読み取ります。そして、以前に受け取った一意の識別子とともにデータを Web サーバーに送信します。ユーザー コミュニティは典型的な B2C ユーザー コミュニティと同じくらい大きいため、スタンドアロン アプリケーションを書き直すという選択肢はありませんでした。このような大規模なコミュニティにアプリケーションのさまざまな使い方を教育するには、多くの労力とサポート スタッフが必要でした。新しいアプリケーションの開発には、製品ライフ サイクルの観点からも多大な労力が必要でした。
JWS の適応には、アプレット用に開発されたコードを再利用できるという利点がありました。ただし、アプレットと Web アプリケーションの間でアプレットと JavaScript のブリッジを使用して情報を交換するオプションは、JWS では利用できませんでした。
これが私たちがJWSを適応させた方法です
ユーザーは、JWS アプリケーションの起動に必要な詳細を含む JNLP ファイルを参照する Web ページにアクセスします。
Web アプリケーションは、JNLP ファイルを介して JWS アプリケーションに一意の識別子を提供します。
この時点で、Web アプリケーションはロング ポーリング/リバース AJAX を開始します。Web アプリケーションを介してエンド ユーザーに成功/失敗の結果を通知する必要があったため、これが必要でした。
シリアル ポートから情報を読み取った後、JWS アプリケーションは HTTP POST を実行し、パラメーターとして UID と共に読み取り値を送信します。
サーバーは結果を保存し、長いポーリング/リバース AJAX 呼び出しを終了します。操作のステータスを Web アプリケーションに通知する
シュリダール