特集開発現場からの提言(後編)SOAの導入を成功させる現実的な方法とは?有限会社アークウェイ 黒石 高広2005/12/03 |
|
|
■パブリッシュ/サブスクライブ・モデルによるメッセージ配布
メッセージ配布のモデルとしては、送信元のアプリケーションから送信先のアプリケーションを指定するポイント・ツー・ポイントでのメッセージを送信ではなく、パブリッシュ/サブスクライブ・モデルを適用する。
パブリッシュ/サブスクライブ・モデルとは、メーリングリストと同じように、メッセージを必要とするサブスクライバ(購読者)を事前にリストに登録しておくと、メッセージ・バスに対してパブリッシュ(発行)されたメッセージが、そのサブスクライバへ届くという仕組みである。
パブリッシュ/サブスクライブ・モデルのイメージ図 |
このモデルは、メッセージを必要とするサブスクライバ(購読者)を事前にリストに登録しておくと、メッセージ・バスに対してパブリッシュ(発行)されたメッセージが、そのサブスクライバへ届くという仕組みである。 |
このパブリッシュ/サブスクライブ・モデルを利用することで、メッセージの送り先が変更された場合や、新しいアプリケーションが追加された場合でも既存の実装を変更することなく、リストの登録情報を変更するだけで対処でき、メッセージ・バスの柔軟性を確保することができる。
■メッセージの送受信や処理状況を管理するためのトレーサビリティ
メッセージ・バスでは、メッセージの送受信だけでなく、どのメッセージがどのアプリケーションへ送信・受信され、メッセージが処理されたかを視覚的に判断できるメッセージのトレーサビリティ確保が重要になる。特に、非同期でのメッセージ送受信となるので、どのメッセージが処理されている途中にエラーとなったかを管理者が把握できる必要がある。
このトレーサビリティの機能は、BPM(Business Process Management)の世界では、Business Activity Monitoring(以下、BAM)とも呼ばれている。BAMは、メッセージ・バス上のメッセージ送受信のログ機能ともいえるので、.NETではEnterprise LibraryのLogging and Instrumentation Application Blockを利用するか、オープンソースのlog4netを利用することで実現できる。
以上が、アプリケーション間連携におけるメッセージ・バス構築の際に最低限必要な機能である。
メッセージ・バスに求められる機能だけを見ると、これはマイクロソフトのEAI製品であるBizTalk Serverが標準で備える機能でもある。今回の記事では、より低い導入コストでSOAを実現できるように、アプリケーション間連携に最低限必要な機能だけをメッセージ・バスとして、自社で構築する方法を提案した。
自社でメッセージ・バスを構築するか、BizTalk Serverを導入するかは、導入コストや中央管理と分散管理のどちらのアプローチが自社に適しているか、アプリケーション間連携のさまざまな制約、BPM機能やビジネス・ルール管理機能などが求められるかを考慮し、事前に検討をすべきだろう。4. メッセージ・バスだけでは難しい問題
メッセージ・バスは、イベント駆動型のメッセージ連携を前提としたアーキテクチャであるため、導入する際には既存アプリケーションの改修も必要となる場合がある。特に既存の古いアプリケーションと連携を行う場合、ドキュメントもなくアプリケーション内部を知っている技術者もいないなどの理由で、既存アプリケーションの改修が困難である場合も多い。
ここでは、メッセージ・バスを導入する際に、よく問題となるケースをいくつか取り上げる。
■Webサービス化できない既存アプリケーションへの対応
標準技術であるWebサービスの採用を決定しても、Webサービス化できない既存アプリケーションは当然存在する。このような場合にはEAI製品を利用することで、既存アプリケーションのインターフェイスをWebサービスとして公開できる。
マイクロソフトのBizTalk Serverは、Webサービスに対応しているだけでなく、FTPやSAPとの連携など、さまざまなアダプタを標準で提供する。よって、Webサービス化できない既存アプリケーションとメッセージ・バスとのゲートウェイとしてBizTalk Serverを利用可能である。
メッセージ・バスとBizTalk Serverの連携 |
BizTalk Serverは、Webサービス以外にも、FTPやSAPとの連携など、さまざまなアダプタを標準で提供するため、アプリケーションとメッセージ・バスとのゲートウェイとして利用可能である。 |
このようにメッセージ・バスとBizTalk Serverを連携することで、Webサービス化できない既存アプリケーションとの連携も可能となり、既存アプリケーションと新しいアプリケーション間でも連携を行えるようになる。
■大量データの扱い
Webサービスで連携を行う場合、問題になるのが大量データの扱いである。
そもそもWebサービスの基盤技術であるXMLは、もともとHTMLから派生して生まれた技術であり、タグでデータを囲う(=マークアップする)記述形式であるため、データ量に比例してタグの量も増えてしまうという問題を抱えている。
このようにXMLは大量データを記述するのに向いていないため、大量データのやりとりが必要な場合は、Webサービスではなく、CSVファイルや固定長ファイルなどの別フォーマットを検討した方がよい。
また、アプリケーション間連携で大量データを扱う目的は、あるアプリケーションに蓄積されたデータを異なるアプリケーションへ転送することである場合が多い。このため、データ統合を目的として提供されるETL(Extract, Transform and Load)ツールの検討もお勧めする。
マイクロソフトから提供されているETLツールとしては、SQL Server 2005 Integration Service(SSIS)がある。
SSISは、SQL Server 2000のデータ変換サービス(DTS:Data Transformation Services)機能の後継であり、CSVファイルなどの大量データを読み込んで、ほかのデータベースやデータ・ウェアハウス(DW)などへインポートすることが可能である。特に、大量データを扱っていて、既存アプリケーションの改修が難しい場合は、メッセージ・バスを適用するのではなく、このETLツールの利用が適している。
■リアルタイムな連携
業務要件としてリアルタイムに近い連携を求められるケースもある。特に既存のアプリケーション間連携が同期連携を使っている場合などである。
そのような場合は、例外ケースとして既存連携をそのまま残すか、同期連携のWebサービスなどで置き換える必要がある。これらは、一般的な解答が存在する問題ではなく、顧客の環境や制約などを考慮し、慎重に検討すべき問題である。
以上が、メッセージ・バスを導入する際によく問題となるケースである。アプリケーション間連携の技術はさまざまなものがあるので、メッセージ・バスだけですべてを解決しようとするのではなく、適材適所に技術を使い分けることで問題へ対処した方がよいだろう。
5. 最後に
SOAは1つの考え方であり、実現方法は企業やベンダによってさまざまである。また経営者、業務分析者、システム管理者、開発者などのステークホルダーによって解釈や主張も異なることを忘れてはならない。
一方、SOAを実現するための最新技術に目を向けてみると、Windows Vista(コード名:Longhorn)に搭載される新APIセットのWinFXでは、最新のWS-*標準であるWS-ReliableMessagingやWS-AtomicTransactionを実現するWindows Communication Foundationやビジネス・プロセスを実行するためのワークフロー・エンジンであるWindows Workflow Foundationのリリースが予定されている。これらを利用することで、さらに信頼性の高いメッセージング、柔軟性の高い連携を行うことが可能となるだろう。このようにSOAを実現するための技術は徐々にそろいつつある。
いままさに求められているのは、SOAの考え方を理解し、技術を組み合わせてその考え方をどのように実現し、企業内にどのように適用していくのかという戦略と実行力である。そしてそれは、技術を一番理解し、その考え方を実現することができる開発者が担うべき役割であると考えている。
今回の記事では、SOA実現への取り組みの1つとして、企業内の火防線としての役割も果たすメッセージ・バスの構築を提案した。読者の皆さんも、企業内のアプリケーション連携の現状を分析し、自社に適した形でのアプリケーション連携のあるべき姿やSOAを実現するために必要なことを考えてみてはいかがだろうか。
INDEX | ||
[特集] | ||
開発現場からの提言(前編) | ||
サービス指向アーキテクチャ(SOA)の実際 | ||
1.なぜいまSOAが求められているのか? | ||
2.「SOA=Webサービス」だけではうまくいかない | ||
開発現場からの提言(後編) | ||
SOAの導入を成功させる現実的な方法とは? | ||
1.アプリケーション間連携の現状(AS-IS)とあるべき姿(TO-BE) | ||
2.メッセージ・バスによるSOAシステムの構築方法 | ||
3.メッセージ・バスだけでは難しい問題 | ||
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|