付録B 添付資料 B: サービス指向アーキテクチャーの概要

JBossESB はサービス指向アーキテクチャー (SOA) インフラストラクチャーです。SOA はアプリケーション開発で人気があるアーキテクチャーパラダイムです。SOA の原則は長年存在し、Web サービスの使用を必要としませんでしたが、SOA は Web サービスの使用によって広まりました。
Web サービスは業界標準のネットワークおよびアプリケーションのインターフェースとプロトコルを使用して他のアプリケーション (または他の Web サービス) を利用できる機能を実装します。SOA はソフトウェアコンポーネントが他のソフトウェアコンポーネントによって活用できるサービスとして機能を提供する手法に準拠します。コンポーネント (またはサービス) は再利用可能なソフトウェアのビルディングブロックを表します。
企業の意識がコスト削減にのみ集中する状態からようやくより安定的なコスト管理に移ってきたなかで、多くの企業は今まで経験したことがない状況に直面しています。現在の経済不況以前は、ほとんどの企業が IT 投資の選択肢を理解していました。多くの企業が主要なパッケージ実装 (Siebel、PeopleSoft など) を導入する一方で、他の企業は長年使用してきたレガシーシステムを元にしてシステムを構築していました。どちらの方法でもほとんどの企業が約束されたリターンを認識し、投資を行っていました。今現在はこのような大規模な投資への意欲は失われました。
ただし、企業は依然として前進し、競争に勝つ必要があります。SOA (およびこれらの原則の具体的な実装としての Web サービス) はこれを可能にします。結果として、ユーザー、アプリケーション、およびテクノロジコンポーネント間のコラボレーションが大幅に改善され、どのようなビジネスにも大きな価値が生み出され、競争力が強化されます。
SAP、PeopleSoft などさまざまなベンダーのソフトウェアを使用している企業を考えてみてください。他社 (顧客、供給業者など) とビジネスを行うにはこれらのいくつかのソフトウェアパッケージが役に立つかもしれません。したがって、企業はこれらの既存のシステムをサービスとして公開することにより他社が利用できるようにします。このサービスはクライアント (他のソフトウェアコンポーネント) が呼び出すことができる安定した公開インターフェースを持つソフトウェアコンポーネントです。したがって、サービスを要求および実行するには、ある企業が所有するソフトウェアコンポーネントが他の企業が所有するコンポーネントと対話する必要があります (ビジネスツービジネス (B2B) トランザクション)。
このような組織間のやり取りに対して従来の分散システムインフラストラクチャー (ミドルウェア) は十分ではありません。
  • ミドルウェアプラットフォームに関係する者の間で同意が必要になります。
  • これらの関係者間には暗黙的な (場合によっては明示的な) 信頼の欠如が存在します。
  • ビジネスデータは機密性が高く、想定された受信者のみによって参照されるべきです。
  • 組織間の対話処理では従来のミドルウェアで前提としていたことの多くが無効です。たとえば、トランザクションは長時間 (数時間または数日) 継続するため、2 フェーズコミットなどの従来のトランザクションプロトコルは適用できません。
