エンタープライズシステムは、モノリシックストレージから、柔軟な使用パターンを持つサービスに基づく分散アプリケーションへと急速に進化しています。 IT組織は、最新の状態を維持するために、変化するビジネス要件にほぼリアルタイムで、事実上2回目のチャンスなしに、古いアプリケーションを適応させる必要があります。サービス指向アーキテクチャ（SOA）は、運用の柔軟性とビジネスプロセスとサブシステムのフェデレーションをサポートするために進化しました。著者のNicolas Serrano、Josune Hernantes、およびGorka Gallardoが、SOAテクノロジーの現在の状態の概要と、既存の環境での進化方法を提供します。

クリストフ・エバートによる序文

現代のビジネスは、市場の要件に柔軟かつ迅速に適応できる必要がありますが、プロセスのわずかな変更でさえ、もともとモノリシックリポジトリとして開発された多くの情報システムの処理につながる可能性があります。競争力を維持するには、サポートコストを常に削減し、システムを常に進化させる必要があります。 SOAは、モノリシックシステムからサービス指向への移行を可能にします。これにより、柔軟性、接続不良、および抽象化と実際のインフラストラクチャの分離が促進されます。 SOAを使用すると、サービスの発見と再利用の機会がはるかに多くなります。追加の機能と原則は、SOAマニフェストに記載されています。 ^{[1] [2]}

SOAの新規性は、アプリケーション全体に焦点を当てるのではなく、サービスベースのアーキテクチャインフラストラクチャがどのようにモデル化されるかです。サービスは、1つの問題を解決する小さな独立したソフトウェア要素であり、多くのアプリケーションで再利用できます。 SOAは疎結合の原則に基づいています。つまり、各サービスは、データベース、レガシーアプリケーション、さまざまなAPIなど、他の共有リソースへの依存関係が制限された独立したエンティティです。このアーキテクチャソリューションにより、消費者と作成者の間に抽象化レベルを作成できます。これには、サービスの利用者を害することなく、実装と更新の自由が伴います。はい、SOAにはビジネスにとって多くの利点がありますが、これはすべての場合に最適なソリューションではありません。このアプローチの利点には、次の点があります。

プラットフォームやテクノロジーに関係なく、さまざまなサプライヤーのサービスを統合することにより、複雑なモジュラーシステムを作成する自然な方法。
疎結合システムにプッシュし、古いシステムでの作業を支援します。
サービスを再利用することで効率を高め、開発コストと時間を削減します。
既存のアプリケーションの異なるレイアウトを使用して多くのサービスを開発できるため、柔軟性とスケーラビリティが向上します。
ソリューションのサポートに関連するコストを削減できます。
システム間の標準通信プロトコルを開発できます。
データへのアクセスはユーザーの地理に依存せず、モバイル通信を使用できます。
システムの一部の段階的なコミッショニングの可能性。これにより、ビジネスニーズに迅速に対応できます。

マイナスには以下が含まれます。

サービス間の非同期相互作用を実装することは困難です
XMLは速度ではなく信頼性を提供するため、リアルタイム応答を実装するのは難しく、時間がかかります。もちろん、JSONの形式で代替があります
多くのアプリケーションとシステム間でデータを交換するプロセスに関連するさまざまなセキュリティの脆弱性。
論理的に異なるシステムの相互作用に関連する複雑なトランザクション管理プロセス。

サービス指向アーキテクチャへの切り替えは簡単なプロセスではありません。 SOAへのアップグレードを希望する企業は、困難と関連する問題を認識している必要があります。移行には多くの妥協が伴い、それぞれに独自の妥協があることは明らかです。より効率的で痛みのない移行を行うには、古いモノリシックシステムからSOAへの段階的（増分）移行をお勧めします。

Webサービス

多くの組織向けのWebサービスの作成は、疎結合の相互作用モデルを構築する最も簡単な方法です。 WSDL、SOAP、UDDIなど、XMLに基づいた一連のオープン標準によって実現されます。これらはすべて、Webサービスの定義、公開、および使用について同じアプローチを提供します。

WebサービスはWebアプリケーションから進化しましたが、実際にはWebアプリケーションを単純化したものです。ユーザーインターフェイスとデータ処理を提供する代わりに、データのみを処理します。クライアントアプリケーションに渡されるデータの表示に対する責任。ただし、多くのシステムはWebサービスを使用しますが、SOAシステムとは呼ばないことに注意してください。

