医療サービスの統合: 第 1 回 エンタープライズ・サービス・バスを医療で使用する

多種多様なアプリケーションが相互接続および相互運用できるように Java Business Integration サーバーを構成する

医療サービスの質と効率性を向上させるには、患者に必要な各種のサービスが相互に接続し、相互運用できると理想的です。この 2 部構成の記事の第 1 回では、JBI (Java™ Business Integration) アーキテクチャーによる医療サービスの集約について説明します。このような集約プラットフォーム (HSB (Healthcare Service Bus)) は、他の業界にも簡単に適応させることができます。

Bilal Siddiqui, Consultant

Bilal Siddiqui は、電気工学エンジニア、XML コンサルタント、そして e-business の簡易化を専門とする会社、WaxSys の共同設立者でもあります。1995年に電子工学技術の学位でパキスタンのラホールにある University of Engineering and Technology を卒業した後、産業用制御システムを対象としたソフトウェア・ソリューションの設計を始めました。その後、XML に転向し、C++ のプログラミング経験を生かして Web ベースや Wap ベースの XML 処理ツール、サーバー側の構文解析ソリューション、そしてサービス・アプリケーションを作成しました。テクノロジー・エバンジェリストである彼が書いた技術書は、頻繁に発行されています。



2010年 5月 18日

この 2 部構成の記事では、サービス・バスを使用してさまざまな医療関連のサービスを集約する例を紹介します。このサービス・バスについては、HSB (Healthcare Service Bus) というぴったりの名前で呼ぶことにします。第 1 回ではまず、患者に応じて必要な処置を提供する各種のアプリケーションが HSB に接続されるという 1 つのシナリオを取り上げ、この場合に HSB が満たさなければならない要件について説明します。次に、HSB を構築するために使用する JBI (Java Business Integration) アーキテクチャーを紹介し、JBI サーバーの内部で起こるイベントのシーケンスを追いながら、JBI がビジネスを統合するために内部でどのような動作をするか、そして JBI の各コンポーネントが外部アプリケーションとどのように連携するかを学んでいきます。そして最後のセクションで、JBI コンポーネントの振る舞いを制御し、医療サービスに対処するように構成する例を説明して第 1 回を締めくくります。続く第 2 回では、オープンソースの JBI 実装 (Apache ServiceMix) の既存の機能を使用して新しい ServiceMix 機能を実装することによって、医療サービスを統合する方法について説明します。

医療の場合のサービス・バス

HSB は、多種多様な医療関連のサービスを統合します。例として、救命処置を必要とする救急患者にどのような処置が必要かを考えてみてください (例えば、輸血や、緊急の投薬、放射線テストなど)。

患者が医療施設に運ばれると、担当医はサービス・バスを使用して、患者にアレルギーの病歴があるかどうかを患者の携帯電話でアプリケーションを実行して調べます。それと同時に、サービス・バスに接続された医療処方アプリケーションに患者の状態について初見を入力します。医師によるこの観察内容は、サービス・バスにより、その患者が加入している保険会社のポータルをホストしている Web サーバーに送られます。

続いて医師は、患者への輸血の処方をこの処方アプリケーションに入力します。処方内容は、サービス・バスを介して自動的に数件の血液バンクに送信されるだけでなく、ドナー・グループ・アプリケーションにも送信されます。これは、血液サンプルが患者の血液と適合するドナーに SMS メッセージを送るアプリケーションです。この血液要件もまた、サービス・バスによってドナー・グループ・アプリケーションに渡されます。

さらに、医師が緊急投薬と放射線テストの処方を書くと、その内容も同じく処方アプリケーションに入力されます。処方アプリケーションはこれらの処方を、サービス・バスを介して医療施設内の薬局と放射線科にそれぞれ送信します。

サービスの集約

