2つの異なるサーバー上で2つの異なる言語でWebサービスとWebサイトを開発することは良い習慣ですか?たとえば、今、同じサーバーで実行されているGlassfishとRubyonRailsプレゼンテーション層で実行されているJavaWebサービスを作成しています。
同じサーバーにWebサービスを残したいのですが、Passengerで実行されているRuby1.9を使用します。
それは良い考えですか?私はウェブアプリのアーキテクチャの経験がありません。
2つの異なるサーバー上で2つの異なる言語でWebサービスとWebサイトを開発することは良い習慣ですか?たとえば、今、同じサーバーで実行されているGlassfishとRubyonRailsプレゼンテーション層で実行されているJavaWebサービスを作成しています。
同じサーバーにWebサービスを残したいのですが、Passengerで実行されているRuby1.9を使用します。
それは良い考えですか?私はウェブアプリのアーキテクチャの経験がありません。
システムのアーキテクチャに関しては、はい、これは「良い習慣」です。良いとは、それが目標を達成し、害を及ぼさず、関心の分離を強制することを意味します。
私は、同様の構造を持つアーキテクチャで開発を行ってきました。ユーザー インターフェイスは .NET で、Java Web サービスを使用します。その Web サービスは、永続メディア、サード パーティ コンポーネントなどとのすべての対話を担当します。
どのシステムでも、ユーザー インターフェイス ロジックをビジネス ロジックから抽象化するように作業する必要があります。それはちょうど良い関心の分離です。Web サービスを使用してそれを行うことは、その目標を達成するための1 つの方法にすぎません。システムの他のユース ケースでこれらのビジネス サービスを再利用する場合に備えて、Web サービスを使用することをお勧めします。
もう一つ; 過去 8 年間、UI と WS で 2 つの異なるテクノロジを使用した後、ほとんどの課題は技術的なものではなく、組織的なものであることがわかりました。たとえば、アプリを維持するために必要な両方のスキルを備えた新しい開発者を見つけるのは困難です。いずれかの専門家を見つけて、もう一方のテクノロジーについてトレーニングする必要があります。
それはそれらがどれほど似ているかによって異なります。
Web サービスが基本的に Web サイトの機能を反映している場合、既存のコードを再利用して同じサーバー上で同じものにすることは非常に理にかなっています。
注 - これは、ビューがビジネス ロジックから分離されているため、階層を絡ませることと同じではありません。
Ruby-on-Rails の観点から見ると、「Web サービス」と「Web サイト」は、ビュー テンプレート (Web サイトの html、Web サービスの xml) のみが異なるだけで、まったく同じコードであるため、しばしば交換可能です。 . 最初から RESTful アーキテクチャを念頭に置いて構築すれば、重複を最小限に抑え、すべてのアプリケーション レイヤーを適切に分離してこれを実現できます。
技術的には、はい、間違いなくそれを行うことができます。これは、WS を使用する利点の 1 つです。それらは相互運用可能です。
ただし、他の誰かがそれを維持し、2 つのプラットフォーム (RoR または Java) のうちの 1 つだけの専門知識を持っている場合、私はその考えを考慮します。いつでも尋ねるのが最善です:-)
XML を使用して生成するコントラクト ファースト Web サービスを作成すると、適切な形式で HTTP GET または POST 要求を作成できる任意のクライアントと通信できます。SOAP か REST かは関係ありません。
XSD で始まる Java/Spring Web サービスを作成しました。Yahoo UI RIA クライアントが WSDL を取得し、HTTP POST を作成して要求ドキュメントを送信し、XML 応答を適切なデータ グリッドに表示しました。