問題タブ [soa]

私はSOAの世界に全く慣れていません。そのため、私はいくつかの「SOAフレームワーク/テクノロジー」を調べ、それらを利用して高度にスケーラブルな（Facebookクラスの）Webサイトを構築する方法を理解しようとしています。

私がここで解決しようとしているいくつかの「痛み」があります：

1. 構成可能性（+依存関係の管理、Pub / Sub）
2. サービスの言語に依存しない
3. スケーラビリティとパフォーマンス
4. 高可用性

上記の基準のサブセットに答えるいくつかのテクノロジーを調べました。

1. Thrift -FacebookのクロスプラットフォームRPCプラットフォーム
2. WCF -SOAP、JSON、RESTをサポートしているため、言語の相互運用性があると見なすことができます。Javaプロキシの生成に使用できるWSDLファイルを生成します。
3. Microsoft DSS-私の調査にそれを含めただけですが、それは高度に状態主導で.NET固有であるため、関連性がないようです。
4. ウェブサービス

これで、上記から構成可能性と言語非依存性のいくつかの側面をどのように得るかを理解しました。しかし、スケーラビリティと高可用性のために上記/他のツールを使用する方法についての具体的な情報（話題ではない）はあまり見つかりませんでした。だから最後に私は私の質問に行きます：

上記で定義した問題を解決するために、SOAテクノロジーをどのように活用しますか？そのためのテクニカルガイドはどこにありますか？システム図だけでなく、実際のライブラリ、コードサンプル、APIを探しています...

複数のビジネスコンポーネント（顧客アプリケーション、ネットワーク、支払いなど）間の要求を仲介する大規模なミドルウェアインフラストラクチャがあるとします。ミドルウェアスタックは、オーケストレーション、ルーティング、変換、およびその他のものを担当します（GregorHohpeによるEnterpriseIntegration Patternsの本と同様）。

私の質問は、ミドルウェアにビジネスロジックを配置するのは良い設計ですか？

私のアプリAがミドルウェアからいくつかの顧客データを要求するとします。ただし、このデータを取得するには、顧客IDとその他のパラメーターを指定する必要があります。このパラメーターのフェッチは、要求元のアプリが行う必要がありますか、それともミドルウェアが顧客IDを受け取り、他のパラメーターを内部的にフェッチするインターフェースを「促進」して提供する責任がありますか？

これは（ビジネスロジックの定義のために）単純な質問ではないことは理解していますが、それが一般的なアプローチなのか、それともいくつかのガイドラインなのか疑問に思いました。

私はWCFが初めてで、大部分は分散プログラミングでもあります。4 つの個別のサービスを必要とするプロジェクトに取り組んでいます。

各サービスの各コンポーネントの責任を正しく定義しようとしています。サービス A と通信する必要があるサービス B があるとします。サービスごとに、サービス実装クラス、サービス ホスト、およびプロキシ クラスを定義しました。

単体テストを行うために、依存性注入を使用しています。サービス B はサービス A と通信する必要があるため、A のプロキシ クラスのインスタンスをコンストラクター引数としてサービス B に渡しました。

サービス B の単体テストを行っているときは、A のサービス ホストを稼働させておく必要があります。

1. これは依存性注入の間違った方法ですか? もしそうなら、なぜ、そしてどのようにすすめますか?
2. 依存性注入についてもっと良い方法はありますか?
3. 単体テストで正しい結果を得るには、サービス ホストを実行する必要がありますか?

IDE で使用できるサービス指向アーキテクチャ/Web サービス機能は何ですか。

利用可能なオープンソースの集中認証サービスはありますか？認証情報を一元化するためのソリューションはたくさんありますが（例：CASやJOSSO）、認証情報についてはどうでしょうか。

いくつかの非常に優れた承認フレームワーク（例：Spring Security（以前のAcegi）とSeam Security）がありますが、これらを個々の層またはサービスに統合する必要があるようです。つまり、スタンドアロンで実行するのは簡単ではありません。SOAを使用する場合、認証だけでなく承認情報（つまり、役割、権限、ルールなど）も一元化することは非常に価値があるように思われます。