以上のシナリオから、HSB で各種のアプリケーションが相互接続および相互運用することによってサービスの集約が可能になることがわかります。HSB に接続される主なアプリケーションのタイプは、サービス・コンシューマーとサービス・プロバイダーの 2 つです。輸血の要件を HSB に送信する処方アプリケーションがサービス・コンシューマー (サービスを要求または利用するアプリケーション) の役割を果たし、血液を提供可能なドナーに SMS メッセージを送信するドナー・グループ・アプリケーションがサービス・プロバイダー (要求されたサービスを提供するアプリケーション) の役割を果たします。相互接続と相互運用はそれぞれに異なる要件であり、この 2 つを満たすことによってサービスの集約が実現します。相互接続とは、サービス・プロバイダーとサービス・コンシューマーが共通の方法で互いに接続 (到達) することです。そして相互接続によって、サービス・プロバイダーとサービス・コンシューマーの相互運用 (情報およびメッセージの交換) が可能になります。HSB はよく使われている XML フォーマットを使用して、相互運用可能なメッセージ交換を行います。

SOA としての HSB

HSB のアーキテクチャーのように「サービス」への依存度が高いアーキテクチャーは、サービス指向アーキテクチャー (SOA) と呼ばれます。SOA とは単に、すべてがサービスであることを意味します。ドナー・グループ・アプリケーションは、SMS メッセージを送信するサービスであり、要請に応じて放射線テストを行う放射線科も同じくサービスです。SOA では、サービスを公開するあらゆるアプリケーションがサービス・プロバイダーとなり、サービスを要求、リクエスト、または使用するアプリケーションがサービス・コンシューマーとなります。

図 1 に、HSB に接続されたサービス・プロバイダーとサービス・コンシューマーを示します。

図 1. HSB に接続されたサービス・プロバイダーおよびサービス・コンシューマー
HSB に接続されたサービス・プロバイダーおよびサービス・コンシューマー

図 1 では、HSB に 3 つのアプリケーション (保険会社ポータル・アプリケーション (Insurance company portal application)、ドナー・グループ・アプリケーション (Donor group application)、放射線科アプリケーション (Radiology department application)) が接続されていることに注意してください。サービス・コンシューマーとサービス・プロバイダーが相互運用するには、HSB がサービス・コンシューマーを内部のサービス・プロバイダーにも、外部のサービス・プロバイダーにも接続できなければなりません。図 1 では、放射線科アプリケーションは医療施設内にあり、ドナー・グループ・アプリケーションと保険会社ポータル・アプリケーションは医療施設外部にあります。

HSB が満たさなければならない要件

相互接続を可能にするためには、HSB が以下の要件を満たす必要があります。

  • サービス・コンシューマーからのサービス使用リクエストを適切なサービス・プロバイダーにルーティングできるように、HSB に接続されたすべてのサービス・プロバイダーのログを記録すること
  • サービス・プロバイダーとサービス・コンシューマーがサービス・バスを介して互いにやりとりするための標準メカニズムを提供すること
  • 他の HSB と相互接続できること

HSB 間の相互接続

HSB 間の相互接続は、興味深いアプリケーションです。図 2 に、HSB相互接続のアーキテクチャーを示します。

図 2. HSB 間の相互接続
HSB 間の相互接続

図 2 に示された 2 つの HSB は、それぞれに異なる医療施設を対象としています。一方の医療施設には、血液バンク・アプリケーションがあります。このアプリケーションを、もう一方の医療施設にある処方アプリケーションが呼び出すには、2 つの HSB 間の相互接続を使用します。

医療サービスを相互運用可能にするための XML

医療サービスの相互運用を可能にするには、XML を以下の 2 つの方法で使用することができます。

  • Web サービス: WSDL (Web Services Description Language) および SOAP (Simple Object Access Protocol) をベースにした Web サービスは、医療をはじめとする多くの業界で頻繁に利用されています。WSDL ではサービスを定義する手段 (つまりサービスで提供するインターフェースを定義する手段) として XML を使用します。もう一方の SOAP は、サービス・プロバイダーとサービス・コンシューマーとの間での実際のメッセージングに使用される XML ベースのプロトコルです (WSDL および SOAP についての詳細は、「参考文献」を参照してください)。HSB は、相互運用性のために WSDL と SOAP を使用するあらゆる医療アプリケーションを相互接続できなければなりません。
  • Health Level 7: よく使用されている医療標準を 1 つにまとめた HL7 (Health Level 7) は、医療記録、処方、患者退院の要約などといった医療情報を指定するための多数のデータ構造を定義しています (以前の HL7 バージョン 1 および 2 は ASCII をベースとしていましたが、最近の HL7 バージョン 3.X ではメッセージ構造を定義するためのデータ・フォーマットに XML を使用しています)。

他の業界での HSB の一般化

この記事で説明する相互接続と相互運用の要件は、医療以外の業界にも当てはまります。旅行業界を例に挙げると、ホテル業者、航空会社、レンタカー業者、旅行業者などが多種多様なサービスを顧客に提供するには、相互接続および相互運用する必要があります。HSB に備わった 3 つの相互接続機能は、旅行業界にも適用することができます。また、ホテル業者やレンタカー業者などの異なるサービス・プロバイダーは WSDL と SOAP を使用して簡単に相互運用することができます。さらにどの業界でも、HL7 のような業界固有の XML ベースの標準を使用することができます。

これから説明する HSB は、WSDL、SOAP、および HL7 標準を使用する医療アプリケーションを相互接続することができます。

ESB: 相互接続および相互運用の一般アーキテクチャー

このような一般化された相互運用可能な相互接続アーキテクチャーは、一般にエンタープライズ・サービス・バス (ESB) と呼ばれます。ESB には以下の利点があります。

  • SOA ベースにすることができます。
  • サービス・プロバイダーおよびサービス・コンシューマーが WSDL と SOAP を使用することができます。
  • サービス・プロバイダーとサービス・コンシューマーが業界固有の XML ベースの標準 (HL7 など) を使用できるという意味において、拡張性および柔軟性があります。

ESB の概念は新しいものではなく、現在、複数の ESB 実装が存在しています (よく使われているオープンソースの ESB については、「参考文献」のリンクを参照してください)。つまり、一から HSB を作成する必要はありません。既存の ESB を医療サービスに合わせて構成すればよいわけです。


HSB として使用する JBI

JBI 仕様では、標準化した Java ビジネス統合環境を定義しています。JBI にはこれまで説明した ESB の機能がすべて備わっているので、JBI を使用して HSB を作成することにします。

使用可能な JBI 実装はいくつかあります。そのうちよく使われているのは、Apache によるオープンソースの実装、ServiceMix です。この連載の内容はここから最後まで、JBI を使用し、ServiceMix を構成して HSB を作成する方法についての説明となります。

医療サービスを対象に連動する JBI コンポーネント

図 3 に、JBI を HSB として使用する方法を示します。

図 3. HSB として機能する JBI
HSB として機能する JBI

図 3 からわかるように、JBI の主要なコンポーネントは BC (Binding Component: バインディング・コンポーネント)、SE (Service Engine: サービス・エンジン)、NMR (Normalized Message Router: 正規化メッセージ・ルーター) の 3 つです。

ここからは、JBI のコンポーネントがイベントのシーケンス (図 4 を参照) を利用して機能する仕組みについて説明します。このイベント・シーケンスは、処方アプリケーション (Prescription application、サービス・コンシューマー) がドナー・グループ・アプリケーション (Donor group application、サービス・プロバイダー) に接続すると発生します。

図 4. JBI でサービス・プロバイダーに接続するサービス・コンシューマー
JBI でサービス・プロバイダーに接続するサービス・コンシューマー

図 4 で発生しているシーケンスを以下に説明します。

ステップ 1: 処方アプリケーション (Prescription application、サービス・コンシューマー) が JBI に接続し、ドナー・グループ・アプリケーション (Donor group application、JBI 環境外部にあるサービス・プロバイダー) によって提供されるサービスを要求します。