したがって、B2B 交換では、複数のミドルウェアプラットフォーム間での標準化が存在しないため、ポイントツーポイントを実現するのにコストがかかります。インターネットにより標準的な対話プロトコル (HTTP) とデータ形式 (XML) が提供されこれらのいくつかの問題は緩和されましたが、インターネットのこれらの標準自体はアプリケーション統合をサポートするのに十分ではなく、インターフェース定義言語、ネームおよびディレクトリサービス、トランザクションプロトコルなどを定義しません。Web サービスは Web が提供するものとアプリケーション統合が必要とするものの違いを解消しようとします。
ただし、SOA の最終的な目標は企業間の対話処理であり、インターネットを使用してサービスにアクセスする必要はありません。サービスはローカルネットワークに存在するクライアントが簡単に利用できます。1 つの企業内で稼働する複数のシステムを統合するために Web サービスがこのように使用されることは一般的です。
企業内および企業間で Web サービスがどのようにアプリケーション同士を接続するかを理解するために、スタンドアロンの在庫システムを考えてみてください。このシステムを他のシステムに接続しない場合、その本来の価値は限定されます。システムは在庫を追跡できますが、それ以外のことはできません。在庫情報は会計および顧客関係管理システムに別々に入力しなければなりません。在庫システムは自動的に供給業者に発注できません。このような在庫システムの利点は高いオーバーヘッドコストによって少なくなります。
しかし、在庫システムを XML を使用して会計システムに接続すると、興味深い結果が得られます。この場合、何かを購入または販売するたびに在庫の結果とキャッシュフローを 1 つのステップで追跡できるようになります。さらに倉庫管理システム、供給業者の発注システム、運送業者を XML を使用して接続するとすぐに、在庫管理システムは多数の価値を生み出すようになります。この場合、ビジネスのエンドツーエンド管理を行うことができ、影響を受ける各システムに対してではなく各トランザクションを 1 度だけ処理するだけですみます。作業が大幅に削減され、エラーの発生も大幅に減少します。これらの接続は Web サービスを使用して簡単に行えます。
ビジネスは以下のものを含む SOA の利点を理解しはじめています。
  • パートナと簡単に接続することにより、新しいビジネスチャンスが生まれます。
  • ソフトウェア開発の時間を削減し、他の企業によって作成されたサービスを使用することにより時間とお金を削減します。
  • 独自のサービスを簡単に利用できるようにすることにより収益ストリームが増加します。

B.1. SOA とは

問題は一般的に過去の IT 投資の eProcurement、eSourcing、サプライチェーン管理、顧客関係管理 (CRM)、インターネットコンピューティングの領域に分類できます。これらのすべての投資は 1 つのサイロで行われました。短期の (戦術的な) 要件を満たすためにこれらシステムが増大し、これらの領域に対して下された決定によりアプリケーションとインフラストラクチャーの長期的な実現できなくなりました。
SOA 手法を実装する 3 つの主要な理由は以下のとおりです。
  1. コスト削減: サービス同士が対話する方法によって達成されます。直接的なコスト効果は、向上した処理の生産性、効果的なソースオプション、現在のコストを可変モデルにシフトする大幅に拡張された機能をによってもたらされます。
  2. 標準に基づいた手法をとることにより、組織は以前よりも非常に迅速かつ簡単に情報/ビジネスプロセスを接続および共有できるようになります。標準的なフレームワークとインターフェースを提供することにより開発者の役割が単純化され IT 導入の生産性が大幅に向上します。個別機能の統合負荷を緩和し、環境内で高速な導入テクニックを適用することにより導入時間は大幅に短縮されます。
  3. Web サービスを使用すると、新しいビジネスモデルを実現でき新しいビジネスチャンスが生み出されます。Web サービスは従来の機能と利益に基づく方法とは大きく異なり価値と離散的なリターンを測定できる機能を提供します。通常の TCO (総所有コスト) モデルでは過去の投資から生まれた生涯の価値が考慮されません。コスト中心のこの観点により、これらの過去の投資を活用する多くのチャンスが失われ、結果的にほとんどの企業が必要性からではなく予見されたニーズのためにアーキテクチャーで冗長性を構築することになってしまいます。これらの同じ組織はインフラストラクチャーのオーバーヘッドによって調整されたアプリケーションのポートフォリオに IT 投資の価値を見出します。Web サービスに基づいた方法では、過去の IT 投資の生涯貢献度が考慮され、計画的なシステムの置き換えではなくこれらの投資の発展が促進されます。
