SOAとは何ですか? 7SOA Steps

このブログでは、エンタープライズサービス指向アーキテクチャが提供するコストと俊敏性の利点を実現するために、組織が真に成功する前に SOAとは何か、およびSOA採用のさまざまな段階について、企業がサービス指向アーキテクチャの取り組みを成功させるために利用可能な技術、プロセス、およ

SOAとは何ですか？

Service-oriented architecture(SOA)は、サービス指向をサポートするソフトウェア設計で使用されるアーキテクチャの一種であり、ネットワーク上の通信プロトコルを介して他のコンポーネ

SOAは何の略ですか？

Wikipediaによって提供されるSOAの定義：

サービス指向アーキテクチャ（SOA）は、ネットワーク上の通信プロトコルを介して、アプリケーションコンポーネントによって他のコンポーネントにサービスが提供されるソフトウェア設計のスタイルです。 サービス指向アーキテクチャの基本原則は、ベンダー、製品、技術から独立しています。 サービスは、リモートでアクセスし、オンラインでクレジットカードの明細書を取得するなど、独立して動作し、更新できる機能の個別の単位です。

サービスは、SOAの多くの定義の一つによると、四つのプロパティを持っています:

1. これは、指定された結果を持つビジネス活動を論理的に表します。
2. 自己完結型です。
3. それは消費者のためのブラックボックスです。
4. 他の基礎となるサービスで構成されている可能性があります。

さまざまなサービスを組み合わせて使用して、大規模なソフトウェアアプリケーションの機能を提供することができます。 サービス指向アーキテクチャは、分散され、別々に維持され、展開されたソフトウェアコンポー これは、ネットワーク上、特にIPネットワーク上でのコンポーネントの通信と協力を容易にする技術と標準によって可能になります。

これはSOAの意味に対する簡潔な答えを提供しますが、組織がサービス指向アーキテクチャに移行したい理由やSOAの利点については説明していません。

また、SOAの略についてWikipediaから：

いくつかのエンタープライズアーキテクトは、SOAは、企業が変化する市場状況に、より迅速かつよりコスト効果的に対応すこのスタイルのアーキテクチャは、マイクロ(クラス)レベルではなく、マクロ(サービス)レベルでの再利用を促進します。 また、既存のIT（レガシー）資産との相互接続や使用を簡素化することもできます。

いくつかの点で、SOAは革命ではなくアーキテクチャの進化とみなすことができます。 これは、以前のソフトウェアアーキテクチャのベストプラクティスの多くをキャプチャします。 例えば、通信システムでは、ネットワーク内の他の機器と通信するために真に静的なバインディングを使用するソリューションの開発はほとんど行われていません。 SOAアプローチを採用することにより、そのようなシステムは、明確に定義された、高度に相互運用可能なインターフェイスの重要性を強調するように

これらの概念を掘り下げてみると、SOAの潜在的な利点を達成するために必要な一連の基本的な機能があることがわかります。 ウィキペディアでは、これらの指導プリンシパルの数について説明しています。:

• 再利用–粗い粒度のビジネス機能をサービスとしてカプセル化し、公開する能力
• 疎結合-サービスコンシューマーがサービスの物理的実装から十分に抽象化されていることを保証
• 識別と分類(発見可能性)–潜在的なコンシューマーが必要なサービスを見つけることができることを確認

どのSOA定義を使用しても、これらの基本的なプリンシパルはサービス指向の利点を段階的に実現するために、組織が完了しなければならない活動の自然な順序 建築。

AkanaがForrester Wave™:API Management Solutions,Q3 2020レポートで強力なパフォーマーである理由を参照してください。

レポートのダウンロード

七つのSOAステップは何ですか？

:

1. サービスの作成/公開
2. サービスの登録
3. 安全なサービス
4. サービスの管理(監視)
5. サービスの仲介と仮想化
6. SOAの管理
7. ESBとのSOA統合