ステップ 2: JBI 環境がサービス・リクエストを適切な BC に転送します。この場合の適切な BC は、処方アプリケーション (Prescription application) からのすべてのサービス・リクエストを受信する BC です。JBI と連動するサービス・コンシューマーまたはサービス・プロバイダーは、JBI 環境内にそれぞれ専用の BC があります。

ステップ 3: BC はサービス呼び出しリクエストを、JBI 仕様で定義された正規化フォーマットに変換します。JBI 仕様が正規化フォーマットを定義している目的は、BC 間での相互運用を可能にするためです。JBI のすべての BC は、この正規化フォーマットを理解できるだけでなく、それぞれの BC が接続されている特定のサービス・プロバイダーまたはサービス・コンシューマーのフォーマットも理解します。つまり JBI の正規化機能とは、すべての BC がそれぞれに対応するサービス・コンシューマーまたはサービス・プロバイダーから受信したメッセージを変換する共通フォーマットのことです。

ステップ 4: 処方アプリケーションの BC は、図 4 に示された NMR に正規化メッセージを渡します。JBI 環境全体で、NMR は 1 つしかありません。

ステップ 5: NMR の役目は、BC から正規化メッセージを受け取った後、対象のサービス・プロバイダーを特定して、そのサービス・プロバイダーに接続された別の BC に正規化メッセージを転送 (ルーティング) することです。この例では、NMR はドナー・グループ・アプリケーションに接続された BC に正規化メッセージを転送します。

ステップ 6: ドナー・グループ・アプリケーションの BC は正規化メッセージを非正規化し、ドナー・グループ・アプリケーションが理解できるフォーマットに変換します。

ステップ 7: BC が非正規化メッセージをドナー・グループ・アプリケーションに渡します。

このイベント・シーケンスは、JBI に関する以下の単純な 2 つの特徴を明らかにしています。

  • JBI は、正規化メッセージをルーティングするという概念に基づいて機能します。各メッセージは BC によって正規化されて NMR に渡されます。NMR がメッセージを別の BC にルーティングすると、その BC がメッセージを非正規化して、対象のサービス・プロバイダーが理解できるフォーマットにします。
  • 正規化メッセージのルーティング・メカニズムは、疎結合アーキテクチャーをもたらします。疎結合とは、サービス・プロバイダーとサービス・コンシューマーが NMR メカニズムを介してのみやりとりするということです。サービス・プロバイダーとサービス・コンシューマーが直接やりとりすることはありません。

この疎結合アーキテクチャーの第一の利点は、特定のデータ・フォーマットや標準を BC という形で 1 度実装するだけで済むことです。BC を実装しさえすれば、後はその特定のデータ・フォーマットに従ってサービスを提供するすべてのサービス・プロバイダーが、この BC のインスタンスを使うだけで JBI 環境に統合されることになります。

例えば、HL7 を JBI に統合しなければならない場合に必要なのは、HL7 を理解できる BC です。HL7 BC を実装すれば、あらゆる HL7 サービスを JBI に統合できるようになり、これらのサービスの統合によって HSB が形作られることになります。

HL7 をベースとした BC を作成して、HL7 を JBI に統合する上での実際の手順については、連載の第 2 回で説明します。この記事では、他にもまだ JBI について説明しなればならないことがあります。

JBI での内部サービスと外部サービスの混成

図 4 では、サービス・コンシューマーと JBI 環境の外部に置かれたサービス・プロバイダーとの通信について説明しました。

ここで、記事の最初で取り上げたシナリオを思い出してください。処方アプリケーションは、医療施設内の放射線科にもメッセージを送信します。つまり JBI 環境は、放射線科アプリケーションを内部サービスとしてホストできなければなりません。内部サービスは、JBI 内では SE としてホストされます。

