JP5548433B2 - Web service platform system - Google Patents
Web service platform system Download PDFInfo
- Publication number
- JP5548433B2 JP5548433B2 JP2009271598A JP2009271598A JP5548433B2 JP 5548433 B2 JP5548433 B2 JP 5548433B2 JP 2009271598 A JP2009271598 A JP 2009271598A JP 2009271598 A JP2009271598 A JP 2009271598A JP 5548433 B2 JP5548433 B2 JP 5548433B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- data
- name
- web service
- message
- 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
Landscapes
- Computer And Data Communications (AREA)
Description
本発明は、クライアントにWebサービスを提供するためのWebサービス基盤技術に関する。 The present invention relates to a web service infrastructure technology for providing a web service to a client.
近年、様々な種類のWebサービスが開発され、クライアントに提供されている。また、Webサービスを実現するにあたりWSDLを使用する場合がある。WSDLは、W3C(World Wide Web Consortium)によって指定された標準のXMLドキュメントである。WSDLは、Webサービスを提供するサービス・プロバイダとWebサービスを利用するサービス・リクエスタ(クライアント)の間でインターフェイス情報をやり取りするために使用される。特許文献1には、コントローラ装置のプログラムと対話することができるWebサービスによりWSDLを使用する通信システムが記載されている。
In recent years, various types of Web services have been developed and provided to clients. In some cases, WSDL is used to implement a Web service. WSDL is a standard XML document specified by the World Wide Web Consortium (W3C). WSDL is used to exchange interface information between a service provider that provides a Web service and a service requester (client) that uses the Web service.
ところで、既存の業務システムをWebサービスとしてクライアントに提供する場合、例えばSOAP(Simple Object Access Protocol)などの通信プロトコルに従って交換されるメッセージの記述形式に従ったプログラムの開発が必要となる。メッセージがXML(eXtensible Markup language)で記述されている場合、XMLによるメッセージのデータ形式とWebサービス・プロバイダ側におけるプログラム言語にて処理可能なデータ形式とは異なるため、各Webサービス・プロバイダ側においてデータ形式の相違を吸収する仕組みが必要となる。 By the way, when providing an existing business system as a Web service to a client, it is necessary to develop a program according to a description format of messages exchanged according to a communication protocol such as SOAP (Simple Object Access Protocol). When the message is described in XML (eXtensible Markup language), the data format of the message in XML is different from the data format that can be processed in the programming language on the Web service provider side. A mechanism to absorb the difference in format is required.
そのため、既存の業務システムをWebサービスとしてクライアントに提供する場合、システムの開発規模、開発コスト、作業負荷が大きく、既存の業務システムを容易にWebサービス化できないという問題がある。 Therefore, when an existing business system is provided to a client as a Web service, there is a problem that the system development scale, development cost, and work load are large, and the existing business system cannot be easily converted to a Web service.
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、既存の業務システムを変更することなく、より容易に既存の業務システムをWebサービスとしてクライアントに提供することにある。 The present invention has been made in view of the above circumstances, and an object of the present invention is to more easily provide an existing business system as a Web service to a client without changing the existing business system.
上記課題を解決するために、本発明は、業務システムが行う処理をWebサービスとしてクライアントに提供するWebサービス基盤システムであって、所定の通信プロトコルに従って、クライアントとの間でメッセージの送受信を行う通信処理手段と、Webサービス毎に設けられた、複数のサービスエンドポイントと、全てのWebサービスに共通のWebサービス提供手段と、を有し、前記通信処理手段は、前記クライアントからのサービス要求を、当該サービス要求で指定されたWebサービス用のサービスエンドポイントを介して、前記Webサービス提供手段に送出し、前記Webサービス提供手段は、前記サービス要求を前記業務システムが処理可能なデータ形式に変換して、当該サービス要求で指定されたWebサービスに対応する業務システムに送信するとともに、前記業務システムの処理結果を前記通信処理手段が処理可能なデータ形式に変換して、前記Webサービス用のサービスエンドポイントを介して前記通信処理手段に送出する。 In order to solve the above problems, the present invention is a Web service infrastructure system that provides a client with processing performed by a business system as a Web service, and performs communication for transmitting and receiving messages to and from a client according to a predetermined communication protocol. A processing unit, a plurality of service endpoints provided for each Web service, and a Web service providing unit common to all Web services, wherein the communication processing unit receives a service request from the client, The service request is sent to the Web service providing means via the Web service service endpoint specified in the service request, and the Web service providing means converts the service request into a data format that can be processed by the business system. To the Web service specified in the service request. Transmits to the business system to respond, the converts the processing result of the business system to the communication processing means processes a data format, and sends it to the communication processing unit via a service endpoint for the Web service.
本発明では、既存の業務システムを変更することなく、より容易に既存の業務システムをWebサービスとしてクライアントに提供することができる。 In the present invention, an existing business system can be provided to a client as a Web service more easily without changing the existing business system.
以下、本発明の実施の形態について説明する。 Embodiments of the present invention will be described below.
図1は、本発明の実施形態が適用されたWebシステムの全体構成図である。本実施形態では、既存の業務システムを、スピーディに、かつ容易にWebサービス化するものである。 FIG. 1 is an overall configuration diagram of a Web system to which an embodiment of the present invention is applied. In this embodiment, an existing business system is quickly and easily converted into a Web service.
図示するWebシステムは、ユーザが使用するクライアント1と、Webサービス基盤システム2と、既存の複数の業務システム7、8とを有する。第1の業務システム7は、Java(登録商標)で記述されたアプリケーションプログラム(トランザクション)を実行することにより各種のサービス(業務処理)を実行する。第2の業務システム8は、Java(登録商標)以外のCOBOL、C言語などで記述されたアプリケーションプログラム(トランザクション)を実行することにより各種のサービス(業務処理)を実行する。
The illustrated Web system includes a
クライアント1とWebサービス基盤システム2とはインターネットなどのネットワークにより接続され、Webサービス基盤システム2と業務システム7、8とはLANなどのネットワークにより接続される。
The
本実施形態のWebサービス基盤システム2は、クライアント1から送信される要求を対応する業務システム7、8のトランザクションに接続し、当該トランザクションによる処理結果を要求元のクライアント1に送信する。
The Web
図示するWebサービス基盤システム2は、実行環境として、Webアプリケーション部21と、SOAPエンジン22(通信処理手段)と、複数のサービスエンドポイント23と、汎用のサービスクラス24および接続部28(Webサービス提供手段)と、サービス呼出定義ファイル31と、データ変換定義ファイル34と、電文定義ファイル35とを有する。
The web
また、Webサービス基盤システム2は、開発環境として、クライアント1にインストールされるWSDL11と、Webサービス基盤システム2の実行環境で使用するサービスエンドポイント23、サービス呼出定義ファイル31、JavaBeans32を生成する生成部29を有する。
Further, the Web
上記説明した、クライアント1、Webサービス基盤システム2、および業務システム7、8は、いずれも、例えば図2に示すようなCPU901と、メモリ902と、HDD等の外部記憶装置903と、キーボードやマウスなどの入力装置904と、ディスプレイやプリンタなどの出力装置905と、ネットワークと接続するための通信制御装置906と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPU901がメモリ902上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。
The
例えば、Webサービス基盤システム2および業務システム7、8の各機能は、Webサービス基盤システム2用のプログラムの場合はWebサービス基盤システム2のCPU901が、そして、業務システム7、8用のプログラムの場合は業務システム7、8のCPU901が、それぞれ実行することにより実現される。
For example, the functions of the Web
なお、入力装置904および出力装置905については、各装置が必要に応じて備えるものとする。また、Webサービス基盤システム2は、複数のサーバで構成されるものであってもよい。例えば、実行環境用のサーバと、開発環境用のサーバとで構成することとしてもよい。
In addition, about the
[実行環境]
以下にWebサービス基盤システム2の実行環境について説明する。
[Execution environment]
The execution environment of the Web
Webアプリケーション部21は、クライアント1から送信されたリクエスト電文(サービス要求)を受け付け、SOAPエンジン22に送出する。
The
SOAPエンジン22は、クライアント1との間でリクエスト電文およびレスポンス電文などのメッセージ交換を行う。SOAP(Simple Object Access Protocol)は、XML、HTTPなどをベースとした、他のコンピュータにあるデータやサービスを呼び出すためのプロトコルである。SOAPによる通信では、XML文書にエンベロープと呼ばれる付帯情報が付いた電文・メッセージを、HTTPなどのプロトコルで交換する。Webサービス(以下、「サービス」という)を利用するクライアントと、サービスを提供する側のシステムの双方がSOAPの生成・解釈エンジンを持つことで、異なる環境間でのオブジェクト呼び出しを可能にしている。
The SOAP
サービスエンドポイント23は、サービスを利用するクライアント1に公開するサービスの受け口(インターフェース、ポート)である。本実施形態では、サービス毎にサービスエンドポイント23を備える。
The
サービスクラス24は、サービスエンドポイント23から呼び出されるWeb処理を行うミドルウェアである。本実施形態のサービスクラス24は、全てのサービスで共通に使用される汎用的なものである。サービスクラスについては、後述する。
The
次に、本実施形態の実行環境における処理について説明する。 Next, processing in the execution environment of this embodiment will be described.
なお、本実施形態では、後述する開発環境の生成部29によりあらかじめ生成された、クライアント1のWSDL11と、Webサービス基盤システム2のサービスエンドポイント23、サービス呼出定義ファイル31、JavaBeans32を用いる。
In this embodiment, the
まず、クライアント1は、ユーザの指示などを受け付けて、SOAPによるリクエスト電文をWebサービス基盤システム2に送信する。すなわち、クライアント1のアプリケーション13は、WSDL11から生成されるスタブ12を用いて、リクエスト電文を生成し、Webサービス基盤システム2に送信する。リクエスト電文には、ミドルヘッダと、アプリケーションデータと、当該リクエスト電文の送信先であるURL(Uniform Resource Locator)とが含まれる。ミドルヘッダは、クライアントと、Webサービス基盤システム2との間でやり取りする制御情報を保持するための領域である。なお、WSDL11については、後述する。
First, the
図3は、クライアント1から送信されるリクエスト電文の一例を示すものである。図示すリクエスト電文は、HTTPヘッダとSOAP電文とを有する。HTTPヘッダには、所望のサービスを識別するためのURL301が含まれ、当該URL301の最後にはサービス名(図示する例では「PT01」)が設定されている。SOAP電文には、ミドルヘッダ302と、アプリケーションデータ303が設定されている。
FIG. 3 shows an example of a request message transmitted from the
Webサービス基盤システム2のSOAPエンジン22は、Webアプリケーション部21を介してリクエスト電文を受け付け、当該リクエスト電文のURL301に設定されたサービス名に対応するサービス呼出定義ファイル31を読み出す。サービス呼出定義ファイル31は、サービス毎に生成されるものとする。また、サービス呼出定義ファイル31は、あらかじめ開発環境の生成部29により生成され、Webサービス基盤システム2の図示しない記憶部に記憶されている。
The
図4は、サービス呼出定義ファイル31の一例を示すものである。図示するサービス呼出定義ファイル31には、サービス名として「PT01」401が記述され、呼出メソッド名としてサービスクラス24(Webサービスプロバイダ部25)を意味する「TRDOperation」402が記述されている。本実施形態では、全てのサービス呼出定義ファイル31において、同一の呼出メソッド名(「TRDOperation」)が設定される。これにより、各サービスエンドポイント23は、全てのサービスエンドポイントに共通の汎用サービスクラス24を呼び出す。
FIG. 4 shows an example of the service
また、サービス呼出定義ファイル31には、業務システムへ送信される上り電文で使用するJavaBeans(データ保持部品)の識別情報403(ミドルヘッダ用:「aifabean」、アプリケーションデータ用:「lay029bean」)と、クライアントへ送信される下り電文で使用するJavaBeansの識別情報404(アプリケーションデータ用:「pt01retaurnbean」)とが記述され、さらに、電文の型定義405が記述されている。
The service
SOAPエンジン22は、対応するサービス呼出定義ファイル31に基づいてリクエスト電文のSOAP電文をデシリアライズし、リクエスト電文で指定されたサービス名に対応するサービスエンドポイント23にJavaBeansを受け渡す。すなわち、SOAPエンジン22は、XMLで記述されたSOAP電文のデータをJava(登録商標)言語に変換し、サービス呼出定義ファイル31で指定された上り電文用のJavaBeansに格納して、サービスエンドポイント23に送出する。
The
なお、図4に示すサービス呼出定義ファイル31の場合、SOAPエンジン22は、SOAP電文のミドルヘッダについては「aifabean」のJavaBeansに、SOAP電文のアプリケーションデータについては「lay029bean」のJavaBeansに、データを格納する。
In the case of the service
また、各サービスで使用するミドルヘッダ、上り電文および下り電文のJavaBeans(データが入っていない空の状態のデータ保持部品)は、あらかじめ開発環境の生成部29により生成され、Webサービス基盤システム2に設けられている。
In addition, the middle header, the upstream message, and the JavaBeans of the downstream message (empty data holding component that does not contain data) used in each service are generated in advance by the
JavaBeansを受け付けたサービスエンドポイント23は、自サービスエンドポイントのサービスに対応するサービス呼出定義ファイル31を参照し、当該サービス呼出定義ファイル31に設定された情報に基づいて、汎用のサービスクラス24を呼び出す。具体的には、呼び出しメソッド名402(図4参照)に設定されたサービスクラス24を呼び出す。その際に、サービスエンドポイント23は、受け付けたJavaBeansおよびサービス呼出定義ファイルに設定された各種情報(サービス名、JavaBeansのIDなど)を引数として、サービスクラス24に受け渡す。
The
サービスクラス24のデータ変換部26は、Webサービスプロバイダ部25を介して、JavaBeans32などの引数を受け取る。そして、データ変換部26は、受け取ったJavaBeans32に保持されたデータのデータチェックを行い、当該データをデータ記憶部36に格納する。本実施形態のデータ記憶部36は、データストアビーン(DSB)と、リクエストデータホルダー(RDH)と、セッションデータホルダー(SDH)とを有する。
The
データ変換部26は、上り電文(アプリケーションデータ)のJavaBeansに保持されたデータについてはDSBに格納し、ミドルヘッダのJavaBeansに保持されたデータについてはRDHおよびSDHに格納する。なお、データ記憶部36は、業務システム7、8の全てのサービスからアクセスが可能なデータ領域である。
The
そして、データ変換部26は、JavaBeans32から生成され、データ記憶部36に格納されたDSB、RDH、SDHのデータ、およびサービス名を引数として、トランザクション呼出部27を呼び出す。トランザクション呼出部27は、トランザクション呼出定義ファイル33を参照し、引数として設定されたサービス名に対応する業務システム7、8のトランザクションIDおよび呼出先を特定する。トランザクション呼出定義ファイル33は、業務システム7、8への呼び出しを定義するファイルであって、図示しない記憶部にあらかじめ記憶されている。
Then, the
図5(a)は、トランザクション呼出定義ファイル33の一例を示すものである。図示するトランザクション呼出定義ファイル33には、サービス名501と、当該サービス名501に対応する業務システムのトランザクションID502および呼出先503とが対応付けて記憶されている。呼出先503には、呼び出す業務システムを識別するための識別情報(システムID等)が設定される。なお、図示するトランザクション呼出定義ファイル33には、一組のサービス名とトランザクションID・呼出先しか記述されていないが、実際には複数の組のサービス名とトランザクションID・呼出先とが対応付けて記述されている。
FIG. 5A shows an example of the transaction
起動するトランザクションが第1の業務システム7のJava(登録商標)ロジックの場合、呼出先503として第1の業務システム7のシステムIDが設定される。一方、起動するトランザクションが第2の業務システム8のCOBOL、C言語などで記述されたアプリケーションプログラムの場合、呼出先503として接続部28が設定される。
When the transaction to be started is the Java (registered trademark) logic of the
トランザクション呼出部27は、特定したトランザクションIDおよびDSB、RDH、SDHのデータを引数として、特定した呼出先を呼び出す。
The
第1の業務システム7が呼び出された場合、第1の業務システム7は引数として指定されたトランザクションを起動し、引数として受け渡されたデータを用いて所定の業務処理を行い、処理結果をトランザクション呼出部27を介してデータ変換部26に送信する。なお、データ変換部26に送信される処理結果は、Java(登録商標)のデータ形式のデータである。
When the
一方、接続部28が呼び出された場合、接続部28は、引数として指定されたトランザクションIDに対応するデータ変換ファイル34を参照し、当該データ変換ファイル34で指定された電文定義ファイルIDを特定する。そして、接続部28は、特定した電文定義ファイルIDの電文定義ファイルを読み出す。データ変換ファイル34は、業務システムの入出力を定義するファイルであり、電文定義ファイル35は、各入出力毎のデータレイアウトを定義するファイルであって、これらのファイル34、35は図示しない記憶部にあらかじめ記憶されている。
On the other hand, when the
図5(b)は、データ変換ファイル34の一例を示すものである。図示するデータ変換ファイル34には、第2の業務システム8のトランザクションID511と、当該トランザクションID511に対応する上り電文用の電文定義ファイルID512および下り電文用の電文定義ファイルID513とが対応付けて記憶されている。
FIG. 5B shows an example of the
図5(c)は、電文定義ファイル35の一例を示すものである。図示する電文定義ファイル35には、電文定義ファイルID521と、当該電文定義ファイルID521に対応する電文のデータレイアウト定義522(データ名、データタイプ、桁数、データの並び順、等)とが対応付けて記憶されている。
FIG. 5C shows an example of the
接続部28は、データ変換ファイル34を参照して特定した上り電文用の電文定義ファイルID512の電文定義ファイル35を読み出し、当該電文定義ファイル35のデータレイアウト定義522を用いて、引数として受け渡されたDSBのデータを、第2の業務システム8のトランザクション(アプリケーションプログラム)で使用可能なデータ形式に変換する。そして、接続部28は、変換したデータおよびトランザクション呼出定義ファイル33から特定したトランザクションIDを引数として第2の業務システム8を呼び出す。
The
第2の業務システム8は、引数として指定されたトランザクションを起動し、引数として受け渡されたデータを用いて所定の業務処理を行い、処理結果を接続部28に送信する。
The
接続部28は、データ変換ファイル34で指定された下り電文用の電文定義ファイルID513に対応する電文定義ファイル35を読み出し、当該電文定義ファイル35のデータレイアウト定義を用いて、第2の業務システム8から送信された処理結果のデータをDSBのデータ形式(Java(登録商標)データ)に変換する。そして、接続部28は、変換したDSBのデータ形式のデータを、トランザクション呼出部27を介してデータ変換部26に送信する。
The
データ変換部26は、業務システム7、8からDSBのデータ形式で受け付けた処理結果(下り電文を)を、データ記憶部36のDSBに記憶するととともに、サービス呼出定義ファイル31(図4参照)で記述された下り電文用のJavaBeansに格納する。なお、サービスエンドポイント23は、サービスクラス24を呼び出す際に、引数として下り電文用のJavaBeansのIDをサービスクラス24(データ変換部26)に通知しておく。
The
そして、データ変換部26は、Webサービスプロバイダ部25および対応するサービスエンドポイント23を介して、下り電文用のJavaBeansをSOAPエンジン22に送出する。また、データ変換部26は、下り電文用のJavaBeansとともに、リターンコードを設定したミドルヘッダ用のJavaBeansを、SOAPエンジン22に送出することとしてもよい。
Then, the
SOAPエンジン22は、受け付けたJavaBeansに格納されたデータを、サービス呼出定義ファイル31に基づいてシリアライズしてレスポンス電文を生成し、クライアント1に送信する。すなわち、SOAPエンジン22は、JavaBeansに格納されたJava(登録商標)データを、XMLで記述されたSOAP電文に変換する。
The
図6は、レスポンス電文の一例を示すものである。図示すレスポンス電文は、HTTPヘッダとSOAP電文とを有し、SOAP電文には、リターンコードが設定されたミドルヘッダ401と、アプリケーションデータ(処理結果)402が記述されている。 FIG. 6 shows an example of a response message. The response message shown has an HTTP header and a SOAP message. The SOAP message describes a middle header 401 in which a return code is set and application data (processing result) 402.
[開発環境の処理]
次に、本実施形態における開発環境について説明する。
[Development environment processing]
Next, the development environment in this embodiment will be described.
Webサービス基盤システム2の生成部29は、クライアント1で使用するWSDL11と、Webサービス基盤システム2の実行環境で使用するサービスエンドポイント23、JavaBeans32、およびサービス呼出定義ファイル31とを生成する(図1参照)。
The
<WSDLの生成>
まず、WSDLの生成処理について説明する。
<Generation of WSDL>
First, the WSDL generation process will be described.
WSDL(Web Service Description Language:ウェブサービス記述言語)は、Webサービスを記述するための、XMLをベースとした言語仕様である。WSDLには、それぞれのWebサービスがどのような機能を持つのか、それを利用するためにはどのような要求をすればいいのか、などの定義が記述され、Webサービスを提供するサービスプロバイダとWebサービスを利用するサービスリクエスタ(クライアント)の間でインターフェイス情報をやり取りするために使用される。WSDLには、クライアントがWebサービスのメソッドを呼び出すのに必要な情報が含まれる。 WSDL (Web Service Description Language) is a language specification based on XML for describing Web services. WSDL describes the definition of what functions each Web service has and what requests it should make in order to use it. The service provider that provides the Web service and the Web Used to exchange interface information between service requesters (clients) that use the service. WSDL includes information necessary for a client to call a method of a Web service.
図7に示すように、本実施形態の生成部29は、実行環境で使用するトランザクション呼出定義ファイル33、データ変換定義ファイル34および電文定義ファイル35に基づいて、クライアント1で使用するWSDL11を生成する。なお、WSDL11の生成の際に、生成部29は、後述するWSDLネーミングルール701を用いる。
As illustrated in FIG. 7, the
図8は、WSDL11の構造を模式的に示す図である。
FIG. 8 is a diagram schematically showing the structure of the
WSDL11は、タイプ要素71、メッセージ要素72、ポートタイプ要素73、バインディング要素75及びサービス要素76とを有する。ポートタイプ要素73は、少なくとも1つのオペレーション要素74を有し、サービス要素76は、少なくとも1つのポート要素77を有する。また、WSDL11は、最上位の要素としてDefinitions要素70を、有する。
The
タイプ要素71では、ミドルヘッダ、上り電文、下り電文、下り電文構造体などの下位のデータ型を定義する。ネストした型も定義することができる。メッセージ要素3では、送信データフォーマットを定義する。要求として受信するメッセージは、どのような名前の要素で、それにはどのタイプ要素71で定義されたデータ型が含まれるのかなどを定義する。
The
ポートタイプ要素4では、メッセージ要素3で定義された送信データフォーマットをいくつか組み合わせて、1つの操作単位を論理的に定義する。具体的には、リクエスト電文(メッセージ)とそれに対応するレスポンス電文(メッセージ)とを定義する。
The
バインディング要素75では、前記タイプ定義71、メッセージ定義72、ポートタイプ定義73などで定義されたインターフェイスの論理的なモデル(こういうデータ型を組み合わせて、こういうメッセージで、こういうやりとりをするという定義)と、物理的なモデル(例えば、SOAP-RPCを、HTTP上で行うという定義)とを結びつける定義をする。SOAP-RPCは、RPC(Remote Procedure Call)すなわち遠隔手続き呼び出しをSOAPすなわちXMLを使用した通信規約を使用して行うための仕様である。
In the
サービス要素76では、具体的なアクセスポイントを定義する。ポート要素77では、どのバインディング要素75のインターフェイスを、どのURLで提供するかを定義する。
The
本実施形態では、実行環境で使用するトランザクション呼出定義ファイル33、データ変換定義ファイル34および電文定義ファイル35に基づいてタイプ定義71を作成し、タイプ定義71に基づいてメッセージ定義72を作成し、メッセージ定義72に基づいてポートタイプ定義73を作成し、ポートタイプ定義73に基づいてバインディング定義75を作成し、バインディング定義75に基づいてサービス定義76を作成する。
In this embodiment, the
図9は、WSDL11を生成する処理の流れを示すフローチャートである。図10は、トランザクション呼出定義ファイル33、データ変換定義ファイル34および電文定義ファイル35と、WSDL11との関連を模式的に示す関連図である。
FIG. 9 is a flowchart showing a flow of processing for generating
まず、生成部29は、トランザクション呼出定義ファイル33、データ変換定義ファイル34および電文定義ファイル35を入力し、図示しない記憶部に記憶する(S11)。
First, the
図10に示すトランザクション呼出定義ファイル33の例では、「PT01」のサービス名に対して、「BE801」というトランザクションIDが関連付けられている。なお、図示するトランザクション呼出定義ファイル33には、一組のサービス名とトランザクションIDしか記述されていないが、実際には複数の組のサービス名とトランザクションIDとが対応付けて記述されているものとする。
In the example of the transaction
また、図10に示すデータ変換定義ファイル34の例では、「BE801」というトランザクションIDの上り電文に対して、「Lay029」(電文レイアウトID)の電文定義ファイルが関連付けられ、当該トランザクションIDの下り電文に対して、「Layout2」(電文レイアウトID)の電文定義ファイルが関連付けられている。また、図10に示す「Lay029」の電文定義ファイル35の例では、「memno」の項目名(カラム)のデータ型は文字列型であり、「passwd」のデータ項目名(カラム)のデータ型は文字列型であることが記述されている。
In the example of the data
そして、生成部29は、WSDL生成情報の入力を受け付ける(S12)。WSDL生成情報には、サービス名、WSDLファイル出力先ディレクトリ名、エンドポイントURLなどが含まれる。生成部29は、WSDL生成情報として入力されたサービス名に対応するWSDL11を、以降の処理により生成する。
And the production |
そして、生成部29は、S11で入力され、記憶部に記憶されたトランザクション呼出定義ファイル33を読み出し、S12で入力されたサービス名に対応するトランザクションIDを取得する(S13)。図9に示す例では、「PT01」のサービス名が入力された場合、「BE801」のトランザクションIDが取得される。
Then, the
そして、生成部29は、記憶部に記憶されたデータ変換定義ファイル34を読み出し、S13で取得したトランザクションIDに対応する電文レイアウトIDを取得し、取得した電文レイアウトIDの電文定義ファイルを記憶部から読み出す(S14)。図9に示す例では、「BE801」のトランザクションIDが取得された場合、上り電文については「Lay029」の電文レイアウトIDを、下り電文については「Layout2」の電文レイアウトIDを取得する。
Then, the
そして、生成部29は、S12で入力されたサービス名およびWSDLネーミングルール701に基づいて、WSDLのDefinitions定義を生成する(S15)。
Then, the generating
WSDLネーミングルール701は、図示しない記憶部にあらかじめ記憶され、サービスID名、出力WSDLファイル名、XML名前空間設定、XML宣言、タイプ定義、メッセージ定義、ポートタイプ定義、バインディング定義、サービス定義の各々に関するネーミングルールを有する。
The
図11から図15は、記憶部に記憶されたWSDLネーミングルール701の一例を示すものである。図11は、サービス名、出力WSDLファイル名、XML名前空間設定、XML宣言に関するネーミングルールの一例を示す。
11 to 15 show an example of the
サービス名は、Webサービスのサービス名であり、Webサービス(アプリケーション)ごとに異なる。このサービス名は、WSDL生成情報としてS12で入力される。出力WSDLファイル名は、生成されたWSDLの出力ファイル名であり、サービス名と拡張子”.wsdl”から構成される。 The service name is a service name of the Web service and is different for each Web service (application). This service name is input in S12 as WSDL generation information. The output WSDL file name is an output file name of the generated WSDL, and includes a service name and an extension “.wsdl”.
XML名前空間設定のネーミングルールは、impl、wsdl、wsdlsoap、xsd、tns1、tns2及びsoapencから構成される。implは、サービスが属する名前空間であり、「サービス名」が設定されされる。wsdlは、WSDLフレームワークのためのWSDL名前空間を示す固定値(例えばhttp://schemas.xmlsoap.org/WSDL/)が設定される。Wsdlsoapは、WSDL SOAPバインディングのためのWSDL名前空間を示す固定値(例えばhttp://schemas.xmlsoap.org/WSDL/soap/)が設定される。xsdは、XSDで定義のスキーマ名前空間を示す固定値(例えばhttp://www.w3.org/2001/XMLScheme/が設定される。tns1は、ミドルヘッダの電文が属する名前空間を示す固定値(例えばhttp://PPPI.header.WSDL.info.nri.co.jp)が設定される。tns2は、上り電文及び下り電文が属する名前空間であり、例えばhttp://[サービス名].apl.wsd.info.nri.co.jpが設定される。soapencは、SOAP1.1で定義されているエンコーディング名前空間を示す固定値(例えばhttp://schemas.xmlsoap.org/soap/encoding/)が設定される。 The naming rule for setting the XML namespace is composed of impl, wsdl, wsdlsoap, xsd, tns1, tns2, and soapap. impl is a name space to which the service belongs, and “service name” is set therein. In wsdl, a fixed value (for example, http://schemas.xmlsoap.org/WSDL/) indicating a WSDL namespace for the WSDL framework is set. In Wsdlsoap, a fixed value (for example, http://schemas.xmlsoap.org/WSDL/soap/) indicating a WSDL namespace for the WSDL SOAP binding is set. xsd is a fixed value indicating the schema namespace defined in XSD (for example, http://www.w3.org/2001/XMLScheme/ is set. tns1 is a fixed value indicating the namespace to which the middle header message belongs. (For example, http://PPPI.header.WSDL.info.nri.co.jp) is set, and tns2 is a name space to which the upstream message and the downstream message belong, for example, http: // [service name]. apl.wsd.info.nri.co.jp is set, soapenc is a fixed value indicating the encoding namespace defined in SOAP1.1 (eg http://schemas.xmlsoap.org/soap/encoding/ ) Is set.
xml宣言のネーミングルールは、xml versionとencodingとを有する。xml versionは、XMLのバージョンを示す固定値であって、例えば1.0となる。encodingは、エンコーディングを示す固定値であって、例えばUTF-8となる。 The naming rule of xml declaration has xml version and encoding. The xml version is a fixed value indicating the XML version, and is 1.0, for example. encoding is a fixed value indicating the encoding, and is, for example, UTF-8.
S12で入力されたサービス名が「PT01」であって、図11に示すWSDLネーミングルールを用いた場合に、生成部29が生成するWSDLのdifinitions要素の一例を以下に示す。
An example of a WSDL definition element generated by the
<?xml version="1.0" encoding="UTF-8"?>
<WSDL:definitions targetNamespace="PT01" xmlns:impl=" PT01"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="http://PPPI.header.wsd.info.nri.co.jp"
xmlns:tns2="http:// PT01.apl.wsd.info.nri.co.jp"
xmlns:WSDL="http://schemas.xmlsoap.org/WSDL/"
xmlns:WSDLsoap="http://schemas.xmlsoap.org/WSDL/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
そして、生成部29は、S14で読み出した電文定義ファイル35及びWSDLネーミングルールに基づいてタイプ定義を作成する(S16)。
<? xml version = "1.0" encoding = "UTF-8"?>
<WSDL: definitions targetNamespace = "PT01" xmlns: impl = "PT01"
xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns: tns1 = "http://PPPI.header.wsd.info.nri.co.jp"
xmlns: tns2 = "http: // PT01.apl.wsd.info.nri.co.jp"
xmlns: WSDL = "http://schemas.xmlsoap.org/WSDL/"
xmlns: WSDLsoap = "http://schemas.xmlsoap.org/WSDL/soap/"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema">
And the production |
図12および図13は、記憶部に記憶されたタイプ定義に関するWSDLネーミングルールの一例を示すものである。図示するように、タイプ定義は、ミドルヘッダ、上り電文、下り電文、下り電文構造体(ミドルヘッダ+下り電文)に関する定義から構成される。 12 and 13 show an example of the WSDL naming rule regarding the type definition stored in the storage unit. As shown in the figure, the type definition is composed of definitions relating to a middle header, an uplink message, a downlink message, and a downlink message structure (middle header + downlink message).
図11に示すように、ミドルヘッダ(O3Wヘッダ)は、タイプ定義名(complexType name)、targetNamespace、名前空間接頭辞、type項目名(element name)、type属性(type)から構成される。タイプ定義名は、ミドルヘッダのデータ名を示す固定値(例えば、O3WheadBean)が設定される。名前空間接頭辞は、ミドルヘッダの電文が属する名前空間の接頭辞を示す固定値(例えば、tns1)が設定される。targetNamespaceは、ミドルヘッダの電文が属する名前空間であり、tns1で指定した名前が設定される。type項目名は、ミドルヘッダとして設定する項目であり、電文定義ファイル35で設定された項目名が設定される。type属性は、ミドルヘッダのデータ型を示す固定値(例えば、xsd:string)が設定される。
As shown in FIG. 11, the middle header (O3W header) includes a type definition name (complexType name), a targetNamespace, a namespace prefix, a type item name (element name), and a type attribute (type). As the type definition name, a fixed value (for example, O3WheadBean) indicating the data name of the middle header is set. As the namespace prefix, a fixed value (for example, tns1) indicating the prefix of the namespace to which the middle header message belongs is set. targetNamespace is the name space to which the middle header message belongs, and is set to the name specified by tns1. The type item name is an item set as a middle header, and the item name set in the
以下に、生成部29が生成するミドルヘッダのタイプ定義に対応するWSDLの一例を示す。
An example of WSDL corresponding to the type definition of the middle header generated by the
<WSDL:types>
<schema targetNamespace="http://PPPI.header.wsd.info.nri.co.jp" xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="O3WheadBean">
<sequence>
<element name="APL_KYOSEI" type="xsd:string"/>
<element name="APLSYOGAI" type="xsd:string"/>
</sequence>
</complexType>
<element name="O3WheadBean" type="tns1:O3WheadBean"/>
</schema>
次に、タイプ定義の上り電文について説明する。図12に示すように、上り電文のネーミングルールは、type定義名(complexType name)、targetNamespace、名前空間接頭辞、type項目名(element name)、type属性(type)とを有する。type定義名は、上り電文のデータ名であり、[電文レイアウトID]+Beanが設定される。名前空間接頭辞には、上り電文が属する名前空間の接頭辞を示す固定値(例えばtns2)が設定される。targetNamespaceは、上り電文が属する名前空間であり、tns2で指定した名前空間が設定される。type項目名およびtype属性は、電文定義ファイル35で設定された項目名およびデータ型が設定される。
<WSDL: types>
<schema targetNamespace = "http://PPPI.header.wsd.info.nri.co.jp" xmlns = "http://www.w3.org/2001/XMLSchema">
<complexType name = "O3WheadBean">
<sequence>
<element name = "APL_KYOSEI" type = "xsd: string"/>
<element name = "APLSYOGAI" type = "xsd: string"/>
</ sequence>
</ complexType>
<element name = "O3WheadBean" type = "tns1: O3WheadBean"/>
</ schema>
Next, the type-defined uplink message will be described. As shown in FIG. 12, the naming rule of the uplink message has a type definition name (complexType name), a targetNamespace, a namespace prefix, a type item name (element name), and a type attribute (type). The type definition name is the data name of the upstream message, and [message layout ID] + Bean is set. In the namespace prefix, a fixed value (for example, tns2) indicating the prefix of the namespace to which the upstream message belongs is set. targetNamespace is the name space to which the upstream message belongs, and the name space specified by tns2 is set. The item name and data type set in the
以下に、生成部29が生成する上り電文のタイプ定義に対応するWSDLの一例を示す。
Below, an example of WSDL corresponding to the type definition of the uplink message generated by the
<schema targetNamespace="http://PT01.apl.wsd.info.nri.co.jp" xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="Lay029Bean">
<sequence>
<element name="memmo" type="xsd:string"/>
<element name="passwd" type="xsd: string"/>
</sequence>
</complexType>
<element name=" Lay029Bean" type="tns2: Lay029Bean"/>
次に、タイプ定義の下り電文について説明する。図13に示すように、下り電文のネーミングルールは type定義名(complexType name)、targetNamespace、名前空間接頭辞、type項目名(element name)、type属性(type)から構成される。type定義名は、下り電文のデータ名であり、[電文レイアウトID]+Beanが設定され、名前空間接頭辞は、下り電文が属する名前空間の接頭辞を示す固定値(例えばtns2)が設定され、targetNamespaceは、下り電文が属する名前空間であり、tns2で指定した名前空間であって、上り電文と共有となる。
<schema targetNamespace = "http://PT01.apl.wsd.info.nri.co.jp" xmlns = "http://www.w3.org/2001/XMLSchema">
<complexType name = "Lay029Bean">
<sequence>
<element name = "memmo" type = "xsd: string"/>
<element name = "passwd" type = "xsd: string"/>
</ sequence>
</ complexType>
<element name = "Lay029Bean" type = "tns2: Lay029Bean"/>
Next, a type-defined downlink message will be described. As shown in FIG. 13, the naming rule of the downlink message is composed of a type definition name (complexType name), a targetNamespace, a namespace prefix, a type item name (element name), and a type attribute (type). The type definition name is the data name of the downlink message, [Message layout ID] + Bean is set, and the namespace prefix is set to a fixed value (for example, tns2) indicating the prefix of the namespace to which the downlink message belongs , TargetNamespace is the name space to which the downlink message belongs, is the name space specified by tns2, and is shared with the uplink message.
type項目名およびtype属性は、電文定義ファイルで設定された項目名およびデータ型が設定される。
以下に、生成部29が生成する下り電文のタイプ定義に対応するWSDLの一例を示す。
In the type item name and type attribute, the item name and data type set in the message definition file are set.
An example of WSDL corresponding to the type definition of the downlink message generated by the
<complexType name="Layout2Bean">
<sequence>
<element name="swkl000ap00" type="xsd:string"/>
<element name="swkl1100d00" type=" xsd:string"/>
</sequence>
</complexType>
</schema>
</WSDL:types>
次に、タイプ定義の下り電文構造体について説明する。下り電文構造体は、ミドルヘッダと下り電文とから構成されるものである。図13に示すように、下り電文のネーミングルールは、type定義名(complexType name)、targetNameplace、名前空間接頭辞、type項目名(element name)、type属性(type)から構成される。type定義名は、下り電文構造体のデータ名であり、[サービス名]+ReturnBeanが設定される。名前空間接頭辞は、下り電文構造体が属する名前空間の接頭辞を示す固定値(例えばtns2)が設定される。
<complexType name = "Layout2Bean">
<sequence>
<element name = "swkl000ap00" type = "xsd: string"/>
<element name = "swkl1100d00" type = "xsd: string"/>
</ sequence>
</ complexType>
</ schema>
</ WSDL: types>
Next, the type-defined downlink message structure will be described. The downlink message structure is composed of a middle header and a downlink message. As shown in FIG. 13, the naming rule of the downlink message is composed of a type definition name (complexType name), a targetNameplace, a namespace prefix, a type item name (element name), and a type attribute (type). The type definition name is the data name of the downlink message structure, and [service name] + ReturnBean is set. As the namespace prefix, a fixed value (for example, tns2) indicating the prefix of the namespace to which the downlink message structure belongs is set.
targetNamespaceは、下り電文構造体が属する名前空間であり、tns2で指定した名前空間であって、上り電文と共有する。type項目名は、下り電文構造体として設定する項目であり、ミドルヘッダと下り電文のtype定義名を小文字にしたも(例えばo3wheadbeanなど)が設定される。type属性は、下り電文構造体のデータ型であり、例えば、ミドルヘッダに関してはtns1:O3WheadBean、下り単純電文に関してはtns2:[下り電文のtype定義名]が設定される。 targetNamespace is the name space to which the downlink message structure belongs, is the name space specified by tns2, and is shared with the uplink message. The type item name is an item set as a downlink message structure, and the middle header and the type definition name of the downlink message in lower case (for example, o3wheadbean) are set. The type attribute is the data type of the downlink message structure. For example, tns1: O3WheadBean is set for the middle header, and tns2: [type definition name of the downlink message] is set for the downlink simple message.
以下に、生成部29が生成する下り電文構造体のタイプ定義に対応するWSDLの一例を示す。
Below, an example of WSDL corresponding to the type definition of the downlink message structure generated by the
<complexType name="PT01ReturnBean">
<sequence>
<element name="o3wheadbean" type="tns1:O3WheadBean"/>
<element name="layout2bean" type="tns2: Layout2Bean"/>
</sequence>
</complexType>
<element name=" PT01ReturnBean" type="tns2: PT01ReturnBean"/>
そして、生成部29は、S16で生成したタイプ定義およびWSDLネーミングルールに基づいて、WSDLのメッセージ定義を生成する(S17)。
<complexType name = "PT01ReturnBean">
<sequence>
<element name = "o3wheadbean" type = "tns1: O3WheadBean"/>
<element name = "layout2bean" type = "tns2: Layout2Bean"/>
</ sequence>
</ complexType>
<element name = "PT01ReturnBean" type = "tns2: PT01ReturnBean"/>
Then, the
図14は、記憶部に記憶されたメッセージ定義およびポートタイプ定義に関するWSDLネーミングルールの一例を示すものである。図14に示すように、メッセージ定義は、リクエスト(Request)定義とレスポンス(Response)定義とから構成される。リクエスト定義およびレスポンス定義は、メッセージ名(message name)、パート名(part name)、パートタイプ(type)から構成される。 FIG. 14 shows an example of a WSDL naming rule related to the message definition and the port type definition stored in the storage unit. As shown in FIG. 14, the message definition includes a request definition and a response definition. The request definition and the response definition are composed of a message name (message name), a part name (part name), and a part type (type).
リクエスト定義については、メッセージ名は、上り電文のメッセージ名であり、[サービス名]+Requestを設定する。パート名およびパートタイプは、ミドルヘッダと上り電文でそれぞれ生成される。ミドルヘッダについては、パート名には、ミドルヘッダのtype定義名を小文字にしたものが設定され、パートタイプには、ミドルヘッダの[type定義で設定したtargetNamespaceの名前空間接頭辞]+":"+[type定義名]が設定される。上り電文については、パート名には、上り電文のtype定義名を小文字にしたものが設定され、パートタイプには、上り電文の[type定義で設定したtargetNamespaceの名前空間接頭辞]+":"+[type定義名]が設定される。 For the request definition, the message name is the message name of the upstream message, and [service name] + Request is set. The part name and part type are generated in the middle header and upstream message, respectively. For the middle header, the lower part of the type definition name of the middle header is set for the part name. For the part type, [namespace prefix of targetNamespace set in the type definition] + ":" for the middle header + [type definition name] is set. For the upstream message, the part name is set to the lower case version of the type definition name of the upstream message. The part type is [namespace prefix of targetNamespace set in the type definition] + ":" + [type definition name] is set.
レスポンス定義については、メッセージ名は、下り電文構造体のメッセージ名であり、[サービス名]+Responseが設定される。パート名は、下り電文構造体のパート名であり、[下り電文構造体のtype定義名を小文字にしたもの]が設定される。パートタイプは、下り電文構造体のパートタイプであり、[下り電文構造体のtype定義で設定したtargetNamespaceの名前空間接頭辞]+":"+[type定義名]が設定される。 For the response definition, the message name is the message name of the downlink message structure, and [service name] + Response is set. The part name is the part name of the downlink message structure, and [type definition name of the downlink message structure in lower case] is set. The part type is the part type of the downlink message structure, and [namespace prefix of targetNamespace set in the type definition of the downlink message structure] + ":" + [type definition name] is set.
以下に、生成部29が生成するWSDLのメッセージ定義の一例を示す。
An example of a WSDL message definition generated by the
<WSDL:message name="PT01Request">
<WSDL:part name="o3wheadbean" type="tns1:O3WheadBean"/>
<WSDL:part name="lay029bean" type="tns2:Lay029Bean"/>
</WSDL:message>
<WSDL:message name="PT01Response">
<WSDL:part name=" pt01returnbean" type="tns2: PT01ReturnBean"/>
</WSDL:message>
そして、生成部29は、S17で生成したメッセージ定義およびWSDLネーミングルールに基づいて、WSDLのポートタイプ定義を生成する(S18)。
<WSDL: message name = "PT01Request">
<WSDL: part name = "o3wheadbean" type = "tns1: O3WheadBean"/>
<WSDL: part name = "lay029bean" type = "tns2: Lay029Bean"/>
</ WSDL: message>
<WSDL: message name = "PT01Response">
<WSDL: part name = "pt01returnbean" type = "tns2: PT01ReturnBean"/>
</ WSDL: message>
Then, the
図14に示すように、ポートタイプ定義は、ポートタイプ名(portType name)、parameterOrder、オペレーション名(operation name)、inputのメッセージ名(message)、データ名(name)、outputのメッセージ名(message)、データ名(name)から構成される。 As shown in FIG. 14, the port type definition includes port type name (portType name), parameterOrder, operation name (operation name), input message name (message), data name (name), output message name (message). It consists of a data name (name).
ポートタイプ名には、[サービス名]+"Server"が設定される。parameterOrderは、パラメータの順序を示す属性であり、"o3wheadbean"+[上り電文のtype定義名を小文字にしたもの]が設定される。オペレーション名は、サービスの呼び出しメソッド(サービスクラス24)を示す固定値(例えばTRDOperation)が設定される。 [Service name] + "Server" is set as the port type name. parameterOrder is an attribute indicating the parameter order, and "o3wheadbean" + [upstream message type definition name in lowercase] is set. As the operation name, a fixed value (for example, TRDOperation) indicating a service call method (service class 24) is set.
inputのメッセージ名は、上り電文のメッセージ名であり、"impl:"+[message定義で設定したRequestメッセージ名]が設定される。inputのデータ名は、上り電文のデータ名であり、[サービス名]+"Request"が設定され、outputのメッセージ名は、下り電文構造体のメッセージ名であり、"impl:"+[message定義で設定したResponseメッセージ名]が設定される。outputのデータ名は、下り電文構造体のデータ名であり、[サービス名]+"Response"が設定される。 The message name of input is the message name of the upstream message, and “impl:” + [Request message name set in the message definition] is set. The data name of input is the data name of the upstream message, [Service Name] + "Request" is set, the message name of output is the message name of the downstream message structure, and "impl:" + [message definition Response message name set in is set. The data name of output is the data name of the downlink message structure, and [service name] + "Response" is set.
以下に、生成部29が生成するWSDLのポートタイプ定義の一例を示す。
An example of the WSDL port type definition generated by the
<WSDL:portType name="PT01Server">
<WSDL:operation name="TRDOperation" parameterOrder="o3wheadbean trl_a1bean">
<WSDL:input message="impl:PT01Request" name="PT01Request"/>
<WSDL:output message="impl:PT01Response" name="PT01Response"/>
</WSDL:operation>
</WSDL:portType>
そして、生成部29は、S18で生成したポートタイプ定義およびWSDLネーミングルールに基づいて、WSDLのバインディング定義を生成する(S19)。
<WSDL: portType name = "PT01Server">
<WSDL: operation name = "TRDOperation" parameterOrder = "o3wheadbean trl_a1bean">
<WSDL: input message = "impl: PT01Request" name = "PT01Request"/>
<WSDL: output message = "impl: PT01Response" name = "PT01Response"/>
</ WSDL: operation>
</ WSDL: portType>
Then, the
図15は、記憶部に記憶されたバインディイング定義およびサービス定義に関するWSDLネーミングルールの一例を示すものである。図15に示すように、バインディング定義は、バインディング名(binding name)、バインディングタイプ(binding type)、transport、soapAction、バインディングスタイル(binding style)、オペレーション名(operation name)、inputのデータ名(input name)、inputのエンコード指定(use)、inputのエンコード形式(encodingStyle)、inputのネームスペース(namespace)、outputのデータ名(output name)、outputのエンコード指定(use)、outputのエンコード形式(encodingStyle)、outputのネームスペース(namespace)から構成される。 FIG. 15 shows an example of a WSDL naming rule related to the binding definition and service definition stored in the storage unit. As shown in FIG. 15, the binding definition includes a binding name, a binding type, transport, soapAction, a binding style, an operation name, and an input data name (input name). ), Input encoding specification (use), input encoding format (encodingStyle), input namespace (namespace), output data name (output name), output encoding specification (use), output encoding format (encodingStyle) , And output namespace.
バインディング名には、[サービス名]+"SoapBinding"が設定され、バインディングタイプは、"impl:"+[portType定義で設定したポートタイプ名]が設定される。transportは、使用するプロトコルを示す固定値(例えばhttp://schemas.xmlsoap.org/soap/http)が設定される。soapActionは、SOAPActionヘッダの値を示す固定値が設定され、バインディングスタイルは、固定値(例えばrpc)が設定される。オペレーション名は、[portType定義で設定したオペレーション名]が設定される。 [Service name] + “SoapBinding” is set as the binding name, and “impl:” + [port type name set in the portType definition] is set as the binding type. In transport, a fixed value (for example, http://schemas.xmlsoap.org/soap/http) indicating the protocol to be used is set. A fixed value indicating the value of the SOAPAction header is set in soapAction, and a fixed value (for example, rpc) is set in the binding style. As the operation name, [operation name set in the portType definition] is set.
inputのデータ名は、上り電文のデータ名を示し、[portType定義で設定したRequestメッセージ名]が設定される。inputのエンコード指定は、上り電文のエンコード指定を示す固定値(例えばuse="encoded")が設定される。inputのエンコード形式は、上り電文のエンコード形式を示す固定値(例えばhttp://schemas.xmlsoap.org/soap/encoding/)が設定される。inputのネームスペースは、上り電文のネームスペースであって、[サービス名]が設定される。 The input data name indicates the data name of the upstream message, and [Request message name set in the portType definition] is set. As the input encoding designation, a fixed value (for example, use = "encoded") indicating the encoding designation of the upstream telegram is set. As the input encoding format, a fixed value (for example, http://schemas.xmlsoap.org/soap/encoding/) indicating the encoding format of the upstream message is set. The input name space is the name space of the upstream message, and [service name] is set.
outputのデータ名は、下り電文構造体のデータ名を示し、[portType定義で設定したResponseメッセージ名]が設定される。outputのエンコード指定は、下り電文構造体のエンコード指定を示す固定値(例えばuse="encoded")が設定される。outputのエンコード形式は、下り電文構造体のエンコード形式を示す固定値(例えばhttp://schemas.xmlsoap.org/soap/encoding/)が設定される。outputのネームスペースは、下り電文構造体のネームスペースであって、[サービス名]が設定される。 The data name of output indicates the data name of the downlink message structure, and [Response message name set in the portType definition] is set. In the output encoding specification, a fixed value (for example, use = "encoded") indicating the encoding specification of the downlink message structure is set. As the output encoding format, a fixed value (for example, http://schemas.xmlsoap.org/soap/encoding/) indicating the encoding format of the downlink message structure is set. The name space of output is the name space of the downlink message structure, and [service name] is set.
以下に、生成部29が生成するWSDLのポートタイプ定義の一例を示す。
An example of the WSDL port type definition generated by the
<WSDL:binding name="PLTr_A1SoapBinding" type="impl:PT01Server">
<WSDLsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<WSDL:operation name="TRDOperation">
<WSDLsoap:operation soapAction=""/>
<WSDL:input name="PT01Request">
<WSDLsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="PLTr_A1" use="encoded"/>
</WSDL:input>
<WSDL:output name="PT01Response">
<WSDLsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="PLTr_A1" use="encoded"/>
</WSDL:output>
</WSDL:operation>
</WSDL:binding>
そして、生成部29は、S19で生成したバインディング定義およびWSDLネーミングルールに基づいて、WSDLのサービス定義を生成する(S20)。
<WSDL: binding name = "PLTr_A1SoapBinding" type = "impl: PT01Server">
<WSDLsoap: binding style = "rpc" transport = "http://schemas.xmlsoap.org/soap/http"/>
<WSDL: operation name = "TRDOperation">
<WSDLsoap: operation soapAction = ""/>
<WSDL: input name = "PT01Request">
<WSDLsoap: body encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" namespace = "PLTr_A1" use = "encoded"/>
</ WSDL: input>
<WSDL: output name = "PT01Response">
<WSDLsoap: body encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" namespace = "PLTr_A1" use = "encoded"/>
</ WSDL: output>
</ WSDL: operation>
</ WSDL: binding>
Then, the
図15に示すように、サービス定義は、サービス名(service name)、バインディング名(port binding)、ポート名(port name)、エンドポイントURL(address location)から構成される。 As shown in FIG. 15, the service definition includes a service name (service name), a binding name (port binding), a port name (port name), and an endpoint URL (address location).
サービス名には、 [サービス名]+ServerServiceが設定され、バインディング名には、”impl:”+[binding定義で設定したバインディング名]が設定される。ポート名には、[サービス名]が設定され、エンドポイントURLは、アクセスする際の相手先を示し、http://サーバアドレス/コンテキストルート/[サービス名]とする。 [Service name] + ServerService is set as the service name, and "impl:" + [binding name set in the binding definition] is set as the binding name. [Service name] is set as the port name, and the endpoint URL indicates the destination at the time of access, and is http: // server address / context route / [service name].
以下に、生成部29が生成するWSDLのポートタイプ定義の一例を示す。
An example of the WSDL port type definition generated by the
<WSDL:service name="PT01ServerService">
<WSDL:port binding="impl:PT01SoapBinding" name="PT01">
<WSDLsoap:address location="http://localhost:8090/axis/services/PT01"/>
</WSDL:port>
</WSDL:service>
生成部29は、上記S15〜S20でそれぞれ生成したdifinitions定義、タイプ定義、メッセージ定義、ポートタイプ定義、バインディング定義及びサービス定義から構成されるWSDLファイルを、WSDL生成情報としてS12で入力されたWSDLファイル出力先ディレクトリに出力する(S21)。
<WSDL: service name = "PT01ServerService">
<WSDL: port binding = "impl: PT01SoapBinding" name = "PT01">
<WSDLsoap: address location = "http: // localhost: 8090 / axis / services / PT01"/>
</ WSDL: port>
</ WSDL: service>
The
<サービス呼出定義ファイルの生成>
次に、サービス呼出定義ファイル31の生成について説明する。
<Generation of service call definition file>
Next, generation of the service
生成部29は、生成したWSDLに基づいてサービス呼出定義ファイル31(図4参照)を生成する。すなわち、生成部29は、WSDLを入力し、SOAPエンジンにより提供されている生成ツール(例えば、WSDL2Java等)を用いて、当該WSDLに対応するサービス呼出定義ファイル31を生成する。生成ツールは、WSDLからJava(登録商標)加工物を生成するためのツールである。生成部29は、生成ツールを用いて、入力されたWSDLを所定の条件に従って加工・編集することによりサービス呼出定義ファイル31を生成する。なお、本実施形態では、サービス呼出定義ファイル31の呼出メソッド名をサービス名ではなく、固定値(TRDOperation)となるように生成する。これにより、本実施形態では、複数のサービスを汎用のサービスクラスで実行することができる。
The
<JavaBeansの生成>
次に、JavaBeans32の生成について説明する。
<Generation of JavaBeans>
Next, generation of
生成部29は、生成したWSDLに基づいて、実行環境で使用するデータ保持用部品であるJavaBeans32を生成する。すなわち、生成部29は、WSDLを入力し、前記生成ツール(例えば、WSDL2Java等)を用いて、当該WSDLで使用するミドルヘッダ、上り電文、下り電文のJavaBeansを生成する。図16は、ミドルヘッダのJavaBeansの一例を示すものである。
The
<サービスエンドポイントの生成>
次に、サービスエンドポイント23の生成について説明する。
<Service endpoint generation>
Next, generation of the
生成部29は、引数としてサービス名の入力を受け付け、サービスエンドポイント用のネーミングルールを参照し、入力されたサービス名のサービスエンドポイントを生成する。図17は、サービス名が、「BEsearch」のサービスエンドポイントの一例を示すものである。サービスエンドポイントは、図1に示すようにサービス毎に設ける必要があるため、生成部29は、全てのサービスについて、それぞれのサービスエンドポイントを生成する。
The
以上説明した本実施形態によれば、既存の業務システムを変更することなく、より容易に既存の業務システムをWebサービスとしてクライアントに提供するができる。 According to the present embodiment described above, an existing business system can be provided to a client as a Web service more easily without changing the existing business system.
すなわち、本実施形態のWebサービス基盤システムは、クライアントから送信されたリクエスト電文を、業務システムが処理可能なデータ形式に変換して業務システムに送信するとともに、業務システムの処理結果をクライアントが処理可能なデータ形式のレスポンス電文に変換して、要求元のクライアントに送信する。つまり、クライアントからのリクエスト電文によりWebサービス基盤システムが起動され、業務システムのトランザクションを呼び出すことにより、既存の業務システムを変更することなく、データ形式の相違を吸収し、既存の業務システムをより容易、よりスピーディにWebサービスとしてクライアントに提供するができる。 In other words, the Web service infrastructure system of the present embodiment converts the request message sent from the client into a data format that can be processed by the business system and sends it to the business system, and the client can process the processing result of the business system Is converted to a response message in a simple data format and sent to the requesting client. In other words, the Web service infrastructure system is activated by a request message from the client, and the transaction of the business system is called to absorb the difference in data format without changing the existing business system, making the existing business system easier. Therefore, it can be provided to the client as a Web service more speedily.
また、本実施形態では、実行環境で使用するトランザクション呼出定義ファイル、データ変換定義ファイルおよび電文定義ファイルに基づいて、クライアントで使用するWSDLを自動生成する。これにより、煩雑で誤りが発生しやすいWSDLのコーディングが不要となり、開発生産性を向上させることができる。また、本実施形態では、Webサービス基盤システムの実行環境で使用するサービスエンドポイント、JavaBeans、およびサービス呼出定義ファイルについても自動生成するため、システム開発者の作業負荷を低減することができる。 In this embodiment, WSDL used by the client is automatically generated based on the transaction call definition file, data conversion definition file, and message definition file used in the execution environment. This eliminates the need for complicated and error-prone WSDL coding and improves development productivity. In the present embodiment, since service endpoints, JavaBeans, and service call definition files used in the execution environment of the Web service infrastructure system are also automatically generated, the workload of the system developer can be reduced.
また、本実施形態では、WSDLを接続仕様としたドキュメント中心型のWebシステムにすることにより、既存の業務システムとの相互接続性をより向上させることができる。また、本実施形態では、Webサービスの標準仕様に対応することで、Webサービスとしての相互運用性、可搬性を高めることができる。 In the present embodiment, the interoperability with an existing business system can be further improved by using a document-centric Web system with WSDL as a connection specification. In the present embodiment, interoperability and portability as a Web service can be improved by supporting the standard specification of the Web service.
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。 In addition, this invention is not limited to said embodiment, Many deformation | transformation are possible within the range of the summary.
1:クライアント、11:WSDL、12:スタブ、13:アプリケーション、2:Webサービス基盤システム、21:Webアプリケーション部、22:SOAPエンジン、23:サービスエンドポイント、24:サービスクラス、25:Webサービスプロバイダ部、26:データ変換部、27:トランザクション呼出部、28:接続部、29:生成部、31:サービス呼出定義ファイル、32:JavaBeans、33:トランザクション呼出定義ファイル、34:データ変換定義ファイル、35:電文定義ファイル、36:データ記憶部、7:第1の業務システム、8:第2の業務システム 1: Client, 11: WSDL, 12: Stub, 13: Application, 2: Web service infrastructure system, 21: Web application unit, 22: SOAP engine, 23: Service endpoint, 24: Service class, 25: Web service provider Part: 26: data conversion part, 27: transaction call part, 28: connection part, 29: generation part, 31: service call definition file, 32: JavaBeans, 33: transaction call definition file, 34: data conversion definition file, 35 : Message definition file, 36: data storage unit, 7: first business system, 8: second business system
Claims (3)
所定の通信プロトコルに従って、クライアントとの間でメッセージの送受信を行う通信処理手段と、
Webサービス毎に設けられた、複数のサービスエンドポイントと、
全てのWebサービスに共通のWebサービス提供手段と、を有し、
前記通信処理手段は、前記クライアントからのサービス要求を、当該サービス要求で指定されたWebサービス用のサービスエンドポイントを介して、前記Webサービス提供手段に送出し、
前記Webサービス提供手段は、前記サービス要求を前記業務システムが処理可能なデータ形式に変換して、当該サービス要求で指定されたWebサービスに対応する業務システムに送信するとともに、前記業務システムの処理結果を前記通信処理手段が処理可能なデータ形式に変換して、前記Webサービス用のサービスエンドポイントを介して前記通信処理手段に送出し、
Webサービス毎に、前記通信処理手段と前記Webサービス提供手段との間でデータを送受信するためのデータ保持部品と、サービスエンドポイントの呼び出し先として前記Webサービス提供手段を示す呼出先情報とが設定されたサービス呼出定義ファイルと、
Webサービスと業務システムのトランザクションとを対応付けて記憶したトランザクション定義ファイルと、
トランザクション毎に、当該トランザクションで使用する電文のデータレイアウトのデータレイアウトIDが記憶されたデータ変換定義ファイルと、
データレイアウトID毎にデータレイアウトが記憶されたレイアウト定義ファイルと、をさらに有し、
前記通信処理手段は、前記サービス要求で指定されたWebサービスに対応するサービス呼出定義ファイルに設定されたデータ保持部品を特定し、当該データ保持部品に前記サービス要求のデータを格納して前記サービスエンドポイントに送出し、
前記サービスエンドポイントは、前記通信処理手段から受け付けた前記データ保持部品を、前記サービス呼出定義ファイルに設定された呼出先情報に基づいて前記Webサービス提供手段に送出し、
前記Webサービス提供手段は、
前記トランザクション定義ファイルを参照して、前記サービス要求で指定されたWebサービスに対応するトランザクションを特定し、
前記データ変換定義ファイルおよび前記レイアウト定義ファイルを参照して、特定したトランザクションに対応するデータレイアウトを読み出し、読み出したデータレイアウトに従って、前記サービスエンドポイントから受け付けたデータ保持部品のデータを変換し、業務システムの前記特定したトランザクションに送出すること
を特徴とするWebサービス基盤システム。 A web service infrastructure system that provides a client with processing performed by a business system as a web service,
Communication processing means for transmitting and receiving messages to and from the client according to a predetermined communication protocol;
A plurality of service endpoints provided for each Web service;
A web service providing means common to all web services,
The communication processing means sends a service request from the client to the Web service providing means via a Web service service endpoint specified in the service request,
The Web service providing means converts the service request into a data format that can be processed by the business system, sends the data to a business system corresponding to the Web service specified by the service request, and the processing result of the business system Is converted into a data format that can be processed by the communication processing means, and sent to the communication processing means via the service endpoint for the Web service,
For each Web service, a data holding component for transmitting and receiving data between the communication processing unit and the Web service providing unit, and call destination information indicating the Web service providing unit as a call destination of a service endpoint are set. Service call definition file,
A transaction definition file storing Web services and business system transactions in association with each other;
For each transaction, a data conversion definition file storing the data layout ID of the data layout of the message used in the transaction,
A layout definition file in which a data layout is stored for each data layout ID;
The communication processing means identifies a data holding component set in a service call definition file corresponding to the Web service specified by the service request, stores the service request data in the data holding component, and stores the service end data Send to point,
The service endpoint sends the data holding component received from the communication processing means to the Web service providing means based on call destination information set in the service call definition file,
The web service providing means includes:
Referring to the transaction definition file, specify a transaction corresponding to the Web service specified in the service request,
A business system that reads the data layout corresponding to the identified transaction with reference to the data conversion definition file and the layout definition file, converts data of the data holding component received from the service endpoint according to the read data layout, and A Web service infrastructure system that transmits the specified transaction to the specified transaction .
前記トランザクション定義ファイル、データ変換定義ファイルおよびレイアウト定義ファイルを用いて、前記クライアントで使用する所定のWebサービスのWSDLを生成する生成手段を、さらに有すること
を特徴とするWebサービス基盤システム。 The web service infrastructure system according to claim 1 ,
A Web service infrastructure system, further comprising: generating means for generating WSDL of a predetermined Web service used by the client using the transaction definition file, the data conversion definition file, and the layout definition file.
前記生成手段は、前記生成した所定のWebサービスのWSDLを用いて、当該所定のWebサービス用のサービス呼出定義ファイルおよびデータ保持部品を生成すること
を特徴とするWebサービス基盤システム。 A web service infrastructure system according to claim 2 ,
The generation unit generates a service call definition file and a data holding component for the predetermined Web service by using the WSDL of the generated predetermined Web service.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009271598A JP5548433B2 (en) | 2009-11-30 | 2009-11-30 | Web service platform system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009271598A JP5548433B2 (en) | 2009-11-30 | 2009-11-30 | Web service platform system |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2011113463A JP2011113463A (en) | 2011-06-09 |
JP5548433B2 true JP5548433B2 (en) | 2014-07-16 |
Family
ID=44235722
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009271598A Expired - Fee Related JP5548433B2 (en) | 2009-11-30 | 2009-11-30 | Web service platform system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5548433B2 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10732944B1 (en) * | 2019-05-14 | 2020-08-04 | Baidu Usa Llc | Generic verification approach for Protobuf based projects |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001160006A (en) * | 1999-12-03 | 2001-06-12 | Hitachi Ltd | Massage relay system |
-
2009
- 2009-11-30 JP JP2009271598A patent/JP5548433B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2011113463A (en) | 2011-06-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9124466B2 (en) | System and method for exposing distributed transaction services as web services | |
US8219970B2 (en) | XML push and remote execution of a wireless applications | |
US8739183B2 (en) | Annotating portions of a message with state properties | |
US7376959B2 (en) | Method and system for outbound web services | |
US7926065B2 (en) | Method and system for dynamically specifying a format for data provided by a web service invocation | |
US20080123668A1 (en) | Systems for dynamic inter-operability of nodes in service grids | |
US20050091386A1 (en) | Method and apparatus for interfacing with a distributed computing service | |
KR101602099B1 (en) | System for Service inter-working based REST in Internet of Things and Method thereof | |
US8230448B2 (en) | Methods, systems and computer program products for web service interaction with a resource management system | |
JP4681968B2 (en) | Service request apparatus, service request method, service request program, and recording medium | |
US7983209B2 (en) | System and method for producing notification based web services | |
US20090327454A1 (en) | Service flow processing apparatus and method | |
CA2543557C (en) | System and method for producing notification based web services | |
JP5548433B2 (en) | Web service platform system | |
EP2101474A1 (en) | Service bindings for web services | |
JP5042415B2 (en) | Client server system | |
JP2002288145A (en) | Information communication system, event processing method thereof, and recording medium recording event processing program in information communication system | |
JP4959339B2 (en) | Port type independent proxy support for web services intermediary | |
JP2005078339A (en) | WSDL document generation apparatus and method | |
KR100755712B1 (en) | Remote management method of embedded device using web service | |
JP4445782B2 (en) | WSDL file generation program and method | |
Schlichter | 7.4 Web Services Description Language (WSDL) | |
JP2006260220A (en) | Information processor, program and storage medium | |
JP2005031905A (en) | Method calling device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120910 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20140221 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20140225 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140423 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140513 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140519 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5548433 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |