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

マイクロサービスを備えたシステムで発生した主要な問題の1つは、トランザクションが異なるサービスにまたがる場合のトランザクションの動作方法です。独自のアーキテクチャ内では、これを解決するために分散トランザクションを使用してきましたが、独自の問題があります。特にこれまでのところ、デッドロックは苦痛です。 別のオプションは、システム内のフローを認識し、システム全体にまたがるバックグラウンドプロセスとしてロールバックを処理する、カスタムメイドのトランザクションマネージャーのようです（他のサービスにロールバックするよう指示します）ダウンしている場合は、後で通知します）。 別の受け入れられるオプションはありますか？これらの両方に欠点があるようです。最初のものはデッドロックやその他の問題を引き起こし、2番目のものはデータの不整合を引き起こす可能性があります。より良いオプションはありますか？

80 architecture  soa  microservices 

最近、マイクロサービスアーキテクチャに関する次の優れた記事を読みました。http：//www.infoq.com/articles/microservices-intro AmazonにWebページをロードすると、100以上のマイクロサービスが協力してそのページを提供することが記載されています。 その記事では、マイクロサービス間のすべての通信はAPIを介してのみ行うことができると説明しています。私の質問は、すべてのデータベースの書き込みはAPIを介してのみ可能であると言うのがなぜ悪いのかということですが、さまざまなマイクロサービスのデータベースから直接読み取ることができます。たとえば、マイクロサービスの外部からアクセスできるデータベースビューはごくわずかであるため、マイクロサービスを管理するチームは、これらのビューをそのまま保持している限り、マイクロサービスのデータベース構造を変更できることを知ることができます。欲しいです。 ここに何かが足りませんか？API経由でのみデータを読み取る必要がある他の理由はありますか？ 言うまでもなく、私の会社はAmazonよりもずっと小さく（常にそうです）、私たちが持つことのできるユーザーの最大数は約500万人です。

64 architecture  web-services  soa  microservices  modularization 

誰もが実際に何が何であるかを実際に理解していない場合でも、誰もがSOAを実行しています。だから彼らは間違っています。それを類推として使用して、RESTが何であるか（または少なくとも私はそう思う）を知っており、その一部を実行したいと考えています。しかし、私はそれを正しくしたい。 だから私の質問は、RESTを行う適切な方法は何ですか？

36 rest  soa  resources  implementations 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 今日、「サービス指向アーキテクチャ」の経験があるかどうかを尋ねられました。私にとって、この概念は非常に混乱しているように見えます。 概念の簡潔な定義と、他のアーキテクチャとの違いを理解するために、この用語をグーグルに頼りました。いくつかの記事を読んだ後、見つけることができると思われる唯一の一般的なスレッドは、XML / SOAPをわずかに優先して、何らかのインターフェイスを介して互いに通信する複数のコンポーネントを持つシステムです。 ほとんどすべてのアプリケーション、特にWebアプリケーションをSOAとして定義できるようです。この用語は「Web 2.0」のtrapに陥り、あなたが意味するものは何でも意味する用語になりましたか？ 私はここから離れていますか？皆さんがこの言葉を聞いたとき、それはあなたに特有の何かを意味しますか？その場合、SOAとは何か、具体的にはSOAではないことを明確に示す簡潔な定義が必要です。

25 terminology  soa 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私はワークフロー開発に不慣れであり、「全体像」を実際に得ているとは思わない。あるいは、別の言い方をすれば、これらのツールは現在私の頭の中で「クリック」していません。 そのため、企業はプロセスを説明するビジネス図面を作成するのが好きで、ある時点で誰かがプログラムのようなステートマシンを使用して、図のような線やボックスからプロセスを実際に制御できると決めたようです。10年後、これらのツールは巨大で非常に複雑になりました（私の会社は現在WebSphereで遊んでいます。私はトレーニングに参加しました。巨大で複雑ですが、WebSphereである獣ほど複雑ではありません）。 この方法で行うことの大きな利点は何ですか？単純な線図とボックス図が有用であることはある程度理解できますが、これらのことは、私が知る限り、この時点では条件とループを備えた視覚的なプログラミング言語です。ここのプログラマーは、ラインとボックスのレイヤーでかなりの量の作業を行っているように見えますが、私にとっては、本当にくだらない、本当に基本的な視覚プログラミング言語のように見えます。 そこまで行くなら、なんらかのスクリプト言語を使用してみませんか？人々はこれでお風呂の水で赤ちゃんを投げ出しましたか？線と箱のことはばかげたレベルになっていますか、それとも私はこのすべての価値を理解していないのですか？ この技術を使って働いた人々がこれを擁護する議論を見て、なぜそれが役に立つのかを理解したいと思います。私はそれに価値を見ませんが、私もこれに慣れていないことを認識しており、まだ十分に理解できないかもしれません。