SE は BC と同様ですが、BC にはない特徴が 1 つあります。それは、SE には内部サービス (例えば、放射線科アプリケーション) のビジネス・ロジックが含まれることです。BC と SE はどちらも図 3 に示されているように、JBI の NMR に接続されます。図 3 に変更を加えた図 5 では、放射線科アプリケーション (Radiology department application) が SE として示されています。

図 5. SE として示された放射線科アプリケーション
SE として示された放射線科アプリケーション

図 6 に、内部サービス (SE) にアクセスする際のイベント・シーケンスを示します。

図 6. 内部サービス・プロバイダーにアクセスするサービス・コンシューマー
内部サービス・プロバイダーにアクセスするサービス・コンシューマー

図 6 に示したイベント・シーケンスは、処方アプリケーションなどのサービス・コンシューマーが放射線科アプリケーション (Radiology department application、内部サービス・プロバイダー) にメッセージを送信した場合に発生するイベント・シーケンスです。

ステップ 1: 処方アプリケーション (Prescription application、サービス・コンシューマー) が JBI に接続し、放射線科アプリケーション (Radiology department application) によって提供されるサービスを要求します。

ステップ 2: JBI 環境はサービス・リクエストを処方アプリケーション (Prescription application) の BC に転送します。

ステップ 3: BC はサービス呼び出しリクエストを正規化メッセージに変換します。

ステップ 4: BC が正規化メッセージを NMR に渡します。

ステップ 5: NMR は、正規化メッセージを放射線科アプリケーション (Radiology department application)(SE) に転送します。

ステップ 6: 正規化メッセージを受信した SE は、内部でメッセージを非正規化して、要求されたビジネス・ロジックを呼び出します。

図 4 に示したイベント・シーケンスとかなりよく似ている上記のイベント・シーケンスでは、SE に BC の機能が含まれ、さらにサービス・プロバイダー・アプリケーションのビジネス・ロジックも含まれていることを示しています。

SE は不必要に 2 つの異なる内容 (BC の機能とビジネス・ロジック) を混在させているように見えます。第 2 回では、この不要な混在をなくすために、既存の BC をベースに内部サービスのビジネス・ロジックを作成する方法を説明します。

JBI べースの ESB 間の相互接続

HSB 間の相互接続を示した図 2 をもう一度見てください。この相互接続は、図 7 に示すように JBI によって実現することができます。

図 7. 相互接続された 2 つの JBI 環境
相互接続された 2 つの JBI 環境

図 7 では、2 つの JBI 環境にさまざまなアプリケーションが接続されています。この場合、図 7 の最初の JBI 環境 (First JBI environment) に接続されている処方アプリケーションが、血液バンク・アプリケーション (2 番目の JBI (Second JBI environment) 環境内に常駐するサービス・プロバイダー) にメッセージを送信すると、以下のイベント・シーケンスが発生します。

ステップ 1: 処方アプリケーション (Prescription application、サービス・コンシューマー) が最初の JBI 環境 (First JBI environment) に接続し、血液バンク・アプリケーションによって提供されるサービスを要求します。

ステップ 2: 最初の JBI 環境 (First JBI environment) がサービス・リクエストを処方アプリケーションの BC (Binding Component (BC) for the Prescription application) に転送します。

ステップ 3: 処方アプリケーションの BC (Binding Component (BC) for the Prescription application) がサービス呼び出しリクエストを正規化メッセージに変換します。

ステップ 4: 処方アプリケーションの BC (Binding Component (BC) for the Prescription application) が正規化メッセージを NMR に渡します。

ステップ 5: NMR は、2 番目の JBI 環境に接続されている BC (Binding Component (BC) connected with second JBI Environment) に正規化メッセージを転送します。

ステップ 6: 2 番目の JBI 環境に接続されている BC (Binding Component (BC) connected with second JBI Environment) がメッセージを非正規化します。

ステップ 7: 2 番目の JBI 環境に接続されている BC (Binding Component (BC) connected with second JBI Environment) が、非正規化メッセージを 2 番目の JBI 環境 (Second JBI enrvironment) に渡します。

