問題タブ [soa]

過去数か月から、最新のドット ネット フレームワークのプロジェクトに取り組んでいます。

最新のドット ネット バージョンでは、コンポーネントよりも「サービス」が推奨されているように感じます。あれは正しいですか？

私はシルバー ライトで見てきました (私はシルバー ライトの初心者です) すべての DB レイヤー操作がサービスとして公開されています。今はわからない コンポーネントプログラムもあるの？

利点は何ですか？すべてのレイヤーが DLL ではなくサービスとして公開されている場合、パフォーマンスはどうなりますか?

このテーマについて、どこからこの概念を正しく理解し始めるべきかを理解してください。

ありがとう

SC

私は現在、かなり大きなJava 6アプリケーションに取り組んでおり、機能の一部をサービス指向アーキテクチャーに分割しようとしています。

アプリケーションスペースの主要なSOAフレームワークはOSGiのようで、私はFelixとKnopplerfishを調べてきましたが、これが私の唯一の選択肢ではないことを確認したかったのです。

Webアプリを構築していなくても、SOAPなどのアプリケーションに実際のWebサービスプロトコルを使用することは理にかなっていますか？これも受け入れられますか？

デスクトップアプリケーションでOSGi（Felixなど）の実装を使用したことがありますか？もしそうなら、それはどうでしたか？もっと良いことを知っていますか？

私たちは皆、ここでSOAにかなり慣れていないので、どんな助けでも大歓迎です。

何年にもわたって何度か見た状況に対処するためのパターンまたはベスト プラクティスに関するフィードバック/考えを求めていますが、希望どおりに対処する解決策は見つかりませんでした。

これが背景です。

会社には、互いに密接に関連する 3 つの個別の「事業部門」をサポートする 3 つのアプリケーションがあります。アプリケーションのうちの 2 つは、文字通りオリジナルからのコピー/ペーストです。アプリケーションは、さまざまな速度で成長し、わずかに異なる機能を備えている必要があります。機能の主な違いは、データ入力フィールドにあります。相違点は、基本的に次のいずれかのカテゴリに分類されます。

1. 一方のインスタンスには、もう一方のインスタンスにはないいくつかのフィールドがあります。
2. 文字列フィールドの最大長は、あるインスタンスでは 200 ですが、別のインスタンスでは 50 です。
3. ルックアップ/参照フィールドには異なる基礎となる値があります (つまり、同じテーブル構造ですが、異なるデータベースからのものです)。
4. フィールドは、あるインスタンスではユーザー提供の自由テキスト、値として定義されますが、別のインスタンスではルックアップ/参照として定義されます。

問題は、これら 3 つの個別のアプリケーションからのデータを消費する必要がある企業内の他のアプリケーションがあることですが、理想的には、コア/集中型の方法で (つまり、3 つの個別のサービスではなく中央のサービスを介して) それらと通信します。私の質問は、特に上記の項目 D をどのように処理するかです。「最小公分母」アプローチが唯一の方法かもしれないと考えています。例えば：

これに関する他の考え/アイデアはありますか？

ティア！

友達、

次のオープンソース プロジェクトについて考えるのに役立つ情報を求めています。私には 2 つのアイデアがあり、どちらかをやりたいと思っています。おそらく、好みの問題として、Java を主要言語として使用します。私が特に知りたいのは、作業を重複させないように、どちらかがすでに行われているかどうか、そして、それがあなたが行った作業に役立つと思うかどうかです.

1 つ目は、UDDI に代わる SOA ディレクトリ サービスです。90 年代半ばにミドルウェア/SOA フレームワークの実装を支援するために働いたとき、私たちが構築した要素の 1 つはディレクトリ サービスでした。現在の UDDI が提供するメタデータ ストレージ機能は提供されませんでしたが、UDDI よりもいくつかの利点がありました。シンプルでした。サービスの登録、ルックアップなどは簡単でした。非常に高速でした。サービスはリース メカニズムを使用して登録されているため、一致するサービス インスタンスのリストを取得でき、インスタンスがまだ稼働している可能性が高いことがわかります。次に、複製されました。確かに、多くの UDDI 実装はレプリケーションをサポートしています。私がやりたくないことは、別の UDDI 実装を作成することではなく、代わりのディレクトリ サービスを構築することです。これは、1990 年代に私たちが行ったことに似ており、今日のフレームワークのニーズと一致していますが、より軽量です。私の考えでは、UDDI は、ほとんどの企業が必要とするよりもはるかに重いソリューションであり、既存のフレームワークとうまく統合されていれば、よりシンプルなソリューションが魅力的である可能性があります。つまり、UDDI の代替として選択しやすいということです。

