PPT

プリミティブWebサービスとエージェ
ントによる商品調達B2Bシステムの
設計と実装
DBWeb2004
２００４年11月25日
松江工業高等専門学校情報工学科
奈良先端科学技術大学院大学博士後期課程
越田高志
1
発表内容
1.はじめに
・現在のWebサービスの問題点について
2.プリミティブWebサービス(PWS)の提案
・提案の背景，定義，導入の利点
３.商品調達B2Bシステムの開発
・ユースケース，システム構成，処理の流れ，機能
（PWS/エージェント），実験
4.おわりに
・まとめ，今後の課題
2
1.はじめに

Webサービスの問題点（ビジネス分野で広く利用さ
れるためには？）
1.
必要なサービスの検出が難しい．

インターネット上でWebサービス情報の登録と検
索を一元化するUDDIがある．しかし，登録情報
の信頼性の問題，検索機能が不十分．

逆に“このサービス”が利用できる企業はどこ
か？なども．
3
２．Webサービスの機能や入力データなど，利用
法が分かりにくい．

UDDIの登録情報（description要素）を読む．

WSDL記述を読む．
• message要素，portType要素から判断する．


人手で，Webサービス毎に確認作業が必要であ
る．
これらを確実に，かつ容易に解決できる方法
は？
4
その解決に向けて，

１，２の問題点解決に加えて，Webサービスの
連携も重要な課題である．

それらの解決手法として，
プリミティブWebサービスを提案する．
5
２．プリミティブWebサービスの提案

提案の背景



Webサービスをインターネット上で一元的に登録し，
管理する手段として，UDDIレジストリがある．
UDDIレジストリをベースに考えたい．
Webサービス名や機能に関する統一基準などはな
い．各企業が任意にサービスを提供している．ユー
ザは，利用するサービス毎にその利用法を確認し
なければならない．煩雑であり，使いづらい．
Webサービスをもっと容易に利用できないか？
6

その定義


Webサービスをある基準の元に統一する．
様々なビジネス分野で共通に利用可能な，一意に
統一された名称，機能，入出力インターフェースを
もつ基本的なWebサービスとして定義する．それを
プリミティブWebサービスとする．
• 例えば，物品購入の商取引では，物品検索，信用確認，
在庫確認，価格見積り，受注など．

そのプリミティブWebサービス(以降，PWS)を組み
合わせて，任意のビジネスプロセスを処理する．
7

導入の利点

ユーザ側の利点
• WebサービスがPWSとして標準化されるので，Web
サービスの名称，機能，入出力インターフェースに関す
る不統一性や曖昧さがなくなる．
• 必要とするWebサービスの的確な検出．
• Webサービスの機能や利用法修得の負荷が減少する．

提供企業側の利点
• 独自のWebサービスではなくて，共通のPWSを提供す
るので，それに対する開発コストが削減される．
• 利用しやすいWebサービスであれば，その使用も増え，
ビジネスチャンスが拡大する．
8
３．商品調達B2Bシステムの開発
プリミティブWebサービスとその連携を行うエー
ジェントを開発し，システムとしてまとめ，ユース
ケースに沿って検証する．
 ユースケース


商品調達のビジネスプロセスを考える．

商品としてビールを考え，メーカ（３社），卸売業者，
小売業者間の商取引を想定する．卸売業者が中心．
小売業者の与信情報を提供する調査会社も含む．

小売業者から受注したビールを供給するメーカに対
して見積りを行い，最も安価な商品を選択して，発注
する，シナリオである．
9
システム構成
メーカ３社は同じPWSを利用する．
選択
小売業者
受注
発注
(7)
(4)
(5)
(6)
商
品
受
注
Web
信用確認 Web サービス
getCredit
エ
ー
ジ
ェ
ン
ト
在
庫
管
理
Web
(3)
エ
ー
ジ
ェ
ン
ト
client1
与信
(2)
エ
ー
ジ
ェ
ン
ト
StockServiceAgent7
(8)
CreditServiceAgent1
(1)
卸売業者
サ
ー
ビ
ス
サ
ー
ビ
ス
メ
ー
カ
getStockdetails
getOrders
信用調査会社
商品受注 Web サービス
getOrders
選別されたメーカ
要求
応答
10
処理の流れ
(１) 商品納品要求：ある小売業者が新規の取引を求めて，
卸売業者に対して商品納品を要求する．
(２) 信用確認要求：卸売業者は企業調査会社に対して，その
小売業者の信用調査を依頼する．
(３) 信用確認回答：信用調査会社は，「信用確認Webサービ
ス」を利用してその小売業者の信用確認を行い，返答する．
(４）在庫確認と価格見積り要求：
信用調査結果に問題がなければ，卸売業者は要求があった商品
を製造するメーカに対して，在庫確認と価格見積りを依頼する．こ
の際，同じ仕様の商品製造メーカが複数存在すると仮定し，その
中の３メーカに対して同時に在庫確認と価格見積りを依頼する．
11
(５) 在庫確認と価格見積り回答：
メーカは「在庫管理Webサービス」を利用して，商品の在庫確認と
価格見積りを同時に行い，卸売業者に返答する．
(６) 商品選別と発注：
卸売業者は，３メーカからの価格見積り結果をエージェント
(StockServiceAgent7)によって比較し，希望条件（様々な条件が考
えられるが，今回は最も価格が安い条件に設定する）に合致した
商品製造メーカを選別し，商品を発注する．
12
(７) メーカ商品受注完了：
発注を受けたメーカは，「商品受注Webサービス」を利用して受注処
理を行い，その完了後に卸売業者に対して受注完了メッセージを
送信する．
(８) 商品受注完了：
それを受けて卸売業者は小売業者に納品要求受注完了メッセージ
を送信する．
13
PWSの機能：メーカ

在庫管理Webサービス（getStockdetails)