22 java  workflows  soa  bpm 

アプリケーションをサービスに分割しようとしているとしましょう。SOAアプローチを採用する理由と、それを必要とするアプリケーションがロードできるライブラリAPIを作成する理由はありますか。

22 api  soa  services 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 今日のSOを閲覧中に、私はこの質問をここで見つけました、そして、それはこれで始まります： 確かに、SOAPは絶望的であり、すべてを使用することを余儀なくされていることを教えてくれます 今までSOでこのような声明をたくさん見つけましたが、これは私にこの質問をするきっかけになりました。 RESTには用途があり、SOAPには用途があり、機能として交差する場所もありますが、相互に交換することはできません。 だから、なぜ人々はSOAPが「非推奨」だと思うのだろうか？それは無知ですか？SOAPおよびWS- *仕様の複雑さ RESTの誇大広告？何？ SOAPが廃止されると思われる場合は、その理由を教えてください。私は興味がある！

20 web-services  soa  soap 

前景 モノリシックプラットフォームから、よりサービス指向のアーキテクチャに移行しています。非常に基本的なDDDの原則を適用し、さまざまな境界のあるコンテキストにドメインを分割しています。各ドメインは配布され、Web API（REST）を介してサービスを公開します。 ビジネスの性質上、予約、サービス、顧客、製品などのサービスを提供しています。 また、主な役割が以下のことを行うIdentity Server（Thinktecture Identity Server 3ベース）をセットアップしました 認証の集中化（トークンを発行する資格情報を指定） 次のようなトークンにクレームを追加します：クライアントのスコープ（クライアントごとに要求を行うアプリケーションを意味する）、顧客識別子（顧客ごとにアプリケーションを使用する人を意味する） また、サービスへの外部アクセスを集中化するAPI Gatewayの役割も導入しました。API Gatewayは、次のような内部ドメインの深い知識を必要としない機能を提供します。 リバースプロキシ：着信要求を適切な内部サービスにルーティングします バージョン管理：API Gatewayのバージョンは、内部サービスの異なるバージョンにマップされます 認証：クライアント要求には、Identity Serverによって発行されたトークンが含まれ、API Gatewayはトークンを検証します（ユーザーが本人であることを確認してください） 調整：クライアントごとの要求数を制限する 認可 認可に関係するものは、これはAPI Gatewayではなく、内部サービス自体で管理されます。現在、主に2種類の承認を行っています。 クライアントスコープに基づく承認。例：クライアント（APIを使用する外部アプリケーション）には、予約サービスAPIエンドポイントにアクセスするためのスコープ「bookings」が必要です 顧客に基づいた承認。例：顧客（アプリケーションを使用する実在の人物）が予約の参加者である場合のみ、予約サービスからエンドポイントGET / bookingsにアクセスできます。 内部サービスで認証を処理できるようにするために、API Gatewayは、クライアント（要求を行うアプリケーション）と顧客としての情報の両方を含むトークン（内部サービスに要求をルーティングするとき）を転送するだけです人がクライアントアプリケーションにログインしている場合）。 問題の説明 これまでのところ、サービス間通信（一部のサービスは他のサービスと通信してデータを取得できます）を導入するまではこれで十分です。 質問 サービス間通信の認可にどのようにアプローチすればよいですか？ 考慮されるオプション さまざまなオプションについて説明するには、次のサンプルシナリオを使用します。 予約フローを構築するために、APIにアクセスするExternalAppと呼ばれる外部アプリケーションがあります（ExternalApp はクライアントとして見ることができます） ExternalAppはBookingsサービスにアクセスする必要があるため、ExternalAppにスコープ「bookings」を付与します 内部的に（これはExternalAppに対して完全に透過的なものです）、予約サービスはサービスサービスにアクセスして、フライト、保険、レンタカーなどの予約のデフォルトサービスを取得します この問題を内部で議論する際、いくつかのオプションが表示されましたが、どのオプションが最適かはわかりません。 BookingsがServicesと通信する場合、API Gatewayから受信した元のトークンを単純に転送する必要があります（クライアントがExternalAppであることを示します） 意味：付与されるべきではないExternalAppにスコープを付与する必要がある場合があります。例：ExternalAppにはスコープ「bookings」と「services」の両方が必要な場合がありますが、「bookings」スコープのみで十分です。 BookingsがServicesと通信する場合、クライアントが（ExternalAppの代わりに）Bookingsになったことを示すトークンを転送し、Bookingsが元のクライアントExternalAppになりすましていることを示すクレームを追加します また、元のクライアントがExternalAppであるという情報を含めることにより、サービスサービスは元の呼び出し元に応じて一部のサービスを除外するなどのロジックも実行できます（たとえば、内部アプリの場合はすべての戦いを返し、外部アプリの場合は一部のみ） サービスは互いに通信すべきではありません（そのため、この質問に直面するべきではありません） ご意見をお寄せいただきありがとうございます。