継承されたシステムは、SOAサービスにラップされ、HTTP経由で応答するか、プロキシ（ おそらく ゲートウェイである 可能性が高い -約Per ）で動作し、リクエストを理解できる言語に変換します。結局、HTTPのメッセージはプレーンテキストであり、あらゆるシステムおよびあらゆるプログラミング言語で処理できます。

技術

SOAベースのソリューションを使用すると、より柔軟なアプリケーションを構築できますが、特定の実装テクノロジの選択は、組織のニーズと機能に依存します。ビジネスプロセスをSOAに移行したい組織にとって、最も可能性の高い技術的な考慮事項を見てみましょう。

SOAP vs. REST

Webサービスを設計するとき、情報交換のための一連のルールを定義する必要があります。このための主要なツールは、SOAPとREST ^[3]です。

SOAPは古いプロトコルです。これは、CORBAなどのデバッグ技術のインターネット互換の代替として開発されました。 SOAPプロトコルはさまざまなトランスポート（HTTP、SMTPなど）を使用できるため、柔軟性が向上します。データはXML形式で交換されるため、送信されるデータの量が多い場合、パフォーマンスの問題が発生する可能性があります。 SOAPは、より安全なデータ交換を提供するメッセージの暗号化と署名の標準であるWebサービスセキュリティで使用できます。 ^[4]

RESTはHTTPをトランスポートとして使用する新しいプロトコルですが、いくつかのデータ形式（XML、JSONなど）をサポートしています。 SOAPとは異なり、XMLを解析する代わりに特別なURLに依存します。厳密な実装を意味しないため、実装に柔軟性があり、より軽量で、ドキュメントへの依存度が低くなります。 RESTは、POSTでSOAPが実装されている場合にGETメソッドを使用することもできます。

当然、RESTとSOAPの選択は、組織の制限とニーズに依存します。 SOAPプロトコルは、セキュリティとエラー処理の問題をより深いレベルでサポートしているため、多くの大規模なオンラインストアがSOAPプロトコルを好んでいます。シンプルさ、パフォーマンス、および実装の自由度により、RESTは、APIレベルでインターネットサービスの相互作用に取り組む人々にとって好ましいプロトコルです。

古いソリューションの近代化

SOAアプローチは、エンタープライズシステムとプロトコル^[5]およびプラットフォームとの頭痛の種ソリューションのシームレスな統合のための最良の選択肢かもしれませんが、ほとんどの人は既存のインフラストラクチャを使用することを余儀なくされています。古いシステムをSOAにアップグレードする問題に対する理想的な解決策はありません。それは、全体の要点が微妙な違いにあるためです。リスクとコストを考慮して、企業内の既存の技術スタックを考慮して最適な移行ソリューションを作成する必要があります。

主要なビジネスプロセスはレガシーシステムに関連付けられているため、純粋なSOAへの途中でのハイブリッドシステムの使用を考慮して、エンタープライズシステムの（革命ではなく）進化を考慮した段階的な移行の計画を作成する必要があります。 そして、それらをSOAに変換するためのいくつかの戦略があります。

最初のアプローチは、現在のシステムを新しいシステムまたは一連のシステムに単純に置き換えることです。一般に、市場が要件を完全に満たす完成品を提供する場合、これは通常のアプローチです。このソリューションはサポートコストを削減しますが、将来の変更のコストを大幅に増加させます。（ この世界では、変化のみが一定であるということは誰もが知っている-およそのトランス。 ）
別の方法は、古いシステムのラッパーを作成することです。これにより、Webサービスを介して既存のインターフェイスへのアクセスを提供できます。この場合、古い機能はサービス層で「ラップ」され、SOA環境に「組み込まれ」ます。これは、すべての問題を解決するわけではありません。たとえば、古いアプリケーションはいくつかの可能なサービスを密接に接続できるため、サービスの所望の独立度を達成することは困難です。財政面では、システム全体を書き換えるのに非常に費用がかかる場合、このような動きは機能しますが、ソリューションの一部を再利用でき、予算が制限されます。
最後のオプションは、レガシーシステムを書き換える決定です。アプリケーションのアーキテクチャに影響を与えることができ、一般にサービス間で必要なレベルの独立性を実現する方法を知っている場合、これは良い選択です。ただし、レガシーシステムは通常、ビジネスに不可欠であり、それらを交換するための高コストの難しさは、古いテクノロジの使用とドキュメントの欠如であり、プロジェクトの実装のリスクが増大するリバースエンジニアリングの問題につながります。このオプションの主な難点は、すべてのリスクを理解することです。