SOA/Web サービスはエンタープライズソフトウェアの開発およびデプロイ方法を根本的に変えます。SOA は進化し、新しいアプリケーションはモノリシックな方法で開発されず、従来の方法により引き起こされた現在の経済的および技術的なボトルネックを解消する仮想オンデマンド実行モデルになります。
作業を効率化し、所有コストを削減し、市場で競争力を持ち、差異化を図りたい先進的な企業にとってサービスとしてのソフトウェアは一般的なモデルです。Web サービスを使用すると、企業はソフトウェアの取得から大きな利益を生み出し、急速に変化する市場に対応し、ビジネスパートナーといつでも取引を行えるようになります。疎結合の規格をベースにしたアーキテクチャーはネットワークで利用可能なソフトウェアリソースを活用できる分散コンピューティングの 1 つの方法です。ビジネスプロセス、プレゼンテーションルール、ビジネスルール、データアクセスを独立した疎結合レイヤに分離することは、より良いソフトウェアを構築するだけでなく今後起こる変更に対応するためにも役に立ちます。
SOA により、既存の機能と新しい開発成果を組み合わせて複合アプリケーションを作成できます。このように既存の機能を再利用することにより、プロジェクトのリスクの低下、導入時間の短縮、ソフトウェアの全体の品質の向上が実現されます。
疎結合により、モノリシックな方法を使用したコストがかかる移行に関連するリスクを負わずに部品を独自のペースで変更できるようになります。SOA により、ビジネスユーザーは技術的な制約を気にせずに現在直面しているビジネス上の問題に集中できます。ソリューションを開発する個人にとって SOA は以下の点で役に立ちます。
  • ビジネスアナリストはビジネスドメインの知識を増やしつつ開発ライフサイクルの高位の仕事に集中できます。
  • 複数のチームが取り組むことができるコンポーネントベースのサービスに機能を分けることによって並列開発が可能になります。
  • 品質保証や単体テストが効率的になります。エラーは開発ライフサイクルの初期に検出できます。
  • 開発チームはリスクを増やさずに初期の要件から内容を変更することもできます。
  • アーキテクチャー内のコンポーネントは再利用可能な資産でありその部品を再び作成する必要はありません。
  • サービスの機能分解やビジネスプロセス関連の基盤コンポーネントで、柔軟性、今後の管理や統合のしやすさを保ちます。
  • セキュリティルールはサービスレベルで実装されるため、企業内の多くのセキュリティ懸念事項を解決できます。

B.2. SOA の基本

従来の分散コンピューティング環境は密接に結合され、変化する環境に十分に対応できません。たとえば、アプリケーションが他のアプリケーションと対話する場合にいずれかのシステムのデータ型が変更されると両方のアプリケーションがどのようにデータ型やデータエンコーディングを処理するかが問題となります。互換性がないデータ型はどのように処理されるのでしょうか?
サービス指向アーキテクチャー (SOA) はリクエスター、プロバイダー、ブローカーの 3 つの役割から構成されます。
サービスプロバイダ
サービスプロバイダはサービスへのアクセスを許可し、サービスの説明を作成し、サービスブローカに公開します。
サービスリクエスター
サービスリクエスターはサービスブローカーによって提供されたサービスの説明を検索することによってサービスを探します。また、リクエスタはサービスプロバイダーによって提供されるサービスにバインドします。
サービスブローカ
サービスブローカーはサービスの説明のレジストリをホストし、リクエスターをサービスプロバイダに関連付けます。

B.3. SOA の利点

SOA は分散エンタープライズシステムに複数の大きな利点を提供します。最も注目すべき利点には相互有用性、効率性、標準化などが含まれます。これらについてはこのセクションで簡単に説明します。

B.3.1. 相互運用性

