1

私は、企業の技術パラダイムをアジャイル開発に移行することに取り組んでいます。大変なプロセスでしたが、あと少しです！:)

データベース管理用のレガシー システム (以前は Access でしたが、現在は .NET と MS SQL に移植されています) を使用しており、将来のビジョンに向けたフレームワークを開発しています。可能な限り Web に移行したいと考えています。しかし、現在のシステムを「今後の」システムと統合したいと考えています。タスクと機能が重複することはありません。

私のビジョンは、ユーザーのすべての連絡先情報を別のデータベースに移動し、それらの「プロファイル」を MS SQL にリンクして履歴と会計情報を取得することです。すべての会計システムはデスクトップ アプリに残しますが、Web、特に Ruby on Rails に大きく依存する多くの機能を追加しようとしています。

問題は、なぜ ESB なのかということだと思います。複雑な ESB システムで大騒ぎせずに SOA を作成する方法はありますか? 全体のアイデアは、とにかくKISSすることです。デスクトップ/Web/モバイルをインターフェイスとして、ビジネス ロジックの機能を維持できるような方法で SOA を作成できますか (もちろん、一部の機能はインターフェイスに実装する必要がありますが、最小限に抑えます)。また、ESB はアジャイルの哲学にも適合するのでしょうか? それらを読んで勉強すればするほど、そうは思いません！:/

ご意見をお寄せいただきありがとうございます。明確にする必要がある場合は、いくつか質問してください。できる限りのことを行います。:)

4

3 に答える 3

3

フレームワーク/インフラストラクチャが配置されると、ESBはアジャイルにうまく適合します。新しいシステムを分割して作成し、古いシステムと並行して新しい部分をしばらく実行し、新しいシステムだけが残るまでシステムの古い部分を徐々にオフにして、だれもそうしないことができることがわかります。違いを知る

基本的なSOAは、アプリケーションではなくサービスを定義するだけです。ESBはチャネル内のサービスを管理してエンドポイントを非表示にし、アップグレードと置換をより「アジャイル」にします

于 2008-12-09T23:24:49.150 に答える
1

「ESB」という用語は非常に過負荷であり、人によって意味が異なるため (また、同じ人でも意味が異なる場合があります :-))

重要なことは、当然のことながら、実際に必要なものは何かを自問することです。

データベースをサービスとしてラップすることは賢明な選択である可能性が高く、特にこのデータに対して複数のクライアントがある場合はそうです。契約とスコープについて考えるのにかなりの時間を費やす必要がありますが、アジャイルはここで大いに役立ちます。

問題は、これらのサービスをどのように呼び出すかです。クライアントとサービスが変更される可能性と、システムがどのように進化するかを比較検討する必要があると思います。

サービス バスは、クライアントからのサービスをマスクするのに役立ちます (他のサービスである可能性があります)。この「マスキング」は、場所、プロトコル、フォーマット、コードなどに中継できます。サービス バスの一部の形式は、旅程 (必要なもの) も維持します。呼ばれる、いつ）しかし、私は一般的にその考えを嫌います。

ですから、最初に自問する必要がある質問は、何から始める必要があるか、そしてどれだけの先行投資を行いたいか (そして正当化できるか) であると思います。

たとえば、最初はよりポイントツーポイントのアプローチに満足している場合、クライアントはサービスを直接呼び出すことができます。後の段階で、サービスが進化するにつれて、「仲介者」を導入してリクエストとレスポンスを仲介することができます (はい、必要に応じて ESB と呼ぶことができます)。

または、基本的な「仲介者」から始めることができます。これにより、クライアントはサービスを直接呼び出すことはありませんが、最初に必要な機能だけを持ち、要件フォームとしてその機能を拡張できます。単純な転送マシンとして開始することもできます。

多くの機能が組み込まれている製品の上に構築するのが理想的です。BizTalk Server は、MS スタックを使用している場合に適しています (ただし、学習曲線があります)。

だから - これが非常に具体的な答えではない場合は申し訳ありません - しかし、私の主なポイントは、「ESB」はやり過ぎである必要はないということだと思います. ）ビッグバンのようなものではなく、徐々に進化できるようにすることで、間違いなく役立ちます.

(上記の内容が完全にナンセンスであるか、少し不明確な場合は、家で生まれたばかりの赤ちゃんとの睡眠不足が原因です! 申し訳ありません :-) )

于 2008-12-10T10:40:16.823 に答える
0

移行全体が私を ESB に導いたのです... しかし、ESB の全体的なアイデアは、約 30,000 のプロファイルが関係する問題を解決するには複雑すぎるようです! 私たちは指数関数的な成長 (数百万のプロファイル) の危機に瀕しており、おそらく新しい道を歩み始めるのが最善でしょう. MySQL DB にあるエントリを MS SQL DB に格納されたデータにリンクするのはどれくらい簡単ですか? 私は明らかにダブルエントリを望んでいませんが、「全体」ESB よりもアジャイルな方法があるかもしれません... ESB を使用した SOA は、アップグレードと置換に関してかなりアジャイルになる可能性があることは理解していますが、そうでしょうか?やり過ぎ？:)

于 2008-12-09T23:41:01.817 に答える