Webサービス関連技術のご紹介 - jaist.ac.jp · • Microsoft (.NET) – .NET My Services (一般消費者向けサービス） • トライアルいろいろ（eBay, Amex,

1

Webサービス関連技術のご紹介

湯原雅信[email protected]

富士通研究所2002年7月12日

ACM SIGMOD日本支部ネットワークトランザクション技術専門委員会（TCNT）

2Copyright © 2002 FUJITSU LIMITED．All rights reserved.

【１】Webサービスの概要

【１】Webサービスの概要【２】SOAP【３】WSDL【４】UDDI【５】Webサービスとeビジネス


Webサービス(Web Services)とは？

• 広義– インターネット上のサービス（従来のWebページ

も含む）– あるいは，XMLを使ったインターネット上の

サービス

• 狭義（本日の定義）– SOAPを使ったサービス

– SOAP/WSDL/UDDIを使ったサービス


Webサービスの意義

（１）ビジネス的意義（２）部品化技術的意義

（３）通信技術的意義（４）知識技術的意義


（１）ビジネス的意義

• 自社のコアコンピタンスを生かすため，バリューチェイン（ビジネスコラボレーション）をダイナミックに構築– 自社の機能をインターネット上で他社に提供

（販売チャネルの拡大）

– インターネット上の他社の機能を利用

（アウトソーシング）

例：知らない海外の会社と即座にビジネス


（２）部品化技術的意義

• ソフトウェアの機能をサービスという観点で部品化（コンポーネント化）– インターネット上に分散する部品を組合わせること

で，高度な機能を簡単に実現しようという考え方

– サービス部品を動的に，かつ，自動的に組合わせる世界の実現を目指している

– プラットフォーム(OS,ハード)非依存，プログラミング言語非依存，通信プロトコル非依存

– WWW(HTML)は，人間用で機械向きではない

– CORBAやDCOMはインターネットで広がっていない（ファイアウォール問題，難しい）


（３）通信技術的意義

• 通信の標準レイヤが上がってきている（どこが統一されているか）– Ethernet(MAC)à TCP/IP à HTTP à XML

• バイナリ通信からテキスト通信へ– 開発者，開発ツールの裾野の広がり（１桁～２

桁？違う）

• 人間（ブラウザ）用から機械用に– HTML à XML


（４）知識技術的意義

• メタ情報を利用した知識処理への道が開ける– データに関するメタ情報：例：XML Schema– サービスに関するメタ情報：例：WSDL

– データ間，サービス間の意味的な関係付けのための最低限の基盤が整った

– Semantic Webは，AI的発想からアプローチ（Semantic Net のインターネット版，RDF Schema）．Webサービスは，実世界からのアプローチ．


Webサービス関連技術の歴史

分散オブジェクト

B2B

OMG結成(1989)

CORBA(1991)

SOAP(1999)

ebXML結成(1999)

Rosettanet結成(1998)

EDI(1975)

インターネット

ARPANET(1969)

TCP(1974)

MOSAIC(1993)

IETF結成(1986)

商用ISP(1990頃)

IE(1995)

WWW(1991)

iMode(1999)

SGML(1986)

XML(1998)

HTML(1989)構造化

ドキュメント

XHTML(2000)

COM(OLE2)(1993)

DCOM(1997?)


Webサービスの基本仕様• XML (eXtensible Markup Language)

– 構造化された情報のテキスト表現形式

• SOAP (Simple Object Access Protocol)

– メッセージの形式（Webサービスは，SOAPメッセージをやりとりする．XMLの一種）

• WSDL (Web Service Definition Language)

– サービスの形式的記述（XMLの一種）

• UDDI (Universal Description, Discovery and Integration)

– 企業等のビジネス（サービスの集合）の記述（XMLの一種）．UDDIサーバに登録する（電話帳に相当）


Webサービス関連の仕様

XML関連(主にW3C)

XML, namespaces in XML, XML Schema, Xpath, XPointer, XLink, XML Signature, XML Encryption, Canonical XML, DOM, XSLT, SAX, HTML, XHTML, voiceXML, CC/PP, RDF, SAML, XACML

SOAP, SOAP with Attachment, WSDL, UDDI,WS-Routing, WS-Referral, WS-Security, WS-Inspection, WSRP, WSIA

Web Services関連（W3C, MS/IBM, uddi.org, OASIS）

ビジネス関連（RosettaNet, OASIS, UN/CEFACT）

RosettaNet, ebXML,その他業界標準

コンシューマ関連

.NET My Services,

.NET Passport,Liberty Alliance

WS-I

ワークフロー／プロセス記述

WSFL(IBM), XLANG(MS), WSCL(W3C), Wf-XML(WfMC), BTP(OASIS)

GRID関連

OGSA


Webサービスの実例（１）• Microsoft (.NET)

– .NET My Services (一般消費者向けサービス）• トライアルいろいろ（eBay, Amex, Groove, Accenture, イースト,

JTB, JR東日本，ニッセン，NTT東日本情報システム）

– OPW(Online Printing Wizard)• WinXP標準搭載．MSN+富士写真フィルムなどでSOAP利用

– その他• ebXML実証デモ(2000.11.10；富士通も参加)• Terrarium （エコシステムのゲーム）

• IBM （Web Sphere他）– DB2のWebサービス対応

• UPnP (Universal Plug and Play)– SOAPを利用. ルータ，WinXPですでに利用されている


Webサービスの実例（２）

• 富士通（Interstage，NetCOBOL for .NET，他）– MS .NETとの接続に成功(2001.01.29)– B-Front

• 従業員向けポータルサイトの構築/運営サービス• ポータルとサービス提供企業の間の連携（の１つ）としてSOAP

を採用

– 企業間電子商取引(ebXML)の相互接続実験(2001.05など)

– ファンクラブサービス• NTT情報通信プラットフォーム研究所と共同実験

• ファンクラブホームページと，バックの個々のサービスの間をWebサービスで結ぶ


Webサービスの実例（３）

• Google– Google Web APIs：検索をWebサービス化してトライ

アル提供中（１人１日1000回まで）

• 日本IBM（WebSphere）系– 日立ソフトのB2CのECサイト「@Buy24」

• ユーザとECサイトの間をSOAPで．

– KDDIの決済Webサービスである「PayCounter」

• イースト社(www.est.co.jp)– MS, JTBとビジネストラベルシステムのパイロット版

– 凸版などと書籍検索（Books.or.jp）

Webサービスの本格的な運用は今後


【２】SOAP



SOAPとは？

• Simple Object Access Protocol• XMLを基本としたメッセージ交換プロトコル

• プラットフォーム非依存，プログラミング言語非依存，通信プロトコル非依存

• シンプルがモットー– 複雑なことはあとから決める

• RPC （SOAP-RPC）だけでなく，一方向のメッセージもあり


SOAPが規定すること

• SOAPの処理モデル– 中継点（Intermediary）を含めたSOAP Nodeでの動作

– ヘッダでのMustUnderstand属性の扱い

• SOAPのメッセージの構造– Envelope/Header/Body や，SOAP Fault

• Encoding– もともとXMLでないデータを，モデル化し，XMLで表現

する方法

• プロトコルへのバインディングの枠組みと具体的なバインディング規則– SOAP over HTTP （HTTP binding）のみ具体的に規定さ

れている


SOAPが規定しないこと

• SOAP Header の具体的な形式– To/From/Via，認証情報，暗号化情報，セッショ

ン情報など⇒ それぞれ別の規格で定義

（別のnamespaceになる）

• SOAP Body の具体的な形式


メッセージ交換パターン

要求

応答

SOAPメッセージ

SOAP RPC

一般のSOAP

SOAPメッセージ

IntermediaryInitial Sender Ultimate Receiver

いろいろなMessage Exchange Patternがある．RPCはその１つ．


SOAPメッセージの構造

<SOAP-ENV:Header>

</SOAP-ENV:Header>

<…>(Header Block)</…>

<…>(Header Block)</…>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

<SOAP-ENV:Envelopexmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/>

</SOAP-ENV:Envelope>

SOAP 1.1の場合

属性として，actor(V1.1)/role(V1.2)mustUnderstand

が規定されている

<…>(Body Child)</…>

<…>(Body Child)</…>

グローバル属性として，encodingStyle

が規定されている


SOAPの長所・短所

• 長所– インターネット（疎結合），XMLと相性がよい

– 拡張性が非常に高い

– プラットフォーム，言語，プロトコルに非依存

• 短所– 性能が悪い

• CORBAなどと比べて，XMLを経由する分遅い

– メッセージサイズが大きい• テキストかつXMLであるため大きくなりがち


SOAP仕様の経過

• V0.9 Draft (1999.09)• V1.0 Draft (1999.12.10)• V1.1 W3C Note (2000.05.08) ← 現在のメイン

• V1.2 W3C Last Call Working Draft (2000.06.27)

• 関連ドキュメント– SOAP Messages with Attachments (W3C Note,

2000.12.11）


【３】WSDL



WSDLとは？

• Web Services Description Language• サービスの仕様を記述するためのXML

フォーマット– プロトコル非依存（SOAPに限らない）

– データスキーマ言語非依存（XML Schemaに限らない）

– データバインディング非依存（SOAP bindingに限らない）

WSDLの要素

<PortType>

msg msg

<operation>

<operation>

抽象的記述

具体的記述

<type>

<Port><operation>

<operation><Port>

<service>URL=

URL=<operation>

<operation>

<PortType>

データモデル

具体的データ表現方法（バインディング）

バインディング先の例：

SOAP,HTTP GET/POST,MIME

<input>

<output>,<fault>

<input>

<output>,<fault>


WSDLドキュメントの構造

0～1<wsdl:types> データ型定義 </…>

<wsdl:message name=“..”> メッセージ型定義 </…> 0～N

<wsdl:portType name=“..”> 抽象I/F定義 </…> 0～N

<wsdl:binding name=“..” type=“…”> </…> 0～N

<wsdl:service name=“..” > </…> 0～N

<wsdl:import namespace=“..” localion=“..”/> 0～N

<wsdl:definitions name=“..” targetNamespace=“..”xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/>

</wsdl:definitions>

抽象的定義

具体的定義

メッセージフォーマットや転送プロトコルを具体的に指定

operation, input, output, fault

port（エンドポイント，URL）の集合


４つのタイプの operation

one-way

notification

request-response

solicit-response

サービス提供者サービス提供者

サービス提供者サービス提供者

<input><input>

<output>

<output>

<input>

<output>


WSDL仕様の経過

• WIDL(WebMethods), NASSL(IBM), SDL(MS), SCL(MS)などがもと

• V1.0 W3C Note (2000.11)• V1.1 W3C Note (2001.03.15) ←現在はこれを利用

• V1.2 W3C WGで検討中（2002.07.09に最初のpublic draft公開）


【４】UDDI



UDDI

• Universal Description, Discovery, and Integration

• Microsoft, IBM, Ariba が半年で設計(V1 2000.09)

• APIもXML形式のメッセージで規定(SOAP)


UDDIの利用形態

UDDIRegistry

(1)登録(2)検索

(3)利用

サービス利用者サービス提供者


パブリックUDDI

IBM

MS

SAP

HP

どのUDDIレジストリノードを使っても同じ結果が得られる

NTTCom

相互に同期

登録

検索


White/Yellow/Greenページ

White Pages企業情報<businessEntity>

Yellow Pagesサービス分類<businessService>

Green Pagesバインド情報<bindingTemplate>

Service Typeサービス技術仕様<tModel>

企業名，テキストでの説明，連絡先（電話番号，Webサイト等），企業のカテゴリ

ビジネスサービスのカテゴリ（産業：NAICS，製品・サービス：UN/SPSC，位置

ECを行うためのビジネス情報．実際のサービスにバインド．

ネストしたモデル（ビジネスプロセス，サービス表記，バインディング情報），プラットフォーム・実装非依存

サービスタイプを示すネームスペースをポイントサービス提供者のIDサービスタイプ登録のID（tModelKey）

1

N

1

N


UDDIの登録情報

<businessEntity>

<businessService>

<bindingTemplate> <bindingTemplate>

<businessService>

<bindingTemplate> <bindingTemplate>

<tModelInstanceInfo>





UDDIへのアクセス

• SOAPインターフェイス– Inquiry 系

• find_business, find_service, find_binding, find-tModel, など• get_businessDetail, get_businessDetailExt, get_serviceDetail,

get_bindingDetail, get_tModelDetail

– Publishing 系• save_business他，delete_business他，など

• Webブラウザ向けインターフェイス– http://www.uddi.org/ の”Find”からたどれる

• V1は，IBM, MS• V2(beta)は，HP, IBM, MS, SAP


UDDI登録情報の例

• 例：UDDIレジストリのSOAPサービス自体に関するUDDI登録情報

– ビジネス名：Microsoft– サービス名：UDDI Web Services

• ブラウザからアクセスして得た情報を示すhttp://uddi.microsoft.com/Details/ServiceDetail.aspx?s

erviceID=33c3d124-e967-4ab1-8f51-d93d95fac91a


UDDI登録情報の例（続き）

• Business detail:Microsoft Corporation - 0076B468-EB27-42E5-

AC09-9955CFF462A3Empowering people through great software - any time, any place and

on any device is Microsofts vision. As the worldwide leader in software for personal and business computing, we strive to produce innovative products and services that meet our customer's

Contacts: Microsoft本社のコンタクト情報（住所，電話），など

Services: UDDI Web Sites, UDDI Web Services, Home Page, Online Shopping, Microsoft Developper Network, Technet, Volume Licensing Select Program, Electronic Business Integration Services, Web services for smart searching（多くは Webページをさしているだけ）



• Service detail: UDDI Web Services - 33C3D124-E967-4AB1-8F51-D93D95FAC91AUDDI SOAP/XML message-based programmatic web service interfaces.

• Bindings: (Production/Test×Publish/Inquireの４つ．そのうち１つを示す）Access pointURL: http://uddi.microsoft.com/inquiretype：httpDescription: Production UDDI server, Inquiry interfaceBinding Key: ED223839-4A96-482C-86BF-FED8AE6427E4Instance details:

Specification signature:tModel: uddi-org:inquiry （uddi.orgによる定義を参照）

Description: UDDI SOAP Inquiry Interface



• tModel detail: uddi-org:inquiry -UUID:4CD7E4BC-648B-426D-9936-443EAAC8AE23

UDDI Inquiry API - Core SpecificationOverview URL:

http://www.uddi.org/wsdl/inquire_v1.wsdlDescription: This tModel defines the inquiry API calls for

interacting with the UDDI registry.

次ページ



• WSDL （tModelの参照先）データ型定義:

http://www.uddi.org/schema/2001/uddi_v1.xsdをインポート

メッセージ定義：find_business, find_service, find_binding, find_tModel ,businessList, serviceList, bindingList, tModelList, … など

ポート型定義:InquireSoapoperation: find_business (input: find_business,

output: businessList),find_service(…), ….

binding定義:SOAP over HTTP へのバインディング


UDDI仕様の経過と現状

• V1⇒V2⇒V3V1: 仕様 2000.9 ，現在運用中

V2：仕様 2001.6.18，beta運用開始 2001.11.19V3：ドラフト公開 2002.07.03

• 仕様は当面V3で固定の方向• パブリックUDDI

– 現在は有用な登録情報が少ない（鶏と卵）• 実際にWebサービスを運用している企業はまだ少な

い（テストやWebページ参照のみが多い）

• 動的にサービスを探す必要／価値がまだ（？）ない

• 与信機関などの環境が整っていない


UDDI仕様の経過と現状（続き）

• プライベートUDDI– 企業内で，他社（や社内）のサービス情報のリ

ポジトリとして利用– パブリックUDDIより，先に広がりそう

– 標準のUDDIだけでは不足している情報を付加• 自社のみに意味があったり，公開できない情報（各

社の評価，取引の優先順位など）


【５】Webサービスとeビジネス


• RosettaNet

• ebXML

• BTP


eビジネスでのWebサービス利用

• SOAP/WSDL/UDDIなどWebサービスの仕様だけでは，ビジネスを行うには不十分

• ビジネスコラボレーションについては，古くEDIで検討されてきていて，そのレベルの仕様が必要– 1対1で closed なEDIから，open ediへの流れがあった

– DELL のSCMに刺激を受けたRosettaNet（IT/PC業界，電子部品業界，半導体業界）

– より一般的な ebXMLへの流れ


ビジネスに必要なもの

• ボキャブラリ（用語）やビジネスプロセスの部品

• ビジネスプロセス（手順）の記述方法

• ボキャブラリやプロセス記述を登録するリポジトリ／レジストリ

• 契約／合意の記述

ビジネスコラボレーション

HTTP 等HTTP 等

RosettaNetV1.1, V2.0

RNIFRNIFSOAPSOAP

PIPsPIPs

RosettaNetV3.0（検討開始） ebXML 純SOAP

(.NET流）

ebXML MessagingebXML Messaging

CPP/CPACPP/CPA

BPSSBPSS

自動車業界仕様

自動車業界仕様

JEITA仕様

JEITA仕様

Rosetta仕様

Rosetta仕様

CCCC

UN/CEFACT

OASIS

W3C

RosettaNet

PC業界仕様

PC業界仕様

xx業界仕様

xx業界仕様

xx業界仕様

xx業界仕様

xx業界仕様

xx業界仕様

IETF等

UDDIRegistry/Repository

DictionariesDictionaries


RosettaNet• 情報機器(IT)業界，電子部品(EC)業界，半導体製

造(SM)業界，およびソリューション提供(SP)業界のコンソーシアム

• Dellのサプライチェーンに対抗

• 規格PIPs(Partner Interface Processes)：取引企業間のビジネ

ス・プロセスDictionaries: 共通の用語定義 (Business Directory,

Technical Directories)RNIF(RosettaNet Implementation Framework)：PIPのメッ

セージやシグナルのpackaging, routing, transport現在はWebサービス準拠ではないが，3.0ではSOAP準拠の ebXMLに準拠すると宣言している


当社でのRosettaNet適用例

http://xml.fujitsu.com/jp/standard/10_jisso.pdf より


RosettaNet の PIPs

• PIP 3A4 のような指定の仕方

– 3A4は，Request Purchase Order

• 現在公開されているものが 87個位あり，さらに検討中のものがある

クラスタ（0～8)3は発注管理セグメント

3Aは見積もりと発注


RosettaNet PIP の例(3A4)

OrganizationalAn organization that sells products to partners in the supply chain.

Seller

FunctionalAn employee or organization that buys products for a partner type in the supply chain.

Buyer

Role TypeRole DescriptionRole

Name

Table 3-1: Partner Role Descriptions

Formally confirms the status of line item(s) in a Purchase Order. A Purchase Order line item may have one of the following states: accepted, rejected, or pending.

Purchase Order Confirmation

A request to accept a purchase order for fulfillment.Purchase Order Request

DescriptionBusiness Document

Table 3-4: PIP Business Documents


3A4のメッセージ交換

発注伝票（要求）

発注伝票受信確認

受注伝票（応答）

受注伝票受信確認

transaction(exactly once)

transaction(exactly once)

:Buyer Service :Seller Service

1. request (PurchaseOrderRequestAction)

1.1 signal (ReceiptAcknowledgment)

1.2 response (PurchaseOrderConfirmationAction)

1.2.1 signal (ReceiptAcknowledgment)


3A4のメッセージ交換制御

YYYNN/AN/AN/AReceipt Acknowledgment

1.2.1.

YYYYN/AN/A2 hrsPurchase Order Confirmation Action

1.2.

YYYYN/AN/AN/AReceipt Acknowledgment

1.1.

YYYY24 hrsN/A2 hrsPurchase Order Request Action

1.

Is Secure Transport Required?

Is Non-Repudiation Required?

Is Authorization Required?

Included in Time to Perform

Time to Respond to Action

Time to Acknowledge Acceptance Signal

Time to Acknowledge Receipt Signal

Name#

Table 4-3: Message Exchange Controls - Request Purchase Order


RosettaNetのプロトコルスタック

添付以外はXML（スキーマ記述はDTD）


ebXML

• e-ビジネスの情報を利用するための，相互運用可能で安全で一貫性が保たれた，XMLベースのオープンなインフラを提供する

• OASIS（下位，XMLの流れ）とUN/CEFACT（上位，EDIの流れ）で標準化

[ebXML] ebXMLによるビジネスebXML

BusinessProcess

Specification

ebXMLBusinessProcess

Specification

BusinessDocument

Specification

BusinessDocument

Specification

ebXMLCore

Components

ebXMLCore

Components

伝票の形式伝票のやりとり方法用語，構造部品

Context For

Reference ToBuilt With

登録

CollaborationProtocolProfile




Registry/Repository

一方のPartnerRoleを実装

CollaborationProtocol

Agreement

CollaborationProtocol

Agreement

他方のPartnerRoleを実装

BusinessService

Interface

BusinessService

Interface

通信

A社のビジネス B社のビジネス

合意

登録登録


[ebXML] ebXMLでのSOAP利用

eb:Error

eb:MessageHeader

eb:なんとか

他:なんとか

eb:Manifest

eb:なんとか

他:なんとか

SOAP-ENV:Header

SOAP-ENV:Body

MIME Part

MIME Part(s)

ペイロード

SOAP with Attachements MIME envelope通信プロトコル envelope (HTTP等）

SOAP-ENV:Envelope


[ebXML] Reliable Messaging

Party AMSH

Party BMSH

Message

Acknowledgement

Message

Message

Acknowledgement

ebXMLメッセージレベルの再送

ebXMLメッセージレベルのAck

重複のため廃棄ただし，Ack再送

MSH: Message Service Handler

Once-and-only-once (Exactly-once, all-or-nothing)の実現


（続き）

• Reliable Messagingのパラメータ(多くはCPAで指定）n <DuplicateElimination> 重複チェック要請

n <AckRequested> 確認要請

n <Retries> 最大再送回数

n <RetryInterval> 最小再送間隔

n <TimeToLive> 有効期限

n <PersistDuration> 最低保管期限

n <syncReplyMode> 同期応答要請


（続き）


ビジネスプロセスとトランザクション• 管理ドメインが複数で，疎に分散し，それぞれが自

律している– 相手の会社のシステムに口出しできない（自社のマシン

がクラッシュしたからといって，他社のシステムを停止してリカバリ処理を行うことなどできない）

– 相手が意図したように動作してくれるとは限らない（相手が自分の資源をロックしたまま何もしてくれないかもしれない）

– 相手が信用できない（言った言わない問題）

– 期間の長いビジネスプロセスがある

ビジネスプロセス全体を，ACIDトランザクションとするのは不適切，ACID性だけでは不十分


予約の例

• デフォルトキャンセル型予約システム– 予約後一定時間内に確認（confirm，例：支払

い）をしないと自動的にキャンセル• 例：チケット電話予約で予約番号ゲット

– 予約金（手付金）が必要な場合あり

• デフォルト契約型予約システム– 予約後なにもしなければ自動的に契約成立

• 例：ホテルの予約（３日前までキャンセル無料）

– 違約金が必要な場合あり


時間感覚の問題

ロングトランザクション

ショートトランザクション

人間社会のタイムフレーム社会的動作が必要

機械のタイムフレーム機械的動作（ロック/ACID）でＯＫ

• ロックでなく，予約• ロールバックというより，逆操作

（compensation）• ビジネスプロセスとして，

時間条件や金銭条件も含めて契約• 特に，予約や契約違反には金銭が関係


BTP

• Business Transaction Protocol (OASIS)– 2002.05.16に，TCが approve– v1.0 の仕様書（2002.06.03）

• 複数の自律組織の管理する参加者の間で，ビジネスプロセスを調停する

• Two-Phase Outcome coordination protocolＩ．Provisional Effect (Prepare)ＩＩ．Final Effect (Confirm) / Counter Effect (Cancel)

• Webサービスに限定していないが，SOAPバインディングが示されている


[BTP] Two-Phase Outcome

典型的なデータベース方式

もとの状態に戻す．アクセスを許可

アクセスを許可

もとの状態を記憶．外部のアクセスを禁止，変更を実行

compensation方式の１例

undo動作を行う

undo情報を削除

変更を行い，結果を公開．変更のundo 情報を記憶

記憶した変更を削除，実行はせず

変更を実行変更を記憶，実行はせず

コメントCounter Effect(Cancel)

Final Effect(Confirm)

Provisional Effect(Prepare)

いくつかの例（参加者が状態をどのように管理するかは規定しない）


[BTP] Superior : Inferior 関係

• ２者間の関係が基礎– Superior : Inferior の関係

initiatingapplicationelement

serviceapplicationelement

BTPSuperior

BTPInferior

アプリケーションメッセージ

BTPメッセージ

PREPARE

CONFIRMCANCEL

PREPARED

CONFIRMEDCANCELED


[BTP] Business Transaction Tree

A

B

C D

E F

SuperiorSuperior

Superior

Superior Superior

InferiorInferior Inferior

InferiorInferior


[BTP] Atom とCohesion

• Atom (Atom Business Transaction)– 全ての Inferior をCancel，または全ての

Inferior をConfirm のどちらか• そのようなSuperior を，Atom Coordinator（トップ）ま

たは，Sub-coordinator（中間）と言う

• Cohesion (Cohesive Business Transaction)– どの Inferior をCancelし，どの Inferior を

Confirm するかは，Superior に結びついたアプリケーションが決定する

• そのようなSuperior を，Cohesive Composer（トップ）または Sub-composer（中間）と言う


[BTP] 自律的判断の許容

• Autonomous Cancel, Autonomous Confirm– Inferior は，"prepared"の状態を保持する有効

期限を示すことができる– その期限後は，勝手に（自律的に）Cancel また

は Confirm 相当の処理をして，CANCELED または CONFIRMED メッセージを送ってよい

– Superior の outcome（判断）と，Inferior の判断が異なった場合には，Superior からCONTRADICTION メッセージが送られる．どのように処置するかは Superior 次第


[BTP] コメント

• ２者間の Superior : Inferior を基盤としているのは，互いに自律したシステム（例：他社）を扱うため．

• Superior が，対応する Inferiors との関係においてトランザクション処理モニタ的役割を果たす．

• 階層化しているところは，Nested Transaction の考え方．Superior が，別の関係では Inferior の役割となり得るため，全体を集中管理しているわけではない．階層に合わせて分散管理している．

• prepared に有効期限を設け，Inferior が自律的に判断することを許している


おしまい