WCF を使用して、SOA に基づくプロジェクトに取り組むように依頼されました。私は WCF (作成と消費) に手を出しましたが、SOA には手を出していません。1 つのサービスに、通常のサービス レイヤー、ビジネス レイヤー、およびデータ アクセス レイヤー (必要な場合) が含まれると言っても過言ではありません。次に、サービス層がメソッドを公開します。
サービス A はサービス B を参照し、サービス B はサービス A を参照できますか?
そして、UI は参照を介してこれらのサービスにアクセスできます。これは本質的に SOA ですか? 私は最新の最新のチュートリアル (Youtube) を見つけようと戦っていますが、オンラインで見る「ガイド」は非常に複雑に見えます。
このウィキペディアのエントリはかなり明確だと思いますか?
簡単な例を試してみましょう。本をチェックインおよびチェックアウトできるライブラリ アプリケーションがあるとします。
n層システムにアプローチする「伝統的な」非SOAの方法を見ると、MyServiceと呼ばれるサービスがあり、 のようなメソッドがありますCheckOutBook。これはなくなり、内部にBookクラスとPersonクラスがあり、 say Book.IsAvailable = Falseandを実行しますPerson.NumberOfBooks。
それは問題ありませんが、People を操作する別のアプリケーションがあるとします。上記のサービスだけを使用することはできません。これは、ロジックが実行していること、つまりライブラリ トランザクションと密接に結びついているためです。代わりに、コードをコピーして新しいサービス「BookShop」に貼り付ける必要があります。
SOA を使用すると、BookサービスとPersonサービスを使用できます。Person サービスには、Person.AssociateWithBookLibrary と BookShop の両方が変更せずに使用できるようなアクションがあります。その後、必要なジョブを実行するために適切なサービスを呼び出すのは、アプリケーション次第です。これは、さまざまなサービスを変更する必要なく再利用できることを意味します。
これは非常に単純化されていますが、うまくいけば、アーキテクチャの違いを示して、うまくいくでしょうか?
SOA (Service Oriented Architecture) を理解していれば、誰でも SOA を呼び出すことができるため、SOA に関する質問はスキップします。つまり、サービスを使用する各アーキテクチャはSOAと呼ぶことができます...
技術的な観点から、次の方法で構築します。
IMO、サービス自体はできる限り少ないロジック（ファサードパターンなど）を持つ必要があり、そこにあるロジックはすべてビジネスロジックに移動する必要があります。
ServiceA.BusinessLogic を使用するサービス A は、サービス B を呼び出します (サービス B のプロキシは ServiceA.BL で使用できます)。
サービス B についても同様で、サービス A を呼び出します。
これにより、デュプレックスの問題（コールバックの破損など）なしで双方向通信が可能になります。
UI も同様にサービスにアクセスする必要があります - UI.BusinessLogic を使用します (私は通常、サービス通信を一種の通信データ アクセス層と考えています)。