このアーキテクチャが良いアイデアか悪いアイデアかについて、SOディスカッションにはすでにいくつかの投稿があります。既存のプログラミングの才能を含む社内の多くの理由から、バックエンドにJavaを使用し、フロントエンドにPHPを使用することにしました。私たちの目的は...
Java-モデル/コントローラー
PHP-ビュー
GlassfishとApache間の相互作用のプロトタイプの作成に取り組んでいます。現在取り組んでいることの1つは、ユーザーがhttp://domain.com/login.htmlにアクセスしてログインすると、そのログインがのような場所にあるGlassfishコントローラーに送信されること/login.javaです。問題はありません。問題は、そのURLでビューをレンダリングすることです。
PHPやその他のテクノロジーでこれを行っている人はいますか？
JavaでSOAP/RESTサーバーをセットアップし、PHPにそれと通信させることを検討しましたか？それはあなたが達成しようとしていることよりもはるかに簡単だと思います。
申し訳ありませんが、これらの言語の1つだけに固執する方がはるかに簡単になるようです。PHPを使用してビューにロジックを追加している場合は、Velocityを確認する価値があるかもしれません。これにより、変数へのアクセスと作成、リストの反復、条件の使用、マクロの定義、メソッド呼び出しの実行などが可能になります。これにより、状況が大幅に改善される可能性があります。ただし、通常は、テンプレートにできるだけ多くのロジックを含めないようにすることをお勧めします。
PHPを使用したい場合は、それが必要なため、Webサービスを使用して通信することを検討することをお勧めします。GoogleのGSONライブラリをご覧ください。これは、JSONオブジェクトをモデルに（およびその逆に）マッピングするための（Java側の）本当に優れたツールです。
フロントエンドでは、 Backboneを確認する価値があるかもしれません。これは、モデルオブジェクトをモックアップしてイベントをオブジェクトにバインドしたり、フィールドに直接結び付けたりするのを簡単にするツールです。
私は、JavaサービスレイヤーとPHPクライアントレイヤーテクノロジースタックを使用している2つの会社で直接経験しましたが、それは排他的に使用されていませんでした。レイヤーを明確に分離するために、明確に定義されたJSON REST APIが構築され、各レイヤーにコーディング可能なコントラクトが作成されました。
Javaレイヤーは、永続レイヤーの間にSpringMVCを使用して、PHPレイヤーからリソースへのルート（つまりURL構造）が明確に定義されたJSONビューを生成しました。GET/PUT/POST/DELETE
特にログインの問題に関しては、実際には2つのJavaサービスがありました。1つはログイン/ログアウト専用で、もう1つは通常のバックエンド用です。
私が訪問/loginするとき、私は.phpファイルであると思います。<form>「ログイン」サービスにログインを送信すると、セッションCookieが追加されましたが、暗号化された「ユーザーID」Cookieも追加されました。暗号化されたCookieを使用して、製品のJavaサービス層へのアクセスを保護できます。PHPからJavaへの各RESTリクエストはCookieにアクセスでき、Javaレイヤーは「ユーザーID」を復号化して、有効な場合はPHPREST呼び出しに応答できます。その後、Javaレイヤーは、永続ストアからユーザー固有のデータを返すために、実際のユーザーIDにアクセスできます。