タグ付けされた質問 「soa」

編集： さらなる混乱を避けるために：私はウェブサービスなどについて話していません。内部でアプリケーションを構造化することについて話しているのですが、それはコンピューターの通信方法についてではありません。プログラミング言語、コンパイラー、および命令型プログラミングパラダイムの拡張方法についてです。 元の： 命令型プログラミングの分野では、過去20年（またはそれ以上）に2つのパラダイムがありました。オブジェクト指向（OO）とサービス指向（SO）です。コンポーネントベース（CB）。 両方のパラダイムは、モジュールの独自の概念を導入することにより、命令型プログラミングパラダイムを拡張します。OOはそれらをオブジェクト（およびクラス）と呼び、データ（フィールド）とプロシージャ（メソッド）の両方を一緒にカプセル化します。SOは対照的に、データ（レコード、Beanなど）をコード（コンポーネント、サービス）から分離します。 ただし、Smalltalk、C ++、Javaおよびその他すべてのJVM互換、C＃およびその他すべての.NET互換、Pythonなど、そのパラダイムをネイティブにサポートするプログラミング言語を持っているのはOOのみです。 SOにはそのような母国語はありません。COM / DCOM（バイナリ、C、C ++）、CORBA、EJB、Spring、Guice（すべてJava）などの手続き型言語またはオブジェクト指向言語の上にのみ存在します。 これらのSOフレームワークは、その概念のネイティブ言語サポートが欠落していることは明らかです。 OOクラスを使用して、サービスとレコードを表し始めます。これにより、メソッドのみ（サービス）を持つクラスとフィールドのみ（レコード）を持つクラスが明確に区別される設計になります。サービスまたはレコード間の継承は、クラスの継承によってシミュレートされます。技術的には、厳密に保持されていませんが、一般的に、プログラマーは2つの役割のうちの1つだけを行うようにクラスを作成することをお勧めします。 追加の外部言語を使用して、欠落している部分を表現します。IDL、XML構成、Javaコードの注釈、またはGuiceのような埋め込みDSLです。サービスの構成はサービスコード自体の一部ではないため、これは特に必要ですが、これに限定されません。OOでは、オブジェクトは他のオブジェクトを作成するため、そのような機能は必要ありませんが、SOでは他のサービスをインスタンス化または構成しないためです。 それらは、プログラマーがSOを「駆動」するために必要なすべてのコードを書かなければならないOO（初期のEJB、CORBA）の上に内部プラットフォーム効果を確立します。クラスはサービスの性質の一部にすぎず、多くのクラスを作成して一緒にサービスを形成する必要があります。プログラマーのためにそれを行うSOコンパイラーがないため、そのすべてのボイラープレートが必要です。これは、一部の人々がC ++が存在しないときにOO for Cでそれを行ったのと同じです。オブジェクトのデータを保持するレコードを、メソッドであるプロシージャの最初のパラメーターとして渡すだけです。OO言語では、このパラメーターは暗黙的であり、コンパイラーは仮想関数などに必要なすべてのコードを生成します。SOの場合、これは明らかに欠落しています。 特に、新しいフレームワークでは、AOPまたはイントロスペクションを使用して、欠落している部分をオブジェクト指向言語に追加しています。これは、必要な言語表現力をもたらしませんが、前のポイントで説明したボイラープラットフォームコードを避けます。 一部のフレームワークは、コード生成を使用してボイラープレートコードを生成します。XMLの構成ファイルまたはOOコードの注釈は、このための情報源です。 上記のすべての現象がSOに起因するとは限りませんが、SO言語が必要であることを明確に示すことを望みます。このパラダイムは非常に人気があるため、なぜ存在しないのですか？または、学術的なものもあるかもしれませんが、少なくとも業界では使用していません。

11 object-oriented  soa 