18 api  microservices  soa  authorization 

プロジェクトのSpringフレームワークを特にサーバーサイドに統合したい。 そのため、warファイルのWEB-INFフォルダーに入れたくありません。 applicationContext.xmlを各レイヤーに配置する必要があります（個別のプロジェクトに分割されているため、各プロジェクトを意味しますか？（サービス、ドメイン、およびDAO） 良い習慣は何ですか？

18 java  soa  spring 

最近、私はHohpeとWoolfのEnterprise Integration Patterns、Thomas ErlのSOAに関する本を読んでおり、Udi Dahanらによるさまざまなビデオやポッドキャストを見てきました。CQRSおよびイベント駆動型システム。 私の職場のシステムは、高い結合に悩まされています。各システムには理論的に独自のデータベースがありますが、それらの間には多くの結合があります。実際には、これは、すべてのシステムが使用する1つの巨大なデータベースがあることを意味します。たとえば、顧客データのテーブルが1つあります。 私が読んだことの多くは、各システムがデータベースのみを使用し、メッセージングを使用して他のすべてのシステムに更新が伝播されるように、データの非正規化を示唆しているようです。 これはSOAの境界を強化する方法の1つだと思いました-各サービスには独自のデータベースが必要ですが、それを読んでみました： /programming/4019902/soa-joining-data-across-multiple-services そして、これは行うのが間違っていることを示唆しています。 データベースを分離することは、システムを分離する良い方法のように見えますが、今は少し混乱しています。これは良いルートですか？SOAサービス、DDDバウンドコンテキスト、アプリケーションなどでデータベースを分離することをお勧めしますか？

17 soa  integration  cqrs  eai  domain-driven-design 

私は最近マイクロサービスについて多くのことを読んでいますが、これまでに得た結論のいくつかを以下に示します（私が間違っている場合は修正してください）。 マイクロサービスアーキテクチャは、ドメイン駆動型の設計に適しています。通常、1つのMSは1つの境界付きコンテキストを表します。 マイクロサービスAがマイクロサービスBにある機能を必要とする場合、私のモデルはおそらく間違っており、AとB は実際には1つのマイクロサービス/ BCである必要があります。 マイクロサービス（直接HTTPリクエスト）間の同期通信は不良であり、マイクロサービスの目的に反し、コンポーネント間の結合を導入します。 サービス間の非同期通信が望ましい。サービスはイベントをメッセージキューに発行する必要があります。これにより、他のサービスがイベントの一部をサブスクライブおよび処理したり、コンテキストを使用してデータの一部を複製したりできます。これにより、サービスは他のサービスがダウンしていても要求を処理できますが、同期通信の場合はそうではありません。 マイクロサービスAがイベントを発行し、マイクロサービスBがそのイベントをサブスクライブし、結果として新しいイベントを生成する場合、マイクロサービスAが新しく作成されたイベントを処理するものであってはなりません。この場合、3番目のマイクロサービスを導入するか、ABマイクロサービスにAとBを組み合わせます。 マイクロサービスは実際には誤解を招く用語です。私たちは小さな文脈に努めるべきですが、そうである必要はありません。用語は「マイクロサービス」ではなく、「ジョブサービスを行うのに十分な大きさ」である必要があります。 マイクロサービスにより、システム全体を壊すことを恐れることなく、より簡単に新しい機能を導入できます。新しいサービスを導入するか、既存のサービスをリファクタリングすることで実現できます。 各マイクロサービスには、独自のデータストレージが必要です。このアーキテクチャでは、データの複製/複製が望ましい動作です。 このアーキテクチャについての私の理解を確認する以外に、質問の他の部分は主にサービスの発見に関連しています。サービスが非同期で通信しており、Amazon SQSのような中央イベントキューを使用している場合、そのようなアーキテクチャではサービスディスカバリーがその場所にないということですか？ サービスは、システム内の他のサービスに関する知識を持っていてはなりません。彼らは、自分のコンテキストと、発行または購読するイベントのみを認識していますか？

