この質問が濃い場合はご容赦ください。
背景:データベースに統合する内部アプリケーションがいくつかあります。私たちはそれを分割する方法を検討しており、他のアプリのデータベースを呼び出す代わりに、各アプリケーションがサービスを通じてその機能を公開するアーキテクチャに移行することが最も理にかなっているようです。これはサービス指向のアーキテクチャのように思えます。サービス指向アーキテクチャの開始に関する情報を探していると、この記事に関する多くの話題を目にします。SOA は死んだ。長生きするサービス。また、Martin Fowler と Jim Webber からもこれを参照できます: Does My Bus Look Big In This? .
質問：
SOA は巧妙なアイデアですが、SOA に関する大々的な宣伝により、人々は「SOA IS NOW DEAD」と書きました。これは正しくありません。「構造的プログラミングは死んでいます。誰もが今すぐ OOP を実行してください!」という文と同じです。また、常に正しいとは限りません。構造化コードが唯一の選択肢である場合もありますが、誇大宣伝ではなく、評価に基づいて決定する必要があります。SOA について話すときも同じことが言えます。SOA が必要な場合もあれば、サービスが必要な場合もあります。
私は SOA については何も知りませんが、通常、次のような種類のテクノロジがサイクルを経ているのを目にします。
私の推測では、SOA はそれらのテクノロジーの 1 つにすぎません。
SOA は死んでいません。すべての良いアイデアと同様に、それは私たちの風景の一部になります。eBusiness という用語は、初期には大きなアイデアでしたが、今ではその言葉を使用することすらありません。私はもはやオブジェクト指向という用語さえ使用していませんが、それはほとんど想定されています。
現在の誇大広告はクラウド コンピューティングです。すべてをクラウドに入れます。
SOA のベスト プラクティスは、適切なサービスを必要な場所に記述することです。SOA を過剰に使用すると、レイテンシーが増加します。コードを効率的に実行する必要がある場合は、データベースでストアド プロシージャを使用します。それが仕事をするなら、あなたは良いローカルサービスに勝るものはありません.
それは死んでいないと言えますが、それがどこで役立つか、そうでないかもしれないことが理解されたので、今では建築家のツールセットに分類されています。
統合を緊密でパフォーマンスの高いものにしたいので、SOAを使用してデータベースと通信する意味はありません。ただし、適切な場所で使用すると、組織のさまざまな部分の間にクリーンなインターフェイスを設定でき、場合によっては、他のシステムに関係なく、各システムをアップグレードできます。
しかし、実際には、給与システムがダウンした場合、誰もが最も不幸になります。アプリがコンポーネントの1つなしでぐったりする可能性があるからといって、システムに影響がないことを意味するわけではありません。
インターフェイスについてのみ知識があり、基盤となるシステムについては知識がないシステムを作成することはできません（「うまく機能し、パフォーマンスが高い」というステートメントに注意してください）。この興味深い例としてWebブラウザーを取り上げます。すべての優れたWebサイトは、「どのブラウザーを使用していて、私のWebサイトを修正し、機能xyzを利用するか」から始まります。
ほとんどのSOAは、イベント駆動型アーキテクチャ（EDA）として知られるSOAのあまり使用されていないサブセットによってより適切に処理されるプロセスを単純化しようとしていました。
問題は、SOAがWebサービスから構築されたものとして普及したことです。これは、そもそもSOAを実装するための基盤となるテクノロジーの選択が難しい場合があります。SOAPは必ずしもそうである必要はありませんが、通常、密結合のRPCメカニズムとして使用されます。これは、内部システムでも十分に拡張できません。システムを横断するものや、さらに悪いことに企業は言うまでもありません。
SOAPの上にEDAを構築することはできますが、通常は、その上にアドホックな手法を取り入れることになります。非同期操作とWebサービスは、いくつかの可能性のあるハッキングに入ります。
RPC Webサービスの緊密に結合された性質をなめたとしても、協力するパートナー間の緊密なバインドとWSDLバージョン管理の問題があります。
XMLペイロードとスキーマは引き続き使用できますが、SOAP自体は、WSDLの完全に外部で定義されたペイロード「blob」の周りのかなりダムなトランスポートラッパーに縮退します。
StackOverflowは、ほとんど分離されたWebアプリケーションです。SOAishであることに最も近いのは、それが使用するOpenIdメカニズムかもしれません。これは単純なクライアントサーバーであり、SOAではありません。あなたは小さすぎると思っています。
はい、SOA は死んでいますが、一時的なものになるために復活しました - http://www.soa-manifesto.org/を参照してください。今では、6 つの戒め (または原則) に従うことを宣言できる限り、誰もが何をしていても SOA を行っていると言うことができます。
私にとってこれは、「将来性のある」IT ソリューションの作成にもう少し時間とお金を費やしている企業は、SOA を行っていると宣言できる、と言っているようなものです。これは本当に良いことです。
SOA は、有用なパターン (特に新しいパターンでさえない) がアーキテクチャーの基礎として販売されたときに何が起こるかを示す典型的な例です。「企業を統合するためのコア設計」のように。
ミドルウェア企業は、この種の概念の影響を特に受けやすくなっています。なぜなら、彼ら自身が製品とサービスを結び付けようとする課題を抱えており、潜在的に大きな予算を伴う大きなアイデアを必要としているからです。
単一のアーキテクチャが企業内のすべてのソフトウェアのすべての統合ニーズを網羅できるというのは、一見怪しいと思われませんか?
SOA の代わりに、インターフェイスを介して機能を公開するモジュラー設計を採用してみませんか?
それは同じことですが、あまり好ましくありません。
企業が存在する限り、統合のニーズがあり、システムは常に話し合う必要があります。SOAは、このような分散した問題に対処するための賢明な方法のようです。ただし、残念ながら、パフォーマンスの問題は無視されます。考えられる解決策の1つを提案するために、メッセージ指向通信の代わりにストリーム指向通信を使用してクライアントとサーバー間の並列処理を活用する「FluidServices」に関する記事を公開しました。
SOA Maganizineに関するこの記事では、概念について説明しています。http: //www.soamag.com/I41/0710-2.php これは、CodeProjectのサンプルWCFコードも含むより実用的な記事です。 、スケーラブルで再利用可能なSOAサービス'（申し訳ありませんが、リンクを張ることはできません）
SOA は、本質的に「分散型」のアーキテクチャ向けです。インターフェイス ベースのプログラミング アプローチについてのみ話している場合は、COM+ や CORBA などの「コンポーネント ベース」のテクノロジに向かっています。または、.NET Remoting のようなものです。しかし、時間の経過とともに進化し、複数の独立したグループによって開発される分散環境での契約ベースの開発について話している場合は、SOA パラダイムを使用しています。これらのサービスは分散する必要があります。しかし、SOA の概念をローカル処理に使用できないと言っているわけではありません。私が言っているのは、それが他の誰もやらないところを本当に狙っているところです。しかし、残念なことに、SOA はパフォーマンスなどを気にしません。それは惨めに失敗しているところだからです。
社内向けのアプリを開発する場合は、SOA で実装しても問題ありません。Web 向けのアプリ (つまり、新しいオープン スタックの oAuth、OpenID などとうまく連携するアプリを意味します) を作成している場合は、SOA を WOA に置き換えます。Stackoverflow.com は、そのような獣の一例です。
SOA の「最良の」例は、SAP の BusinessByDesign アドベンチャーです。多くの時間とリソースを費やし、適切に機能させる前に販売を開始し、修正/シャットダウンを試みました。
これらの記事があなたを怖がらせたり、他の方法で影響を与えたりしないようにすることをお勧めします. あなたの特定の状況を考えてみてください。サービスを提供することはあなたに利益をもたらしますか? はいの場合は、それを行ってください。そうでない場合、行動方針は明らかです。
SOA の背後にある心には、基本的に理想的なアイデアがあると思います。相互に発見し、相互運用して高レベルのサービスを何らかの方法で自動的に提供する、さまざまな多数のサービスの世界を作成します。しかし、それは AI/サイエンス フィクションの方向性です。アルゴリズムのアプローチでプログラムできる非常に特定のシナリオでのみ、何かに近いものを達成できます。それ以上……いや、今世紀じゃないけど……