soaステップ2～6では、集中型Soaインフラストラクチャプラットフォームで対処すべき企業間の懸念について説明します。 手順1と7は特定のニーズに対応しており、多くの場合、既存のエンタープライズアプリケーションスタックの一部として提供されます。 これらのステップに従うことで、組織はSOAの利点を実現するための正しい道を歩むことができます。 SOAの各ステップを詳しく説明するために読み続けてください。

サービスの作成/公開

組織をSOAに移行するための最初のステップは明らかです。 サービスのないSOAアプリケーションは存在しないため、最初のステップは、Webサービス対応アプリケーションによって容易に消費できるサービスを公開または作

企業がこのプロセスを開始する際に直面する興味深い決定がいくつかあります。 これはもちろんバイナリの決定ではなく、ほとんどの組織はJ2EEや.NETを使用して新しいサービスをゼロから構築し、既存のメインフレームやその他のビ

既存のアプリケーションをサービスとして公開しようとしている企業には、Akanaの市場をリードするSOLAを含む、メインフレームCICSアプリケーションが信頼性の高

メインフレームに大きな（ガートナーによると1000MIPS以上）投資をしている企業は、このプラットフォームの利点をよりよく活用する方法を調査し、webサービスを使 AkanaのSOLAは、Merrill Lynchのような顧客で生産実績があり、600以上のWebサービスから1日あたり200万件以上の取引を処理しています。 SOLAは、メインフレームプログラマに、CICSアプリケーションからサービスを公開して消費するための使いやすいWebベースのインターフェイスを提供する唯一の これには、WS-Security、XML-Encryption、XML-Signatureなどの高度なWebサービス機能のサポートが組み込まれています。

従来のenterprise application integration（EAI）企業のほとんどは、従来の独自プロトコルではなくWebサービスを公開するバージョンのアダプタも提供しています。 実際には、これらのEAIプラットフォームの多くは、エンタープライズサービスバス製品として再浮上しています。 その1つは、従来のアダプタからWebサービスインタフェースを公開するために使用されるcommodity data servicesタイプの機能です。

ウェブサービスとは何ですか？

:

W3C Webサービスに関して、W3Cはwebサービスを次のように定義しました。”webサービスは、ネットワーク上で相互運用可能なマシン間の相互作用をサポートするように設計されたソフトウェアシステムです。 これは、マシン処理可能な形式（特にWSDL）で記述されたインターフェイスを持っています。 他のシステムは、SOAPメッセージを使用してその記述によって規定された方法でwebサービスと対話します。”

この定義は技術的な観点からは興味深いものですが、SOAやWebサービスから派生できる価値の中心には実際には到達しません。 Webサービスの基本的な側面は、標準ベースのインターフェイスを介してビジネスロジックを公開することです。 サービスを公開または作成する際の重要な側面の1つは、その粒度です。 サービスを構成するものについては、多くの異なる考え方があります（上記参照）が、ほとんどのエンタープライズアーキテクトは、SOAで有用であるためには、サー

もちろん、これはSOAにおけるサービスの基本的な教義の一つであり、サービスを再利用するためには、一般的に有用で使用可能でなければなりません。 一般的に有用なサービスの例としては、顧客識別子から顧客に関する詳細を返す”getCustomerInfo”サービスがあります。 一般的には有用ではないかもしれないよりきめ細かなサービスは、特定のアプリケーションに固有のもの、例えば”setApplicationState”である可能性があります。

新しいサービスを構築するときと、既存のビジネスロジックをサービスとして公開するときの両方で、サービスの粒度を考慮することが重要です。 一方、現実には、トランザクション全体を単一のサービスとして公開するより粗い粒度のサービスは、はるかに一般的に有用であり、したがって価値があ

関連読書：AkanaのSOLAメインフレームAPIは、メインフレームアプリケーションを安全なwebサービスとして公開するための迅速かつ簡単なプロセスを顧客に提供し、メインフレームアプリケーションがwebサービスを利用できるようにする方法をご覧ください。

を登録すると、企業で利用可能なサービスが1つ以上あります。 今は何？