15 architecture  domain-driven-design  soa  microservices 

SOAサービスの主要な設計原則の1つは、サービスの構成可能性の原則（https://en.wikipedia.org/wiki/Service_composability_principle）です。 アイデアは、既存のサービスを構成要素として使用して新しいサービスを構成することにより、新しいサービスを迅速に開発できるということです。新しいメソッドを実装するときにオブジェクトのexisingメソッドを呼び出す方法に似ています。これは、SOAによる生産性の向上の多くがもたらされることになっている場所です。 実際に誰かがこれを実際にしていますか？私はこれを文章で延々と繰り返してきましたが、実際の実装を実際に経験したことはありません。また、ほとんどのテキストでは、トランザクション処理に関する記述が省略されています。これは、構成可能なサービスを実現する上で最大の障害であると思われます。 最初に、重要なサービスを作成する前に、トランザクションの問題に取り組む必要があります。もちろん、例にサービス「findCurrentTime（）」および「writeLogMessage（）」がある場合、トランザクションについて心配することは簡単ですが、「depositMoney（）」および「withdrawMoney（）」などの実世界の例を持っている場合はそうではありません。 私は2つのオプションを知っています： WS-Atomic Transactionなどを使用して実際のトランザクションを実装する Aへの呼び出しを「cancelA（）」またはBへの呼び出しが失敗した場合に何らかの補償を行う補償ベースのソリューションを実装する これらは両方とも非常に問題があるように思われます。 WS-Atomic Transaction 多くの複雑さのは、私は警告したことが最もアドバイス「お尻の痛みは、それを行ういけません」 サポートは制限されています。たとえば、オープンソースのESBを使用する場合、ServiceMix、Mule、またはWSO2の主要な代替はサポートしません 補償 補償の処理を実装することは私にとって非常に複雑に思えます。サービスAが成功し、サービスBから回答を得られず、失敗したか成功したかわからない場合はどうすればよいですか？このようなロジックを（合成サービスの実装者として）手動で処理すると、手首を切り裂きたいと思うようになります。 また、重要なサービスで補償方法を使用する方法もわかりません。サービスAが「depositMoney（）」で成功した場合、他のアクションがすぐに別の場所に送金し、「compensateDepositMoney（）」を受け取ったとします。ワームの大きな缶のようです。 私にとっては、サービスの構成は非常に基本的なSOAの原則であるため、サービスを（便利に）構成できない場合は、SOAの利点を実際には得られないようです。。現実は何ですか？90％のSOAユーザーは、実際のサービスを使わずに「暗号化されたSOA」を使用していますか？または、ほとんどのユーザーが実際にサービス構成を使用しており、その難しさを誇張していますか？

15 web-services  soa  transaction 

私は新しいアプリケーションを構築しており、マイクロサービスアーキテクチャについて読んでいました。アーキテクチャ自体は、開発、展開、ライフサイクル管理の観点から非常に理にかなっています。しかし、出てきた問題の1つは、マスターデータの処理方法に関するものでした。 たとえば、2つのアプリがあります。たとえば、SalesアプリとTicketingアプリです。これらのアプリは両方とも独自のマイクロサービスとして構築されていると仮定します。ただし、これらのアプリの両方をデプロイする場合（セールスがMongoDBを使用し、チケットがMariaDBを使用すると言う場合）、別々にデプロイすると、アカウント、製品などの同じマスターデータインスタンスにアクセスする必要があります。これは、特定のマスターデータエンティティの所有者アプリ（例：アカウントの場合は販売アプリ）と関係者（例：発券アプリにはアカウントに関する情報が必要）があることを意味します。 これを実現する方法は複数あります。-マスターから関係者へのデータ複製-関係者からマスターへの同期読み取り（同期依存関係はマイクロサービスアーキテクチャパラダイムでは推奨されません）-独自の中央リポジトリ また、アカウント内でも、販売と発券の両方に共通のコア部分（アカウント名、住所など）が存在する場合があります。ただし、アカウントの一部の側面は販売にのみ関連し、他の側面はチケットにのみ関連する場合があります。 上記のオプションのいずれかに関する考え/ベストプラクティス/意見はありますか？

14 soa  services 