本質的に非常にモジュール化された新しいソリューションの設計を検討しており、その設計をサポートする構造を作成して、将来の拡張、懸念の明確な分離、モジュールごとのライセンス付与などを可能にします。 Webで発見されたモジュラーアプリケーションまたは複合アプリケーションはUI中心で、Silverlight、WPFなどに焦点を当てています。私の場合は、さまざまなUIプロジェクトに取り組んでいる他の開発者が使用するWCFサービスアプリケーションを開発しています。 バックグラウンド 私のプロジェクトの目標は、ビジネス/ドメインロジックの一元化されたソースを作成して、現在プロセスやルールなどを複製しているいくつかのビジネスアプリケーションをサポートすることです。また、モジュール性のすべての利点が得られるわけではありませんが、活用できるこれらの部分を活用するフレームワークを確立する機会。 サービスアプリケーションによって公開されるAPIを見て、設計を開始しました。私が検討していたモジュラー回線に沿ってサービスを分離できることは明らかです。たとえば、FinanceService、InventoryService、PersonnelServiceなどのサービスを使用して、サービス操作をグループ化して、APIで高い凝集度を提供し、カップリングを低く抑えて、クライアントがアプリケーションに関連するサービスのみを消費するようにします。 MyApp.Finance、MyApp.Inventory、My.Personnelなど、これらのサービスごとに個別のモジュールを持つことができるのは理にかなっています。横断的関心事と共有タイプは、MyApp共有アセンブリにあります。ここから少し縛られます。 （ああ、アプリケーションの疎結合を維持するためにDependency InjectionにIoCコンテナーを使用することに言及する必要があります。Pandoraのボックスを開きたくないので、どれに言及しません！） MyApp.ServiceHostで、FinanceService.svcなどの各モジュールに対応するサービスホストファイル（.svc）を作成します。サービスホストには、サービスコントラクトを定義するインターフェイスを含む構成ファイルの情報に対応するサービスの名前が必要です。次に、IoC構成を使用して、使用するインターフェイスの具体的な実装をマップします。 1.サービス層はAPIを実装し、モジュールに委任する必要がありますか、またはモジュールは自己完結型である必要があります（サービス実装を含む、そのモジュールに関連するすべてを含むという点で）。 問題にアプローチする1つの方法は、サービスコントラクトの実装を含むMyApp.Services "モジュール"を持つことです。各サービスクラスは、操作のドメインロジックを含む適切なモジュール内の別のクラスに単純に委任します。たとえば、MyApp.ServicesのFinanceService WCFクラスは、Financeモジュールに実装されて操作を実行する別のインターフェイスに委任します。これにより、シンサービスファサードを維持し、実装をサービス実装に「プラグイン」して、たとえばモジュールがWCFを心配する必要がなくなります。 一方で、インターフェイスと実装を備えているという点で、各モジュールが自己完結していることが望ましい場合があります。サービスホストは、モジュールにあるサービスコントラクトインターフェイスを参照し、モジュールからの適切な実装も使用するようにIoCが構成されます。つまり、新しい.svcファイルとIoC構成情報を追加する以外に、サービスレイヤーを変更せずに新しいモジュールを追加できます。 標準のWCFからRESTfulサービスインターフェイスに切り替えるか、RIAサービスなどにアクセスした場合の影響について考えています。各モジュールにサービスコントラクトの実装が含まれている場合、サービステクノロジーまたはアプローチを変更すると、すべてのモジュールに変更を加える必要があります。しかし、ファサードが独自のモジュールである場合、変更するためにその部分を交換するだけです。モジュールは、共有アセンブリで定義されている可能性のある異なるコントラクト（インターフェイス）のセットを実装する必要がありますか？ 2.モジュール間でリソースを共有したり、モジュール間で依存関係を処理する最良の方法は何ですか？ たとえば、受信操作を考えます。商品を受け取ることは在庫機能であるため、最初は赤面でこれが在庫モジュールに入ることは理にかなっています。ただし、領収書を生成して支払いを承認する必要があるという点で、財務的な側面もあります。 一方では、操作を伝えるために何らかのタイプのドメインイベント/メッセージングを使用することを期待します。Inventoryモジュールは、Financialモジュールによって処理されるGoodsReceivedEventを発生させて、領収書を生成し、支払いプロセスを開始します。ただし、これは、金融モジュールが受け取った在庫品目について知る必要があることを意味します。IDで単純に参照できますが、名前や説明、単価など、領収書の追加情報が必要な場合はどうすればよいですか？各モジュールが、そのモジュールのニーズに合うように設計されたインベントリアイテムの独自のバージョンを持つことは理にかなっていますか？その場合、GoodsReceivedEventを処理するときに、Financialモジュールは在庫アイテムの独自のルックアップを実行する必要があります。 ... さまざまなERPシステムで多くの作業をしており、このタイプのモジュール方式で設計されていることを知っているため、この例を意図的に使用しました-方法がわかりません。また、上記では明示的に言及していませんが、ドメインドリブンデザインの原則に従ってソリューションを設計し、このタイプのモジュール性がその領域にぴったりと収まると考えています。 私の頭をこれに巻き付ける助けは大歓迎です。

11 architecture  domain-driven-design  wcf  soa  modules 

