プリミティブWebサービスとエージェントによる商品調達B2Bシステムの設計と実装 DBWeb2004 ２００４年11月25日 松江工業高等専門学校　情報工学科 奈良先端科学技術大学院大学　博士後期課程 越田　高志

発表内容 1.はじめに 2.プリミティブWebサービス(PWS)の提案 ・提案の背景，定義，導入の利点 ３.商品調達B2Bシステムの開発 　・提案の背景，定義，導入の利点　 ３.商品調達B2Bシステムの開発 　・ユースケース，システム構成，処理の流れ，機能（PWS/エージェント），実験 4.おわりに ・まとめ，今後の課題

1.はじめに Webサービスの問題点（ビジネス分野で広く利用されるためには？） 必要なサービスの検出が難しい． インターネット上でWebサービス情報の登録と検索を一元化するUDDIがある．しかし，登録情報の信頼性の問題，検索機能が不十分． 逆に“このサービス”が利用できる企業はどこか？なども．

２．Webサービスの機能や入力データなど，利用法が分かりにくい． UDDIの登録情報（description要素）を読む． WSDL記述を読む． message要素，portType要素から判断する． 人手で，Webサービス毎に確認作業が必要である． これらを確実に，かつ容易に解決できる方法は？

その解決に向けて， １，２の問題点解決に加えて，Webサービスの連携も重要な課題である． それらの解決手法として，

２．プリミティブWebサービスの提案 提案の背景 Webサービスをインターネット上で一元的に登録し，管理する手段として，UDDIレジストリがある．UDDIレジストリをベースに考えたい． Webサービス名や機能に関する統一基準などはない．各企業が任意にサービスを提供している．ユーザは，利用するサービス毎にその利用法を確認しなければならない．煩雑であり，使いづらい． Webサービスをもっと容易に利用できないか？

その定義 Webサービスをある基準の元に統一する． 様々なビジネス分野で共通に利用可能な，一意に統一された名称，機能，入出力インターフェースをもつ基本的なWebサービスとして定義する．それをプリミティブWebサービスとする． 例えば，物品購入の商取引では，物品検索，信用確認，在庫確認，価格見積り，受注など． そのプリミティブWebサービス(以降，PWS)を組み合わせて，任意のビジネスプロセスを処理する．

導入の利点 ユーザ側の利点 提供企業側の利点 WebサービスがPWSとして標準化されるので，Webサービスの名称，機能，入出力インターフェースに関する不統一性や曖昧さがなくなる． 必要とするWebサービスの的確な検出． Webサービスの機能や利用法修得の負荷が減少する． 提供企業側の利点 独自のWebサービスではなくて，共通のPWSを提供するので，それに対する開発コストが削減される． 利用しやすいWebサービスであれば，その使用も増え，ビジネスチャンスが拡大する．

３．商品調達B2Bシステムの開発 プリミティブWebサービスとその連携を行うエージェントを開発し，システムとしてまとめ，ユースケースに沿って検証する． ユースケース 商品調達のビジネスプロセスを考える． 商品としてビールを考え，メーカ（３社），卸売業者，小売業者間の商取引を想定する．卸売業者が中心．小売業者の与信情報を提供する調査会社も含む． 小売業者から受注したビールを供給するメーカに対して見積りを行い，最も安価な商品を選択して，発注する，シナリオである．

システム構成 メーカ３社は同じPWSを利用する． 選択 受注 与信 発注

処理の流れ (１) 商品納品要求：ある小売業者が新規の取引を求めて， 卸売業者に対して商品納品を要求する． (１) 商品納品要求：ある小売業者が新規の取引を求めて，　　　　　　　　　　卸売業者に対して商品納品を要求する． (２) 信用確認要求：卸売業者は企業調査会社に対して，その　　　　　　　　　小売業者の信用調査を依頼する． (３) 信用確認回答：信用調査会社は，「信用確認Webサービ　　　　　　　　　ス」を利用してその小売業者の信用確認を行い，返答する． (４）  在庫確認と価格見積り要求： 信用調査結果に問題がなければ，卸売業者は要求があった商品を製造するメーカに対して，在庫確認と価格見積りを依頼する．この際，同じ仕様の商品製造メーカが複数存在すると仮定し，その中の３メーカに対して同時に在庫確認と価格見積りを依頼する．

(５) 在庫確認と価格見積り回答： メーカは「在庫管理Webサービス」を利用して，商品の在庫確認と価格見積りを同時に行い，卸売業者に返答する． (６) 商品選別と発注： 卸売業者は，３メーカからの価格見積り結果をエージェント(StockServiceAgent7)によって比較し，希望条件（様々な条件が考えられるが，今回は最も価格が安い条件に設定する）に合致した商品製造メーカを選別し，商品を発注する．

(７) メーカ商品受注完了： 発注を受けたメーカは，「商品受注Webサービス」を利用して受注処理を行い，その完了後に卸売業者に対して受注完了メッセージを送信する． (８) 商品受注完了： それを受けて卸売業者は小売業者に納品要求受注完了メッセージを送信する．

PWSの機能：メーカ 在庫管理Webサービス（getStockdetails) 商品受注Webサービス（getOrders) 入力データ 卸売業者ID番号，卸売業者名，希望ビールタイプ，数量，納品日 出力データ 回答メーカ名，指定されたビールタイプ，商品名，商品コード，単価，指定数量，全体価格 商品受注Webサービス（getOrders) 卸売業者ID番号，卸売業者名，数量，納品日 受注完了メッセージ