私が取り組んでいる場所は、いくつかの基本的なルールを確立しようとしています。そして、私たちが現在持っている議論は、コードを再利用するためのローカルライブラリとWebサービスです。Webサービスは、ほとんどの企業で人気のある選択肢のようです。そして、それは、ここの開発者のほとんどが傾いていることです。 深刻な仕事にWebサービスを効果的に使用する方法がわかりません。トランザクションを使用できない場合、どうすれば複数のサービスコールを安全に実行できますか？ 通知が必要な特定の条件を満たす顧客をデータベースから取得するcronジョブがあるとします。ファックス、電子メールが送信され、チケットを作成して問題を内部的に追跡します。これは、forループの各顧客に対して発生する3つの異なるサービスコールです。 そこのどこかでエラーが発生した場合、たとえば、ファックスとメールが顧客に送信されても​​、チケットは作成されない可能性があります。さらに悪いことに、このcronジョブにはバグが含まれていて、毎回同じポイントで失敗し、同じ顧客に繰り返しメールを送信する可能性があります。ライブラリがすべてローカルである場合、すべてをトランザクションにラップすることができますが、それはまったく起こりません。ただし、この例ではWebサービスを使用しています。 電子メールとFAXのメソッドは、実際にはデータベースにバックアップされたキューテーブルにデータを挿入します。これは、別のcronジョブプロセスによって処理されます。したがって、「電子メールの送信」および「ファックスの送信」サービスメソッドの呼び出しは、必要に応じて副作用なしで中止できます。 オプションは、このコード全体をWebサービス自体に配置することです。そのため、Webサービス自体は、トランザクションで電子メール、ファックス、およびチケット作成メソッドを呼び出します。ただし、トランザクションを使用するためだけにWebサービスメソッドを作成しています。この1つのcronスクリプト以外のどこからでも実際にこのメソッドを呼び出す必要がある正当な理由はありません。 このメソッドを一般的にどのように処理しますか？

14 web-services  soa  services 

当社はかなり大規模なSOAイニシアチブを開始しています。私たちは多くのことを正しくやっています。良いコミュニケーションがあります。必要に応じてツールの費用。そして、移行に役立ついくつかの優れた専門知識をもたらしました。 私たちはグループとして従うことができる標準を開発しようとしていますが、提案されている標準の1つが私をかなり悩ませています。 すべての操作が要求オブジェクトを受け取り、応答オブジェクトを返すパターンを標準化しました。 私はこれが多かれ少なかれ多くの人々にとって標準的なアプローチであることを理解していますが、なぜ私は気にする必要があるのでしょうか？（私は受け取った知恵があまり得意ではありません。なぜか必要です）。 私が提供するサービスのほとんどは、単純な組織メタデータの取得です。たとえば、特定のユーザーのセキュリティポリシーを見つけます。これにはユーザーIDのみが必要です。標準では、この要求をオブジェクトにラップし、返されたポリシーを応答オブジェクトにラップする必要があると説明されています。 私の不安は、契約から生成されるWSDLを見ると増幅されます。WCFは要求および応答メッセージを自動的に生成し、要求/応答オブジェクトもラップします。 複雑なリクエストを行う場合は、複雑な入力オブジェクトが必要であることを完全に理解しています。これは、サービスが関与していなくても行うことです。 私の質問は、次の場合に要求と応答を自動的にラップする必要がある理由です。 シンプルなサービスの表現力が低下します とにかく複雑なサービスのためにそれをするでしょう とにかくWCFは要求/応答メッセージを作成します このアプローチを支持する次の議論を見つけました。 オプションのパラメーターを要求オブジェクトに組み込むことにより、バージョン管理をサポートします。 当時、私はかなりの量のCOMを実行していましたが、これはバージョニングのほぼアンチパターンと考えています。いくつかの点で、私はそれが助けになると思いますが、それが助けになる場所では、とにかく既にパラメータオブジェクトを持っていると期待しています。 共通のデータと動作を基本クラスに分離できます これは私にいくらかの重さをもたらします。 RPCスタイルの動作からメッセージング動作に人々を誘導します マイクロソフトのサイトでこれを読んで、教祖から聞いたが、それが何を意味するのか、なぜそれが価値があるのか​​、まだはっきりとはわからない。自然に見えるインターフェースは、人々がリモートサービスを呼び出していることを忘れがちなのでしょうか？ おそらく300のメソッドのシグネチャをリファクタリングすることを検討しているので、これは些細なことではありません。私は実装における一貫性の大ファンですので、私は喜んで痛みを引き受けます。それは最終的にすべての価値があることを知るのに役立ちます。

12 soa  wcf