そのようなプロジェクトを構築する実際の経験を持っている人はいますか?「いいアイデアかどうか」という質問は避けたいのですが、考えられる解決策に焦点を当てます。1つの簡単な方法(HTTP GET / POST + xml / json)ともう1つのエレガントな方法(AJAX / DWR)がわかります。最初のものに関しては-私はそれが可能であることを理解していますが、かなり多くのコーディングが必要です。2番目の方法として-PHPフロントエンドでJavaDWRエンジンを使用することは可能ですか?DWRはクライアント側で言語に依存しませんか(JavaScriptのみを使用するため)?
クライアントページが1つのWebサーバー(たとえば、apache + php)によって生成され、別のサーバー側(たとえば、tomcat)によって提供されるというのは問題でしょうか?Tomcatがセッションについて文句を言うのではないかと思います。この問題は、クロスドメインAJAXを許可することで修正できますか?
前もって感謝します。
デニス。
3 に答える
JavaとPHPはどちらもサーバーサイドテクノロジーです。「フロントエンド」は、HTML、CSS、およびJavaScriptを使用して記述されますが、フロントエンドの一部をレンダリングするためにPHP(またはJSP)テンプレートを使用することもできます。
PHPを「フロントエンド」として使用している場合は、PHPをプロキシとして機能させ、JavaWebサーバーにリクエストを返す必要があります。
「ビジネスロジック」がJavaで記述されているときに、PHPを使用してWebページをアセンブルしたい場合は、PHP / Java Bridge(LGPLおよびMITライセンス)を使用することをお勧めします。
私はJavaの「バックエンド」とmod_perlの「フロントエンド」を使用するプロジェクトに取り組んできました。否定論者にとって、これはJavaがサービス/ API機能を提供しているためです。HTML、WAP、SMTP、SOAPなどのUIの処理には関与せず、関与すべきではありません。
歴史的な理由から、mod_perlはXML-RPCについて話します。この段階でお勧めするルートではありません。Java、Perl、およびPHPは、エンコード/デコードのオーバーヘッドが低いため、はるかに多くのJSONタイプのトランザクションを非常にうまく処理できます。また、mod_perl(PHPではありません)環境では、永続的な接続を介してJSON-RPCを簡単に実行できるため、オーバーヘッドがさらに削減されます。
このアプローチには、さまざまなUIへの個別のアップグレード、サービスレイヤーの安定性、各レイヤーの個別の責任など、多くの利点があります。
欠点には、サービスの改善を実現するための遅延、より複雑な開発、ステージングおよびテスト環境、新しい開発者の参入障壁の高さ、ドキュメントと管理の増加などがあります。
「Javaフロントツーバック」の人にとって、これはOSGiコンテナーを使用するのと同様のタイプのアプローチであり、より多くのドメインに適した言語のみを使用します。ヘビーリフティング用のJava、より流動的なテキストベースのインターフェイス用のスクリプト。