3

C# から相互運用できるように、いくつかの Java Web サービスを公開しようとしています (このSO の質問を参照してください)。以下の概念実証コードは、WCF でうまく機能します。

私の質問は、javax.xml.ws.Endpoint私のサービスを公開するためのクラスの使用についてです:

  1. 本格的なアプリケーション サーバーではなく、この方法を使用することで何を失うのでしょうか?
  2. これは、通話量が少なく長時間実行されるサービスに適したソリューションですか?

以下は WSDL を生成し、.Net からきれいに呼び出すことができ、適切に実行されます。 なぜ私はそれを使用しないのですか？

@javax.jws.WebService
public class TestSvc { 
    @javax.jws.WebMethod()
    public String sayHello() {
        return "Hello!";
    }
}

import javax.xml.ws.Endpoint;
public class Main  {
    public static void main(String[] args) throws Exception {
        Endpoint.publish("http://localhost:8181/Test", new TestSvc());
    }
}
4

2 に答える 2

4

多くの場合、スケーラビリティの引数 (スレッド プールなど) は非常に強力ですが、既にそれらを割り引いています。

次に信頼性。一部のアプリケーション サーバーには優れたクラスタリング機能があり、新しいインスタンスを非常に簡単に追加できるため、統合された管理ビューを有効にしながらフォールト トレランスを有効にできます。

一般に、サービスの数が増えるにつれて、管理が容易になることは非常に便利です。

セキュリティ インフラストラクチャと宣言型セキュリティ モデルは非常に重要です。

私にとって、Java EE プログラミング モデル全体は、ビジネス ロジックが自明でなくなったときに持つ価値があります。これで、EJB v Spring v ... の議論全体に入ることができました。しかし、私が言いたい一般的なポイントは、ビジネス ロジックがより深刻になるにつれて、スレッド管理、永続性、接続プーリング、メッセージング、キャッシング、スケジューリングなどの機能が必要になるということです。アプリサーバーで見つけたもの。その中には、EJB3+JPA または Spring で自然に導入されるものもあれば、App Server の自然なアドオンとして導入されるものもあります。本格的なエンタープライズ規模の Java 開発を行う見込みがある場合は、将来に備えて拡張可能な基盤を構築するために、もう少し複雑なものを受け入れる方がよいかもしれません。

于 2009-11-10T20:32:25.483 に答える
2

一般に、アプリケーション サーバーの利点が失われるだけでなく、アプリケーション サーバーを使用すると、サービスを管理およびテストする機能が失われる可能性があります。

相互運用側では、Java 呼び出しなしでは WSDL を抽出できません。新しいサービスが公開されたときに何かを実行した場合は、それを考慮して設計する必要がある場合があります。WCF などを使用して WSDL を使用する予定の場合、サービス クライアントを生成するときに回避する必要がある VS 側の癖がいくつかあります (この癖は世代ごとに発生するわけではありませんが、ときどき発生します)。時間。）

長時間実行されるサービス (つまり、無期限に実行されることが期待されるサービスを意味すると思います) は、プロセスとして管理する必要があります。設計と要件に応じて、プロセスの開始と停止、一時停止などを検討する必要があります。

于 2009-11-10T20:43:16.093 に答える