免責事項 私は誰かのつま先を踏んだり、どちらかのコンセプトの愛好家を怒らせたりしていないことを願っています バックグラウンド 私は明確な答えを見つけることなく、サービス指向アーキテクチャとマイクロサービスの真の違いを探していました。 私は次のようなものを読みます： SOAの副作用 SOAはアンチパターン マイクロサービスはSOAの障害を修正するようになりました ESBは実際にはESBではなく、EAIです。 メッセージブローカーへの過度の依存 ベンダーはSOAの概念を悪用し、自社製品の販売を試みています SOAが制御不能に成長する しかし、それでもなお、サービス指向アーキテクチャー（概念として）とマイクロサービス（概念として）の間のアーキテクチャーの違いを明確に定義するものはありません 私が理解したところによると、彼らはどちらも持っています： 1つのことだけを行うサービスプロバイダー これらのサービスをコンシューマーに公開するService Gateway / ESB ESB / Service Gatewayを介してサービスにアクセスするサービスコンシューマー 質問 では、SOAをマイクロサービスに再ラベル付けする以外に何か違いはありますか？マイクロサービスがマクロになることを制限するために配置されたテクノロジーの制約ですか？ 注：箇条書きで意見を探すのではなく、難しい事実を探しています。 参考文献 ソフトウェア工学の質問 マーティン・ファウラーのサイト（彼はそれが大いに嫌いだと思う） 情報の世界 マイケル・フェザースのウェブサイト スタックオーバーフローの質問 更新 スタックオーバーフローの質問でも同様の議論が起こったようです。意見が分かれるかどうかにかかわらず、マイクロサービスは変装したサービス指向アーキテクチャーです。 SOの質問からの結論： MSはSOAの特殊なケースです MSは、サービスをホスティングするアプリケーションのより小さなサイズを推奨します MSはテクノロジーに依存します（オープンプロトコルオプションではなくHTTPの使用） MSはテクノロジーを利用して規律を強化します（サービスの自動展開） MSはESB（悪）を考慮しますが、IMHOがESBの一種である APIゲートウェイを使用します 次の条件に当てはまる場合、MSはSOAであると結論付けます。 MSはオーケストレーションの概念をサポートしていますか？ワークフローを管理する1つ以上のマスタープロセス MSにメッセージブローカーレイヤーはありますか？メッセージフォーマットをサービスプロデューサーのメッセージスペースからサービスコンシューマーに変換する一連のアダプター マイクロサービスはモノリシックエンタープライズアプリケーションからデータを読み取ることができますか？モノリシックアプリケーションのAPIにすることはできますか？それとも独立して動作できるスタンドアロンの自己完結型アプリケーションでなければなりませんか？ 最後の質問に対する答えが「いいえ」であることが判明した場合、マイクロサービスは、クレジットカード管理システムや照合システムなどの複雑なワークフローシステムを処理することができません。

10 microservices  enterprise-architecture  soa 

このサイトでマイクロサービスについて読んでいたときに、以下のステートメントに出くわしました。正規スキーマとはどういう意味ですか？ドメインモデルと同じではありませんか？ マイクロサービスアーキテクチャパターンは、正規スキーマの概念など、SOAの他の部分も拒否します。

9 web-services  soa  microservices  nginx 

私は、「時々接続された」モバイルデバイスが使用するWebサービスレイヤー用のWCFベースのソリューションを開発しています。追加の複雑さのため、サービスは（この段階では）キューイングを使用しないため、単純な要求/応答アプローチを操作します。 もちろん、モバイルデバイスであるため、挿入/更新中にデバイスが信号を失う可能性があります。Webサービス自体がトランザクションを完了した可能性がありますが、クライアントはこのメッセージを受信しません。このため、サーバーは要求を再送信します。その時点で、サーバーはこれを重複要求として認識し、最初のインスタンスで試行したのと同じ応答を返す必要があります。 したがって、私はサービスをべき等にすることを試みています。これを実現するために、RequestIDと、呼び出しを完了するために必要なパラメーターで構成されるRequest Paramter DTOオブジェクトを実装しています。 ただし、リクエストIDを監視する方法を実装するのは難しいです。サービスは現在ステートレスであるため、現在想定できる唯一の方法は、データベースにServiceRequestテーブルを作成することです。これにより、RequestIDがプライマリになります。これを照会すると、クライアントが同じRequestIDを送信するため、要求がすでに処理されているかどうかがわかります。ただし、サービスはどのメッセージを返信するかを知る必要もあります。挿入/更新の場合、影響を受ける集約ルートIDも、リクエストテーブルに直接、またはRequestToObjectLookupテーブルに直接格納する必要があります。 それで、これを実装するためのベストプラクティスの方法があるかどうか疑問に思っていますか？私の考えは、リクエストID、追加情報、および結果オブジェクトIDへの参照（保存/挿入/更新）を格納するServiceRequestテーブル（サービスに固有）を用意することです。そのため、新しいリクエストが来たときに、保存を実行するか、または以前に更新されたオブジェクト（最初のリクエストの試行で実行されたオブジェクト）を返すだけかを問わず、残りのリクエストに進む前にこのテーブルを最初に参照できます。 （述べたように）残りの情報を取得するために関係を使用できるようにする必要があるため、リクエストで参照されるルート集約IDのみを保持する必要があると私は考えています。

8 web-services  soa