サーバへの配備状況

PWSの機能：信用調査会社 信用確認Webサービス（getCredit) PWSの開発 入力データ 出力データ 調査対象企業名，電話番号 出力データ 企業名，代表者名，住所，電話番号，信用結果(OK/NG) PWSの開発 いずれもApache-Axis-1.0で開発し，ｈｔｔｐサーバTomcat-4.1.27に配備している．DBMSはMicrosoft　Access2000を使い，JDBCでPWSとアクセスしている．

サーバへの配備状況

エージェントの機能 ３エージェントが卸売業者サーバで稼動． メーカのPWSを実行するエージェント(StockServiceAgent7) 信用調査会社のPWSを実行するエージェント(CreditServiceAgent1) この2エージェントを連携，制御するエージェント　(client1) JADE-3.0で開発した．

エージェントの稼動状況 今回開発した３エージェント

エージェントの処理の流れ 連携，制御エージェント(client1) 信用調査へのデータ入力を促す． そのデータをCreditServiceAgent1*Aに伝え，＊Aは信用確認PWSを実行し，その結果をclient1に返す． 信用OKならば，小売業者に発注データ入力を促し，そのデータをStockServiceAgent7*Bに伝える．*Bはメーカ3社への在庫管理と価格見積りPWSを同時に実行し，その結果をclient1に返す． メーカ3社の見積り結果を比較し，最も安価な商品を選択し，卸売業者の判断を待つ．OKならば，そのまま*Bに発注を依頼する．

実験： エージェントの処理の流れ(1,2の実行) getCreditの実行 入力データ 出力結果

エージェントの処理の流れ　(３の実行) getStockdetailsの実行 入力 データ

エージェントの処理の流れ (３の実行) ３メーカのgetStockdetails 実行結果 各メーカからの出力結果

エージェントの処理の流れ　(４の実行) エージェントによる選別結果 商品発注を指示 (getOrdersの実行)

実験結果 商品調達のビジネスプロセスに沿って，開発したPWSと３エージェントの機能と連携の正常動作を確認した． 今はメーカ毎に異なるWebサービスを使うので，共通のPWSを利用すれば，比較・選別するメーカ数に比例して，処理が効率化される．

４．おわりに（まとめ/今後の課題） まとめ 共通かつ基本的なビジネスプロセスに対応した，プリミティブWebサービスを提案した． UDDIレジストリから，必要とするWebサービスの的確な検出と利用法に対する理解が容易になる．

まとめ(続き) サービスの名称，機能，入出力データが一意に統一されることによって，逆にWebサービス名から企業が検索できる． 　（例　このPWSが利用できる“企業”はどこか，など） 商品調達B2Bシステムの開発 PWSとそのPWSの実行と連携を制御するエージェントを開発し，システムとして開発した．

今後の課題 PWSの粒度，設計について PWSの実行と連携について まだ，漠然としている． もっと基本的な定義と設計基準が必要か？→今は「一意に統一された名称，機能，入出力インターフェースをもつ」 多様なビジネスプロセスの分析．→「汎用化の範囲」と「基本的」の意味を明確にする． PWSの実行と連携について 今回は予め，実行するPWSを静的に決めているが，動的に組み合わせて実行する形式にすべき．

そのためには， 入力支援ユーザインターフェースの自動生成 入力データは複合型に統一する（メソッド引数の統一）． WSDL記述を解析し，入力データの種類と型を抽出する． その入力支援のコマンドプロンプトやGUIを動的に生成する． 入力データは複合型に統一する（メソッド引数の統一）． 複合型を構成する入力データの種類と型は任意にできる，自由度がある．複合型のデータ名を統一する． 入力データを扱うJavaBeansクラスを，ユーザ側で用意する必要がある．出力データに対しても同様． その動的生成手法は開発済み．

<s:element name="GetLatLong"> <s:complexType> <s:sequence> <s:element name="zipcode" type="s:string" /> <s:element name="LicenseKey" type="s:string" /> </s:sequence> </s:complexType> </s:element> <message name="GetLatLongSoapIn"> <part name="parameters" element="s0:GetLatLong" /> </message> <wsdl:message name="getTempMakerRequest"> <wsdl:part name="in0" type="xsd:string"/> </wsdl:message> 　　<wsdl:part name="in1" type="xsd:string"/> 複合型 基本型 メソッドへの引数は固定される．その内容は任意にできる． メソッドへの引数は，入力データ種類によって変わる．固定できない．

　最後に，本論文に対して，貴重な御意見を頂きました査読委員の方と，事務局の筑波大学 佐藤先生に感謝致します．有難うございました．