ステップ 8: 2 番目の JBI 環境 (Second JBI enrvironment) がリクエストを受け取り、最初の JBI 環境に接続されている BC (Binding Component (BC) connected with first JBI Environment) にリクエストを転送します。これは、2 つの JBI 環境がそれぞれの適切な BC を介して相互に接続することを意味します。

ステップ 9: 最初の JBI 環境に接続されている BC (Binding Component (BC) connected with first JBI Environment) がサービス呼び出しリクエストを正規化メッセージに変換します。

ステップ 10: 最初の JBI 環境に接続されている BC が、正規化メッセージを NMR に渡します。

ステップ 11: NMR は、正規化メッセージを血液バンク・アプリケーション (SE) に転送します。

ステップ 12: SE は内部でメッセージを非正規化して、要求されたビジネス・ロジックを呼び出します。

JBI でのメッセージ交換パターン

図 4、5、6、および 7 で示しているのは、単方向の通信です。つまり、サービス・コンシューマーはサービス・プロバイダーにメッセージを送信しますが、サービス・プロバイダー (ドナー・グループ・アプリケーションなど) はレスポンス・メッセージを送信しません。JBI のドキュメントでは、このタイプのメッセージングを In-Only メッセージ交換と呼んでいます。In-Only メッセージ交換パターンが適しているのは、ドナー・グループ・アプリケーションのようなサービスです。ドナー・グループ・アプリケーションに必要なのは、グループに対して単方向でメッセージを送信することだけで、リクエストを送信した処方アプリケーションに返信しなければならない情報はありません。

その一方、レスポンスを送信する必要のあるサービスもあります (例えば、保険会社ポータル・アプリケーション)。このようなリクエスト/レスポンス・メッセージング・パターンは、JBI でも In-Out メッセージ交換として使用することができます。お察しの通り、レスポンスもリクエストと同じようにサービス・プロバイダーから JBI 環境 (BC、SE、および NMR) を介してサービス・コンシューマーに渡されるので、In-Out メッセージングを説明するイベント・シーケンスの記載は省略します。


JBI 環境の構成とブートストラップ

JBI 仕様では、JBI でホストする必要のあるすべての BC および SE の振る舞いを定義するための詳細な XML スキーマを規定しています。ここからは、JBI スキーマを利用して、JBI 実装を HSB として構成する方法を説明します。

今回の記事では JBI スキーマ全体を取り上げることはせず、<component> という重要な JBI タグに焦点を絞ります。他の JBI スキーマ・タグについては、第 2 回で使用方法を紹介します。

<component> タグは、JBI コンポーネントを定義します。コンポーネントは BC または SE のいずれかにすることができます。リスト 1 に一例として、XML で構成された処方アプリケーションの BC を記載します。

リスト 1. 処方アプリケーションの BC を定義する XML 構成
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
        <name>Prescription-Application</name>
        <description>Binding Component for the prescription application</description>
    </identification>
    <component-class-name>
        org.apache.servicemix.cxfbc.CxfBcComponent
    </component-class-
    <component-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
</component>
</jbi>

リスト 1<component>タグには、1 つの type 属性と、<identification><component-class-name><component-class-path><bootstrap-class-name>、および <bootstrap-class-path> という 5 つの子タグがあります。

type 属性は、コンポーネントが BC であるか、SE であるかを指定する属性です。リスト 1 では処方アプリケーションの BC を構成しているので、type 属性の値は binding-component となっています。

リスト 1 の <identification> タグが指定しているのは、BC の名前と説明です。

