ミドルウェア アプリはビジネス ロジックを実行する必要がありますか?

Question

いくつかのビジネス コンポーネント (顧客のアプリケーション、ネットワーク、支払いなど) 間のリクエストを仲介する大規模なミドルウェア インフラストラクチャがあるとします。ミドルウェア スタックは、オーケストレーション、ルーティング、変換などを担当します (Gregor Hohpe の『Enterprise Integration Patterns』と同様)。

私の質問は次のとおりです。いくつか置くのは良いデザインですか？ ビジネスの論理 ミドルウェア上で？

私のアプリ A がミドルウェアに顧客データを要求したとします。しかし、このデータを取得するには、次のものを提供する必要があります 顧客ID いくつかの 他のパラメータ. 。このパラメータの取得は、要求元のアプリによって実行される必要があります。それとも、ミドルウェアが「促進」し、データを受け取るインターフェイスを提供する役割を果たしますか? 顧客ID そして内部的に取得します 他のパラメータ?

(ビジネス ロジックの定義のため) これが単純な質問ではないことは承知していますが、これが一般的なアプローチなのか、それともガイドラインなのか疑問に思っていました。

Answer 1

これは「複合アプリケーション」パターンです。サービス指向アーキテクチャの中心。それが ESB ベンダーが販売しているものです。置く方法 追加 既存のアプリケーションから複合アプリケーションを作成するビジネス ロジック。

複合アプリケーションは単なるルーティングではないため、これは単純ではありません。これは、ルーティングの上に重ねられた適切な新しい複合トランザクションです。

ヒント。先に進む前に、適切な ESB を取得することを検討してください。これは急速に制御不能になるため、追加のサポートがあると役立ちます。サンのようなものを買わなくても JCAPS または オープンESB, 、それが何をするのか、そして複雑な複合アプリケーションをどのように編成するのかを学べたことに満足するでしょう。

Answer 2

ルーティング、変換、オーケストレーションとは別に、機能要件を持つミドルウェアをロードする際にはパフォーマンスを念頭に置く必要があります。ミドルウェアは、エンドツーエンドのトランザクション存続時間全体の一部を占める必要があります。これは、ホスト システムの機能を補完するのではなく、ミドルウェアのコア機能に集中することによってのみ実現できます。

Answer 3

オーケストレーション、ルーティング、変換。

これらのいずれも、技術的な理由やランダム、あるいは単なる遊びで行うのではなく、何らかのビジネス要件があるため、つまりビジネス ロジックが関与するために行うのです。

完全なビジネス システムに欠けているのは計算とレポートだけです (セキュリティがすでに導入されていると仮定しましょう!)。

非常に低レベルのネットワーク、OS、およびストレージの問題を除いて、コンピュータ システムを構成するほぼすべてのものは、企業/政府/エンド ユーザーがそこに存在することを望んでいるためにそこに存在します。

用語としての「ビジネス ロジック」の選択は非常に不十分であり、設計とアーキテクチャに際限のない歪みをもたらしました。

優れたデザイナー/アーキテクトのほとんどがビジネス ロジックで意味するものは、計算と分析です。

"%s/Business Logic/Calculation/g" にすると、ほとんどのアーキテクチャ上の命令がより意味を持ちます。

Answer 4

ミドルウェア アプリケーションがそれを行う必要があります。システム A は、他のパラメータが存在することを知らないはずであり、それを取得する方法についてもまったく知りません。