2 つ目の可能性は、データ フェデレーション システムのオープンソース実装を行うことです。使用されたことのないクライアント用に作成しましたが、そこにはいくつかの良いアイデアがありました. 便利な機能がいくつかあるので、オープンソース プロジェクトとしてもう一度やりたいと思います。基本的に、ユーザーはドキュメントをマスター ノードに公開してから、ドキュメントを地域サーバーに複製できます。つまり、組織内で使用される場所の近くにデータをプッシュできます。たとえば、ドキュメントが組織のヨーロッパ地域に関連するものとしてフラグ付けされている場合、ドキュメントはその地域のサーバーにプッシュされ、近隣地域のバックアップ サーバーにプッシュされます。その地域のユーザーは、必要に応じてドキュメントに注釈を付け、それらを元の作成者にプッシュして検討してもらうことができます。このようなフェデレーション システムは、モノリシックなドキュメント サーバーを使用する場合と比較して、可用性とパフォーマンスの点でメリットがあります。ユーザーが自分の地域に保存されていないドキュメントを必要とする場合、システムはマスター サーバーまたは別の地域サーバーに戻って取得します。追加機能として、元のシステムは、外部ソースからデータを取得できるプラグインをサポートしていました。これを含めると便利な場合があります。

サービスの参照データに使用する「最適な」パターンに関するフィードバック/オプション/コメントを求める。

参照データとはどういう意味ですか?

例として Northwind を使用してみましょう。Order は、データベース内の Customer に関連付けられています。注文サービスを実装するとき、注文から「完全な」顧客を参照する必要がある場合と、顧客 (キー/値のペアなど) への参照だけが必要な場合があります。

たとえば、GetAllOrders() を実行している場合、完全に入力された Order を返すのではなく、各注文の Customer の参照データのみを含む軽量バージョンの Order を返す必要があります。ただし、GetOrder() メソッドを実行した場合は、このメソッドのコンシューマーが必要とする可能性があるため、顧客の詳細を入力したいと思うでしょう。特定のメソッド呼び出し中に顧客の詳細を入力するように依頼したいが、他の状況では省略したい状況が他にもあるかもしれません。

これが私が思いついたものです：

ここでの考え方は、CustomerDTO では ReferenceInfo (一般的なキーと値のペア) が常に必要であるため、常に ReferenceInfo を保持するということです。後で必要に応じて顧客の詳細を取得するのに十分な情報が得られます。CustomerDTO に ReferenceInfo を要求することの欠点は、完全な CustomerDTO (つまり、CustomerInfo が入力された状態) を取得するときにやり過ぎになる可能性があることですが、少なくとも参照情報は保証されます。

このシナリオ/実装を「よりクリーン」にするために使用できる他のパターンまたはフレームワークの一部はありますか?

私が尋ねる理由は、Northwind では常に完全な CustomerDTO を返すように単純に言うことができますが、Northwind の単純な状況ではうまく機能する可能性があるからです。私の場合、参照/ルックアップ タイプのデータである 25 ～ 50 のフィールドを持つオブジェクトがあります。さまざまな状況で他のものよりもロードすることが重要なものもありますが、これらの参照型の定義をできるだけ少なくしたいと思います (「DTO メンテナンス地獄」に陥らないようにするため)。

意見？フィードバック？コメント?

ありがとう！

質問のタイトルは明確ではないかもしれませんが、私がやりたいことは次のようなものです:

これが私のアプリをレイヤー化する方法です

アプリ.ドメイン アプリ.サービス アプリ.Web