<component-class-name> タグは、BC に必要なロジックを実装する Java クラスを指定します。JBI 仕様では、javax.jbi.component.Component という名前の標準インターフェースがあり、すべての BC はこのインターフェースを実装しなければならないことになっています。この連載で HSB の機能を説明するために使用するのは、Apache ServiceMix です。ServiceMix が提供する BC を使用することで、SOAP ベースの Web サービスを使用するすべてのサービス・コンシューマーと連動することができます。この BC のロジックを実装するクラスの名前は org.apache.servicemix.cxfbc.CxfBcComponent です。第 2 回では、処方アプリケーションがこのクラスを使用して JBI と連動する方法を説明するつもりなので、リスト 1 では、org.apache.servicemix.cxfbc.CxfBcComponent をコンポーネント・クラスの名前として <component-class-name> タグ内にラップしています。

次に、リスト 1<component-class-path> タグに目を向けてください。このタグには <path-element> という名前の 2 つの子タグが含まれています。この 2 つのタグは、コンポーネント・クラスを実行するために必要なすべての JAR ファイルのパスを指定します。つまり、<component-class-name> タグと <component-class-path> タグがペアとなって、BC の Java クラスの名前、ならびにこの Java クラスを実行するために必要な完全パスを指定するというわけです。

リスト 1 には、<bootstrap-class-name> タグと <bootstrap-class-path> タグのペアもあります。このペアは前述の <component-class-name> タグと <component-class-path> タグのペアと似ていて、この場合は BC をブートストラップするロジックを実装する Java クラスの名前とクラス・パスを指定するブートストラップ・ペアとなります。

ブートストラップとは、BC をサービス状態にすることを意味します。ブートストラップが行われるのは、JBI サーバー (ServiceMix) を起動した時点です。ブートストラップ・クラスには、BC を起動して稼働状態にするための完全なロジックが含まれます。

今度はリスト 2 の <component> タグを見てください。これは、ドナー・グループ・アプリケーションのような外部サービス・プロバイダーを表すタグです。リスト 2 の構造はリスト 1 とまったく同じなので、説明の必要はありません。

リスト 2. 外部サービス・プロバイダーを定義する XML 構成
<?xml version="1.0" encoding="UTF-8"?> 
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
        <name>Donor-Group-Application</name>
        <description>Binding Component for the Donor Group application</description>
    </identification>
    <component-class-name>
        org.apache.servicemix.cxfbc.CxfBcComponent
    </component-class-
    <component-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
</component>
</jbi>

リスト 3 には、SE (放射線科アプリケーションなどの内部サービス・プロバイダー) の構成方法を指定する <component> タグを記載します。

リスト 3. 内部サービス・プロバイダーを定義する XML 構成
<?xml version="1.0" encoding="UTF-8"?> 
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="service-engine" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
      <name>Radiology-Department-Application</name>
      <description>Radiology Department Service Application</description>
    </identification>
    <component-class-name>
        org.hsb.radiology.RadiologyBean</component-class-name>
    <component-class-path>
      <path-element>lib/radiology-bean.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/ radiology-bean.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
  </component>

</jbi>

リスト 3リスト 2 と比べてみると、大きな違いは 1 つしかないことがわかります。それは、リスト 2type 属性の値は (外部サービス・プロバイダーを表す BC であるため) binding-component となっているのに対し、リスト 3 の太字で示した type 属性の値は、これが内部サービスを表す SE であることから service-engine となっていることです。


次回の予告

以上が、JBI の <component> タグを使用して BC と SE を構成する方法です。JBI は、さまざまなシナリオで使える汎用の BC を構成するための再利用メカニズムにもなります。

ServiceMix のような JBI 実装には、事前ビルドされた BC がバンドルされています。そのような BC の場合、<component> タグを構成する必要すらありません。実装にはあらかじめ、BC のクラスや他の詳細についての情報が提供されています。

第 2 回では今回説明した要素を組み合わせて、ServiceMix の既存の機能を使用して新しい機能を作成および構成 (つまり、BC または SE を実装して構成) し、医療サービスを統合する方法を説明します。

参考文献

学ぶために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, Open source, Industries
ArticleID=495685
ArticleTitle=医療サービスの統合: 第 1 回 エンタープライズ・サービス・バスを医療で使用する
publish-date=05182010