問題タブ [soa-governance]

SOA ガバナンスとは何かを理解している人はいますか? SOA ガバナンスと IT ガバナンスの違い (または相関関係) は何ですか? 市場で入手可能な SOA プラットフォームを使用してどのように適用できますか?

SOA プラットフォーム上に構築されたプロジェクトは、SOA ガバナンスを適用せずに成功できますか? どのように？私はここで実用的な観点から話しています。

Greg に新しいアーティファクトをアップロードして、既存のアーティファクトを参照しようとしています。たとえば、Greg に A.xsd、B.xsd、および C.xsd があり、それらを参照する WSDL をアップロードしていますが、機能しません。xsd、wadl、およびその他のアーティファクトを使用する他のシナリオがあります。バグですか？はいの場合、これはガバナンス ツールであるため深刻です。これらの参照を使用しました: https://docs.wso2.com/display/Governance501/Uploading+Schemas+with+Imports+from+Local+Filesystem+into+Governance+Registry https://docs.wso2.com/display /ガバナンス501/Creating+a+ガバナンス+アーカイブ

背景: フェデレーション モデルを持つ国際企業は、慢性的なモノリシックな痛みのためにマイクロサービスに移行しています。迅速な展開を備えた自律的なチームは、非常に望ましいものです。理論に反して、サービスは確かに高度な機能のために相互に依存していますが、自律的です (独立して開発および展開されます)。これは連合モデルで分散型の管理であるため、国連のように厳格なルールを課すことはできません。さまざまな国で複数のバージョンが運用されているため、他の依存関係を管理するガバナンス プラットフォームがなければ、制御不能な混乱が予想されます。

連携が必要なマイクロサービスのセットを「互換セット」と呼びましょう。サービスは展開できますが、互換性セットの上位機能を満たさない場合があります。たとえば、MicroService A-4.3 は完全に自律的で、展開され、完全に機能しています。ただし、BusinessFunctionality 8.6 を満たすには、MicroService B-5.4 および MicroService C-2.9 と連携する必要があります。一緒に (A-4.3、B-5.4、および C-2.9)、「互換セット」を形成します。

このジレンマには 2 つのアプローチがあります。ゴムが道にぶつかり、経験からの学習が始まる現実のマイクロサービス...

アプローチ 1) ガバナンス プラットフォーム

根拠: 100 か国以上の国際企業における連邦モデル。つまり、中央 IT はモデルを策定できますが、個々の国は独自の運命を選択できます。それは頻繁に混乱に発展し、中央 IT チームは窮地に立たされています。DDD は、互換性セットに適合しないサービスをリリースするなど、バージョンの不一致によって機能が損なわれず、個別に非難されることはありませんが、一緒にするとばらばらになったり、欠陥や一貫性のない機能が発生したりする理想的な世界のソリューションです。

• 均質性はなく、用語の標準化さえありません
• 開発者はさまざまなスキルがあり、多くはジュニアであり、多くはリアクティブ プログラミングとクラウド ネイティブ テクノロジーを学んでいます
• 境界付けられたコンテキストは共有語彙に大きく依存しており、微妙になる可能性がありますが、これを実施することは不可能であり、複数のバージョンが実行されている国際的な混合スキルの断片化されたシナリオで想定することは単純です
• このような異種システムでは、単一のビジネス モデルでの標準化は現実的ではありません (理想的ではありますが)。

このカオスの責任を負わされた場合、Central IT はどうすればよいでしょうか?

ガバナンス プラットフォーム の適用 マイクロサービス ガバナンス システムまたはフレームワークを作成して、依存関係管理を適用します。マニフェストを介して特定のマイクロサービスに対する設計時および実行時の依存関係を検証および適用し、提供されるサービス実装 (「互換性セット」) を検証するためにいくつかのチェック アンド バランスを実行します。

アプローチ 2) ドメイン駆動設計 (DDD) DDD は、常に進化しているドメインをモデル化するものであり、ドメインの専門家 (通常はビジネス関係者またはアナリスト) が開発者と協力してシス​​テムを設計します。各ドメイン内でユビキタス言語が形成され、そのコンテキスト内では、同じ単語は常に同じことを意味します。重要なことは、システムの一部では、「注文」が 1 つのことを意味する場合があることです。たとえば、製品のリストを意味する場合があります。システムの別の部分では、「注文」は別の意味である場合があり、発生した金融取引を意味する場合があります。これは、あなたが説明したモデルが失敗する可能性がある場所です.私のサービスが注文のリストを取得する必要がある場合、おそらく注文のリストを提供する機能があります. しかし、それらはどの命令ですか？製品のリストまたは金融取引？ここで同じ言語を使用するために必要な数の開発者を調整しようとすることは、失敗する運命にある不可能な作業です。

DDD では、システム レベルでこれを管理し、すべてのサービスに同じ順序の定義を使用するように強制するのではなく、DDD は、非常に多くの開発者が関与する非常に大規模な展開を調整する際の固有の複雑さを受け入れ、各チームが独立して作業できるようにします。集中型の依存関係管理システムではなく、必要に応じて他のチームと調整します。DDD で使用される用語は、境界付けられたコンテキストです。あるコンテキストでは、順序は 1 つのことを意味し、別の境界付けられたコンテキストでは、順序は別のことを意味します。これらのコンテキストは真に自律的に機能できます。サービスを自律的であると説明しますが、依存関係を登録して中央レジストリに提供することにより、システム全体と順序の定義を一致させる必要がある場合は、

したがって、DDD ベースのアプローチでは、システム レベルで依存関係や機能を強制するという手の込んだアプローチを試みることは決してありません。むしろ、サービス A がサービス B と対話する必要がある場合、個々のチームが中央の調整を必要とせずに作業できるようにします。サービス A を管理するチームは、サービス B を管理するチームと協力して、境界付けられたコンテキスト間のインターフェイスを構築し、そのインターフェイスの言語について合意に達することができます。相互の依存関係を管理するのはこれらのチーム次第であり、システム レベルでは物事が非常に不透明/強制されないままになる可能性があります。

人々が「マイクロサービス」を実装しているのをよく見かけますが、最終的にはモノリスと同じくらい柔軟性がなく、しばしば壊れやすいシステムになってしまいます。「Minilith」または「Monolith 2.0」とも呼ばれるマイクロサービスでは、アーキテクチャとソフトウェア開発プロセスを完全に再考する必要があり、サービスが自律的で独立して管理されるようにするだけでなく、チームが集中管理ではなく独立している必要があります。システム内の依存関係と機能の管理を一元化することは、マイクロサービス ベースのシステムの構築を成功させる妨げになる可能性があります。

知的で実用的なコメントを募集しています...

アプローチ 1 (ガバナンス) は実用的かつ戦術的であり、非常に現実的な課題を解決することを目的としています。問題は、企業の長期的な戦略的 DDD モデルを台無しにするかどうかです。

アプローチ 2 (DDD) は理想的で意欲的なものですが、現在対処しなければならない非常に現実的な課題には対処していません。

意見？考え？コメント?

I have configured my WSO2 Governance repository to MySQL by following the steps in https://docs.wso2.com/display/ADMIN44x/Changing+to+MySQL.

Is there a document which explains the REGDB schema? For e.g. which table stores the asset's association information and etc.

Thanks in advance.

Rgds, neo