相互運用性は、データと機能を共有することによってさまざまなシステムのソフトウェア同士の通信を可能にします。SOA と Web サービスは Web とインターネットスケールコンピューティングと同様に相互運用性に大きく基づきます。ほとんどの企業はその存続期間において数多くのビジネスパートナーと取引を行います。SOAP などの Web サービステクノロジを使用すると、新しいパートナーを得るたびに 1 つのインターフェースを作成するだけですみます。したがって、パートナーは UDDI を使用してサービスを動的に見つけ、SOAP を使用してバインドできます。また、自社のネットワーク内に Web サービスを導入することによりシステムの相互運用性を拡張することもできます。システムに Web サービスを追加すると、統合コストを削減し、コミュニケーションと顧客ベースを増大させることができます。
重要なのは業界が Web Services Interoperability Organization を創設したことです。
「Web Services Interoperability Organization はプラットフォーム、アプリケーション、およびプログラミング言語間の Web サービスの相互運用性を促進するために設立されたオープンな組織です。この組織は相互運用可能な Web サービスを開発するためのガイダンスや推奨される慣習を提供したり、リソースを提供したりすることにより多様な Web サービスのリーダーが顧客のニーズに応えることができるよう支援します。」 (www.ws-i.org)
WS-I は実際には Web サービスが業界標準と同様に WS-I 標準に準拠するかどうかを判断します。整合性や信頼性を確立するために企業は WS-I 標準に準拠して Web サービスを構築しようとします。

B.3.2. 効率性

SOA を使用すると、既存のアプリケーションを再利用できます。完全に新しいアプリケーションを作成する代わりに、既存のアプリケーションによって公開されたさまざまな組み合わせのサービスを使用してアプリケーションを作成できます。開発者は業界標準のテクノロジを学ぶことに集中できるため作業は効率的になり、新しいテクノロジが現れるたびに時間をかけて学ぶ必要がありません。マネージャにとってこれは新しいソフトウェアを購入し、新しいスキルを持った開発者を雇用するコストが削減されることを意味します。この手法により、開発者は変化するビジネス要件に対応し、プロジェクトの開発サイクル期間を短縮できるようになります。一般的に SOA を使用するとアプリケーションの再利用、開発者の学習時間の短縮、全体的な開発プロセスの短縮が可能になり効率が向上します。

B.3.3. 標準化

標準化を実際に図るには、その標準が業界の多数によって認められ使用される必要があります。1 つのベンダやベンダの小規模なグループがテクノロジや仕様の進化を支配することがあってはなりません。業界リーダーの全員とは言わないまでもそのほとんどが Web サービス仕様の開発に参加します。ほとんどの企業は何らかの形でインターネットと World Wide Web を使用します。WWW の基礎となるプロトコルは当然 HTTP です。Web サービスの基礎は HTTP と XML に基づいて構築されます。SOA では特定の実装フレームワークを必要としませんが、相互運用性が重要であり、SOAP は優れたすべての SOA 実装がともに使用する複数のプロトコルの 1 つです。

B.3.4. ステートフルおよびステートレスサービス

