JP4233775B2 - データ通信方法、データ通信システムおよびプログラム - Google Patents
データ通信方法、データ通信システムおよびプログラム Download PDFInfo
- Publication number
- JP4233775B2 JP4233775B2 JP2001206983A JP2001206983A JP4233775B2 JP 4233775 B2 JP4233775 B2 JP 4233775B2 JP 2001206983 A JP2001206983 A JP 2001206983A JP 2001206983 A JP2001206983 A JP 2001206983A JP 4233775 B2 JP4233775 B2 JP 4233775B2
- Authority
- JP
- Japan
- Prior art keywords
- communication
- data
- data communication
- protocol
- class
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ通信方法、データ通信システムおよびプログラムに関する。特に、分散環境におけるコンポーネント間のメッセージ（データ）通信に適用して有効な技術に関する。
【０００２】
【従来の技術】
コンピュータプログラムのより効率的な開発・メンテナンスの観点からオブジェクト指向プログラミングが注目されている。そして、オブジェクト（クラス）の集合からプログラムを部品化したコンポーネントを作成し、このコンポーネントを組み合わせることによって所定のタスク（処理）を実現するコンポーネントベースのシステム開発が行われるようになっている。たとえばＪａｖａのコンポーネント化技術であるＪａｖａＢｅａｎｓを用いたコンポーネント（ジャバビーン）の場合、イベントを受け取ったコンポーネントはメソッドを実行し、メソッドはそのコンポーネントのプロパティを変化させ、あるいは他のコンポーネント（あるいはインスタンス）からのメソッドの呼び出し、他のコンポーネントへのイベントの発行等の処理を行う。これらコンポーネントの動作（メソッド）を組み合わせて複雑なタスクを実現する。このようにコンポーネントの動作は、他のコンポーネントとのメッセージ（情報あるいはデータ）の交換が前提となる。
【０００３】
コンポーネントは同一のハードウェアシステム内に存在する場合もあるが、ＬＡＮ（Local Area Network）やインターネットで接続されたネットワーク上に存在する場合もある。従って、分散型コンポーネントの場合には、データがネットワーク上を通信するためのプロトコルが必要になる。たとえば、互いにインターネットで接続されるコンポーネント間では、インターネット分野の標準的な通信プロトコルであるＨＴＴＰ（HyperText Transfer Protocol）が利用できる。より信頼性が要求される場合には、ＣＯＲＢＡ（Common Object Request Broker Architecture）で採用されている分散オブジェクトの標準規格ＩＩＯＰ（Internet Inter-ORB Protocol）が利用できる。非同期通信が必要な場合は、ＭＱ（Message Queuing）を利用することができる。ホストコンピュータと端末との通信の場合にはＳＮＡ（Systems Network Architecture）を利用できる。ＪＶＭ（Java Virtual Machine）が稼動する環境では、ＲＭＩ（Remote Method Invocation）ライブラリを利用できる。なお、Ｊａｖａ２ではＲＭＩがＩＩＯＰにも対応しているので、ＲＭＩ over ＩＩＯＰが利用できる。なお、Ｊａｖａ、ＪａｖａＢｅａｎｓ、Ｊａｖａ２等はサンマイクロシステムズ社の商標である。また、以下の説明で登場するＷｉｎｄｏｗｓ、Ｕｎｉｘ、Ｃ、Ｃ＋＋等は、各々それを保有する各社あるいは団体の商標である。
【０００４】
ところで、コンポーネントベースのシステムによって実現される処理は多種多様である。たとえば企業における生産・在庫管理、財務会計管理、人事・給与支払い業務等企業活動の基幹業務を担うＥＲＰ（Enterprise Resource Planning）、データベース管理システム、ウェブサーバ等多岐に渡る。一般に企業内で利用されるイントラネットの場合、その通信信頼性は比較的高く設計する必要がある。また、１秒を争うミッションクリティカルな処理に適用し得るシステムを構築する必要がある。他方、ウェブアプリケーションの場合、１秒の処理速度を争うようなタスクは少なく、また、その通信信頼性が保証されないことを前提にシステムを構築することが許される。従って、システムを構築する場合、コンポーネント間の通信にどのようなプロトコルを採用するべきであるかは、その構築されるシステムの要求あるいはコンポーネントが担う処理の性質によって相違する。たとえば企業内のミッションクリティカルな処理に適用するには、その接続信頼性の高さ、障害発生時の追跡調査の容易性、セキュリティ、トランザクションコンテキストの伝搬可能性、パフォーマンスの高さ等の観点からＩＩＯＰを採用することが好ましい。また、ウェブアプリケーションの場合は、事実上の標準プロトコルであるＨＴＴＰを採用することが妥当である。ファイアウォールを構築するうえでもＨＴＴＰが使いやすい。非同期システムとの通信を行う場合はＭＱを採用することが好ましい。
【０００５】
ただし、これら各プロトコルには、デメリットもある。たとえばＩＩＯＰでは、ＩＩＯＰを利用するアプリケーション（コンポーネント）の通信インタフェイスが固定される。このため、通信データの属性の追加等データ仕様に変更が生じた時には、これに適合するようインタフェイスを修正する必要がある。ＨＴＴＰではＩＩＯＰで保証されるほどの通信信頼性が保証されず、障害発生時の追跡も容易でない。また、ＨＴＴＰは、基本的に文字列の転送規約であるから、バイナリデータの通信信頼性は確保されない。また、ＨＴＴＰでバイナリデータを転送するには、一旦キャラクタセットにエンコードし、これを転送する必要がある。転送の際にエンコード、デコードのためのサーバ負荷が増加し、またそのための処理時間が必要になる。よってミッションクリティカルが用途に適用することは難しい。
【０００６】
【発明が解決しようとする課題】
上記した通り、各プロトコルには各々メリットとデメリットがある。よってシステムを構築する際に何れのプロトコルを採用するかは、その利害得失を勘案したうえでシステム開発者によって選択されることになる。ところが、一つのアプリケーション（コンポーネント）で複数のプロトコルを利用する場合、各プロトコルに適合するようにプログラムの通信部分（インタフェイス）をプロトコル毎に作成する必要がある。つまり、プログラマはデータの送受信を担う部分のプログラムを作成する際に、利用するプロトコルを意識してプログラムを作成しなければならない。システム開発の生産性向上を考えれば、プログラマは、本来そのコンポーネントが担う機能を実現するプログラムの作成に意識を集中するべきであり、コンポーネントの機能以外の通信プロトコルを意識しなければならない状況は、システム開発の効率を低下させているといえる。
【０００７】
本発明の目的の一つは、プログラム作成あるいはメンテナンス環境においてコンポーネント間通信で利用するプロトコルへの整合性を意識することなく、単一の手順でコンポーネント間通信が実現できるインタフェイス技術を提供することにある。
【０００８】
ところで、近年注目されつつある企業間のインターネットを介した取引（Ｂ２Ｂ）を実現するシステムでは、どの様なプロトコルの採用が好ましいであろうか。企業間取引であることを考慮すれば、高い通信信頼性とパフォーマンスを備えたＩＩＯＰを利用することが好ましい。ところが、Ｂ２Ｂ取引では、既に構築されている企業内システム同士を、インターネットを介して接続する必要がある。Ｂ２Ｃ取引（企業顧客間取引）の場合は、サーバにアクセスする顧客に対して企業が独自に定義したデータ入力画面等を提示できるので、企業側が独自にデータフォーマットを決定することが許される。しかし、Ｂ２Ｂ取引の場合、接続先企業のシステムは殆どの場合既に構築されているので、接続先企業のデータフォーマットとの整合性を考慮する必要がある。たとえばデータ転送を行うミドルウェアを用意し、相手先企業のデータフォーマットの変更にも迅速に対処する必要がある。このような状況において、企業間取引にＩＩＯＰをそのまま採用すると以下のような問題がある。ＩＩＯＰには、前記したようなメリットがあるものの、ＩＩＯＰを利用するアプリケーションでは、通信インタフェイスが固定される。このため、たとえば通信相手のシステムにおいて、データ属性の追加等その仕様に変更があった時、インタフェイスもそれに適合するよう変更する必要がある。ここで、他のコンポーネント（あるいはクラス）がこのインタフェイスを利用している場合、インタフェイスを利用するコンポーネントに直接影響しないデータ仕様の変更であっても、インタフェイスの変更に影響を受けて、コンポーネントの再コンパイル等変更が必要になる。インタフェイスを利用するコンポーネントが多数存在する場合、このようなデータ仕様の変更に対処する作業が大きな負担になる。なおＩＩＯＰ以外のその他のプロトコルにおいてインタフェイスの変更が必要になる場合があり、このような場合、同様な問題が生じることは勿論である。
【０００９】
本発明の他の目的は、データの仕様等が変更されても、最小限のメンテナンス負荷で変更に対応できる通信インタフェイス技術および通信データの構造を提供することにある。
【００１０】
さらに、通信インタフェイスおよび通信データの一般化が行われても、これが実用レベルで使用に耐えるものでなければならない。特に企業内あるいは企業間取引で想定されるようなミッションクリティカルな処理に適用できる高いレベルのレスポンスを実現する必要がある。
【００１１】
本発明のさらに他の目的は、一般化された通信データにおいて、そのデータ転送のためのオーバーヘッドを低減し、また、通信データの検証が必要な場合には、その検証のための処理負荷を低減する技術を提供することにある。
【００１２】
その他の目的は、以下の実施の形態においてさらに明らかになるであろう。
【００１３】
【課題を解決するための手段】
本願の発明の概略を説明すれば、以下の通りである。すなわち、本発明のコンポーネント間のデータ通信方法は、プロパティおよび通信データを受け取るステップと、プロパティで指定されたプロトコルに従った通信データの通信を実行するステップと、を含む。つまり、本発明では、アプリケーションプログラムの稼動環境あるいは開発環境において、プロトコルに依存しないデータの通信が可能なインタフェイスプログラムを用意する。このデータ通信用インタフェイスプログラムは、たとえばデータ通信用のクラス、インタフェイス等の一連のプログラムとして提供される。アプリケーションプログラムにおいてデータ通信用のクラスを初期化（インスタンスの生成）し、さらにそのインスタンスからの通信メソッドの呼び出しとして通信インタフェイスの機能を実現する。通信データは、通信メソッドの引数として通信用プログラムに引き渡すことができる。また、本発明では、たとえば通信用クラスのインスタンスが生成（初期化）される際に、プロトコル毎に用意した通信用実装クラスをインスタンス化する。通信用実装クラスにはプロトコル毎の通信手順を通信メソッドとして記述しておく。何れの通信用実装クラスをインスタンス化するかは、初期化の際に渡されるプロパティ引数で特定されるプロトコルによって選択できる。すなわち、指定されたプロトコルに対応した通信用実装クラスをインスタンス化することにより、通信用インスタンス内の通信メソッドを呼び出すだけで、プロトコルに適合したデータ通信を実現できる。
【００１４】
このように、本発明の通信用インタフェイスプログラムでは、各プロトコルに対応したインスタンスの生成によって、プロトコル毎に相違するプログラム記述様式を吸収する。これにより、アプリケーションレベルでは、プロトコル毎に相違するプログラム記述様式を意識する必要はなく、単に通信用クラス（インタフェイスプログラム）のプロトコルを指定した初期化（インスタンスの生成）と、通信メソッドの呼び出しとによって、ターゲットコンポーネント（通信相手）とのデータ通信を実現できる。通信データは通信メソッドの引数として渡すだけなので、プログラマはプロトコル毎の記述様式の相違を意識する必要は全くない。しかも、採用すべきプロトコルは、インスタンス生成の際のプロパティ指定によって簡単に選択できるので、多様なプロトコルからその状況に応じた最適のプロトコルを簡単に利用できる。これによりプログラマは本来の機能実現のためのアプリケーション開発に意識を集中することができ、プログラム開発およびメンテナンスの効率を向上することができる。なお、通信メソッド呼び出しの結果（戻り値）は適当な変数に代入することにより受け取る。
【００１５】
また、本発明では、通信データとして、ＸＭＬ（Extensible Markup Language）形式で記述された文字列、またはバイナリデータとＸＭＬ文字列との組合せを用いる。つまり、ＸＭＬ文字列によって通信データを一般化する。本発明では、データの要素が構造化されているので、データ仕様の変更等に対処しやすくなる。しかも、ＸＭＬではタグによって各要素を独自に定義できる。このため、アプリケーションで必要なデータのみを参照することが可能になり、関係のないデータ（要素）は読み飛ばす等の柔軟な処理が可能になる。これにより、データ仕様が変更になっても、アプリケーションレベルでそのデータ仕様の変更に対処することができ、通信インタフェイスに影響を及ぼすことがない。つまり、データ仕様の変更によりインタフェイスプログラムの変更を行う必要がないので、多数のコンポーネントからインタフェイスを利用している場合であってもコンポーネントの再コンパイル等再構成をする必要がなくなる。つまりデータ仕様の変更があっても、そのデータを利用するアプリケーションでのプログラムの変更に限られ、システムの各コンポーネントを全体的にメンテナンスする必要がない。
【００１６】
また、本発明では、通信データにバイナリデータを含むため、バイナリデータを一旦文字列等にエンコードし、受信側でデコードする作業がない。これにより通信のオーバーヘッドを少なくすることができる。バイナリデータを含む場合には、その開始位置と終了位置を特定する必要がある。このバイナリデータの区分情報は、前記したようなＸＭＬ文字列として通信できる。バイナリデータの位置情報を示すＸＭＬ文字列は、バイナリデータ内の要素の開始位置を示す文字列、カンマ文字その他任意定義のセパレータ、および要素の終了位置を示す文字列からなる要素位置文字列を生成するステップと、要素位置文字列を要素の要素タグおよびその終了タグで囲むステップとで生成できる。
【００１７】
また、本発明では、通信に採用するデータ構造としてＸＭＬを前提にした場合のオーバーヘッドの軽減手段を備える。つまり、通信しようとするデータに配列型データを含む場合には、配列型データの各要素を、カンマ文字その他任意定義のセパレータで区分し、各要素およびセパレータからなる配列データ文字列を生成するステップと、配列データ文字列を配列型タグおよびその終了タグで囲みＸＭＬ形式の文字列を生成するステップと、を含むことができる。あるいは、通信しようとするデータにマップ型データを含む場合には、マップ型データの要素と要素にマッピングされたマッピングデータとをイコール文字その他任意定義の関連付け文字で関連付け、要素、関連付け文字およびマッピングデータからなる要素・データ文字列を生成するステップと、要素毎の要素・データ文字列を、カンマ文字その他任意定義のセパレータで区分し、要素・データ文字列およびセパレータからなるマップデータ文字列を生成するステップと、マップデータ文字列をマップ型タグおよびその終了タグで囲みＸＭＬ形式の文字列を生成するステップと、を含むことができる。たとえばＳＯＡＰ（Simple Object Access Protocol）などのＸＭＬによるＲＰＣ（Remote Procedure Call）通信を行うプロトコルでは、文書の各要素にタグを付けた形式でデータの送受信を行うと定義している。配列型あるいはマップ型等同一タイプの要素を多数繰り返すようなデータの場合、各要素に逐一タグがつけられるのでオーバーヘッドが大きくなる。このような構造のデータの場合、その構造を単純した規約で記述したとしてもＸＭＬの可読性、構造化性を損なうことなく、付加されるタグの数を顕著に少なくできる。これにより、ＸＭＬ文字列の文字数を少なくして、通信のオーバーヘッドを軽減できる。また、タグ数の低減は、ＸＭＬプロセッサやパーサによる妥当性検証によるオーバーヘッドも少なくできる。これらオーバーヘッドの軽減により、実用的な通信手段を提供できる。
【００１８】
また、本発明では、より簡略化したＸＭＬ文字列の生成のための独自パーサを提供する。すなわち、通信しようとするデータ、およびデータを指標する指標文字列を受け取るステップと、通信しようとするデータまたはその属性データを、指標文字列を含む開始タグおよびその終了タグで囲み、ＸＭＬ形式の文字列を生成するステップと、他の通信しようとするデータについてステップを繰り返し、他の通信しようとするデータについてのＸＭＬ形式の第２文字列を生成し、文字列第２文字列を追加するステップと、を有する。このような手法によれば、要素内に子要素をもつような深い構造のＸＭＬ文書は作成されない。従って、ＸＭＬ文書の一般性、汎用性は幾分損なわれるが、単純な構造のＸＭＬ文書であるため特に妥当性検証が必要な場合の処理速度の向上が期待できる。本発明のように通信データとしてＸＭＬを用いる場合には、深い構造を用いてデータを表現する必要性はあまりない。他方、妥当性検証でのオーバーヘッドを軽減して高速な通信手段を実現するメリットの方が大きい場合がある。このようなときに適用して有効である。データの妥当性について信頼できない通信相手からのデータ受信の際には妥当性検証は重要であり、特に不特定多数のユーザからデータ受信を受信するようなアプリケーションの場合に利用できる。なお、十分に信頼できる相手からの通信の場合に、妥当性検証を省略して通信速度を向上できることは言うまでもない。特定の相手であって、そのデータ構造を含めたデータ通信についてテストされているような場合は、むしろ妥当性検証を省略してレスポンスを高める方がメリットが大きい場合もある。
【００１９】
なお、前記した簡略化されたパーサの場合に、配列型あるいはマップ型のデータが含まれるとき、前記したと同様にその構造を簡略化してタグの数を減ずることができるのは勿論である。また、データにバイナリデータが含まれる場合に、簡略化されたパーサにおいても、前記と同様に取り扱えることも勿論である。
【００２０】
なお、本発明で対処できるプロトコルとして、ＣＯＲＢＡ／ＩＩＯＰ、ＲＭＩ over ＩＩＯＰ、ＨＴＴＰ、メッセージ・キューイング（ＭＱ）、ＳＯＡＰを例示できる。ただし、本発明はこれらプロトコルに限られず、前記した通信用インタフェイスプログラム（クラス）に実装できる限り、その他のプロトコルであっても良いことは勿論である。
【００２１】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００２２】
以下の実施の形態で説明する方法またはシステムは、当業者であれば明らかなとおり、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。
【００２３】
また以下の実施の形態では、そのシステムとして一般的なコンピュータシステムを用いることができる。実施の形態で用いることができるコンピュータシステムは、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ）、不揮発性記憶装置（ＲＯＭ）、コプロセッサ、画像アクセラレータ、キャッシュメモリ、入出力制御装置（Ｉ／Ｏ）等、一般的にコンピュータシステムに備えられるハードウェア資源を備える。また、ハードディスク装置等の外部記憶装置、インターネット等のネットワークに接続可能な通信手段を備える。コンピュータシステムには、パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等各種のコンピュータが含まれる。
【００２４】
また、本実施の形態で説明するプログラムを稼動させる環境に特に制限はない。以下の説明ではＥＪＢ（Enterprise Java Beans）を想定するが、Ｊａｖａサーブレット、アパッチ等のウェブサーバ、その他のミドルウェア、Ｕｎｉｘ、Ｗｉｎｄｏｗｓ、その他のＯＳ等の環境であってもよい。また、プログラム言語にも制限はない。ただし、プログラム言語はオブジェクト指向であることが好ましい。以下の説明では、プログラム言語として主にＪａｖａあるいはＪａｖａ２を利用した場合を説明するが、Ｃ＋＋、ｏｂｊｅｃｔｉｖ−Ｃ、ｓｍａｌｌｔａｌｋ、Ｃ等であってもよい。
【００２５】
（実施の形態１）
図１は、本発明の一実施の形態であるデータ通信システムを模式的に示した概念図である。本実施の形態のデータ通信システムは、システム１ａとシステム１ｂにあるアプリケーションプログラム２ａ、２ｂ間のデータ通信を行う。各システム１ａ、１ｂには、図示するように各々、データ通信用プログラム３ａ、３ｂ、インタフェイスプログラム４ａ、４ｂ、プロトコル毎の実装プログラム５ａ〜９ａ、５ｂ〜９ｂを有する。
【００２６】
アプリケーションプログラム２ａで通信する必要がある通信データは、選択するプロトコルをプロパティとして指定した上でデータ通信用プログラム３ａに送られる。データ通信用プログラム３ａにデータを送るための手順はプロトコル毎に相違するものではなく、統一された単純な手順である。このような統一された単純な手順を用いてアプリケーションプログラム２ａからの通信が行えるため、プログラマはプロトコル毎の仕様あるいは手順を意識すること無く、アプリケーションの開発あるいはメンテナンスを行うことができる。
【００２７】
データ通信用プログラム３ａでは、インタフェイスプログラム４ａを利用して指定されたプロトコルに対応する実装プログラム５ａ〜９ａを実装する。そして受け取った通信データを、実装されたプログラム（実装プログラム５ａ〜９ａの何れか）を利用してシステム１ｂに送信する。なお、図では、実装プログラムとしてＣＯＲＢＡ（ＩＩＯＰ）、ＥＪＢ（ＲＭＩ over ＩＩＯＰ）、ＭＱ、ＨＴＴＰを例示しているが、これには限られない。例えばＳＯＡＰを用いても良い。その他のプロトコルを用いてもよいことは勿論である。ただし、利用するプロトコルに適合させるための実装プログラムを用意しなければならないことはもとよりである。
【００２８】
システム１ｂでは所定の操作を行い、その結果を同様な手法でシステム１ａに返送する。システム１ａは結果を戻り値として受け取る。なお、システム１ｂでの処理は必須ではなく、単にデータを受け取った旨の確認メッセージを返送してもよい。
【００２９】
各プロトコルを利用した通信データの送受信は、通信線１０を介して行われる。図ではプロトコル毎の通信線を示しているが、プロトコル毎の通信線は概念的あるいは論理的なものである。現実に通信線がプロトコル毎に設けられているものではないことはいうまでもない。
【００３０】
図２は、本実施の形態のデータ通信システムおよびその機能の一例を示したブロック図である。本実施の形態のデータ通信システムには、データ通信用のプログラムパッケージ１２を有する。なお、本実施の形態のデータ通信用プログラムを実行するために、プログラムの実行環境あるいはユーティリティプログラム、プログラムライブラリ等が必要であるが、図では省略している。以下に説明するＪａｖａプログラムでは、ＪＶＭ等の実行環境、コアＡＰＩ、標準拡張ＡＰＩ等のＪａｖａＡＰＩが必要である。
【００３１】
データ通信用プログラムパッケージ１２には、データ通信用クラス１３、データ通信用インタフェイス１４、ＣＯＲＢＡインプリメンテーション・クラス１５、ＥＪＢインプリメンテーション・クラス１６、ＭＱインプリメンテーション・クラス１７、ＨＴＴＰインプリメンテーション・クラス１８を有する。
【００３２】
データ通信用クラス１３は、アプリケーションプログラムにおいて初期化され、そのインスタンスが通信インタフェイスとして利用されるＪａｖａＡＰＩ（ジャバ・アプリケーション・プログラム・インタフェイス）のクラスである。データ通信用クラス１３には、その初期化によって生成されるデータ通信用インタフェイス１９（インスタンス）を含む。また、データ通信用クラス１３の初期化により、初期化に際に引数として渡されるプロパティで指定されたプロトコルに対応する通信用実装クラスのインスタンスを生成する。この通信用実装クラスは、前記ＣＯＲＢＡインプリメンテーション・クラス１５、ＥＪＢインプリメンテーション・クラス１６、ＭＱインプリメンテーション・クラス１７、ＨＴＴＰインプリメンテーション・クラス１８の何れかである。また、生成された通信用実装クラスのインスタンスは、前記したデータ通信用インタフェイス１９（インスタンス）にキャストされる。これにより、データ通信用クラス１３は、その初期化によって、プロトコルに対応したインスタンスを生成する。
【００３３】
データ通信用インタフェイス１４は、アプリケーションプログラムにおいて初期化されることにより、そこで記述された通信メソッド２０を継承するＪａｖａインタフェイスである。前記したように、データ通信用クラス１３のインスタンス内では、通信用実装クラスのインスタンスがインタフェイスにキャストされるので、このインタフェイスに記述されたメソッドを利用できるようにアプリケーションプログラム内でデータ通信用インタフェイス１４をインプリメントする必要がある。
【００３４】
ＣＯＲＢＡインプリメンテーション・クラス１５、ＥＪＢインプリメンテーション・クラス１６、ＭＱインプリメンテーション・クラス１７、ＨＴＴＰインプリメンテーション・クラス１８は、各々のプロトコルに適合した通信を実現するためのＪａｖａクラスである。各インプリメンテーション・クラス内では、各プロトコルに適合する様式で通信データを送受信するように通信メソッド２１〜２４が各々記述される。
【００３５】
以下にデータ通信用クラス１３、データ通信用インタフェイス１４、ＣＯＲＢＡ、ＥＪＢ、ＭＱ、ＨＴＴＰの各インプリメンテーション・クラス１５〜１８の一例をＪａｖａプログラムコードとして例示する。データ通信用クラス１３のクラス名は「CommunicationComponent」、データ通信用インタフェイスのインタフェイス名は「CommunicationInterface」である。ＣＯＲＢＡ、ＥＪＢ、ＭＱ、ＨＴＴＰの各インプリメンテーション・クラス１５〜１８のクラス名は、各々「CommunicationCORBAImplementation」、「CommunicationEJBImplementation」、「CommunicationMQImplementation」、「CommunicationHTTPImplementation」である。また、通信メソッドのメソッド名は、「call」である。
【００３６】
なお、以下のコードは、その主要部を示すものであり、プログラムの完全な実行を保証するものではない。また、以下の全ての例示コードにおいて、行頭の括弧書き数字は行番号を示す。
【００３７】
「CommunicationComponent」の内容（データ通信用クラス１３）
(1.01) CommunicationInterface commi;
(1.02) init(Property prop) {
(1.03) if(prop.get("Mode")=="CORBA")
(1.04) java.lang.Class cls =
(1.05) Class.forName("CommunicationCORBAImplementation.class");
(1.06) if(prop.get("Mode")=="EJB")
(1.07) java.lang.Class cls =
(1.08) Class.forName("CommunicationEJBImplementation.class");
(1.09) if(prop.get("Mode")=="MQ")
(1.10) java.lang.Class cls =
(1.11) Class.forName("CommunicationMQImplementation.class");
(1.12) if(prop.get("Mode")=="HTTP")
(1.13) java.lang.Class cls =
(1.14) Class.forName("CommunicationHTTPImplementation.class");
(1.15) commi = (CommunicationInterface) cls.newInstance();
(1.16) }
(1.17) Parser call(String target, Parser parser) {
(1.18) Parser ret_parser = commi.call(target, parser);
(1.19) return ret_parser;
(1.20) }
【００３８】
行番号(1.01)において、インタフェイス「CommunicationInterface」のインスタンス「commi」を生成する。この「CommunicationInterface」がデータ通信用インタフェイス１９に相当する。(1.02)〜(1.16)でプロパティ「prop」に応じた実装クラス（インプリメンテーション・クラス）が選択され、実装クラスのインスタンスは、インタフェイス型のインスタンス「commi」にキャストされる。(1.17)〜(1.20)はCommunicationInterfaceインスタンスでのcallメソッドの内容が記述される。すなわち、「CommunicationComponent」のcallメソッドが呼ばれると、commiインタフェイスにキャストされた「CommunicationCORBAImplementation」等実装インスタンスのcallメソッドが呼び出される。
【００３９】
「CommunicationInterface」の内容（データ通信用インタフェイス１４）
(2.01) public interface CommunicationInterface {
(2.02) Parser call (String target, Parser parser);
(2.03) }
「CommunicationInterface」では、Parserおよびcallメソッドが記述され、アプリケーションプログラムでの継承が可能になる。このcallメソッドが通信メソッド２０に相当する。
【００４０】
「CommunicationCORBAImplementation.class」内のcallメソッド（通信メソッド２１）の内容
(3.01) java.util.Properties props = new java.util.Properties();
(3.02) props.put("org.omg.CORBA.ORBClass", "com.ibm.CORBA.iiop.ORB");
(3.03) ORB orb = (com.ibm.CORBA.iiop.ORB) ORB.init
(3.04) (new String[0],props);
(3.05) obj = orb.resolve_initial_references("NameService");
(3.06) iExtendedNC = NamingContextHelper.narrow(obj);
(3.07) obj = iExtendedNC.resolve_with_string("CommunicationCORBA");
(3.08) CommunicationCORBA comm = CommunicationCORBAHelper.narrow( obj )
;
(3.09) parser = comm.call("targetMethod", parser.getString(),
(3.10) parser.getBinary());
行番号(3.01)〜(3.04)で「CORBA ORB」(通信部品)の初期化を行い、(3.05)〜(3.06)でネーム・サービスを取得する。(3.07)〜(3.08)でネーム・サービスによるサーバ・オブジェクトの検索と取得を行い、(3.09)〜(3.10)でCORBAサーバ・オブジェクトのcallメソッドの呼び出しを行っている。
【００４１】
「CommunicationEJBImplementation.class」内のcallメソッド（通信メソッド２２）の内容
(4.01) InitialContext context = new InitialContext();
(4.02) java.lang.Object obj = init_context.lookup("CommunicationEJB");
(4.03) CommunicationEJBHome cHome = (CommunicationEJBHome)
(4.04) javax.rmi.PortableRemoteObject.narrow
(4.05) (obj, CommunicationEJBHome.class );
(4.06) CommunicationEJB comm = cHome.create();
(4.07) parser = comm.call("targetMethod",
(4.08) parser.getString(), parser.getBinary());
行番号(4.01)でEJBの初期化を行い、(4.02)〜(4.06)でサーバEJBオブジェクトのHomeの検索と取得行う。そして、(4.07)〜(4.08)でEJBサーバ・オブジェクトのcallメソッドの呼び出しを行っている。
【００４２】
「CommunicationMQImplementation.class」内のcallメソッド（通信メソッド２３）の内容
(5.01) iMq_msg = new MQMessage();
(5.02) iMq_msg.correlationId = getUniqueId();
(5.03) iQMgr = getQueueManager();
(5.04) iQueue_manager = new MQQueueManager(iQMgr);
(5.05) iPut_queue = iQueue_manager.accessQueue(iPut_qName,
(5.06) (int)iQopen_option, null, null, null);
(5.07) iGet_queue = iQueue_manager.accessQueue(iGet_qName,
(5.08) (int)iQopen_option, null, null, null);
(5.09) iMq_msg.write(parser.getString() + parser.getBinary());
(5.10) iPut_queue.put(iMq_msg, iPut_option);
(5.11) iGet_queue.get(iMq_msg, iGet_option, iMaxMsg_size);
(5.12) byte retByte[] = new byte[iMq_msg.getDataLength()];
(5.13) iMq_msg.readFully(retByte);
(5.14) parser.restore(retByte)
行番号(5.01)〜(5.08)では、初期化を行っている。(5.01)では、メッセージの初期化を行い、(5.02)では、ユニークなIDを採番する。(5.03)では、キュー・マネージャーを取得し、(5.04)では、MQマネージャーを取得する。(5.05)および(5.06)では、PUTキューを取得し、(5.07)および(5.08)では、GETキューを取得する。また、(5.09)〜(5.14)では、メッセージの送受信(PUT/GET)を行う。(5.09)では、メッセージの作成を行い、(5.10)では、PUT (送信)を行う。(5.11)では、GET (受信)を行い、(5.12)では、帰りのデータを復元する。(5.13)では、帰りデータの取得を行い、(5.14)では、帰りのデータをパーサに復元する。
【００４３】
「CommunicationHTMLImplementation.class」内のcallメソッド（通信メソッド２４）の内容
(6.01) URLConnection urlConnection = url.openConnection();
(6.02) urlConnection.setDoOutput(true); // POST
(6.03) BufferedWriter bwn =
(6.04) new BufferedWriter(
(6.05) new OutputStreamWriter(urlConnection.getOutputStream()) );
(6.06) bwn.write(parser.getString()+parser.getEncodedBinary());
(6.07) bwn.close();
(6.08) BufferedReader brn = new BufferedReader(
(6.09) new InputStreamReader(urlConnection.getInputStream()) );
(6.10) String line = brn.readLine();
(6.11) brn.close();
(6.12) parser.restoreEncoded(line);
行番号(6.01)および(6.02)では、接続のオープンを行い、(6.03)〜(6.07)では、データの書き込みを行う。(6.08)〜(6.12)では、データの読み取りを行う。
【００４４】
上記の通りのプログラムパッケージ１２が用意されているシステムにおいて、アプリケーションプログラムからデータ通信を実現するデータ通信方法について以下に説明する。図２において、クライアントのシステム１ａ内に記載されている通信データ１１は、クライアントのアプリケーションプログラムで通信するべき通信データである。また、データ通信用インスタンス２５は、データ通信用クラス１３が初期化されることにより生成されるインスタンスであり、データ通信用インスタンス２５にはデータ通信用インタフェイス２６を含む。初期化により生成されたデータ通信用インタフェイス２６（前記例示コードではcommiに相当する）に通信メソッド２８（前記例示コードではcommi内のcallに相当する）が含まれることは前記の通りである。また、データ通信用インタフェイス２６には、初期化により、ＣＯＲＢＡ、ＥＪＢ、ＭＱ、ＨＴＴＰの何れかのインプリメンテーション（実装）クラスのインスタンスがキャストされるので、初期化後のデータ通信用インタフェイス２６は即ち何れかのインプリメンテーション・インスタンス２７である。インプリメンテーション・インスタンス２７には、各実装毎の通信メソッド２８（通信メソッド２１〜２４の何れか）を含む。インプリメンテーション・インスタンス２７によって、この通信メソッド２８がサーバのシステム１ｂの通信メソッド２８に紐付けられているため、アプリケーションプログラムから通信メソッド２８（前記例示コードではcallメソッドに相当する）を呼び出すことは、即ちサーバのシステム１ｂと通信することになる。本実施の形態のシステムでのアプリケーションプログラムにおけるデータ通信用プログラムの例示コードを以下に示す。
(7.01) CommunicationComponent cc = new CommunicationComponent(property);
(7.02) String return = cc.call(String target, Parser parser);
【００４５】
このように、本実施の形態のシステムでは、極めて簡単にデータ通信を実現できる。プログラマは、propertyにプロトコルを代入し、parserに通信データを代入し、targetに通信相手を代入して、前記コマンドを記述するのみである。なお、parserには文字列データとバイナリデータの両方が含まれる。
【００４６】
以下、前記通信プログラムの実行における処理の詳細をフローチャートに基づいて説明する。図３は、本実施の形態のデータ通信方法の一例を示したフローチャートである。まず、システム１ａでのアプリケーションプログラムにおいて、データ通信用インタフェイス１４をインプリメントし、通信メソッド（call）が利用可能であることを前提とする（ステップ３０）。
【００４７】
データ送信を行うアプリケーションプログラムにおいて、通信データ、プロパティを生成する（ステップ３１）。通信データはparserに、プロパティはpropertyに代入する。次に、データ通信用クラス（CommunicationComponent）のインスタンスccを生成し、引数propertyを代入してCommunicationComponentクラスを初期化する。初期化後の値はインスタンスccに代入される（ステップ３２、行番号7.01）。
【００４８】
このCommunicationComponentクラスの初期化によって、データ通信用インタフェイス（CommunicationInterface）のインスタンスcommiが生成される（ステップ３３、行番号1.01）。次に、プロパティ内のモードが判断され、モードがＣＯＲＢＡであればCommunicationCORBAImplementation.classが、ＥＪＢであればCommunicationEJBImplementation.classが、ＭＱであればCommunicationMQImplementation.classが、ＨＴＴＰであればCommunicationHTTPImplementation.classが各々選択され（ステップ３４、行番号1.03〜1.14）、選択されたインプリメンテーション・クラスのインスタンスが生成される（ステップ３５）。また、生成されたインスタンスはcommiにキャストされる（ステップ３６、行番号1.15）。
【００４９】
アプリケーションプログラムからccインスタンスのcallメソッドを呼び出すと（ステップ３８、行番号7.02）、commiインタフェイス、各実装（インプリメンテーション）のインスタンスを通じてサーバのcallメソッドが呼び出され（ステップ３９）、サーバ側に通信データparserが渡される。
【００５０】
サーバ側では、受け取ったデータを基に所定の処理を行い、戻り値を前記同様の方法により戻せる。クライアント側では、callメソッドの戻り値として、サーバ側の処理実行結果を受け取る（ステップ４０、行番号7.02）。なお、戻り値はreturnに代入される。
【００５１】
以上説明したように、本発明のデータ通信方法、セータ通信システムによれば、アプリケーションプログラムの開発あるいはメンテナンスにおいて、プログラマの負荷を下げることができる。これにより、プログラム開発の効率を向上できる。
【００５２】
（実施の形態２）
上記した実施の形態１において、アプリケーションプログラムで生成する通信データ１１に特に限定はなかった。本実施の形態では、通信データとしてＸＭＬを用いて記述する文字列データの例を説明する。即ち、本実施の形態のデータ通信システムで用いる通信データは、ＸＭＬに基づいて記述されたＸＭＬ文字列あるいはＸＭＬ文字列およびバイナリデータである。
【００５３】
ＸＭＬ文字列でデータを記述する際、たとえば名前データであれば、
(8.01) ＜Name＞特許太郎＜/Name＞
のように、データを記述するタグ（この例ではNameタグ）および終了タグでデータを囲む。そして、このデータは全て文字列として扱う。上記(8.01)が実施の形態１に適用される場合、
(8.02) String xml_data = String("＜Name＞特許太郎＜/Name＞");
(8.03) CommunicationComponent cc = new CommunicationComponent(property);
(8.04) String return = cc.call(String target, String xml_data);
を実行すればよい。
【００５４】
このように通信データをＸＭＬで構造化することにより、データの内容をアプリケーションレベルで把握することができる。即ち、ＸＭＬは可読性が高いので、データの内容についての理解が容易である。また、ＸＭＬは一般化できるため、必要なデータのみを取捨選択してアプリケーションプログラムで利用できる。このため、たとえば通信相手先のデータフォーマットが変更された場合でも、通信インタフェイスを変更すること無く、そのデータを利用するアプリケーションプログラムのみの変更でデータ仕様の変更に対処できる。このようなメリットは、特にデータ内容の変更に素早く対処しなければならないようなアプリケーションの場合に有効である。たとえば企業間のＢ２Ｂ取引の場合にメリットが大きい。また、ＸＭＬで記述されているので、データを受け取った後のアプリケーションプログラムにおいてデータの加工が容易である。さらに、ＸＭＬはパーサによって妥当性が検証できるので、通信データの信頼性、利用性が高くなる。また、アプリケーションの開発も容易になる。即ち、通信データにＸＭＬを用いることにより柔軟なアプリケーションシステムの構築が容易になる。
【００５５】
（実施の形態３）
実施の形態２では、通信データにＸＭＬを適用する例を説明したが、本実施の形態では、ＸＭＬ文字列を取り扱う際のデメリットを軽減する手法を説明する。即ち、ＸＭＬはパーサあるいはＸＭＬプロセッサによって妥当性が検証できる。しかし、妥当性検証のためのオーバーヘッドが大きければ、ミッションクリティカルな用途への適用が難しくなる。そこで、本実施の形態では、妥当性検証のための負荷を軽減する手法を説明する。
【００５６】
たとえば、配列（arrey）型のデータをＳＯＡＰ等ＸＭＬによるＲＰＣ通信を行うための規約に基づいて表現すると以下のようになる。たとえば３×２の文字列型配列をＳＯＡＰで記述すれば、
(9.01) ＜SOAP-ENC:Array SOAP-ENC:ArrayType="xsd:string[3,2]"＞
(9.02) ＜item＞row1col1＜/item＞＜item＞row1col2＜/item＞
(9.03) ＜item＞row2col1＜/item＞＜item＞row2col2＜/item＞
(9.04) ＜item＞row3col1＜/item＞＜item＞row3col2＜/item＞
(9.05) ＜/SOAP-ENC:Array＞
【００５７】
ここで、row1col1は１行１列の要素であり、その他同様に配列の各様をを示す。つまり、上記記述では配列の各要素がitemタグで囲まれている構造を持つ。ところが、このような同一構造のデータを多数繰り返す構造を持つデータでは、パーサによる文法解析の負荷が大きいことを本発明者は認識した。そこで、(9.01)〜(9.05)に示す構造と同様の構造を表すデータ構造として、以下のようなデータ構造を採用する。
(9.06) ＜Arraydata ARRAY_CONTENTS="true"＞
(9.07) row1col1,row1col2,row2col1,row2col2,row3col1,row3col2
(9.08) ＜/Arraydata＞
【００５８】
すなわち、同一構造を繰り返す部分について、タグを省略し、タグ（開始タグおよび終了タグ）をカンマ文字に置き換える。つまり、配列の要素間をカンマ文字で置き換えて、構造の特徴を維持しつつ、タグ数を減らせる。これによりパーサの妥当性検証負荷を軽減し、通信データとしてＸＭＬ文字列を用いる場合の処理を高速化できる。特にＸＭＬ文書の妥当性検証を行う場合にメリットが大きい。なお、カンマ文字は例示であり、その他のセパレータを用いることができることは勿論である。また、同様のアイデアは、一次元配列、マップ型等にも適用できる。その他同一構造が繰り返しタグ付けされて記述される場合にも適用できる。
【００５９】
上記配列型あるいはマップ型の場合のデータＸＭＬ文書として通信データに適用し、これを実施の形態１のシステムで実現する例を以下に示す。まず、配列型文字データを例示する。
(10.01) String cols[] = new Stirng[3];
(10.02) cols[0] = "Name";
(10.03) cols[1] = "Adrress";
(10.04) cols[2] = "Phone";
(10.05) TableModel table = new TabeleModel(cols);
(10.06) table.addValue("name","fname lname");
(10.07) table.addValue("Adrress","Country City Street");
(10.08) table.addValue("Phone","03-3000-3000");
(10.09) String xml_data = table.toString();
(10.03) CommunicationComponent cc;
(10.04) cc = new CommunicationComponent(property);
(10.05) String return = cc.call(String target, String xml_data);
【００６０】
この場合、生成される通信データxml_data（文字列型）は、
＜Table1＞fname lname,Country City Street,03-3000-3000＜/Table1＞
のようになる。
【００６１】
同様に、マップ型文字データは以下のように処理できる。
(11.01) MapModel map = new MapModel();
(11.02) map.put("name","fname lname");
(11.03) map.put("Adrress","Country City Street");
(11.04) map.put("Phone","03-3000-3000");
(11.05) String xml_data = map.toString();
(11.06) CommunicationComponent cc;
(11.07) cc = new CommunicationComponent(property);
(11.08) String return = cc.call(String target, String xml_data);
【００６２】
この場合、生成される通信データxml_data（文字列型）は、
＜Map1＞Name=fname lname,Adrress=Country City Street,Phone=03-3000-3000
＜/Map＞
のようになる。なお、ここでマップ要素とマップ要素に関連付けられるデータとの関連付けに「=」（イコール）文字を用いているが、その他の関連付け文字を適用できることは勿論である。
【００６３】
このように、本実施の形態では、同一構造が繰り返されるＸＭＬ文書において、その同一構造の特徴を損なわない範囲でこれを簡略化してタグ数の少ないＸＭＬ文字列を生成する。これにより、データ通信の速度を向上できる。特にパーサ等でのＸＭＬの妥当性検証を行う場合に顕著な効果を持つ。また、本実施の形態のようにＸＭＬ文書を簡略化するため、若干の汎用性が損なわれることは否めないが、エンジニアリング分野では、このような繰り返しのデータ構造が多く利用されるため、当該分野でなおかつ高速度の通信速度が要求される場合に本実施の形態のデータ通信方法を適用して効果が大きい。
【００６４】
（実施の形態４）
前記した実施の形態２，３では、何れも通信データとして文字列を用いる例を説明した。本実施の形態では、通信データにバイナリデータが含まれる場合を説明する。
【００６５】
通信データにバイナリデータが含まれる場合には、バイナリデータbyte[]と共に、このバイナリデータに含まれる要素の開始位置および終了位置をＸＭＬ文字列として通信データに含める。即ち、バイナリデータbyte[]の０バイト目から１００バイト目にPhoto1のバイナリデータが入り、１０１バイト目から２００バイト目にImage2のバイナリデータが入る場合、生成するＸＭＬ文字列は、
(12.01) ＜Photo1＞0,100＜/Photo1＞＜Image2＞101,200＜/Image2＞
とすることができる。
【００６６】
この場合のアイデアを実施の形態１で実現する例を示す。
(12.02) BinaryModel binary = new BinaryModel();
(12.03) binary.put("Photo1","byte[]);
(12.04) binary.put("Image2","byte[]);
(12.05) String xml = binary.toString();
(12.06) CommunicationComponent cc;
(12.07) cc = new CommunicationComponent(property);
(12.08) String return = cc.call(String target, xml, binary);
【００６７】
なお、実施の形態１では、文字列、バイナリの両方を通信データparserに入れているので、これと整合させるため、
(12.09) Parser parser;
(12.10) parser.putString(xml);
(12.11) parser.putBinary(binary);
とし、(12.08)を、
(12.12) String return = cc.call(String target, Parser parser);
としても良い。
【００６８】
本実施の形態によれば、バイナリデータのままで通信データを取り扱えるたえめ、たとえばバイナリデータを文字にエンコードし、その後デコードする必要がない。このため、通信速度を向上できる。また、バイナリデータのままで通信しても、同時にＸＭＬ文字列としてバイナデータ内の要素（前記例ではPhoto1、Image2）の開始位置、終了位置が特定されるので、何ら不都合はない。
【００６９】
（実施の形態５）
本実施の形態では、さらにＸＭＬ文書を簡略化してデータ通信速度を向上する方法を説明する。本実施の形態では、簡略化されたＸＭＬ文字列を生成するオリジナルパーサを提供する。以下例示コードを示す。
(13.01) OriginalParser parser = new OriginalParser();
(13.02) parser.put("Table1",table);
(13.03) parser.put("Map1",map);
(13.04) parser.put("Photo1",byte[]);
(13.05) parser.put("Image2",byte[]);
(13.06) CommunicationComponent cc=new CommunicationComponent(property);
(13.07) String return = cc.call(String target, Parser parser);
(13.08) parser.restore(return);
【００７０】
OriginalParserは、putメソッドを呼び出すことにより、第１引数で指定した指標文字のタグで第２引数のデータを囲む操作を行う。そして、第２引数のデータで囲んだタグ付き文字をparserに追加する。つまり、このオリジナルパーサで生成されるＸＭＬ文書の各要素の深さは１であり、要素の子要素は生成されない。なお、(13.02)〜(13.05)のtable,map,byte[]は、実施の形態３および４と同様である。また、(13.08)では、戻り値をパーサに入れ、戻り文書を解析した後に個々のデータを取り出す操作を行っている。
【００７１】
上記例示コードにより生成されるデータの文字列データは以下のようになる。
＜Table1＞fname lname,Country City Street,03-3000-3000＜/Table1＞＜Map1＞Name=fname lname,Adrress=Country City Street,Phone=03-3000-3000＜/Map＞＜Photo1＞0,100＜/Photo1＞＜Image2＞101,200＜/Image2＞
すなわち、通常のＸＭＬ文書とは相違して、配列内に別のデータ構造が存在したり、いくつかの階層に入れ子構造になったりしている構造がない。つまり単純な要素をタグで囲んだ構造が単純に繰り返されるだけである。
【００７２】
本実施の形態のパーサを用いれば、一般的汎用的なＸＭＬ文書を生成することはできないが、通常のビジネスデータを表現するには本実施の形態のパーサで生成されるＸＭＬ文字列で十分である。すなわち、本実施の形態の簡略化されたＸＭＬ文書を生成する独自パーサを利用して実施の形態１等に示したデータ通信方法を実現すれば、ビジネスデータの通信には何ら支障無く、かつ、メンテナンスが容易なＸＭＬ文書を容易に扱うことができる。しかも、本実施の形態のパーサで生成されるＸＭＬ文書は単純な構造なので、ＸＭＬ文書の妥当性解析が必要な場合であっても、パーサへの負荷が小さく、高速なデータ通信を実現することが可能になる。
【００７３】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更することが可能である。
【００７４】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、プログラム作成あるいはメンテナンス環境においてコンポーネント間通信で利用するプロトコルへの整合性を意識することなく、単一の手順でコンポーネント間通信が実現できる。また、データの仕様等が変更されても、最小限のメンテナンス負荷で変更に対応できる通信インタフェイス技術および通信データの構造を提供できる。また、通信データにＸＭＬ文字列が適用される場合に、そのデータ転送のためのオーバーヘッドを低減し、また、通信データの検証が必要な場合には、その検証のための処理負荷を低減することができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるデータ通信システムを模式的に示した概念図である。
【図２】本発明の一実施の形態であるデータ通信システムおよびその機能の一例を示したブロック図である。
【図３】本発明の一実施の形態であるデータ通信方法の一例を示したフローチャートである。
【符号の説明】
１ａ，１ｂ…システム、２ａ，２ｂ…アプリケーションプログラム、３ａ，３ｂ…データ通信用プログラム、４ａ，４ｂ…インタフェイスプログラム、５ａ〜９ａ，５ｂ〜９ｂ…実装プログラム、１０…通信線、１１…通信データ、１２…データ通信用プログラムパッケージ、１３…データ通信用クラス、１４…データ通信用インタフェイス、１５…ＣＯＲＢＡインプリメンテーション・クラス、１６…ＥＪＢインプリメンテーション・クラス、１７…ＭＱインプリメンテーション・クラス、１８…ＨＴＴＰインプリメンテーション・クラス、１９…データ通信用インタフェイス、２０〜２４…通信メソッド、２５…データ通信用インスタンス、２６…データ通信用インタフェイス、２７…インプリメンテーション・インスタンス、２８…通信メソッド。
【発明の属する技術分野】
本発明は、データ通信方法、データ通信システムおよびプログラムに関する。特に、分散環境におけるコンポーネント間のメッセージ（データ）通信に適用して有効な技術に関する。
【０００２】
【従来の技術】
コンピュータプログラムのより効率的な開発・メンテナンスの観点からオブジェクト指向プログラミングが注目されている。そして、オブジェクト（クラス）の集合からプログラムを部品化したコンポーネントを作成し、このコンポーネントを組み合わせることによって所定のタスク（処理）を実現するコンポーネントベースのシステム開発が行われるようになっている。たとえばＪａｖａのコンポーネント化技術であるＪａｖａＢｅａｎｓを用いたコンポーネント（ジャバビーン）の場合、イベントを受け取ったコンポーネントはメソッドを実行し、メソッドはそのコンポーネントのプロパティを変化させ、あるいは他のコンポーネント（あるいはインスタンス）からのメソッドの呼び出し、他のコンポーネントへのイベントの発行等の処理を行う。これらコンポーネントの動作（メソッド）を組み合わせて複雑なタスクを実現する。このようにコンポーネントの動作は、他のコンポーネントとのメッセージ（情報あるいはデータ）の交換が前提となる。
【０００３】
コンポーネントは同一のハードウェアシステム内に存在する場合もあるが、ＬＡＮ（Local Area Network）やインターネットで接続されたネットワーク上に存在する場合もある。従って、分散型コンポーネントの場合には、データがネットワーク上を通信するためのプロトコルが必要になる。たとえば、互いにインターネットで接続されるコンポーネント間では、インターネット分野の標準的な通信プロトコルであるＨＴＴＰ（HyperText Transfer Protocol）が利用できる。より信頼性が要求される場合には、ＣＯＲＢＡ（Common Object Request Broker Architecture）で採用されている分散オブジェクトの標準規格ＩＩＯＰ（Internet Inter-ORB Protocol）が利用できる。非同期通信が必要な場合は、ＭＱ（Message Queuing）を利用することができる。ホストコンピュータと端末との通信の場合にはＳＮＡ（Systems Network Architecture）を利用できる。ＪＶＭ（Java Virtual Machine）が稼動する環境では、ＲＭＩ（Remote Method Invocation）ライブラリを利用できる。なお、Ｊａｖａ２ではＲＭＩがＩＩＯＰにも対応しているので、ＲＭＩ over ＩＩＯＰが利用できる。なお、Ｊａｖａ、ＪａｖａＢｅａｎｓ、Ｊａｖａ２等はサンマイクロシステムズ社の商標である。また、以下の説明で登場するＷｉｎｄｏｗｓ、Ｕｎｉｘ、Ｃ、Ｃ＋＋等は、各々それを保有する各社あるいは団体の商標である。
【０００４】
ところで、コンポーネントベースのシステムによって実現される処理は多種多様である。たとえば企業における生産・在庫管理、財務会計管理、人事・給与支払い業務等企業活動の基幹業務を担うＥＲＰ（Enterprise Resource Planning）、データベース管理システム、ウェブサーバ等多岐に渡る。一般に企業内で利用されるイントラネットの場合、その通信信頼性は比較的高く設計する必要がある。また、１秒を争うミッションクリティカルな処理に適用し得るシステムを構築する必要がある。他方、ウェブアプリケーションの場合、１秒の処理速度を争うようなタスクは少なく、また、その通信信頼性が保証されないことを前提にシステムを構築することが許される。従って、システムを構築する場合、コンポーネント間の通信にどのようなプロトコルを採用するべきであるかは、その構築されるシステムの要求あるいはコンポーネントが担う処理の性質によって相違する。たとえば企業内のミッションクリティカルな処理に適用するには、その接続信頼性の高さ、障害発生時の追跡調査の容易性、セキュリティ、トランザクションコンテキストの伝搬可能性、パフォーマンスの高さ等の観点からＩＩＯＰを採用することが好ましい。また、ウェブアプリケーションの場合は、事実上の標準プロトコルであるＨＴＴＰを採用することが妥当である。ファイアウォールを構築するうえでもＨＴＴＰが使いやすい。非同期システムとの通信を行う場合はＭＱを採用することが好ましい。
【０００５】
ただし、これら各プロトコルには、デメリットもある。たとえばＩＩＯＰでは、ＩＩＯＰを利用するアプリケーション（コンポーネント）の通信インタフェイスが固定される。このため、通信データの属性の追加等データ仕様に変更が生じた時には、これに適合するようインタフェイスを修正する必要がある。ＨＴＴＰではＩＩＯＰで保証されるほどの通信信頼性が保証されず、障害発生時の追跡も容易でない。また、ＨＴＴＰは、基本的に文字列の転送規約であるから、バイナリデータの通信信頼性は確保されない。また、ＨＴＴＰでバイナリデータを転送するには、一旦キャラクタセットにエンコードし、これを転送する必要がある。転送の際にエンコード、デコードのためのサーバ負荷が増加し、またそのための処理時間が必要になる。よってミッションクリティカルが用途に適用することは難しい。
【０００６】
【発明が解決しようとする課題】
上記した通り、各プロトコルには各々メリットとデメリットがある。よってシステムを構築する際に何れのプロトコルを採用するかは、その利害得失を勘案したうえでシステム開発者によって選択されることになる。ところが、一つのアプリケーション（コンポーネント）で複数のプロトコルを利用する場合、各プロトコルに適合するようにプログラムの通信部分（インタフェイス）をプロトコル毎に作成する必要がある。つまり、プログラマはデータの送受信を担う部分のプログラムを作成する際に、利用するプロトコルを意識してプログラムを作成しなければならない。システム開発の生産性向上を考えれば、プログラマは、本来そのコンポーネントが担う機能を実現するプログラムの作成に意識を集中するべきであり、コンポーネントの機能以外の通信プロトコルを意識しなければならない状況は、システム開発の効率を低下させているといえる。
【０００７】
本発明の目的の一つは、プログラム作成あるいはメンテナンス環境においてコンポーネント間通信で利用するプロトコルへの整合性を意識することなく、単一の手順でコンポーネント間通信が実現できるインタフェイス技術を提供することにある。
【０００８】
ところで、近年注目されつつある企業間のインターネットを介した取引（Ｂ２Ｂ）を実現するシステムでは、どの様なプロトコルの採用が好ましいであろうか。企業間取引であることを考慮すれば、高い通信信頼性とパフォーマンスを備えたＩＩＯＰを利用することが好ましい。ところが、Ｂ２Ｂ取引では、既に構築されている企業内システム同士を、インターネットを介して接続する必要がある。Ｂ２Ｃ取引（企業顧客間取引）の場合は、サーバにアクセスする顧客に対して企業が独自に定義したデータ入力画面等を提示できるので、企業側が独自にデータフォーマットを決定することが許される。しかし、Ｂ２Ｂ取引の場合、接続先企業のシステムは殆どの場合既に構築されているので、接続先企業のデータフォーマットとの整合性を考慮する必要がある。たとえばデータ転送を行うミドルウェアを用意し、相手先企業のデータフォーマットの変更にも迅速に対処する必要がある。このような状況において、企業間取引にＩＩＯＰをそのまま採用すると以下のような問題がある。ＩＩＯＰには、前記したようなメリットがあるものの、ＩＩＯＰを利用するアプリケーションでは、通信インタフェイスが固定される。このため、たとえば通信相手のシステムにおいて、データ属性の追加等その仕様に変更があった時、インタフェイスもそれに適合するよう変更する必要がある。ここで、他のコンポーネント（あるいはクラス）がこのインタフェイスを利用している場合、インタフェイスを利用するコンポーネントに直接影響しないデータ仕様の変更であっても、インタフェイスの変更に影響を受けて、コンポーネントの再コンパイル等変更が必要になる。インタフェイスを利用するコンポーネントが多数存在する場合、このようなデータ仕様の変更に対処する作業が大きな負担になる。なおＩＩＯＰ以外のその他のプロトコルにおいてインタフェイスの変更が必要になる場合があり、このような場合、同様な問題が生じることは勿論である。
【０００９】
本発明の他の目的は、データの仕様等が変更されても、最小限のメンテナンス負荷で変更に対応できる通信インタフェイス技術および通信データの構造を提供することにある。
【００１０】
さらに、通信インタフェイスおよび通信データの一般化が行われても、これが実用レベルで使用に耐えるものでなければならない。特に企業内あるいは企業間取引で想定されるようなミッションクリティカルな処理に適用できる高いレベルのレスポンスを実現する必要がある。
【００１１】
本発明のさらに他の目的は、一般化された通信データにおいて、そのデータ転送のためのオーバーヘッドを低減し、また、通信データの検証が必要な場合には、その検証のための処理負荷を低減する技術を提供することにある。
【００１２】
その他の目的は、以下の実施の形態においてさらに明らかになるであろう。
【００１３】
【課題を解決するための手段】
本願の発明の概略を説明すれば、以下の通りである。すなわち、本発明のコンポーネント間のデータ通信方法は、プロパティおよび通信データを受け取るステップと、プロパティで指定されたプロトコルに従った通信データの通信を実行するステップと、を含む。つまり、本発明では、アプリケーションプログラムの稼動環境あるいは開発環境において、プロトコルに依存しないデータの通信が可能なインタフェイスプログラムを用意する。このデータ通信用インタフェイスプログラムは、たとえばデータ通信用のクラス、インタフェイス等の一連のプログラムとして提供される。アプリケーションプログラムにおいてデータ通信用のクラスを初期化（インスタンスの生成）し、さらにそのインスタンスからの通信メソッドの呼び出しとして通信インタフェイスの機能を実現する。通信データは、通信メソッドの引数として通信用プログラムに引き渡すことができる。また、本発明では、たとえば通信用クラスのインスタンスが生成（初期化）される際に、プロトコル毎に用意した通信用実装クラスをインスタンス化する。通信用実装クラスにはプロトコル毎の通信手順を通信メソッドとして記述しておく。何れの通信用実装クラスをインスタンス化するかは、初期化の際に渡されるプロパティ引数で特定されるプロトコルによって選択できる。すなわち、指定されたプロトコルに対応した通信用実装クラスをインスタンス化することにより、通信用インスタンス内の通信メソッドを呼び出すだけで、プロトコルに適合したデータ通信を実現できる。
【００１４】
このように、本発明の通信用インタフェイスプログラムでは、各プロトコルに対応したインスタンスの生成によって、プロトコル毎に相違するプログラム記述様式を吸収する。これにより、アプリケーションレベルでは、プロトコル毎に相違するプログラム記述様式を意識する必要はなく、単に通信用クラス（インタフェイスプログラム）のプロトコルを指定した初期化（インスタンスの生成）と、通信メソッドの呼び出しとによって、ターゲットコンポーネント（通信相手）とのデータ通信を実現できる。通信データは通信メソッドの引数として渡すだけなので、プログラマはプロトコル毎の記述様式の相違を意識する必要は全くない。しかも、採用すべきプロトコルは、インスタンス生成の際のプロパティ指定によって簡単に選択できるので、多様なプロトコルからその状況に応じた最適のプロトコルを簡単に利用できる。これによりプログラマは本来の機能実現のためのアプリケーション開発に意識を集中することができ、プログラム開発およびメンテナンスの効率を向上することができる。なお、通信メソッド呼び出しの結果（戻り値）は適当な変数に代入することにより受け取る。
【００１５】
また、本発明では、通信データとして、ＸＭＬ（Extensible Markup Language）形式で記述された文字列、またはバイナリデータとＸＭＬ文字列との組合せを用いる。つまり、ＸＭＬ文字列によって通信データを一般化する。本発明では、データの要素が構造化されているので、データ仕様の変更等に対処しやすくなる。しかも、ＸＭＬではタグによって各要素を独自に定義できる。このため、アプリケーションで必要なデータのみを参照することが可能になり、関係のないデータ（要素）は読み飛ばす等の柔軟な処理が可能になる。これにより、データ仕様が変更になっても、アプリケーションレベルでそのデータ仕様の変更に対処することができ、通信インタフェイスに影響を及ぼすことがない。つまり、データ仕様の変更によりインタフェイスプログラムの変更を行う必要がないので、多数のコンポーネントからインタフェイスを利用している場合であってもコンポーネントの再コンパイル等再構成をする必要がなくなる。つまりデータ仕様の変更があっても、そのデータを利用するアプリケーションでのプログラムの変更に限られ、システムの各コンポーネントを全体的にメンテナンスする必要がない。
【００１６】
また、本発明では、通信データにバイナリデータを含むため、バイナリデータを一旦文字列等にエンコードし、受信側でデコードする作業がない。これにより通信のオーバーヘッドを少なくすることができる。バイナリデータを含む場合には、その開始位置と終了位置を特定する必要がある。このバイナリデータの区分情報は、前記したようなＸＭＬ文字列として通信できる。バイナリデータの位置情報を示すＸＭＬ文字列は、バイナリデータ内の要素の開始位置を示す文字列、カンマ文字その他任意定義のセパレータ、および要素の終了位置を示す文字列からなる要素位置文字列を生成するステップと、要素位置文字列を要素の要素タグおよびその終了タグで囲むステップとで生成できる。
【００１７】
また、本発明では、通信に採用するデータ構造としてＸＭＬを前提にした場合のオーバーヘッドの軽減手段を備える。つまり、通信しようとするデータに配列型データを含む場合には、配列型データの各要素を、カンマ文字その他任意定義のセパレータで区分し、各要素およびセパレータからなる配列データ文字列を生成するステップと、配列データ文字列を配列型タグおよびその終了タグで囲みＸＭＬ形式の文字列を生成するステップと、を含むことができる。あるいは、通信しようとするデータにマップ型データを含む場合には、マップ型データの要素と要素にマッピングされたマッピングデータとをイコール文字その他任意定義の関連付け文字で関連付け、要素、関連付け文字およびマッピングデータからなる要素・データ文字列を生成するステップと、要素毎の要素・データ文字列を、カンマ文字その他任意定義のセパレータで区分し、要素・データ文字列およびセパレータからなるマップデータ文字列を生成するステップと、マップデータ文字列をマップ型タグおよびその終了タグで囲みＸＭＬ形式の文字列を生成するステップと、を含むことができる。たとえばＳＯＡＰ（Simple Object Access Protocol）などのＸＭＬによるＲＰＣ（Remote Procedure Call）通信を行うプロトコルでは、文書の各要素にタグを付けた形式でデータの送受信を行うと定義している。配列型あるいはマップ型等同一タイプの要素を多数繰り返すようなデータの場合、各要素に逐一タグがつけられるのでオーバーヘッドが大きくなる。このような構造のデータの場合、その構造を単純した規約で記述したとしてもＸＭＬの可読性、構造化性を損なうことなく、付加されるタグの数を顕著に少なくできる。これにより、ＸＭＬ文字列の文字数を少なくして、通信のオーバーヘッドを軽減できる。また、タグ数の低減は、ＸＭＬプロセッサやパーサによる妥当性検証によるオーバーヘッドも少なくできる。これらオーバーヘッドの軽減により、実用的な通信手段を提供できる。
【００１８】
また、本発明では、より簡略化したＸＭＬ文字列の生成のための独自パーサを提供する。すなわち、通信しようとするデータ、およびデータを指標する指標文字列を受け取るステップと、通信しようとするデータまたはその属性データを、指標文字列を含む開始タグおよびその終了タグで囲み、ＸＭＬ形式の文字列を生成するステップと、他の通信しようとするデータについてステップを繰り返し、他の通信しようとするデータについてのＸＭＬ形式の第２文字列を生成し、文字列第２文字列を追加するステップと、を有する。このような手法によれば、要素内に子要素をもつような深い構造のＸＭＬ文書は作成されない。従って、ＸＭＬ文書の一般性、汎用性は幾分損なわれるが、単純な構造のＸＭＬ文書であるため特に妥当性検証が必要な場合の処理速度の向上が期待できる。本発明のように通信データとしてＸＭＬを用いる場合には、深い構造を用いてデータを表現する必要性はあまりない。他方、妥当性検証でのオーバーヘッドを軽減して高速な通信手段を実現するメリットの方が大きい場合がある。このようなときに適用して有効である。データの妥当性について信頼できない通信相手からのデータ受信の際には妥当性検証は重要であり、特に不特定多数のユーザからデータ受信を受信するようなアプリケーションの場合に利用できる。なお、十分に信頼できる相手からの通信の場合に、妥当性検証を省略して通信速度を向上できることは言うまでもない。特定の相手であって、そのデータ構造を含めたデータ通信についてテストされているような場合は、むしろ妥当性検証を省略してレスポンスを高める方がメリットが大きい場合もある。
【００１９】
なお、前記した簡略化されたパーサの場合に、配列型あるいはマップ型のデータが含まれるとき、前記したと同様にその構造を簡略化してタグの数を減ずることができるのは勿論である。また、データにバイナリデータが含まれる場合に、簡略化されたパーサにおいても、前記と同様に取り扱えることも勿論である。
【００２０】
なお、本発明で対処できるプロトコルとして、ＣＯＲＢＡ／ＩＩＯＰ、ＲＭＩ over ＩＩＯＰ、ＨＴＴＰ、メッセージ・キューイング（ＭＱ）、ＳＯＡＰを例示できる。ただし、本発明はこれらプロトコルに限られず、前記した通信用インタフェイスプログラム（クラス）に実装できる限り、その他のプロトコルであっても良いことは勿論である。
【００２１】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００２２】
以下の実施の形態で説明する方法またはシステムは、当業者であれば明らかなとおり、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。
【００２３】
また以下の実施の形態では、そのシステムとして一般的なコンピュータシステムを用いることができる。実施の形態で用いることができるコンピュータシステムは、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ）、不揮発性記憶装置（ＲＯＭ）、コプロセッサ、画像アクセラレータ、キャッシュメモリ、入出力制御装置（Ｉ／Ｏ）等、一般的にコンピュータシステムに備えられるハードウェア資源を備える。また、ハードディスク装置等の外部記憶装置、インターネット等のネットワークに接続可能な通信手段を備える。コンピュータシステムには、パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等各種のコンピュータが含まれる。
【００２４】
また、本実施の形態で説明するプログラムを稼動させる環境に特に制限はない。以下の説明ではＥＪＢ（Enterprise Java Beans）を想定するが、Ｊａｖａサーブレット、アパッチ等のウェブサーバ、その他のミドルウェア、Ｕｎｉｘ、Ｗｉｎｄｏｗｓ、その他のＯＳ等の環境であってもよい。また、プログラム言語にも制限はない。ただし、プログラム言語はオブジェクト指向であることが好ましい。以下の説明では、プログラム言語として主にＪａｖａあるいはＪａｖａ２を利用した場合を説明するが、Ｃ＋＋、ｏｂｊｅｃｔｉｖ−Ｃ、ｓｍａｌｌｔａｌｋ、Ｃ等であってもよい。
【００２５】
（実施の形態１）
図１は、本発明の一実施の形態であるデータ通信システムを模式的に示した概念図である。本実施の形態のデータ通信システムは、システム１ａとシステム１ｂにあるアプリケーションプログラム２ａ、２ｂ間のデータ通信を行う。各システム１ａ、１ｂには、図示するように各々、データ通信用プログラム３ａ、３ｂ、インタフェイスプログラム４ａ、４ｂ、プロトコル毎の実装プログラム５ａ〜９ａ、５ｂ〜９ｂを有する。
【００２６】
アプリケーションプログラム２ａで通信する必要がある通信データは、選択するプロトコルをプロパティとして指定した上でデータ通信用プログラム３ａに送られる。データ通信用プログラム３ａにデータを送るための手順はプロトコル毎に相違するものではなく、統一された単純な手順である。このような統一された単純な手順を用いてアプリケーションプログラム２ａからの通信が行えるため、プログラマはプロトコル毎の仕様あるいは手順を意識すること無く、アプリケーションの開発あるいはメンテナンスを行うことができる。
【００２７】
データ通信用プログラム３ａでは、インタフェイスプログラム４ａを利用して指定されたプロトコルに対応する実装プログラム５ａ〜９ａを実装する。そして受け取った通信データを、実装されたプログラム（実装プログラム５ａ〜９ａの何れか）を利用してシステム１ｂに送信する。なお、図では、実装プログラムとしてＣＯＲＢＡ（ＩＩＯＰ）、ＥＪＢ（ＲＭＩ over ＩＩＯＰ）、ＭＱ、ＨＴＴＰを例示しているが、これには限られない。例えばＳＯＡＰを用いても良い。その他のプロトコルを用いてもよいことは勿論である。ただし、利用するプロトコルに適合させるための実装プログラムを用意しなければならないことはもとよりである。
【００２８】
システム１ｂでは所定の操作を行い、その結果を同様な手法でシステム１ａに返送する。システム１ａは結果を戻り値として受け取る。なお、システム１ｂでの処理は必須ではなく、単にデータを受け取った旨の確認メッセージを返送してもよい。
【００２９】
各プロトコルを利用した通信データの送受信は、通信線１０を介して行われる。図ではプロトコル毎の通信線を示しているが、プロトコル毎の通信線は概念的あるいは論理的なものである。現実に通信線がプロトコル毎に設けられているものではないことはいうまでもない。
【００３０】
図２は、本実施の形態のデータ通信システムおよびその機能の一例を示したブロック図である。本実施の形態のデータ通信システムには、データ通信用のプログラムパッケージ１２を有する。なお、本実施の形態のデータ通信用プログラムを実行するために、プログラムの実行環境あるいはユーティリティプログラム、プログラムライブラリ等が必要であるが、図では省略している。以下に説明するＪａｖａプログラムでは、ＪＶＭ等の実行環境、コアＡＰＩ、標準拡張ＡＰＩ等のＪａｖａＡＰＩが必要である。
【００３１】
データ通信用プログラムパッケージ１２には、データ通信用クラス１３、データ通信用インタフェイス１４、ＣＯＲＢＡインプリメンテーション・クラス１５、ＥＪＢインプリメンテーション・クラス１６、ＭＱインプリメンテーション・クラス１７、ＨＴＴＰインプリメンテーション・クラス１８を有する。
【００３２】
データ通信用クラス１３は、アプリケーションプログラムにおいて初期化され、そのインスタンスが通信インタフェイスとして利用されるＪａｖａＡＰＩ（ジャバ・アプリケーション・プログラム・インタフェイス）のクラスである。データ通信用クラス１３には、その初期化によって生成されるデータ通信用インタフェイス１９（インスタンス）を含む。また、データ通信用クラス１３の初期化により、初期化に際に引数として渡されるプロパティで指定されたプロトコルに対応する通信用実装クラスのインスタンスを生成する。この通信用実装クラスは、前記ＣＯＲＢＡインプリメンテーション・クラス１５、ＥＪＢインプリメンテーション・クラス１６、ＭＱインプリメンテーション・クラス１７、ＨＴＴＰインプリメンテーション・クラス１８の何れかである。また、生成された通信用実装クラスのインスタンスは、前記したデータ通信用インタフェイス１９（インスタンス）にキャストされる。これにより、データ通信用クラス１３は、その初期化によって、プロトコルに対応したインスタンスを生成する。
【００３３】
データ通信用インタフェイス１４は、アプリケーションプログラムにおいて初期化されることにより、そこで記述された通信メソッド２０を継承するＪａｖａインタフェイスである。前記したように、データ通信用クラス１３のインスタンス内では、通信用実装クラスのインスタンスがインタフェイスにキャストされるので、このインタフェイスに記述されたメソッドを利用できるようにアプリケーションプログラム内でデータ通信用インタフェイス１４をインプリメントする必要がある。
【００３４】
ＣＯＲＢＡインプリメンテーション・クラス１５、ＥＪＢインプリメンテーション・クラス１６、ＭＱインプリメンテーション・クラス１７、ＨＴＴＰインプリメンテーション・クラス１８は、各々のプロトコルに適合した通信を実現するためのＪａｖａクラスである。各インプリメンテーション・クラス内では、各プロトコルに適合する様式で通信データを送受信するように通信メソッド２１〜２４が各々記述される。
【００３５】
以下にデータ通信用クラス１３、データ通信用インタフェイス１４、ＣＯＲＢＡ、ＥＪＢ、ＭＱ、ＨＴＴＰの各インプリメンテーション・クラス１５〜１８の一例をＪａｖａプログラムコードとして例示する。データ通信用クラス１３のクラス名は「CommunicationComponent」、データ通信用インタフェイスのインタフェイス名は「CommunicationInterface」である。ＣＯＲＢＡ、ＥＪＢ、ＭＱ、ＨＴＴＰの各インプリメンテーション・クラス１５〜１８のクラス名は、各々「CommunicationCORBAImplementation」、「CommunicationEJBImplementation」、「CommunicationMQImplementation」、「CommunicationHTTPImplementation」である。また、通信メソッドのメソッド名は、「call」である。
【００３６】
なお、以下のコードは、その主要部を示すものであり、プログラムの完全な実行を保証するものではない。また、以下の全ての例示コードにおいて、行頭の括弧書き数字は行番号を示す。
【００３７】
「CommunicationComponent」の内容（データ通信用クラス１３）
(1.01) CommunicationInterface commi;
(1.02) init(Property prop) {
(1.03) if(prop.get("Mode")=="CORBA")
(1.04) java.lang.Class cls =
(1.05) Class.forName("CommunicationCORBAImplementation.class");
(1.06) if(prop.get("Mode")=="EJB")
(1.07) java.lang.Class cls =
(1.08) Class.forName("CommunicationEJBImplementation.class");
(1.09) if(prop.get("Mode")=="MQ")
(1.10) java.lang.Class cls =
(1.11) Class.forName("CommunicationMQImplementation.class");
(1.12) if(prop.get("Mode")=="HTTP")
(1.13) java.lang.Class cls =
(1.14) Class.forName("CommunicationHTTPImplementation.class");
(1.15) commi = (CommunicationInterface) cls.newInstance();
(1.16) }
(1.17) Parser call(String target, Parser parser) {
(1.18) Parser ret_parser = commi.call(target, parser);
(1.19) return ret_parser;
(1.20) }
【００３８】
行番号(1.01)において、インタフェイス「CommunicationInterface」のインスタンス「commi」を生成する。この「CommunicationInterface」がデータ通信用インタフェイス１９に相当する。(1.02)〜(1.16)でプロパティ「prop」に応じた実装クラス（インプリメンテーション・クラス）が選択され、実装クラスのインスタンスは、インタフェイス型のインスタンス「commi」にキャストされる。(1.17)〜(1.20)はCommunicationInterfaceインスタンスでのcallメソッドの内容が記述される。すなわち、「CommunicationComponent」のcallメソッドが呼ばれると、commiインタフェイスにキャストされた「CommunicationCORBAImplementation」等実装インスタンスのcallメソッドが呼び出される。
【００３９】
「CommunicationInterface」の内容（データ通信用インタフェイス１４）
(2.01) public interface CommunicationInterface {
(2.02) Parser call (String target, Parser parser);
(2.03) }
「CommunicationInterface」では、Parserおよびcallメソッドが記述され、アプリケーションプログラムでの継承が可能になる。このcallメソッドが通信メソッド２０に相当する。
【００４０】
「CommunicationCORBAImplementation.class」内のcallメソッド（通信メソッド２１）の内容
(3.01) java.util.Properties props = new java.util.Properties();
(3.02) props.put("org.omg.CORBA.ORBClass", "com.ibm.CORBA.iiop.ORB");
(3.03) ORB orb = (com.ibm.CORBA.iiop.ORB) ORB.init
(3.04) (new String[0],props);
(3.05) obj = orb.resolve_initial_references("NameService");
(3.06) iExtendedNC = NamingContextHelper.narrow(obj);
(3.07) obj = iExtendedNC.resolve_with_string("CommunicationCORBA");
(3.08) CommunicationCORBA comm = CommunicationCORBAHelper.narrow( obj )
;
(3.09) parser = comm.call("targetMethod", parser.getString(),
(3.10) parser.getBinary());
行番号(3.01)〜(3.04)で「CORBA ORB」(通信部品)の初期化を行い、(3.05)〜(3.06)でネーム・サービスを取得する。(3.07)〜(3.08)でネーム・サービスによるサーバ・オブジェクトの検索と取得を行い、(3.09)〜(3.10)でCORBAサーバ・オブジェクトのcallメソッドの呼び出しを行っている。
【００４１】
「CommunicationEJBImplementation.class」内のcallメソッド（通信メソッド２２）の内容
(4.01) InitialContext context = new InitialContext();
(4.02) java.lang.Object obj = init_context.lookup("CommunicationEJB");
(4.03) CommunicationEJBHome cHome = (CommunicationEJBHome)
(4.04) javax.rmi.PortableRemoteObject.narrow
(4.05) (obj, CommunicationEJBHome.class );
(4.06) CommunicationEJB comm = cHome.create();
(4.07) parser = comm.call("targetMethod",
(4.08) parser.getString(), parser.getBinary());
行番号(4.01)でEJBの初期化を行い、(4.02)〜(4.06)でサーバEJBオブジェクトのHomeの検索と取得行う。そして、(4.07)〜(4.08)でEJBサーバ・オブジェクトのcallメソッドの呼び出しを行っている。
【００４２】
「CommunicationMQImplementation.class」内のcallメソッド（通信メソッド２３）の内容
(5.01) iMq_msg = new MQMessage();
(5.02) iMq_msg.correlationId = getUniqueId();
(5.03) iQMgr = getQueueManager();
(5.04) iQueue_manager = new MQQueueManager(iQMgr);
(5.05) iPut_queue = iQueue_manager.accessQueue(iPut_qName,
(5.06) (int)iQopen_option, null, null, null);
(5.07) iGet_queue = iQueue_manager.accessQueue(iGet_qName,
(5.08) (int)iQopen_option, null, null, null);
(5.09) iMq_msg.write(parser.getString() + parser.getBinary());
(5.10) iPut_queue.put(iMq_msg, iPut_option);
(5.11) iGet_queue.get(iMq_msg, iGet_option, iMaxMsg_size);
(5.12) byte retByte[] = new byte[iMq_msg.getDataLength()];
(5.13) iMq_msg.readFully(retByte);
(5.14) parser.restore(retByte)
行番号(5.01)〜(5.08)では、初期化を行っている。(5.01)では、メッセージの初期化を行い、(5.02)では、ユニークなIDを採番する。(5.03)では、キュー・マネージャーを取得し、(5.04)では、MQマネージャーを取得する。(5.05)および(5.06)では、PUTキューを取得し、(5.07)および(5.08)では、GETキューを取得する。また、(5.09)〜(5.14)では、メッセージの送受信(PUT/GET)を行う。(5.09)では、メッセージの作成を行い、(5.10)では、PUT (送信)を行う。(5.11)では、GET (受信)を行い、(5.12)では、帰りのデータを復元する。(5.13)では、帰りデータの取得を行い、(5.14)では、帰りのデータをパーサに復元する。
【００４３】
「CommunicationHTMLImplementation.class」内のcallメソッド（通信メソッド２４）の内容
(6.01) URLConnection urlConnection = url.openConnection();
(6.02) urlConnection.setDoOutput(true); // POST
(6.03) BufferedWriter bwn =
(6.04) new BufferedWriter(
(6.05) new OutputStreamWriter(urlConnection.getOutputStream()) );
(6.06) bwn.write(parser.getString()+parser.getEncodedBinary());
(6.07) bwn.close();
(6.08) BufferedReader brn = new BufferedReader(
(6.09) new InputStreamReader(urlConnection.getInputStream()) );
(6.10) String line = brn.readLine();
(6.11) brn.close();
(6.12) parser.restoreEncoded(line);
行番号(6.01)および(6.02)では、接続のオープンを行い、(6.03)〜(6.07)では、データの書き込みを行う。(6.08)〜(6.12)では、データの読み取りを行う。
【００４４】
上記の通りのプログラムパッケージ１２が用意されているシステムにおいて、アプリケーションプログラムからデータ通信を実現するデータ通信方法について以下に説明する。図２において、クライアントのシステム１ａ内に記載されている通信データ１１は、クライアントのアプリケーションプログラムで通信するべき通信データである。また、データ通信用インスタンス２５は、データ通信用クラス１３が初期化されることにより生成されるインスタンスであり、データ通信用インスタンス２５にはデータ通信用インタフェイス２６を含む。初期化により生成されたデータ通信用インタフェイス２６（前記例示コードではcommiに相当する）に通信メソッド２８（前記例示コードではcommi内のcallに相当する）が含まれることは前記の通りである。また、データ通信用インタフェイス２６には、初期化により、ＣＯＲＢＡ、ＥＪＢ、ＭＱ、ＨＴＴＰの何れかのインプリメンテーション（実装）クラスのインスタンスがキャストされるので、初期化後のデータ通信用インタフェイス２６は即ち何れかのインプリメンテーション・インスタンス２７である。インプリメンテーション・インスタンス２７には、各実装毎の通信メソッド２８（通信メソッド２１〜２４の何れか）を含む。インプリメンテーション・インスタンス２７によって、この通信メソッド２８がサーバのシステム１ｂの通信メソッド２８に紐付けられているため、アプリケーションプログラムから通信メソッド２８（前記例示コードではcallメソッドに相当する）を呼び出すことは、即ちサーバのシステム１ｂと通信することになる。本実施の形態のシステムでのアプリケーションプログラムにおけるデータ通信用プログラムの例示コードを以下に示す。
(7.01) CommunicationComponent cc = new CommunicationComponent(property);
(7.02) String return = cc.call(String target, Parser parser);
【００４５】
このように、本実施の形態のシステムでは、極めて簡単にデータ通信を実現できる。プログラマは、propertyにプロトコルを代入し、parserに通信データを代入し、targetに通信相手を代入して、前記コマンドを記述するのみである。なお、parserには文字列データとバイナリデータの両方が含まれる。
【００４６】
以下、前記通信プログラムの実行における処理の詳細をフローチャートに基づいて説明する。図３は、本実施の形態のデータ通信方法の一例を示したフローチャートである。まず、システム１ａでのアプリケーションプログラムにおいて、データ通信用インタフェイス１４をインプリメントし、通信メソッド（call）が利用可能であることを前提とする（ステップ３０）。
【００４７】
データ送信を行うアプリケーションプログラムにおいて、通信データ、プロパティを生成する（ステップ３１）。通信データはparserに、プロパティはpropertyに代入する。次に、データ通信用クラス（CommunicationComponent）のインスタンスccを生成し、引数propertyを代入してCommunicationComponentクラスを初期化する。初期化後の値はインスタンスccに代入される（ステップ３２、行番号7.01）。
【００４８】
このCommunicationComponentクラスの初期化によって、データ通信用インタフェイス（CommunicationInterface）のインスタンスcommiが生成される（ステップ３３、行番号1.01）。次に、プロパティ内のモードが判断され、モードがＣＯＲＢＡであればCommunicationCORBAImplementation.classが、ＥＪＢであればCommunicationEJBImplementation.classが、ＭＱであればCommunicationMQImplementation.classが、ＨＴＴＰであればCommunicationHTTPImplementation.classが各々選択され（ステップ３４、行番号1.03〜1.14）、選択されたインプリメンテーション・クラスのインスタンスが生成される（ステップ３５）。また、生成されたインスタンスはcommiにキャストされる（ステップ３６、行番号1.15）。
【００４９】
アプリケーションプログラムからccインスタンスのcallメソッドを呼び出すと（ステップ３８、行番号7.02）、commiインタフェイス、各実装（インプリメンテーション）のインスタンスを通じてサーバのcallメソッドが呼び出され（ステップ３９）、サーバ側に通信データparserが渡される。
【００５０】
サーバ側では、受け取ったデータを基に所定の処理を行い、戻り値を前記同様の方法により戻せる。クライアント側では、callメソッドの戻り値として、サーバ側の処理実行結果を受け取る（ステップ４０、行番号7.02）。なお、戻り値はreturnに代入される。
【００５１】
以上説明したように、本発明のデータ通信方法、セータ通信システムによれば、アプリケーションプログラムの開発あるいはメンテナンスにおいて、プログラマの負荷を下げることができる。これにより、プログラム開発の効率を向上できる。
【００５２】
（実施の形態２）
上記した実施の形態１において、アプリケーションプログラムで生成する通信データ１１に特に限定はなかった。本実施の形態では、通信データとしてＸＭＬを用いて記述する文字列データの例を説明する。即ち、本実施の形態のデータ通信システムで用いる通信データは、ＸＭＬに基づいて記述されたＸＭＬ文字列あるいはＸＭＬ文字列およびバイナリデータである。
【００５３】
ＸＭＬ文字列でデータを記述する際、たとえば名前データであれば、
(8.01) ＜Name＞特許太郎＜/Name＞
のように、データを記述するタグ（この例ではNameタグ）および終了タグでデータを囲む。そして、このデータは全て文字列として扱う。上記(8.01)が実施の形態１に適用される場合、
(8.02) String xml_data = String("＜Name＞特許太郎＜/Name＞");
(8.03) CommunicationComponent cc = new CommunicationComponent(property);
(8.04) String return = cc.call(String target, String xml_data);
を実行すればよい。
【００５４】
このように通信データをＸＭＬで構造化することにより、データの内容をアプリケーションレベルで把握することができる。即ち、ＸＭＬは可読性が高いので、データの内容についての理解が容易である。また、ＸＭＬは一般化できるため、必要なデータのみを取捨選択してアプリケーションプログラムで利用できる。このため、たとえば通信相手先のデータフォーマットが変更された場合でも、通信インタフェイスを変更すること無く、そのデータを利用するアプリケーションプログラムのみの変更でデータ仕様の変更に対処できる。このようなメリットは、特にデータ内容の変更に素早く対処しなければならないようなアプリケーションの場合に有効である。たとえば企業間のＢ２Ｂ取引の場合にメリットが大きい。また、ＸＭＬで記述されているので、データを受け取った後のアプリケーションプログラムにおいてデータの加工が容易である。さらに、ＸＭＬはパーサによって妥当性が検証できるので、通信データの信頼性、利用性が高くなる。また、アプリケーションの開発も容易になる。即ち、通信データにＸＭＬを用いることにより柔軟なアプリケーションシステムの構築が容易になる。
【００５５】
（実施の形態３）
実施の形態２では、通信データにＸＭＬを適用する例を説明したが、本実施の形態では、ＸＭＬ文字列を取り扱う際のデメリットを軽減する手法を説明する。即ち、ＸＭＬはパーサあるいはＸＭＬプロセッサによって妥当性が検証できる。しかし、妥当性検証のためのオーバーヘッドが大きければ、ミッションクリティカルな用途への適用が難しくなる。そこで、本実施の形態では、妥当性検証のための負荷を軽減する手法を説明する。
【００５６】
たとえば、配列（arrey）型のデータをＳＯＡＰ等ＸＭＬによるＲＰＣ通信を行うための規約に基づいて表現すると以下のようになる。たとえば３×２の文字列型配列をＳＯＡＰで記述すれば、
(9.01) ＜SOAP-ENC:Array SOAP-ENC:ArrayType="xsd:string[3,2]"＞
(9.02) ＜item＞row1col1＜/item＞＜item＞row1col2＜/item＞
(9.03) ＜item＞row2col1＜/item＞＜item＞row2col2＜/item＞
(9.04) ＜item＞row3col1＜/item＞＜item＞row3col2＜/item＞
(9.05) ＜/SOAP-ENC:Array＞
【００５７】
ここで、row1col1は１行１列の要素であり、その他同様に配列の各様をを示す。つまり、上記記述では配列の各要素がitemタグで囲まれている構造を持つ。ところが、このような同一構造のデータを多数繰り返す構造を持つデータでは、パーサによる文法解析の負荷が大きいことを本発明者は認識した。そこで、(9.01)〜(9.05)に示す構造と同様の構造を表すデータ構造として、以下のようなデータ構造を採用する。
(9.06) ＜Arraydata ARRAY_CONTENTS="true"＞
(9.07) row1col1,row1col2,row2col1,row2col2,row3col1,row3col2
(9.08) ＜/Arraydata＞
【００５８】
すなわち、同一構造を繰り返す部分について、タグを省略し、タグ（開始タグおよび終了タグ）をカンマ文字に置き換える。つまり、配列の要素間をカンマ文字で置き換えて、構造の特徴を維持しつつ、タグ数を減らせる。これによりパーサの妥当性検証負荷を軽減し、通信データとしてＸＭＬ文字列を用いる場合の処理を高速化できる。特にＸＭＬ文書の妥当性検証を行う場合にメリットが大きい。なお、カンマ文字は例示であり、その他のセパレータを用いることができることは勿論である。また、同様のアイデアは、一次元配列、マップ型等にも適用できる。その他同一構造が繰り返しタグ付けされて記述される場合にも適用できる。
【００５９】
上記配列型あるいはマップ型の場合のデータＸＭＬ文書として通信データに適用し、これを実施の形態１のシステムで実現する例を以下に示す。まず、配列型文字データを例示する。
(10.01) String cols[] = new Stirng[3];
(10.02) cols[0] = "Name";
(10.03) cols[1] = "Adrress";
(10.04) cols[2] = "Phone";
(10.05) TableModel table = new TabeleModel(cols);
(10.06) table.addValue("name","fname lname");
(10.07) table.addValue("Adrress","Country City Street");
(10.08) table.addValue("Phone","03-3000-3000");
(10.09) String xml_data = table.toString();
(10.03) CommunicationComponent cc;
(10.04) cc = new CommunicationComponent(property);
(10.05) String return = cc.call(String target, String xml_data);
【００６０】
この場合、生成される通信データxml_data（文字列型）は、
＜Table1＞fname lname,Country City Street,03-3000-3000＜/Table1＞
のようになる。
【００６１】
同様に、マップ型文字データは以下のように処理できる。
(11.01) MapModel map = new MapModel();
(11.02) map.put("name","fname lname");
(11.03) map.put("Adrress","Country City Street");
(11.04) map.put("Phone","03-3000-3000");
(11.05) String xml_data = map.toString();
(11.06) CommunicationComponent cc;
(11.07) cc = new CommunicationComponent(property);
(11.08) String return = cc.call(String target, String xml_data);
【００６２】
この場合、生成される通信データxml_data（文字列型）は、
＜Map1＞Name=fname lname,Adrress=Country City Street,Phone=03-3000-3000
＜/Map＞
のようになる。なお、ここでマップ要素とマップ要素に関連付けられるデータとの関連付けに「=」（イコール）文字を用いているが、その他の関連付け文字を適用できることは勿論である。
【００６３】
このように、本実施の形態では、同一構造が繰り返されるＸＭＬ文書において、その同一構造の特徴を損なわない範囲でこれを簡略化してタグ数の少ないＸＭＬ文字列を生成する。これにより、データ通信の速度を向上できる。特にパーサ等でのＸＭＬの妥当性検証を行う場合に顕著な効果を持つ。また、本実施の形態のようにＸＭＬ文書を簡略化するため、若干の汎用性が損なわれることは否めないが、エンジニアリング分野では、このような繰り返しのデータ構造が多く利用されるため、当該分野でなおかつ高速度の通信速度が要求される場合に本実施の形態のデータ通信方法を適用して効果が大きい。
【００６４】
（実施の形態４）
前記した実施の形態２，３では、何れも通信データとして文字列を用いる例を説明した。本実施の形態では、通信データにバイナリデータが含まれる場合を説明する。
【００６５】
通信データにバイナリデータが含まれる場合には、バイナリデータbyte[]と共に、このバイナリデータに含まれる要素の開始位置および終了位置をＸＭＬ文字列として通信データに含める。即ち、バイナリデータbyte[]の０バイト目から１００バイト目にPhoto1のバイナリデータが入り、１０１バイト目から２００バイト目にImage2のバイナリデータが入る場合、生成するＸＭＬ文字列は、
(12.01) ＜Photo1＞0,100＜/Photo1＞＜Image2＞101,200＜/Image2＞
とすることができる。
【００６６】
この場合のアイデアを実施の形態１で実現する例を示す。
(12.02) BinaryModel binary = new BinaryModel();
(12.03) binary.put("Photo1","byte[]);
(12.04) binary.put("Image2","byte[]);
(12.05) String xml = binary.toString();
(12.06) CommunicationComponent cc;
(12.07) cc = new CommunicationComponent(property);
(12.08) String return = cc.call(String target, xml, binary);
【００６７】
なお、実施の形態１では、文字列、バイナリの両方を通信データparserに入れているので、これと整合させるため、
(12.09) Parser parser;
(12.10) parser.putString(xml);
(12.11) parser.putBinary(binary);
とし、(12.08)を、
(12.12) String return = cc.call(String target, Parser parser);
としても良い。
【００６８】
本実施の形態によれば、バイナリデータのままで通信データを取り扱えるたえめ、たとえばバイナリデータを文字にエンコードし、その後デコードする必要がない。このため、通信速度を向上できる。また、バイナリデータのままで通信しても、同時にＸＭＬ文字列としてバイナデータ内の要素（前記例ではPhoto1、Image2）の開始位置、終了位置が特定されるので、何ら不都合はない。
【００６９】
（実施の形態５）
本実施の形態では、さらにＸＭＬ文書を簡略化してデータ通信速度を向上する方法を説明する。本実施の形態では、簡略化されたＸＭＬ文字列を生成するオリジナルパーサを提供する。以下例示コードを示す。
(13.01) OriginalParser parser = new OriginalParser();
(13.02) parser.put("Table1",table);
(13.03) parser.put("Map1",map);
(13.04) parser.put("Photo1",byte[]);
(13.05) parser.put("Image2",byte[]);
(13.06) CommunicationComponent cc=new CommunicationComponent(property);
(13.07) String return = cc.call(String target, Parser parser);
(13.08) parser.restore(return);
【００７０】
OriginalParserは、putメソッドを呼び出すことにより、第１引数で指定した指標文字のタグで第２引数のデータを囲む操作を行う。そして、第２引数のデータで囲んだタグ付き文字をparserに追加する。つまり、このオリジナルパーサで生成されるＸＭＬ文書の各要素の深さは１であり、要素の子要素は生成されない。なお、(13.02)〜(13.05)のtable,map,byte[]は、実施の形態３および４と同様である。また、(13.08)では、戻り値をパーサに入れ、戻り文書を解析した後に個々のデータを取り出す操作を行っている。
【００７１】
上記例示コードにより生成されるデータの文字列データは以下のようになる。
＜Table1＞fname lname,Country City Street,03-3000-3000＜/Table1＞＜Map1＞Name=fname lname,Adrress=Country City Street,Phone=03-3000-3000＜/Map＞＜Photo1＞0,100＜/Photo1＞＜Image2＞101,200＜/Image2＞
すなわち、通常のＸＭＬ文書とは相違して、配列内に別のデータ構造が存在したり、いくつかの階層に入れ子構造になったりしている構造がない。つまり単純な要素をタグで囲んだ構造が単純に繰り返されるだけである。
【００７２】
本実施の形態のパーサを用いれば、一般的汎用的なＸＭＬ文書を生成することはできないが、通常のビジネスデータを表現するには本実施の形態のパーサで生成されるＸＭＬ文字列で十分である。すなわち、本実施の形態の簡略化されたＸＭＬ文書を生成する独自パーサを利用して実施の形態１等に示したデータ通信方法を実現すれば、ビジネスデータの通信には何ら支障無く、かつ、メンテナンスが容易なＸＭＬ文書を容易に扱うことができる。しかも、本実施の形態のパーサで生成されるＸＭＬ文書は単純な構造なので、ＸＭＬ文書の妥当性解析が必要な場合であっても、パーサへの負荷が小さく、高速なデータ通信を実現することが可能になる。
【００７３】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更することが可能である。
【００７４】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、プログラム作成あるいはメンテナンス環境においてコンポーネント間通信で利用するプロトコルへの整合性を意識することなく、単一の手順でコンポーネント間通信が実現できる。また、データの仕様等が変更されても、最小限のメンテナンス負荷で変更に対応できる通信インタフェイス技術および通信データの構造を提供できる。また、通信データにＸＭＬ文字列が適用される場合に、そのデータ転送のためのオーバーヘッドを低減し、また、通信データの検証が必要な場合には、その検証のための処理負荷を低減することができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるデータ通信システムを模式的に示した概念図である。
【図２】本発明の一実施の形態であるデータ通信システムおよびその機能の一例を示したブロック図である。
【図３】本発明の一実施の形態であるデータ通信方法の一例を示したフローチャートである。
【符号の説明】
１ａ，１ｂ…システム、２ａ，２ｂ…アプリケーションプログラム、３ａ，３ｂ…データ通信用プログラム、４ａ，４ｂ…インタフェイスプログラム、５ａ〜９ａ，５ｂ〜９ｂ…実装プログラム、１０…通信線、１１…通信データ、１２…データ通信用プログラムパッケージ、１３…データ通信用クラス、１４…データ通信用インタフェイス、１５…ＣＯＲＢＡインプリメンテーション・クラス、１６…ＥＪＢインプリメンテーション・クラス、１７…ＭＱインプリメンテーション・クラス、１８…ＨＴＴＰインプリメンテーション・クラス、１９…データ通信用インタフェイス、２０〜２４…通信メソッド、２５…データ通信用インスタンス、２６…データ通信用インタフェイス、２７…インプリメンテーション・インスタンス、２８…通信メソッド。
Claims (3)
- クライアント・サーバ通信システムにおいて、
クライアントコンピュータ上にプログラムパッケージとして、データ通信用インターフェイスを含むデータ通信用クラス、通信メソッドを含むデータ通信用インタフェイス、プロトコル毎に用意された通信メソッドを含むインプリメンテーションクラスを有し、
前記データ通信用クラスは、プロトコルを引数として初期化することにより、該データ通信用クラス内のデータ通信用インタフェイスとして、該プロトコルに対応したインプリメンテーションクラスをキャストして、データ通信用インスタンスを生成する機能を有し、
該生成されたデータ通信用インスタンスは、前記プロトコルに応じたサーバとの通信メソッドをクライアントアプリケーションに提供する機能を有し、
クライアントアプリケーションは、
プロトコルを引数として、前記データ通信用クラスの初期化処理を行い、データ通信用インスタンスを生成する機能と、
通信データおよび通信相手のサーバを引数として、前記データ通信用インスタンスの通信メソッドを呼び出す機能を有することにより、
前記クライアントアプリケーションがプロトコル毎の通信方式を意識せずに単一手順でサーバとの通信を可能にするデータ通信システム。 - クライアント・サーバ通信方法において、
クライアントコンピュータ上にプログラムパッケージとして、データ通信用インターフェイスを含むデータ通信用クラス、通信メソッドを含むデータ通信用インタフェイス、プロトコル毎に用意された通信メソッドを含むインプリメンテーションクラスを有し、
前記データ通信用クラスは、プロトコルを引数として初期化することにより、該データ通信用クラス内のデータ通信用インタフェイスとして、該プロトコルに対応したインプリメンテーションクラスをキャストして、データ通信用インスタンスを生成する機能を有し、
該生成されたデータ通信用インスタンスは、前記プロトコルに応じたサーバとの通信メソッドをクライアントアプリケーションに提供する機能を有し、
クライアントアプリケーションによって、プロトコルを引数として、前記データ通信用クラスの初期化処理を行い、データ通信用インスタンスを生成するステップと、
前記クライアントアプリケーションによって、通信データおよび通信相手のサーバを引数として、該データ通信用インスタンスの通信メソッドを呼び出すステップを有することにより、
前記クライアントアプリケーションがプロトコル毎の通信方式を意識せずに単一手順でサーバとの通信を可能にするデータ通信方法。 - クライアント・サーバ通信プログラムにおいて、
クライアントコンピュータ上にプログラムパッケージとして、データ通信用インターフェイスを含むデータ通信用クラス、通信メソッドを含むデータ通信用インタフェイス、プロトコル毎に用意された通信メソッドを含むインプリメンテーションクラスを有し、
前記データ通信用クラスは、プロトコルを引数として初期化することにより、該データ通信用クラス内のデータ通信用インタフェイスとして、該プロトコルに対応したインプリメンテーションクラスをキャストして、データ通信用インスタンスを生成する機能を有し、
該生成されたデータ通信用インスタンスは、前記プロトコルに応じたサーバとの通信メソッドをクライアントアプリケーションに提供する機能を有し、
前記クライアントコンピュータに、
プロトコルを引数として、前記データ通信用クラスの初期化処理を行い、データ通信用 インスタンスを生成するステップと、
通信データおよび通信相手のサーバを引数として、該データ通信用インスタンスの通信メソッドを呼び出すステップを実行させることにより、
前記クライアントコンピュータをしてプロトコル毎の通信方式を意識せずに単一手順でサーバとの通信を可能にするデータ通信プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001206983A JP4233775B2 (ja) | 2001-07-06 | 2001-07-06 | データ通信方法、データ通信システムおよびプログラム |
| US10/170,336 US7587505B2 (en) | 2001-07-06 | 2002-06-12 | Data communication method, data communication system, and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001206983A JP4233775B2 (ja) | 2001-07-06 | 2001-07-06 | データ通信方法、データ通信システムおよびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003022251A JP2003022251A (ja) | 2003-01-24 |
| JP4233775B2 true JP4233775B2 (ja) | 2009-03-04 |
Family
ID=19043036
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001206983A Expired - Fee Related JP4233775B2 (ja) | 2001-07-06 | 2001-07-06 | データ通信方法、データ通信システムおよびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7587505B2 (ja) |
| JP (1) | JP4233775B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005024614A1 (en) * | 2003-09-09 | 2005-03-17 | Koninklijke Philips Electronics N.V. | Control interface selection |
| US8321506B2 (en) * | 2003-10-23 | 2012-11-27 | Microsoft Corporation | Architecture for an extensible real-time collaboration system |
| US20060101397A1 (en) * | 2004-10-29 | 2006-05-11 | Microsoft Corporation | Pseudo-random test case generator for XML APIs |
| US8495664B2 (en) * | 2005-07-06 | 2013-07-23 | International Business Machines Corporation | System, method and program product for invoking a remote method |
| JP2011142378A (ja) * | 2010-01-05 | 2011-07-21 | Seiko Epson Corp | コンピューターが組み込まれた装置の制御 |
| CN102799472B (zh) * | 2012-06-18 | 2014-07-16 | 西北工业大学 | 水下主动探测系统的实时信息处理及数据传输方法 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2288477A (en) * | 1994-04-05 | 1995-10-18 | Ibm | Communications system for exchanging data between computers in a network. |
| US5822520A (en) * | 1995-12-26 | 1998-10-13 | Sun Microsystems, Inc. | Method and apparatus for building network test packets |
| US6938263B2 (en) | 1996-04-23 | 2005-08-30 | Sun Microsystems, Inc. | System and method for facilitating dynamic loading of “stub” information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space |
| JP2000242587A (ja) | 1999-02-24 | 2000-09-08 | Pfu Ltd | オブジェクト処理装置及びそのプログラム記憶媒体 |
| US6658625B1 (en) * | 1999-04-14 | 2003-12-02 | International Business Machines Corporation | Apparatus and method for generic data conversion |
| JP2000354053A (ja) | 1999-06-11 | 2000-12-19 | Sanyo Electric Co Ltd | ネットワーク用通信モジュール、及び該通信モジュールが接続可能な電気機器 |
| US6356933B2 (en) * | 1999-09-07 | 2002-03-12 | Citrix Systems, Inc. | Methods and apparatus for efficiently transmitting interactive application data between a client and a server using markup language |
| TW586069B (en) * | 2001-03-01 | 2004-05-01 | Ibm | A method and a bridge for coupling a server and a client of different object types |
-
2001
- 2001-07-06 JP JP2001206983A patent/JP4233775B2/ja not_active Expired - Fee Related
-
2002
- 2002-06-12 US US10/170,336 patent/US7587505B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20030126306A1 (en) | 2003-07-03 |
| JP2003022251A (ja) | 2003-01-24 |
| US7587505B2 (en) | 2009-09-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7971210B2 (en) | Interface for processing client-server method calls within a single virtual machine | |
| US7546606B2 (en) | System and method using a connector architecture for application integration | |
| US5737607A (en) | Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats | |
| US6915523B2 (en) | PL/I metamodel | |
| US6910216B2 (en) | IMS transaction messages metamodel | |
| US7644415B2 (en) | Application programming interface to the simple object access protocol | |
| KR101159350B1 (ko) | 웹 서비스와 대화하고 이 웹 서비스를 생성하는 인터페이스 인프라스트럭처 | |
| US5758351A (en) | System and method for the creation and use of surrogate information system objects | |
| US7246358B2 (en) | Methods, system and articles of manufacture for providing an extensible serialization framework for an XML based RPC computing environment | |
| US7007278B2 (en) | Accessing legacy applications from the Internet | |
| US6775680B2 (en) | High level assembler metamodel | |
| US20010047385A1 (en) | Passthru to shared service funtionality | |
| US7490331B2 (en) | Mapping to and from native type formats | |
| US20060149746A1 (en) | Web application communication protocol | |
| US20030204645A1 (en) | Method, system, and articles of manufacture for providing a servlet container based web service endpoint | |
| US20020056012A1 (en) | COBOL metamodel | |
| US20030233477A1 (en) | Extensible infrastructure for manipulating messages communicated over a distributed network | |
| WO2003034183A2 (en) | System and method using a connector architecture for application integration | |
| US6516354B2 (en) | Method and apparatus for efficient representation of variable length identifiers in a distributed object system | |
| JP4233775B2 (ja) | データ通信方法、データ通信システムおよびプログラム | |
| Rock-Evans | DCOM explained | |
| Slamkovic | A generic middleware broker for distributed systems integration | |
| Gao | Aspect-oriented middleware | |
| Gao | Copyright (c) 2006 by Dapeng Gao | |
| Toulemonde et al. | Connecting Domino to the Enterprise Using Java |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050727 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050926 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20051031 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20070306 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20071029 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081105 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081210 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111219 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111219 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121219 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121219 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131219 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |