JP2008197974A - Ｄｂアクセスの疎結合化システム - Google Patents

Abstract

【課題】 ＤＢ中のテーブルに格納された業務データを、ＳＱＬ文を用いてＤＢアクセスする構造の業務システムにおいて、ＤＢアクセスを含む密結合型システムをＷｅｂサービスを用いて疎結合化すること。
【解決手段】 業務システムにおける業務ロジックの実行時に、業務ロジックがＤＢアクセスするＳＱＬ文をフックする手段と、フックしたＳＱＬ文の内容を解析し、アクセスの対象となる業務データが、外部システム上に存在するＤＢ上のテーブルに存在する場合には、フックしたＳＱＬ文をＷｅｂサービスのメッセージ交換に変換して外部システム上の業務データにアクセスする手段と、アクセスの対象となる業務データが、業務システム内部に存在するＤＢ上のテーブルに存在する場合には、フックしたＳＱＬ文を業務システム内部に存在するＤＢのＤＢ管理システムへ処理を依頼し、業務システム内の業務データにアクセスする手段とを備える。
【選択図】 図１

Description

本発明は、ＤＢアクセスを含む密結合型システムをＷｅｂサービスを用いて疎結合化するシステムに関するものである。

大規模な業務システムでは、取り扱うデータの種類が多いため、最初にデータ構造の設計を一括して行い、データの流れを中心としたアプローチによってシステム設計を行うデータ指向アーキテクチャを採用すること一般的である。
しかし、データ指向アーキテクチャで設計したシステムは、データ構造と業務ロジックが密接に関連しているため、業務システムの一部を部分的に別の業務システムで再利用することが容易ではないという欠点がある。
データ指向アーキテクチャに対して、業務をデータではなく、プロセスの流れを中心としたアプローチによって設計するプロセス指向アーキテクチャがある。
プロセス指向アーキテクチャでは、各プロセスを独立したサービスとして設計することにより、サービスを別の業務システムで再利用することが容易である。プロセス指向アーキテクチャは、サービス指向アーキテクチャとも呼ばれる。

旧来の業務システムでは、ユーザが業務システムに業務の運用を合わせることにより、業務システムの改修を軽減し、業務システムのライフサイクルを延ばしてきた。しかし、最近の業務システムでは、業務の運用の変化のニーズに業務システムが柔軟に追従することが求められてきている。業務システムが柔軟であるためには、業務システムの部分再利用性が高いことが重要であり、データ指向アーキテクチャよりも、サービス指向アーキテクチャが向いている。しかし、データ指向アーキテクチャで設計された業務システム全体を一括してサービス指向アーキテクチャに転換することは困難である。
そこで、データ指向アーキテクチャで設計された業務システムの一部を、ラッピングなどの手法を用いてサービス指向アーキテクチャのサービス化して再利用し、逐次、サービス指向アーキテクチャによる業務システムの構築を進める方法が公知となっている。

図３は、データ指向アーキテクチャで設計された業務システムの一部の業務ロジックをラッピングによりサービス化し、サービス指向アーキテクチャのシステムの一部として再利用する例を示す図である。
図３に示すように、データ指向アーキテクチャで設計された業務システムＢ３０２に含まれる業務ロジックＢ３０４を、ネットワーク経由でサービスとして再利用可能にするためのサービスラッパーＢ３０３を用いてラッピングしてサービス化し、サービス指向アーキテクチャで設計された業務システムＡ３０１から、サービスとして再利用している。
同様に、業務システムＣ３０５に含まれる業務ロジックＣ３０７を、ネットワーク経由でサービスとして再利用可能にするためのサービスラッパーＣ３０６を用いてラッピングしてサービス化し、サービス指向アーキテクチャで設計された業務システムＡ３０１から、サービスとして再利用している。
前記サービスによるラッピングにより、業務システム全体としては、サービス指向アーキテクチャの業務システムになる。
なお、本発明に関連する公知技術文献としては下記の特許文献１がある。

特開２００５−９２５４７号

ところで、データ指向アーキテクチャで設計された業務システムは、構造化された業務データと、業務データと密接に関連した業務ロジックの組み合わせで構成されている。
業務システムの一部を外部システムからサービスとして再利用するためには、業務ロジックの一部を切り出してラッピングするだけでは不十分であり、業務ロジックに関連する業務データへのアクセスをラッピングする必要がある。

図４は、ＤＢを含む業務システムの構造例を示す図である。
業務システムＡ４０１に含まれる業務ロジックＡ４０２は、業務ロジックＣ４０５を手続きとして呼び出す。また、業務ロジックＡ４０２は、業務データＡ４０３と業務データＢ４０４に対して、それぞれのテーブルをにアクセスするためのＳＱＬ文を発行する。
図４のシステムにおいて、サービス化のためのラッピングを行う場合には、業務ロジックＣ４０５、業務データＡ４０３、業務データＢ４０４がラッピング対象になる。
業務ロジックと業務データをラッピングして、サービス指向アーキテクチャにおけるサービスとして再利用する際には、ラッピングするサービスのインタフェースが、それ自体で自己完結する疎結合なインタフェースにすることにより利便性が高まる。
自己完結する疎結合なインタフェースをもつ標準的な技術として、Ｗｅｂサービスが使われることが多くなってきている。

Ｗｅｂサービスは、ＸＭＬをベースにした疎結合なサービスをＷｅｂインフラ上で実現する技術であり、手続きの呼び出しやデータをＸＭＬ形式のメッセージでやりとりすることを特徴としている。
業務ロジックと業務データとをＷｅｂサービス技術を用いてラッピングし、サービス化する場合において、業務ロジックを構成する一連のプログラムコードから成る手続きは、Ｗｅｂサービスの手続き呼び出しに対応することができる。
一方、通常の場合、業務データはＤＢ中のテーブルに格納されており、テーブルの参照や更新などのＤＢアクセス操作を行うためには、ＳＱＬ文などのＤＢアクセス言語を記述して、ＤＢ管理システムへ処理を依頼する必要がある。しかし、Ｗｅｂサービスは、ＤＢアクセスなどの特定のデータアクセス手段に依存するメッセージ交換仕様を規定していないため、テーブルに格納された業務データにアクセスするための手段をＷｅｂサービスで実現するためには、各テーブルについて、データアクセスのための手続きを個別に用意する必要があり、手間がかかってしまうとい問題があった。
なお、前述の特許文献１に開示された技術は、サーバ内の複数のデータベースソフトの構成定義に合わせて業務アプリケーションが発行するＤＢアクセス要求を変換するものであるが、Ｗｅｂサービスに対応させる構成については開示されていない。

本発明は、前記課題を解決するためのものであり、ＤＢ中のテーブルに格納された業務データを、ＳＱＬ文を用いてＤＢアクセスする構造の業務システムにおいて、データアクセスのための手続きを個別に用意することなく、ＤＢアクセスを含む密結合型システムをＷｅｂサービスを用いて疎結合化することが可能なシステムを提供することを目的とする。

上記目的を達成するために、本発明のＤＢアクセスの疎結合化システムは、業務システムにおける業務ロジックの実行時に、業務ロジックがＤＢアクセスするＳＱＬ文をフックする手段と、フックしたＳＱＬ文の内容を解析し、アクセスの対象となる業務データが、外部システム上に存在するＤＢ上のテーブルに存在する場合には、フックしたＳＱＬ文をＷｅｂサービスのメッセージ交換に変換して外部システム上の業務データにアクセスする手段と、アクセスの対象となる業務データが、業務システム内部に存在するＤＢ上のテーブルに存在する場合には、フックしたＳＱＬ文を業務システム内部に存在するＤＢのＤＢ管理システムへ処理を依頼し、業務システム内の業務データにアクセスする手段とを備えることを特徴とする。

本発明のＤＢアクセス疎結合化方法によれば、業務システムのコードの書き換えを行わずに、ＤＢアクセスを含む密結合型システムをＷｅｂサービスを用いて疎結合化することができる。

以下、本発明を適用したＤＢアクセス疎結合化システムの一実施の形態について、図面に基づき説明する。
図１は、本発明の実施の形態に係わるＤＢアクセスの疎結合化システムの概略構成を示す図である。
図１に示すように、本実施の形態に係わるＤＢアクセスの疎結合化システム１０５は、ＳＱＬフック機構１０７、ＳＱＬ解析機構１０８、ＳＱＬ再発行機構１０９、データ所在記憶機構１１０、ＳＱＬ・Ｗｅｂサービス変換機構１１１、Ｗｅｂサービススタブ１１２とで構成している。
ＳＱＬフック機構１０７は、ＳＱＬ文を発行するプログラムのコードに対して、フック１０４を埋め込むこんでＳＱＬ文をフックする。

業務ロジックＡ１０２は、業務データにアクセスするためにＳＱＬ文を発行するが、ＳＱＬ文によってアクセスする対象となる業務データを含むテーブルは、業務ロジックＡ１０２と同一の業務システムＡ１０２内にある業務データＡ１０６の場合と、ネットワークを介して接続された別の業務システムＢ１１４内にあって、Ｗｅｂサービス１１５として提供されている業務データ１１６の両方の可能性があるものとする。しかし、業務ロジックＡ１０２は、前記の業務データの所在の相違を意識することなく、仮想業務データ１０３に対してアクセスするためのＳＱＬ文を発行する。
前記の業務データの所在の相違は、本実施の形態に係わるＤＢアクセスの疎結合化システムが吸収するものである。

図２は、本実施の形態に係わるＤＢアクセスの疎結合化システム１０５が行うＳＱＬフック処理手順を示すフローチャートである。
ＳＱＬフック機構３０７は、業務ロジックＡ１０２が仮想業務データ１０３に対して発行したＳＱＬ文を、フック３０４を埋め込んでフックし、発行されたＳＱＬ文を横取りする（ステップ２０１）。
ＳＱＬ解析機構１０８は、ＳＱＬフック機構１０７で取り込んだＳＱＬ文を解析し、ＳＱＬ文がアクセス対象とする業務データが存在するテーブルを特定する名称を切り出す（ステップ２０２）。
さらに、ＳＱＬ解析機構１０８は、テーブルを特定する名称を用いて、データ所在記憶機構１１０を参照して検索して、テーブルの所在を特定する（ステップ２０３）。

ステップ２０３で、テーブルの所在を特定した結果、テーブルがＳＱＬ文を発行した業務ロジックＡ１０２と同じ業務システム１０１内の業務データＡ１０６に存在する場合は、ＳＱＬ再発行機構１０９を用いてＳＱＬ文を発行し、業務データＡ１０６にアクセスし、業務ロジックＡ１０２へアクセス結果を返して終了する（ステップ２０５）。
ステップ２０３で、テーブルの所在を特定した結果、テーブルがＳＱＬ文を発行した業務ロジックＡ１０２と異なる業務ロジックＢ内の業務データＢ１１６に存在し、Ｗｅｂサービス１１５を介して利用可能な場合には、ＳＱＬ文を、ＳＱＬ・Ｗｅｂサービス変換機構１１１を用いて、Ｗｅｂサービスのメッセージに変換する（ステップ２０６）。

Ｗｅｂサービススタブ１１２は、ＳＱＬ文をＷｅｂサービスに変換したメッセージを、業務システムＢ内のＷｅｂサービス１１５へ送信する（ステップ２０７）。
Ｗｅｂサービス１１５は、ＳＱＬ発行機構１１７を用いてＳＱＬ文を発行し、業務データＢ１１６にアクセスし、業務ロジックＡ１０２へアクセス結果を返して終了する（ステップ２０８）。

これにより、業務ロジックＡ１０２のＳＱＬ文を発行するプログラムコードを変更することなく、業務システムＡ内に存在する業務データＡ１０６と、業務システムＡ１０１とネットワーク１１３で接続された業務システムＢ１１４内に存在する業務データＢ１１６に透過的にアクセスすることが可能になり、ＤＢアクセスを含む密結合型システムをＷｅｂサービスを用いて疎結合化することができる。

本発明の一実施の形態例を示すシステム構成図である。 本発明の一実施の形態に係わるＳＱＬフック処理手順を示すフローチャートである。 業務システムの一部の業務ロジックをサービス化して再利用する従来の一例を示す図である。 業務システム内でサービス化対象の一例を示す図である。

符号の説明

１０１…業務システムＡ、１０２…業務ロジックＡ、１０３…仮想業務データ、１０４…フック、１０５…本発明の一実施形態に係わる疎結合化システム、１０６…業務データＡ、１０７…ＳＱＬフック機構、１０８…ＳＱＬ解析機構、１０９…ＳＱＬ再発行機構、１１０…データ所在記憶機構、１１１…ＳＱＬ・Ｗｅｂサービス変換機構、１１２…Ｗｅｂサービススタブ、１１３…ネットワーク、１１４…業務システムＢ、１１５…Ｗｅｂサービス、１１６…業務データＢ、１１７…ＳＱＬ発行機構、３０１…業務システムＡ、３０２…業務システムＢ、３０３…サービスラッパーＢ、３０４…業務ロジックＢ、３０５…業務システムＣ、３０６…サービスラッパーＣ、３０７…業務ロジックＣ、４０１…業務システムＡ、４０２…業務ロジックＡ、４０３…業務データＡ、４０４…業務データＢ、４０５…業務ロジックＣ、４０６…業務データＣ。

Claims (1)

1. 業務システムにおける業務ロジックの実行時に、業務ロジックがＤＢアクセスするＳＱＬ文をフックする手段と、フックしたＳＱＬ文の内容を解析し、アクセスの対象となる業務データが、外部システム上に存在するＤＢ上のテーブルに存在する場合には、フックしたＳＱＬ文をＷｅｂサービスのメッセージ交換に変換して外部システム上の業務データにアクセスする手段と、アクセスの対象となる業務データが、業務システム内部に存在するＤＢ上のテーブルに存在する場合には、フックしたＳＱＬ文を業務システム内部に存在するＤＢのＤＢ管理システムへ処理を依頼し、業務システム内の業務データにアクセスする手段とを備えることを特徴とするＤＢアクセスの疎結合化システム。

Images