2

Webサービスレイヤーとして確立されたアプリケーションにゼロから構築されたSOAベースのプロジェクトがあります。

ClientA->                       
ClientB-> ESB-> Atomic Services->確立されたアプリ（DB / NASなど）
ClientC->

ESBによって提供されるサービスが、相互作用で順番に呼び出される複数のアトミック呼び出しで構成されているシナリオがいくつかあります。論理的には、次のようになります。

def composed_service（xmlrequest）：
    output_of_decision_service =decision_service（xmlrequest）
    if（output_of_decision_service.matches（ "foo"））：
        xmlresult = foo_service（xmlrequest）
    if（output_of_decision_service.matches（ "bar"））：
        xmlresult = bar_service（xmlrequest）
    xmlresultを返す

実際、このロジックはXSLT変換を使用して実装されており、XPathクエリは購入したESB実装に組み込まれています。これは、いくつかの理由で私には問題があるようです。

  • ESBの実装は「重すぎ」てローカルに展開できないため、開発者は構成サービス（ビジネスの観点から見た単純な機能）をローカルでテストできません。全体的なテストは統合アクティビティです。
  • これらおよび同様の制御ブロックを形成するために使用されるXSLT構文は、一般的なプログラミング言語のコードほど読み取り可能またはアクセス可能ではありません。（もし...なら、そうでなければ最後になど）XSLTは非常に長くて恐ろしいものになっています。
  • 特定の複雑なシナリオでは、よりきめ細かい制御が有益です。つまり、補償アトミックサービスを呼び出して以前のアクションをロールバックすることにより、失敗した呼び出しを補償します。

プロジェクトに1年取り組んだ後、アプリケーション機能をアトミックサービスに分解するという概念は良いものだと思います。ただし、Javaのような単純な古いプログラミング言語で作成中のWebサービスを実装したいと思うことがよくあります。

私はこれがこのように見えると思います：

ClientA-> ComposedServiceA->                   
ClientB->ComposedServiceB->アトミ​​ックサービス->アプリ
ClientC-> ComposedServiceC->

しかし、ここを読んで、私は次のように参照されていないステートメントを見つけました：

確かに、コードでESBの動作をエミュレートするのは悪いオプションです

悲しいことに、これは裏付けとなる理由もなく、事実の盲目的な声明（意見）として残されました。しかし、それは私をガタガタさせました。なぜ上記が真実である可能性がありますか？私は建築家に上記のすべての懸念を表明する電子メールを作成する準備ができていましたが、このコメントは私がすべきかどうか疑問に思いますか？

確かに、コードでESBの動作をエミュレートするのが最悪のオプションなのはなぜですか？

4

1 に答える 1

1

ステートメントの完全なコンテキストを知らないとコメントするのが難しくなりますが、独自のESBを最初から実装しようとすることを意味する場合は、同意する必要があります。ESBは十分に複雑なので、自分で作成してみたくはありません。

アーキテクチャに関しては、「作成」サービスに分解したいのは当然です。これはサービスレイヤリングと呼ばれ、通常は3つのレイヤになります。アトミックサービスは、エンティティレイヤーサービスまたはユーティリティレイターサービスに対応します。これらはビジネスプロセスに依存せず、通常は非常に再利用可能です。構成サービスは通常、他のサービスを構成するタスクレイヤーサービスに対応し、特定のビジネスプロセスに関連しており、通常は再利用できません。

于 2012-02-27T22:53:12.590 に答える