助言がありますか？

アプリケーション/サービスアーキテクチャの図を作成するために何を使用しているのか知りたいですか?

アプリケーション全体のさまざまなレイヤーを表す図を作成したいと思います。一部の部分については、より深く (クラス レベル)

Service Factoryと同様の方法でWCFアプリケーションを編成するための青写真を知っていますか？

問題は、Service Factoryは適切に構成されていますが、私のアプリケーションは中規模のアプリケーションであり、ファクトリを使用するのはやり過ぎになることです。ファクトリが作成するサブプロジェクトのいくつかは、私が使用することはありません。

では、中規模プロジェクトのWCFアプリケーションの構造を整理するための一般的なモデル/アーキテクチャ/青写真/パターンは何ですか？

ありがとうございました。

この質問が濃い場合はご容赦ください。

背景:データベースに統合する内部アプリケーションがいくつかあります。私たちはそれを分割する方法を検討しており、他のアプリのデータベースを呼び出す代わりに、各アプリケーションがサービスを通じてその機能を公開するアーキテクチャに移行することが最も理にかなっているようです。これはサービス指向のアーキテクチャのように思えます。サービス指向アーキテクチャの開始に関する情報を探していると、この記事に関する多くの話題を目にします。SOA は死んだ。長生きするサービス。また、Martin Fowler と Jim Webber からもこれを参照できます: Does My Bus Look Big In This? .

質問：

• SOA は終わったのでしょうか、それとも単に話題になっただけなのでしょうか?
• サービス指向アーキテクチャを可能な限り薄くシンプルに保つには、どのような方法が最適でしょうか?

私がコンサルティングしているビジネスをサポートする一連のサービスの SOA アーキテクチャを検討しています。以前は、各アプリケーションが共有 MS SQL データベースから必要なものを選択し、それを操作するデータベース統合を使用していました。 Java、.net、Microsoft Access などのモンスター データベースと統合するアプリでは、すべてが密結合されているため、参照整合性がありました。

サービス間のデータ共有をサポートする方法について少し混乱しています。

卸売業者が毎月提供する製品データベースの上にある製品サービスを見てみましょう。ドメイン モデルを構築し、これを Hibernate などを使用してデータベースに配置します。実装に関して言えば、製品は、製品について卸売業者から提供された情報を考慮した大きなオブジェクト グラフです。

ここで、Review サービス、Pricing Service、Shipping Service、および Stock Service が ProductUpdated、ProductAdded、ProductDeleted をサブスクライブするとします。問題は、各サービスが製品に関する情報の一部または一部しか必要としないことです。配送には、寸法と重量のみが必要な場合があります。価格設定には、製品 ID、卸売コスト、ボリューム ディスカウント、現在まで有効な価格のみが必要な場合があります。レビューには、製品 ID、製品名、生産者が必要な場合があります。

製品全体 (ProductUpdated などの適切な非サブスクライバー固有のコントラクト、およびすべての製品オブジェクト グラフを表す適切なスキーマ) を公開し、サブスクライバーに必要なものをドメイン モデルにマップさせる (または、彼らが何をするか) だけが標準的な方法ですか?ドメインモデルさえないかもしれません）...

または、これを書いているときに、おそらく次のように考えています。

Product Service は ProductAdded メッセージを発行します (製品の ID とおそらくタイムスタンプだけの製品の詳細は含まれません)

Pricing Service は ProductAdded をサブスクライブし、RequestPricingForProduct メッセージを発行します

製品サービスは ResultForPricingForProduct メッセージを公開します

うーん..少し良くなったように見えます...しかし、私が識別できる他のサービスとそれらが必要とするものに基づいて、製品サービスの契約を構築しているように感じます.おそらく将来、XYZサービスは何か違うものを必要とします. 私が混乱している場所がより明確になってきていると思うので、そこで停止します...おそらく、公開すべきものは何でも返す方法を公開する必要があるため、上記は機能します。

コメントや指示は大歓迎です。これが中途半端に見えたらごめんなさい。