サービスを使用するためには、再利用はもちろんのこと、このサービスから利益を得る可能性のあるアプリケーションアーキテクトや開発者は、それが存在することを知る必要があります。 これは、レジストリが入ってくる場所です。 最も単純なレベルでは、レジストリは、サービスの潜在的なユーザーが関心のあるサービスを見つけるのに役立つライブラリインデックスにすぎません。 レジストリは、検索と参照の両方のインターフェイスを提供し、サービスの迅速かつ正確な検出を容易にするために論理的に整理する必要があります。

今日のSOAでは、基本的なレジストリサービスのために受け入れられている標準はUDDI(Universal Discover,Description,And Integration)です。 UDDI仕様では、サービスの公開と検出のためのデータモデルと一連のインターフェイス(すべてのWebサービス自体)、およびレジストリサーバー自体を管理するためのさらなるインターフェイスのセットが提供されています。

多くのレジストリベンダーは、レジストリの元の概念をかなりさらに取り入れ、より完全なリポジトリのベースとしてレジストリ技術を使用しています。 また、レジストリベンダーは、公開ツールに”ポリシー”ベースのフィルタを追加し、”設計時のガバナンスソリューション”を提供しています。

Akanaは、レジストリをSOAの基本的な構成要素と考えています。 当社のすべての製品は、SOA内のサービスに関する権威ある情報のための単一の中央ストアとしてUDDIを活用しています。 Akanaには、独自のUddiv3レジストリサーバーと、レジストリをまだ持っていない企業向けのService Manager製品が含まれています。 この点で、レジストリは、LDAPがIdおよびアクセス管理ソリューションのために満たしたSOAの役割を満たしています。

Akanaの製品はランタイムガバナンスに焦点を当て、レジストリを中心としたランタイムポリシーを実装および実施するための場所として活用しています。 もちろん、組み込みレジストリは完全に機能するUddiv3サーバーであるため、理想的な設計時のサービスリポジトリにもなります。

beyond registryは、SOAのサービスのすべての設計時および実行時の成果物の包括的なリポジトリを提供するポリシーおよびメタデータサービスの全体的な概念です。 この概念については、Akanaのホワイトペーパー”SOA Infrastructure Reference Model”で詳しく説明されています。

Secure

SOAとWebサービスの世界はすべてワインとバラではありません。 あなたが今ステップワンとステップを完了したと仮定して、一歩戻って、あなたが何をしたかを検討してください。 最大のビジネス価値を目指していると仮定すると、ミッションクリティカルなアプリケーションを取り、それらを粗い粒度の機能に分割し、この機能をサービスとして公開し、これらのサービスを普遍的にアクセス可能なレジストリに公開している可能性があります。

これはすべて良いことのように見えるかもしれませんし、ほとんどの場合、それは素晴らしいことですが、誤って組織にいくつかの大きなセキュリテ サービスのセキュリティを確保することは、サービスプロバイダーにセキュリティ強制層を構築し、サービスコンシューマーにセキュリティ実装層を構築す

Webサービスのセキュリティリスクを理解する良い方法は、従来のグリーンスクリーンメインフレームアプリケーションに戻って考えることです。 これらのアプリケーションで必要な唯一のセキュリティは、アプリケーションにアクセスできる場合は、ログインセキ これらのアプリケーションには、最新のアプリケーション（インターフェイス、ビジネスロジック、データサービス）と同じ基本的な部分が含まれていましたが、 Webサービスの世界では、コア-データ-サービスの一部がサービスとして公開される可能性が高く、ビジネス-ロジックの一部は確かに公開されるべきであり、アプ つまり、個別に公開するサービスを保護することが重要であり、アプリケーションの内部に依存して独自のセキュリティを確保することはできません。

では、Webサービスを保護するとはどういう意味ですか？ 他のアプリケーションに適用されるのと同じ5つのセキュリティプリンシパルがWebサービスにも適用されます:

• 認証-サービス要求者のidを知っていることを確認します（また、要求者が連絡しているサービスのidを知っていることを確認します）。 Http基本認証のような単純なアプローチから、SAMLやX.509署名のようなより複雑なメカニズムまで、要求を認証するための複数の異なるWebサービス標準があ 優れたWebサービスセキュリティツールは、これらのさまざまなオプションをすべてサポートする必要があります。
• 承認–要求元が要求しているサービスまたは操作へのアクセスを許可されていることを確認します。 承認は複雑な問題であり、利用可能なさまざまなポリシー決定製品の数があります。 ほとんどの大企業には承認のための既存のソリューション（CA SiteMinder、IBM TAMなど）があり、優れたWebサービス-セキュリティ-ソリューションはこれらと統合し、独自の認
• プライバシー–許可されていない第三者が要求および応答メッセージを読み取ることができないようにします。 これは、XML暗号化のような標準が独自に登場する場所ですが、XML暗号化を正常に使用するためには、Webサービスセキュリティソリューションは、効果的なキーと証明書の管理と配布機能を提供し、理想的にはコンシューマー開発者を支援するためのクライアント側のツールを提供する必要があります。
• 否認防止-要求者が要求の送信を拒否できないこと、およびサービスが応答の送信を拒否できないことを確認します。 これはXML-Signatureの役割であり、プライバシーと同じキー管理と配布の規定があります。
• 監査–必要に応じて、システムが要求と応答の正確かつタイムリーな記録を維持できることを確認します。

Webサービスのセキュリティに関する興味深い質問と議論のポイントは、このセキュリティをどこに適用すべきかです。 一部のベンダーは、セキュリティは中央にデプロイされたプロキシのクラスタを通じて強制される中心的な機能であるべきであると主張し、他のベンダーは、サービスプロバイダーまたはコンテナのドメインのみであるべきであると主張するでしょう。 現実はもちろん、これら二つの位置の間のどこかにあります。 外部の脅威から保護するために、ネットワークのエッジで認証および脅威検出サービスを提供する際には、プロキシ（またはプロキシのクラスター）には確かに重要な役割があります。 また、最後の1マイルまでのサービスのセキュリティを確保するために、プロバイダーまたはコンテナベースのセキュリティにも同様に重要な役割があ

多くの企業は、セキュリティ上の脅威の大部分が外部ではなく企業の内部にあることを示す研究を見落とす傾向があり、したがって、ファイアウォー Akanaは、集中型またはネットワークエッジセキュリティ機能を実行する高性能プロキシと、展開されたサービスのラストマイルセキュリティを確保するた

Webサービスのセキュリティ確保が必要です:

• 完全に機能するコンテナ内エージェントを展開してラストマイルのセキュリティを確保し、暗号化操作の負荷を分散する
• ルーティングとネットワークエッジセキュリティ強制のための高性能ネットワーク仲介者を展開する
• 包括的な鍵と証明書の管理と配布を提供して、サービスプロバイダとコンシューマー開発者が必要なセキュリティポリシーを正常に実装できるようにする
• コンシューマー開発者ツールキットを提供して、エンタープライズセキュリティの検出と実装の複雑さからコンシューマー開発者を抽象化する。 ポリシー

関連する読書:APIセキュリティのベストプラクティスについての詳細をご覧ください。

Manage

SOAへの7つのステップアプローチに三つのステップを導入し、エンタープライズSOAから真の価値を達成するためにいくつかの進歩を遂げ始めています。 私たちにはいくつかのサービスがあり、レジストリに公開され、潜在的なユーザーによって発見される可能性があり、安全であることが保証されています。 他に何が必要なのでしょうか？

この質問に答えるために、まず潜在的な災害シナリオを検討する必要があります。 私のサービスが彼ら自身の成功の犠牲者になるとどうなりますか？ I.e. サービスは非常に人気があり、それを消費するいくつかの（数十、または数百、または数千）異なるアプリケーションがあり、負荷の下でバックルを開始します。 私たちは突然、何十、何百、何千ものアプリケーションが失敗しているか、パフォーマンスが不十分であり、その理由や停止方法がわかりません。

サービスが通常の動作パラメータ内で実行されているかどうかを把握し、容量計画モデルを実装することによって潜在的な問題が発生する前に見

私たちが展開する監視ソリューションは、基本的な可用性、パフォーマンス（応答時間）、スループットのためにサービスを監視し、コンテンツやユーザーベースの監視 特定のSLAしきい値を監視および警告できる必要があり、同じサービスまたは操作の異なるユーザに異なるSlaを適用できる必要があります。

多くのベンダーは、このカテゴリの製品をWebサービス管理ソリューションとして定義していますが、多くのアナリストは、管理は単純な監視ソリューションよりもはるかに広範であり、次のステップで説明する機能の多くを含めるべきであると同意しています。

理想的には、もちろん、エージェントや仲介者を介してメッセージを傍受するたびに、別のパフォーマンスのボトルネックが追加されるため、セキュリティと監視のために別々のソリューションを展開する必要はありません。 このため、AkanaのService ManagerはNetwork Directorと組み合わせて、包括的なSOAセキュリティ、監視、管理プラットフォームを単一の高性能で展開が容易なソリューションで提供し

一部のWebサービス管理(監視)ベンダーは、Bamは多くのバックオフィスシステムやフロントオフィスシステムやデータベースとの統合を必要とする複雑なソリ コンテンツのWebサービスの相互作用を監視することは、エンタープライズBAMソリューションの代替として考慮すべきではありません。

関連読書: AkanaのエンドツーエンドのAPI管理ソリューションの詳細をご覧ください。

5. 仲介と仮想化

この時点で、私たちのSOAはゴールデンタイムの準備ができているように見えます。 そして、それは少なくともしばらくの間、です。..

SOAが成熟するにつれて、次の一連の課題が発生します。 新しいバージョンのサービスを導入したり、複数のインスタンスを実行してサービスの容量を増やしたり、サービスの特定のインスタンスを使用するよう

これがサービス仮想化の出番です。 仮想化は複雑に見えますが、現実は非常に簡単です。 仮想サービスは、独自のWSDLによって定義され、独自のネットワークアドレスとトランスポートパラメータを持つ全く新しいサービスです。 単に1つまたは複数の物理サービス、ルーティング、負荷分散、変換、および異なる要求メッセージタイプと標準間の仲介のプロキシとして機能します。

表面的には単純ですが、仮想化の概念は非常に強力です。 これは、物理的なサービスの任意の直接の知識からサービス消費者を完全に抽象化する機能を提供します。 たとえば、仮想サービスを介して、HTTP経由でSOAPを使用した信頼性の高いメッセージング-プロトコルのMicrosoft実装を使用する.NETクライアントは、メインフレーム-アプ .NETクライアントは、信頼性の高いメッセージングプロトコルをサポートするhttpサービスとの通信であると信じ、メインフレームアプリケーションは別のネイ

仮想サービスは幅広い機能を提供します:

• xml変換テクノロジを使用すると、コンシューマーは、古いバージョンと展開された新しいバージョンの間で要求メッセージと応答メッセージを変換することによ
• 複数の異なるサービスから特定の操作を選択し、それらを使用するアプリケーションの特定のクラスの単一の機能WSDLに結合することができます。
• 異なるクラスのユーザーに対して異なるポリシー要件を提供することができます（つまり、 1つのポリシーセットを持つ内部ユーザー、および外部コンシューマーに対して異なるポリシーセットを強制するサービスの別の実装）。
• 互換性のないトランスポート(httpやJMSなど)でサービスとコンシューマーにトランスポートブリッジを提供できます。 •それらは標準の異なった実施また更に版の間で仲介してもいいです。
• RSS、SOAP、REST、POX(Plain Old XML)など、さまざまなメッセージングスタイル間で仲介することができます。
• これらは、高度な負荷分散と高可用性機能を提供するために、強力なコンテンツベースまたはコンテキストベースのルーティングを提供できます。

仮想サービスの一番下の行は、ルーティングやその他の高度なWebサービスに必要であり、すぐにエンタープライズSOAの不可欠な部分になるということです。

Govern

7つのステップのうち5つが完了すると、エンタープライズSOAはかなり準備ができています。 これで、信頼性の高い負荷分散された方法で幅広いユーザーが利用でき、簡単に検出できる、安全で管理されたサービスが得られました。

次のステップは、最初の5つのステップで提供されたすべての機能をガバナンスフレームワークで結びつけることです。 ガバナンスは過度に使用され、誤用されている作業なので、ガバナンスの定義を簡単に見てみましょう。 再びウィキペディアから：

ガバナンスという用語は、組織や社会が運営するプロセスやシステムを扱っています。 多くの場合、政府は、これらのプロセスやシステムを管理するために設立されています。

この定義から取るべき重要な点は、ガバナンスはプロセスとシステムに関するものであるということです。 SOAガバナンスの場合、アーキテクチャレビューボードのような組織プロセスと、このブログで議論されているレジストリ、セキュリティ、管理技術のようなシ

SOAのガバナンスは、多くの場合、デザインタイムガバナンスとランタイムガバナンスの二つの別々の部分に分かれています。 設計時に、組織は、公開できるサービスの種類、公開できるユーザー、これらのサービスが受け入れることができるスキーマとメッセージの種類、およびサービスに関す 実行時には、組織はサービスのセキュリティ、信頼性、パフォーマンスを確保し、サービスが定義されたエンタープライズポリシーに準拠していることを確認す 設計時のガバナンスは興味深いものであり、組織化された、適切に設計されたSOAを確実にするのに役立ちますが、実行時のSOAのアクティブな制御と比較

Akanaのサービスマネージャーは、業界をリードするランタイムガバナンスプラットフォームであり、セキュリティ、監視、管理、仲介、およびレジストリの包括的なソリ ランタイムガバナンスは、基本的に、このドキュメントで説明されているSOAへのさまざまなステップの適用を制御および監視するための単一のフ これは、サービスレジストリ、セキュリティ、管理、および仲介に監督を提供する単一の包括的なソリューションを提供します。 優れたランタイムガバナンスソリューションは、SOAのアクティブな参加者全員にツールを提供するワークベンチの一形態として現れます。

• サービス開発者: 6827>
• サービスコンシューマー:サービスの検出、選択、アクセスワークフローを容易にするツール
• 運用スタッフ:サービスのパフォーマンスを監視するツール、問題のトラブルシューテ6827>
• エンタープライズアーキテクト: 6827>
• エンタープライズIT管理:再利用メトリック管理、サービス再利用メトリック、SOA統計

ESBとのSOA統合

SOAに向けた最後の6つのステップの結果を振り返ってみると、他に何ができるのだろうかと疑問に思っている。 今では、レジストリで公開され、安全で管理され、信頼性が高く、疎結合された一連のサービスがあり、すべてが堅実な設計とランタイムガバナンスソリューシ

一部の企業の最後のステップは、1つ以上のEnterprise Services Bus(ESB)実装を展開して、サービスを高レベルの複合サービスまたはオーケストレーションされたサービスに統合することです。 これらのEsbは、多くの場合、Oracle eBusiness applicationsやSAPなどのより広範なアプリケーション・スイートの一部として提供されます。 いくつかの特殊なEsbは、複雑な複合サービスを作成するために使用される可能性があり、ビジネスプロセス管理（BPM）の領域に拡張されます。

関連読書：Akanaの統合ソリューションについての詳細をご覧ください。

エンタープライズ-サービス-バス(ESB)は、ますます人気のある概念です。 もともとメッセージ指向ミドルウェアとeai(enterprise application integration)ソリューションの両方の進化として考案されたESBは、組織によって非常に異なることを意味します。 Esbは、レガシーアプリケーションとの接続を確保するためのeaiツールから取られたアダプタ、信頼性の高い配信を確保するためのメッセージ指向のミドルウェ

アナリストの間でのコンセンサスは、ほとんどの組織が複数のベンダーから複数のESBプラットフォームを持ち、独自のコンテキストでサービスを提供することになるということである。 この環境では、Esbが中央のSOAインフラストラクチャを使用して、公開および消費するサービスのセキュリティおよびメッセージングポリシーに一貫した

AkanaのService Manager製品とNetwork Director製品を組み合わせて、企業内の複数のESBインスタンスのガバナンスと仲介のための完全なソリューションを提供します。

SOAの略とSOAの重要なステップについてもっと知ったので、Akana in actionをチェックしてください！

トライアル開始