Web サービスのほとんどの提唱者は、アーキテクチャが Web のようにスケーラブルかつ柔軟であることが重要であると認識しています。結果として、Web サービスの現在の対話パターンは粒度が粗いサービスやコンポーネントに基づきます。アーキテクチャは意図的にサービスエンドポイントの背後で起こることについて規定していません。Web サービスは究極的には関係者間の構造化データの転送とこのような転送を (メッセージの暗号化やデジタル署名などによって) 保護するメタレベルの情報にのみ関係します。これにより、実装の柔軟性が提供され、ユーザーに直接影響を与えずにシステムが要件やテクノロジの変更に適応できるようになります。また、ほとんどの企業はさまざまな理由からバックエンド実装の決定や方針をユーザーに公開したくありません。
CORBA、J2EE、DCOM などの分散システムでは、通常対話はコンテナ内に存在するステートフルオブジェクト間で行われます。これらのアーキテクチャーでは、オブジェクトは個別に参照されるエンティティとして公開され、特定のコンテナ、したがって多くの場合は特定のマシンに関連付けられます。ほとんどの Web サービスアプリケーションはオブジェクト指向言語を使用して作成されているため、そのアーキテクチャを Web サービスに拡張することを考えるのは自然です。したがって、サービスは、特定の状態を表す Web サービスリソースを公開します。結果として、このようなアーキテクチャーによりクライアントとサービスの結合は密接になり、World Wide Web と同等のスケーラビリティを実現することは難しくなります。
現在、Web サービス定義に参加する企業によって定義されるセッションコンセプトには、WS-Addressing EndpointReferences (ReferenceProperties/ReferenceParameters とともに使用) と WS-Context の明示的なコンテキスト構造の 2 つの主要なモデルが存在します。これら両方のモデルは JBossESB 内でサポートされます。WS-Addressing セッションモデルは Web サービスエンドポイント情報とセッションデータ間の結合を提供し、分散オブジェクトシステムのオブジェクト参照に類似します。
WS-Context は HTTP サーバー、トランザクション、MOM システムで存在するセッションモデルが進化したセッションを提供します。その一方で、WS-Context を使用するとサービスクライアントがサービスとの関係を動的および一時的にバインドできるようになります。サービスに対するクライアントの通信チャネルは特定のセッション関係によって影響されません。
これは、Web サービスを内部デプロイメントからインターネットで提供されている一般的なサービスにスケーリングするときに重要になります。Web サービスの現在の対話パターンは粒度が粗いサービスまたはコンポーネントに基づいています。アーキテクチャーは意図的にサービスエンドポイントの背後で起こることについて規定していません。Web サービスは究極的には関係者間の構造化データの転送とこのような転送を (メッセージの暗号化やデジタル署名などによって) 保護するメタレベルの情報にのみ関係します。これにより、実装の柔軟性が提供され、ユーザーに直接影響を与えずにシステムが要件やテクノロジの変更に適応できるようになります。また、サービスがユーザーや (一時的にバインドされる) その対話を代表してステータスを保持するかどうかなどの問題は実装によって異なり、通常はユーザーに公開されません。
ステートフルサービスと対話するときに WS-Addressing に基づくセッション形式のモデルを使用する場合は、ステータスとサービス間の密接な結合によりクライアントが影響を受けます。このモデルが使用されている他の分散環境 (CORBA や J2EE など) と同様に、クライアントがサービスエンドポイントに対して持つリモート参照 (アドレス) は以降の起動のためにクライアントによって記憶されなければなりません。クライアントアプリケーションが同じ論理セッション内の複数のサービスと対話する場合、サービスは他のサービスの関連付けられたステータスとともに使用する場合のみクライアントに影響します。つまり、クライアントは各サービス参照を記憶し、特定の対話と何らかの方法で関連付ける必要があります。したがって、複数の対話の結果として、さまざまな参照セットを組み合わせて各セッションを表すことができるようになります。
たとえば、同じアプリケーションセッション内で N 個のサービスが使用され、各サービスが m 個の異なるステータスを保持する場合、クライアントアプリケーションは N*m 個の参照エンドポイントを保持する必要があります。初期サービスエンドポイント参照が UDDI など一部のブートストラッププロセスから取得されることがよくあることに注意してください。ただし、このモデルではこれらの参照はステートレスであり、アプリケーション対話を開始する以外は役に立ちません。これ以降に特定のステータスへのアクセスが必要なこれらのサイトにアクセスする場合は、WS-Addressing モデルで異なる参照を使用する必要があります。
これにより、当然 Web のサイズの環境にスケーリングされませんが、代わりに WS-Context を使用して Web サービスの疎結合の性質を引き続き受け継ぐことができます。これまでに示したように、一連のサービスとの各対話はセッションとしてモデル化でき、セッションは関連付けられたコンテキストを持つ WS-Context アクティビティとしてモデル化できます。クライアントアプリケーションが同じセッション内の一連のサービスと対話するときは、コンテキストがサービスに必ず伝播され、このコンテキストはクライアントとの対話で必要なステータスにマッピングされます。
このマッピングがどのように行われるかは実装によって異なり、クライアントに公開する必要はありません。また、特定のセッション内の各サービスは同じコンテキストを取得し、これらのサービスに後で再びアクセスしたときに同じコンテキストが再び提供されるため、クライアントアプリケーションは必ず正しいステータスセットに戻ることができます。したがって、前述した例の N 個のサービスと m 個のステータスの場合、クライアントは N 個のエンドポイント参照のみを必要とし、これまでに述べたように通常これらのエンドポイント参照はブートストラッププロセスから取得されます。この結果、このモデルのスケーリングは大幅に向上します。