私が欲しいのは、私が何かを要求/api/OrderProcessor/GetAllOrderすると、メソッドを呼び出すことGetAllOrderですApp.Services.OrderProcessorService。

メソッドは を返し、IList<Order>特定の形式 (実際には ExtJS を使用しています) に従って JSON にシリアル化したいと思います。おそらく次のようになります。

サービスをコントローラーとして作成することはできますが、サービス層がプレゼンテーション要素で汚染されることは望ましくありません。

このようなラッパーコントローラーを作成するにはどうすればよいですか?

Service クラス自体に属性をアタッチしたくありません。IoC を使用して構成できればおそらくいいでしょう。後で、出力を XML にするか、代わりに DTO クラスを使用できるようにする必要があります。元のドメイン クラス。

何か案が？

この質問は、特定の対象を絞った質問というよりも、実際の状況でコミュニティで人々が何をしているかを発見するための調査です。私はこれについてかなり広範囲に検索しました。多くのブロガーがコントラクト ファースト サービス設計を提唱し、それらを裏付けるいくつかのコメントを見つけましたが、WCF でのコントラクト ファーストの実装、長所と短所に関する実用的な情報をまだ見つけていません。私は最近、主に Thomas Erl の著書を通じて SOA について大規模な調査を行いましたが、彼が提唱する主要な概念の 1 つはコントラクト優先設計です。

私の質問は次のとおりです。

1. .NET と WCF を使用してコントラクト ファーストのサービス設計にどのようにアプローチしますか?
2. コントラクトからクライアントとサービスの両方を生成できる svcutil 以外のツールはありますか? （VSと統合できるものなら何でも理想的です）
3. コントラクト ファースト デザインと wCF に関して、実際にどのようなプロに出会ったことがありますか?
4. コントラクト ファースト デザインと WCF に関して実際に遭遇した短所は何ですか?

コントラクトファースト開発の主な問題の 1 つは、ツールにあるようです。Svcutil は、コントラクトからサービス コードを生成できる唯一のものであり、出力がかなり貧弱です。その単一ファイルには、属性とコード生成アーティファクトがぎっしり詰まっており、基本的に、コントラクトが更新されるたびに再生成して置き換える必要があります。私はより良いアプローチ、できればregen-replaceを必要としないものを好むでしょう。実際のシナリオで実用的であると仮定して、サービス側のコントラクトを手動で作成しても問題ありません。

編集：

WCSF は当面のニーズを解決してくれましたが、 Protocol BuffersとService Factoryについて学ぶことはどちらも興味深いツールであり、将来役立つと確信しています。

Mule 2.0フレームワークで使用されるコレクションアグリゲーターは、次のように機能します。

• インバウンドルーターはメッセージのコレクションを受け取り、それをいくつかの小さなメッセージに分割します-それぞれの小さなメッセージには、親メッセージに対応する相関IDがスタンプされます

• これらのメッセージはさまざまなサービスを流れます

• 最後に、これらのメッセージは、親メッセージの相関IDと予想されるメッセージの数に基づいてメッセージを収集するインバウンドアグリゲーターに到着します。予期されたすべてのメッセージが受信されると、集計関数が呼び出され、結果が返されます。

これで、グループ内のメッセージの数が適度に少ない場合にこれが正常に機能します。ただし、グループ内のメッセージの数が最大100kになると、後のメッセージが到着するのを待っているメッセージのグループを保持するために、多くのメモリが拘束されます。複数のグループが同時に集約されている場合、これはさらに悪化します。

この問題を回避する方法は、ストリーミングアグリゲーターを実装することです。私のユースケースでは、基本的にキーに基づいてさまざまなメッセージを要約しています。これは、グループ内のすべてのメッセージを同時に表示しなくても実行できます。結果をエンドポイントに転送する前に、すべてのメッセージが受信されたことを知りたいだけです。

これは問題の合理的な解決策のように聞こえますか？

これはすでにMuleのどこかに実装されていますか？

これを行うためのより良い方法はありますか？

私は現在SeeBeyond/SunのJCAPS製品の使用を考えているクライアントがいますが、SOの誰かがそれを使用/開発したことで、ポジティブまたはネガティブな経験がありますか？