入力データ
• 卸売業者ID番号，卸売業者名，希望ビールタイプ，数量，
納品日

出力データ
• 回答メーカ名，指定されたビールタイプ，商品名，商品
コード，単価，指定数量，全体価格

商品受注Webサービス（getOrders)

入力データ
• 卸売業者ID番号，卸売業者名，数量，納品日

出力データ
• 受注完了メッセージ
14
サーバへの配備状況
15
PWSの機能：信用調査会社

信用確認Webサービス（getCredit)

入力データ
• 調査対象企業名，電話番号

出力データ
• 企業名，代表者名，住所，電話番号，信用結果
(OK/NG)

PWSの開発

いずれもApache-Axis-1.0で開発し，ｈｔｔｐサーバ
Tomcat-4.1.27に配備している．DBMSは
Microsoft Access2000を使い，JDBCでPWSと
アクセスしている．
16
サーバへの配備状況
17
エージェントの機能

1.
３エージェントが卸売業者サーバで稼動．
メーカのPWSを実行するエージェント
(StockServiceAgent7)
2.
信用調査会社のPWSを実行するエージェント
(CreditServiceAgent1)
3.

この2エージェントを連携，制御するエージェ
ント (client1)
JADE-3.0で開発した．
18
エージェントの稼動状況
今回開発した３
エージェント
19
エージェントの処理の流れ

連携，制御エージェント(client1)
1.
信用調査へのデータ入力を促す．
そのデータをCreditServiceAgent1*Aに伝え，＊Aは
信用確認PWSを実行し，その結果をclient1に返す．
信用OKならば，小売業者に発注データ入力を促し，そ
のデータをStockServiceAgent7*Bに伝える．*Bは
メーカ3社への在庫管理と価格見積りPWSを同時に実
行し，その結果をclient1に返す．
メーカ3社の見積り結果を比較し，最も安価な商品を選
択し，卸売業者の判断を待つ．OKならば，そのまま*B
に発注を依頼する．
2.
3.
4.
20
実験：エージェントの処理の流れ(1,2の実行)
getCreditの実行
入力データ
出力結果
21
エージェントの処理の流れ (３の実行)
getStockdetailsの実行
入力
データ
22
エージェントの
処理の流れ
(３の実行)
３メーカの
getStockdetails
実行結果
各メーカから
の出力結果
23
エージェントの処理の流れ (４の実行)
エージェントによる
選別結果
商品発注を指示
(getOrdersの実行)
24
実験結果

商品調達のビジネスプロセスに沿って，開発し
たPWSと３エージェントの機能と連携の正常動
作を確認した．

PWSを想定することにより，３メーカに対する在
庫・価格見積りが一括実行でき，その結果から
の商品選別処理も効率化される．

今はメーカ毎に異なるWebサービスを使うので，
共通のPWSを利用すれば，比較・選別するメー
カ数に比例して，処理が効率化される．
25
４．おわりに（まとめ/今後の課題）

まとめ
共通かつ基本的なビジネスプロセスに対応した，プ
リミティブWebサービスを提案した．
 それにより，Webサービスの名称，機能，入出力イ
ンターフェースに対する不統一性や曖昧さが解消さ
れる．


UDDIレジストリから，必要とするWebサービスの
的確な検出と利用法に対する理解が容易になる．
26
まとめ(続き)

サービスの名称，機能，入出力データが一意に統
一されることによって，逆にWebサービス名から企
業が検索できる．
（例このPWSが利用できる“企業”はどこか，など）

商品調達B2Bシステムの開発
•PWSとそのPWSの実行と連携を制御するエー
ジェントを開発し，システムとして開発した．
27
今後の課題


PWSの粒度，設計について

まだ，漠然としている．

もっと基本的な定義と設計基準が必要か？→今は
「一意に統一された名称，機能，入出力インターフェー
スをもつ」

多様なビジネスプロセスの分析．→「汎用化の範囲」
と「基本的」の意味を明確にする．
PWSの実行と連携について

今回は予め，実行するPWSを静的に決めているが，
動的に組み合わせて実行する形式にすべき．
28
そのためには，

入力支援ユーザインターフェースの自動生成
• WSDL記述を解析し，入力データの種類と型を抽出する．
• その入力支援のコマンドプロンプトやGUIを動的に生成す
る．

入力データは複合型に統一する（メソッド引数の統一）．
• 複合型を構成する入力データの種類と型は任意にできる，
自由度がある．複合型のデータ名を統一する．
• 入力データを扱うJavaBeansクラスを，ユーザ側で用意す
る必要がある．出力データに対しても同様．
• その動的生成手法は開発済み．
29
複合型
メソッドへの引数は固定される．
その内容は任意にできる．
<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:message name="getTempMakerRequest">
<wsdl:part name="in0" type="xsd:string"/>
<wsdl:part name="in1" type="xsd:string"/>
</wsdl:message>
メソッドへの引数は，
入力データ種類に
よって変わる．固定
できない．
30
最後に，本論文に対して，貴重な御意見を
頂きました査読委員の方と，事務局の筑波
大学佐藤先生に感謝致します．有難うご
ざいました．
31

Download Report