エンタープライズ統合

システムのSOA実装への計画的な移行は、サードパーティ製品を使用することで促進できます。しかし、常に起こるように、すべてのオファーはサポートする能力と複雑さが異なるため、正しい選択が不可欠です。統合の複雑さに応じて、すべてのソリューションを3つのグループに分けることができます。

統合フレームワークは、さまざまな開発環境向けに特定のAPIを備えたライブラリを構築する最も簡単な方法です。このようなフレームワークの例には、Apache CamelとJava用のSpring Integrationおよび.NET用のNServiceBusが含まれます。
Enterprise Service Bus（ESB）は、統合フレームワークの可能性と、「戦闘」モードでの展開、管理、および監視のためのツールを提供します。 ESBは、データプロバイダーとコンシューマー間の接続を維持し、さらに高度な抽象化レベルで統合問題を解決するコストと複雑さを大幅に削減する改善されたツールを提供します。 ESBの例には、Oracle Service BusおよびMule ESBが含まれます。
統合パッケージは、ESB機能だけでなく、BPM（ビジネスプロセス管理）、ビジネスプロセス監視、重要なデータ管理、リポジトリなどのビジネス指向ツールも含む完全なツールキットスタックを提供します。これらのすべての機能により、より迅速に変更に対応できます。このようなパッケージを互いに比較することは非常に困難です。

選択をする

明らかに、最良の選択は常にプロセスの特定のニーズと複雑さに依存し、単純なオプションから始まる除外方法によってそのような問題を解決する方が良いです。最初に決定する必要があります。おそらく統合フレームワークが必要なだけです。たとえば、通信を必要とするアプリケーションが2つしかない場合、または1つのプロトコル（REST）のみで作業できる場合は、ツールとサポートが不足しているにもかかわらず、統合フレームワークの形式で最も単純なソリューションを使用できます。それ以外の場合は、ESBの方が適している可能性があります。十分でない場合は、より複雑な統合パッケージの研究に飛び込む価値があります。

次のステップは、SOAソリューションとクラウドサービスの統合を容易にすることです。クラウドには、リソースをオンデマンドで受信する機能があり、データを保存し、サービスを作成し、データを処理するための豊富なツールが既に含まれています。

一般に、今日のビジネスの主な課題はクラウドサービスとの統合です。これに関連して、iPaaS（サービスとしての統合プラットフォーム）は、幅広い統合タスクに適したソリューションとして人気を集めています。 iPaaSは、ユーザーが特別な機器やライブラリをインストールせずに、多くのアプリケーションやデータの統合フローを作成、管理、整理できるクラウドサービスのセットです。

今後、Gartherの研究者は、2016年には、すべての中大企業の少なくとも35％が何らかの形で少なくとも1つのiPaaSソリューションを使用すると予測しています。ただし、専門家はiPaaSがSOAに取って代わるとは言いません。 SOAを使用した従来のソリューションは、メッセージ処理の速度が重要であり、企業内のデータベースと企業間でデータの集中的な交換が行われるシナリオで必要になります。

参照資料

Gold et al。、「Understanding Service Oriented Software」、IEEE Software、vol。 21、いいえ。 2、2004、pp。 71–77。
ジョーンズ、「受け入れられるサービスの定義に向けて」IEEE Software、vol。 22、いいえ。 3、2005、pp。 87–93。
MumbaikarとP. Padiya、「SOAPおよびRESTの原則に基づくWebサービス」、国際J.科学および研究出版物、vol。 3、いいえ。 5、2013、pp。 1–4。
Louridas、「SOAPおよびWebサービス」、IEEE Software、vol。 23、いいえ。 6、2006、pp。 62–67。
Vinoski、「REST Eye for SOA Guy」、IEEEインターネットコンピューティング、vol。 11、いいえ。 1、2007、pp。 82–84。

ソース： http : //www.infoq.com/articles/service-oriented-architecture-and-legacy-systems

記事のトピックがあなたに近い場合、または API を適切に設計、保守、操作する方法について詳しく知りたい場合は 、会議に参加してください APIとバックエンド ！ 伝えるべきストーリーがある場合、 私たちはあなたの物語を待っています ！

サービス指向アーキテクチャとレガシーシステム