約3ヶ月前、最新のEclipseバージョン（ネオン）がBPELプロジェクトをサポートしていないため、SOA composition.itは簡単ではないと説明したプレゼンテーションとデモを担当しました。Eclipse Lunaとこのような状況で私の延長が助けになりました。 その時から、私の心の中を歩き回るいくつかの質問があります。 なぜSOAコンポジションについての新しいチュートリアルはありませんか？ これらのアーキテクチャは推奨されていませんか？はいの場合はどうしてですか？SOAのオーケストレーションとChoregraphieは推奨されていないアーキテクチャですか？
SOAP/SOA/ESB/BPELは廃止され、RESTfulアーキテクチャによって引き継がれていると思います（これは意見です）。 RESTfulでは、基本的なJSON + HTTP APIを持つものを意味するのではなく、エンドポイントがダムではなく、それらに属するワークフローの一部を定義する実際の分散アプリケーションです。
したがって、2つの概念的な衝突があります。ESBや純粋なBPELサービスのような中央のスマートなコンポーネントとSOAPエンドポイントのようなダムが必要ですか？あるいは、むしろ中央のコンポーネントとスマートな "エンドポイント"（RESTリソースのような）を持たないのですか？
私は概念的には後者が多くのケースではっきりと勝者であると確信しています（間違いなくすべて）。しかし実用的な問題があります。企業は常に集中化したい。集中化は、特に、エンタープライズアーキテクトの場合、「すっきり」と「きれい」に見えます。中央の構成要素がその比率から成長するまで、それはです。
私のクライアントの1人が、去年ちょうどESBを導入しました。だから間違いなく終わりです。しかし、私はすでに（私の考えでは）私はすでに中央集中型のアーキテクチャとモノリスを試していたと思います。彼らは常に "レガシーシステム"のビンに終わりますが、それはすべてを行うため交換できません。彼らはどこにいるのか知っているので、違うものを試す必要があります。 :)
スマートエンドポイントが混乱してしまったため、ESBが導入されました。 ESBは引き継ぎ、複雑すぎる高価な獣に成長しました。私たちはESBにうんざりしたので、RESTで実装されたスマートなエンドポイントに戻ります。シンプルで効率的。その間、REST APIゲートウェイと仕様が出現します。我々は再び集中化の傾向に辿り着くかもしれない。私は最良のものは、集中化されなければならないものと、分散されたものを残した方が正しい選択をすることだと考えています。 – KarelHusa