WebService QoS & Policy 1 日本IBMシステムズ・エンジニアリング(株) Webインフラストラクチャー

WebService QoS & Policy
日本IBMシステムズ・エンジニアリング(株)
Webインフラストラクチャー
高浜 めぐみ ([email protected])
© 2008 IBM Corporation
1
Disclaimer
WAS
WAS V7
V7 W/S
W/S
当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みます。
この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレ
ビューを受けておりません。
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、この資料の内容は2008年
10月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変
わる可能性があるのでご注意下さい。
今後国内で提供されるリリース情報は、対応する発表レターなどでご確認くださ
い。
WebSphere Application Server V7
Announcement Workshop 2008
#2
© IBM Corporation.
2
Agenda
WAS
WAS V7
V7 W/S
W/S
WebサービスにおけるQoS
高信頼性Webサービス～WS-ReliableMessaging～
会話型Webサービス・セキュリティ～WS-SecureConversation～
Webサービス・ポリシー
(参考)Webサービス・トランザクション
WebSphere Application Server V7
Announcement Workshop 2008
#3
© IBM Corporation.
3
WebサービスにおけるQoS
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
#4
© IBM Corporation.
4
QoSとは
WAS
WAS V7
V7 W/S
W/S
サービスの性能、品質
一般的に非機能要件に属する
非機能要件
機能要件/業務要件
アプリケーション
要件
性能・品質要件
データ要件
9パフォーマンス
9信頼性
9セキュリティー
9運用管理
制約
9予算
9スケジュール
9スキル
9配置場所/環境
9既存システム
9準拠する標準/規約
QoSを支えるWebサービス標準仕様
QoSを支えるWebサービス標準仕様
信頼性
セキュリティ
運用管理
トランザクション
WS-ReliableMessaging….
WS-Security,WS-SecureConversation…
WS-Policy…
WS-AtomicTransaction,WS-BusinessActivity…
WebSphere Application Server V7
Announcement Workshop 2008
#5
© IBM Corporation.
WebサービスにおけるQoSの在り方について説明します。
QoSは一般的に非機能要件に属します、システムやサービスが提供すべき性能と品質のことを指します。具体的
にはパフォーマンス、信頼性、セキュリティー及び運用管理などが挙げられます。
Webサービスは実装言語や環境に依存しないという特徴から、QoSを実現するための技術を標準仕様で提供し
ています。OASISやW3Cなどの標準化団体が策定しています。
5
Webサービス仕様群
WAS
WAS V7
V7 W/S
W/S
Webサービスに関連する仕様
Service
Composition
Quality of
Service
(QoS)
Description
WS-Reliable Messaging
WS-Security
Messaging
XML
Transports
HTTP/HTTPS
WSDL
SOAP
WS-Transaction
WS-Resource Lifetime
WS-Resource Properties
XSD
WS-BPEL
WS-Notification
WS-Service Group
WS-Base Faults
WS-Policy WS-Metadata Exchange
WS-Addressing
SMTP
WASv6.1 FeaturePack for WebServices NEW
WS-Renewable References
RMI / IIOP
JMS
WAS V7 NEW
グレー文字：WAS未サポート
WebSphere Application Server V7
Announcement Workshop 2008
#6
© IBM Corporation.
現在標準化団体や営利企業グループによって策定作業が進められているWeb サービス関連
仕様の一部をレイヤー化して示します。青印のものはWAS V6.1 FeaturePack for
WebServicesで新たにサポートされた仕様、赤印のものは更に、WAS V7で新たにサポートさ
れた仕様を示しています。
グレー文字の仕様はWASではまだサポートされていない仕様です。
6
WAS V7におけるWS-I プロファイル構成
WS-Trust 1.3
WS-I Reliable Secure Profile 1.0
WAS
WAS V7
V7 W/S
W/S
WS-ReliableMessaging 1.1
WS-SecureConversation 1.3
WS-I Basic Profile 2.0 SOAP1.2
WS-I Basic Profile 1.2
WS-Addressing
WS-I Basic Security Profile 1.0/1.1
Kerberos Token Profile
WS-Security 1.0/1.1
MTOM
WS-I Attachment Profile
New
v7
Username Token Profile
X.509 Token Profile
WS-I Basic Profile 1.0/1.1
SAML Token Profile
REL Token Profile
WS-I Simple SOAP Profile
WS-I ReliableSecureProfile(RSP) 1.0
Webサービスの信頼性とセキュリティに関する相互運用のためのプロファイル
IBMがGM社,Ford社,Daimler Chrysler社と共に作成したB2B要件のプロファイル
2006年4月 WS-Iから正式採用を承認
2008年5月 Working Group Draft
Webサービス 非同期通信の標準技術
WebSphere Application Server V7
Announcement Workshop 2008
#7
© IBM Corporation.
WAS V7がサポートするWS-Iプロファイルの構成を説明します。
WS-IはWebサービス関連の各種標準を策定しているW3CやOASISと連携しながら活動しています。それ以外
の団体とも協調しながら業界の標準となるものを作成しています。WS-Iの活動のメインは、”プロファイル”と呼ば
れるインターオペラビリティに関するガイドを作成することです。プロファイルとはインターオペラビリティの実現に
必要な仕様を選択し組み合わせて、矛盾、曖昧性が無いようにガイドしたものです。WS-Iでは、新しく仕様を作
成することはありません。あくまでも既に存在する複数の標準を対象としてインターオペラビリティを保つにはどの
ようにしたらよいかをプロファイルとして文書化して公開しています。一般的な標準化団体では、技術仕様を発表
してから投票採用が実施されますが、WS-Iはまず、企業顧客やソフトウェアベンダーがプロファイルを発表してか
ら投票採用が行われます。
・WS-I Reliable Secure Profile (RAMP)
RAMPはIBMがGM社、Ford社、Daimler Chrysler社とともに作成したB2B要件のプロファイルで2006年4月に
WS-Iから正式採用が承認されました。Webサービスの非同期通信の標準技術です。RAMPはWS-I
BasicProfileおよびWS-I Basic Security Profileの上に、WS-Addressing、WS-ReliableMessaging(WS-RM)、
WS-SecureConversation(WS-SC)の３つの仕様を追加したものになります。
WS-SC V1.3でWS-RM V1.1を使用するよう更新され策定されたのがWS-I RSP(Reliable Secure Profile)です。
RSP1.0はWS-I BasicProfile1.2および2.0、WS-I BasicSecurityProfile1.0および1.1にWS-RM1.1、WSSC1.3の仕様を追加したものになります。
・WS-I BasicProfile
WS-I Basic Profile1.2はWS-Addressingに加えてSOAP
MTOM(MessageTransmissionOptimizationMechanism)およびXOP(XML-binary Optimized Packaging)も
対象となっています。MTOMとXOPは添付ファイルに関して規定しています。
SOAP1.2を対象としているのがWS-I BasicProfile2.0になります。
7
WS-I RSPの信頼性
WAS
WAS V7
V7 W/S
W/S
登場の背景
インターネットを利用したB2Bにおける高信頼性の必要性
WS-I RSPが求める信頼性
メッセージ配信保証
ネットワークの信頼性は各社で異なる
回線速度が速いとは限らない
重複排除
WS-ReliableMessaging
課金処理では必須
順序性
WS-SecureConversation
セキュリティ
インターネット
C社システム
A社システム
D社システム
WebSphere Application Server V7
Announcement Workshop 2008
#8
© IBM Corporation.
WS-I RSPの登場背景には「インターネットを利用したB2Bにおける高信頼性の必要性」があり
ます。
信頼性としては以下の内容が挙げられます。
・メッセージ配信保証：複数の会社を相手としたB2Bの場合、ネットワークの信頼性は各社で異
なり回線速度が速いとは限りません。メッセージが確実に配信されたことを保証する必要があり
ます。
・重複排除：処理内容が課金処理であった場合、問題発生時の単純な再試行による2重更新
処理というのは避けなければなりません。
・順序性：処理内容によっては順序性が必要なケースがあります。
・セキュリティ：Webサービス通信をセキュアに実行する必要があります。
これらの信頼性を満たすための仕様として登場したのが"WS-ReliableMessaging"と"WSSecureConversation"です。各仕様に対してインターオペラビリティ（相互運用性）の観点から
制約を設け規定したプロファイルがWS-I RSPになります。
8
高信頼性Webサービス
～WS-ReliableMessaging～
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
#9
© IBM Corporation.
Webサービス通信の信頼性を高める「WS-ReliableMessaging(WS-RM)」について説明しま
す。
9
WS-RM登場の背景
WAS
WAS V7
V7 W/S
W/S
既存技術で信頼性を確保する際の問題点
SOAP/HTTP
SOAP/HTTP
Webサービス・
リクエスター
Webサービス・
プロバイダー update
システムＡ
システムＢ
エラー発生時・・・
• リクエスター側に再試行の仕組みが必要
• プロバイダー側に2重更新を防ぐ仕組みが必要
開発コスト高
SOAP/JMS
1UOW
Webサービス・
プロバイダー update
Webサービス・
リクエスター
SOAP/JMSを使用したい・・
• SOAP/JMSのサポート（インターオペラビリティなし）
• MOM製品(WMQなど)の統一
SOAP/JMS
共通ソフトウェア使用の制約
システムＡ
システムＢ
メッセージ転送は
MOM製品が保証
メッセージの処理をグローバルトランザクション
で実施すればメッセージロス、2重更新はない
WebSphere Application Server V7
Announcement Workshop 2008
# 10
© IBM Corporation.
WS-RM登場の背景として、既存技術で信頼性を確保しようとした場合の問題点について触れ
てみます。
まずは、SOAP/HTTPの場合です。Webサービス・プロバイダーではデータベースなどのリ
ソース更新処理を実行していて2重更新は防ぐ必要があるとします。このようなケースで、Web
サービス・リクエスターがエラーを受け取った場合、リクエスター側には再試行の仕組みが必要
になります。しかしながら、エラーの発生したタイミングがリソース更新前なのか後なのかはエ
ラー内容からだけでは判断できません。2重更新を防ぐための仕組みが必要になり、最終的に
は開発コストが高くなるという問題を抱えることになります。
SOAP/JMSの場合、メッセージ転送はMOM(Message Oriented Middleware)製品によって
保証されます。また、プロバイダー側でメッセージのGETとリソース更新処理をグローバル・トラ
ンザクション・スコープ内で実行すればメッセージ・ロスや2重更新を防ぐことができます。しかし
ながら、MOM製品を使用するという時点でMOM製品を統一しなければならないという制約が
でてきます。また、SOAP/JMSはインターオペラビリティが保証されていないというデメリットが
あります。
各々のケースにおいて、再試行の仕組み、2重更新を防ぐ対策、インターオペラビリティという
観点での問題を抱えており、これらの問題を解決すべく登場したのがWS-RMです。
10
WS-RM(Web Services Reliable Messaging)とは
WAS
WAS V7
V7 W/S
W/S
Webサービスで信頼性の高いメッセージ送受信を行うための仕組み
SOAP/HTTPをベースとした高信頼性を実現するためのプロトコルを規定
RM SourceとRM Destinationが確実なSOAP/HTTPのメッセージ配信を行う
アプリケーションで再試行処理のコーディングは必要なし
受信済みのメッセージはRM Destinationが削除
メッセージはRM SoueceとRM Destinationで保管される
WS-I RSPによるインターオペラビリティの確保
server1
server2
Webサービス・
リクエスター・アプリ
Webサービス・
プロバイダー・アプリ
WS.invoke()
invoke()
メッセージ送信を委譲
ＣｒｅａｔｅSequence
ＣｒｅａｔｅSequenceResponse
RM Source
メッセージ送信
Sequence
SequenceAcknowledgement
RM Destinationから
メッセージを受信
RM Destination
メッセージ受信
WS-RMプロトコルによるメッセージ配信保証
WebSphere Application Server V7
Announcement Workshop 2008
# 11
© IBM Corporation.
Web Services Reliable Messaging(WS-RM)はWebサービスで信頼性の高いメッセージ送
受信を行うための仕組みを規定したOASISの標準仕様です。
2005年2月にV1.0、2007年6月にV1.1がリリースされ、WAS V7ではV1.0/1.1の両方をサポー
トしています。
○OASIS Web Services Reliable Messaging http://docs.oasis-open.org/wsrx/wsrm/v1.1/wsrm.html
WS-RMではSOAP/HTTPをベースとした高信頼性を実現するためのプロトコルを規定してい
ます。
基本的な仕組みとして、Webサービス・リクエスター・アプリケーションがWebサービス呼び出し
を実行すると、RM Sourceがメッセージ送信を委譲します。メッセージ受信についても同様で、
アプリケーションの代わりにRM Destinationがメッセージを受信し、Webサービス・プロバイ
ダー・アプリケーションのメッセージを渡します。
WS-RMプロトコルの規定に従った信頼性の高いメッセージ配信はRM SourceとRM
Destinationの間で行われます。
Webサービス・アプリケーションでは、例外発生時の再試行処理のコーディングは必要なく、ま
た、一度受信されたメッセージはRM Destinationが削除するので2重更新の心配はありません。
また、メッセージはRM SourceとRM Destinationの両方で保管されるため、設定によりますが、
障害時のメッセージ・ロスもありません。
WS-I RSP(Reliable Secure Profile)によってインターオペラビリティも確保されています。
11
WS-RMの基本動作
－非同期型片方向－
WAS
WAS V7
V7 W/S
W/S
リクエストに対して、WS-RMのメッセージで送達確認(Ack)が返される
送達確認が返されないリクエストは自動で再送信
重複メッセージはRM Destinationで削除
プロバイダー
(RM Destination)
リクエスター
(RM Source)
リクエスト1
リクエスト1の送達確認
リクエスト2
障害
リクエスト2
リクエスト2
リクエスト2の送達確認
×
削除
RM Sourceによるリクエスト送信
はアプリケーションとは別スレッド
WebSphere
Application Server V7
Announcement Workshop 2008
# 12
© IBM Corporation.
WS-RMの基本動作について、非同期型片方向を例に説明します。
[リクエスト１]Webサービス・リクエスターがWebサービス呼び出しを実行すると、アプリケーショ
ンが実行されているスレッドとは別スレッドでRM Sourceがリクエスト送信を行います。WS-RM
のプロトコルでは、リクエストに対して送達確認(Ack)が返ってくると正常に処理が完了したこと
になります。
[リクエスト２]リクエストの送信中にネットワーク障害などが発生し、リクエストがRM Destination
に届かないとします。RM Sourceは一定の間隔で送達確認が返されないリクエストを自動的に
再送信します。
リクエスト２をRM Destinationが受信し、送達確認をRM Sourceが受け取る前に、RM Source
がリクエスト２の再送信を実行したとします。RM Destinationはリクエスト２を既に受信し、Web
サービス・プロバイダーに渡したことを記録しているので、重複メッセージとなるリクエスト２は削
除します。
12
WS-RMの基本動作
－同期型、非同期型双方向－
WAS
WAS V7
V7 W/S
W/S
リクエストとレスポンスの両方に対して、送達確認(Ack)が返される
送達確認が返されないリクエストとレスポンスは再送信
重複メッセージは削除
障害時
正常時
リクエスター
(RM Source)
プロバイダー
リクエスター
(RM Destination)
(RM Source)
プロバイダー
(RM Destination)
リクエスト1
リクエスト1
リクエスト1の送達確認
リクエスト1
障害
リクエスト1の送達確認
レスポンス1
レスポンス1
レスポンス1の送達確認
障害
レスポンス1
レスポンス1の送達確認
WebSphere Application Server V7
Announcement Workshop 2008
# 13
© IBM Corporation.
同期型、非同期型双方向のWebサービス呼び出しのケースを説明します。
前ページの非同期型片方向を組み合わせた形でリクエストとレスポンスの両方に対して送達
確認(Ack)が返されます。非同期型片方向と同様に、送達確認が返されないリクエストとレスポ
ンスは再送信され、重複メッセージは削除されます。
13
メッセージは「シーケンス」の概念の元で送受信される WAS
WAS V7
V7 W/S
W/S
シーケンス：特定のRMSourceとRMDestination間で送受信されるメッセージ集合
特定のWebサービスで送受信されるメッセージ集合
シーケンス確立でRMSourceとRMDestinationのエンドポイントURLの組を情報として持つ
シーケンス確立後にメッセージ送信を行う
リクエスター
（RM Source）
プロバイダー
（RM Destination）
CreateSequence
①シーケンスの確立
①シーケンスの確立
CreateSequenceResponse(Identifier=seq1)
リクエスト1(Identifier=seq1,Message#=1)
リクエスト1送達確認(Identifier=seq1,Message#=1 )
②メッセージの送信
②メッセージの送信
SOAPヘッダーにSequence情報を含む
SOAPヘッダーにSequence情報を含む
リクエスト2(Identifier=seq1,Message#=2)
リクエスト2送達確認(Identifier=seq1,Message#=1~2 )
：
TerminateSequence(Identifier=seq1)
③シーケンスの終了
③シーケンスの終了
TerminateSequenceResponse(Identifier=seq1)
WebSphere Application Server V7
Announcement Workshop 2008
# 14
© IBM Corporation.
WS-RMのメッセージは「シーケンス」という概念の元で送受信されています。
「シーケンス」とは特定のRM SourceとRM Destinationの間で送受信されるメッセージ集合、
つまり、特定のWebサービスで送受信されるメッセージ集合と言えます。
WS-RMの仕様では、このシーケンスを明示的に区切り、シーケンス内で送受信されるメッセー
ジ集合について確実な配信を行います。WASの実装では、デフォルトでアプリケーション起動
後の最初のリクエスト実行時にシーケンス確立の処理が行われます。明示的にシーケンスを区
切るにはアプリケーションでのコーディングが必要になります。コーディング方法の詳細につい
ては、以下リンクのInfoCenterをご参照ください。
○WAS V7 InfoCenter 「Controlling WS-ReliableMessaging sequences
programmatically」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/i
nfo/ae/ae/twbs_wsrm_prog_seq.html
WS-RMのプロトコルでは最初にシーケンスの確立を行い、RM SourceとRM Destinationの
互いのエンドポイントURLの組を情報として保持します。この時にシーケンスIDが発行されます。
確立されたシーケンスの元で、Webサービス呼び出しがRM SourceとRM Destinationの間で
行われます。同一のWebサービス呼び出しについては、同じシーケンスの元で異なるメッセー
ジIDが割り当てられることになります。すべてのリクエストにシーケンスIDとメッセージIDが付与
され、管理されます。障害発生時にもシーケンスIDによって宛先にエンドポイントURLを認識し、
メッセージIDによって配信に失敗したリクエストを判断し、リクエストの再送信を実行することが
できます。
14
(参考)シーケンスの確立
WAS
WAS V7
V7 W/S
W/S
CreateSequenceメッセージ（新規シーケンス作成要求）
<soapenv:Envelope ><soapenv:Header>
<wsa:To>http://abcd.makuhari.japan.ibm.com/HelloWSRMSrvWeb/HelloWSRMService</wsa:To>
</soapenv:Header>
<soapenv:Body>
RM Destination側
<wsrm:CreateSequence xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">
エンドポイントURL
<wsrm:AcksTo>
<wsa:Address>http://efgh.makuhari.japan.ibm.com/HelloWSRMSrvWeb/HelloWSRM</wsa:Address>
</wsrm:AcksTo>
</wsrm:CreateSequence>
RM Source側
</soapenv:Body></soapenv:Envelope>
エンドポイントURL
CreateSequenceResponseメッセージ（シーケンス作成応答）
<soapenv:Envelope><soapenv:Header>
<wsa:To>http://efgh.makuhari.japan.ibm.com/HelloWSRMSrvWeb/HelloWSRM</wsa:To>
</soapenv:Header>
<soapenv:Body>
<wsrm:CreateSequenceResponse xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">
<wsrm:Identifier>urn:uuid:BB591B19CEBBA392711187699405920</wsrm:Identifier>
</wsrm:CreateSequenceResponse>
</soapenv:Body></soapenv:Envelope>
シーケンスID
シーケンスIDとRM
シーケンスIDとRM Source/RM
Source/RM DestinationのエンドポイントURLが紐付けられる
DestinationのエンドポイントURLが紐付けられる
WebSphere Application Server V7
Announcement Workshop 2008
# 15
© IBM Corporation.
参考情報としてシーケンス確立時の送受信されるCreateSequenceメッセージと
CreateSequenceResponseメッセージをご紹介します。
SOAPヘッダーにWS-RMのプロトコルが含まれていることがわかります。
CreateSequenceResponseメッセージではシーケンスIDが付与されていることがわかります。
15
(参考)WS-Addressing
WAS
WAS V7
V7 W/S
W/S
W3Cの仕様、Webサービスのアドレス情報を記述するための標準
二つの概念を定義
End Point References(EPRs)
エンドポイントの場所を特定するためのURI（必須）+参照プロパティ＋参照パラメーター
<wsrm:AcksTo>
<wsa:Address>http://abcd.makuhari.japan.ibm……..</wsa:Address>
</wsrm:AcksTo>
Message Information ヘッダー
==<wsrm:AcksTo>
メッセージを転送するための情報
Toヘッダー
<wsa:To>http://host/…..</wsa:To>
エンドポイントのURI
ReplyToヘッダー
<wsa:ReplyTo>
<wsa:Address>http://host/…</wsa:Address>
</wsa:ReplyTo>
応答メッセージが送信されるべきＥＰ
Ｒ（エンドポイントURI）
MessageID
<wsa:MessageID>uuid:0123555</wsa:MessageID>
メッセージを一意に識別するためのURI
Action
<wsa:Action>http://host/……</wsa:Action>
メッセージの意図を特定するための情報
RelatesTo
<wsa:RelatesTo>uuid:0123555</wsaRelatesTo>
先に交換されているメッセージのMessageId
を含み、そのメッセージとの関連を示す
トランスポート・レベルに依存することなくメッセージを伝搬
トランスポート・レベルに依存することなくメッセージを伝搬
WebSphere
Application Server V7
Announcement Workshop 2008
# 16
© IBM Corporation.
参考情報として、WS-Addressingの情報をご紹介します。
WS-Addressingは、それ自体単独で使用されることは稀ですが、WS-RMやWS-Transaction
などの他のWebサービス技術の中で暗黙的に使用されることの多い技術です。
Webサービスのアドレス情報を記述するためのW3Cの標準仕様で、HTTPヘッダーの情報と
は別にSOAPヘッダーにアドレス情報を含ませる場合に使用されます。
16
MessagingEngine(ME)を使用したメッセージの永続化
WAS
WAS V7
V7 W/S
W/S
WASではメッセージをメモリー、またはMessagingEngine(ME)に保管
別JVM上で稼動するMEを使用することでメッセージの永続化を実現
server1
server2
Webサービス・
リクエスター
Webサービス・
プロバイダー
WS.invoke()
QoS
invoke()
メッセージ送信を委譲
RM Source
メモリー
メッセージ送信
ＣｒｅａｔｅSequence
ＣｒｅａｔｅSequenceResponse
Sequence
SequenceAcknowledgement
RM Destinationから
メッセージを受信
RM Destination
メッセージ受信
QoS
メモリー
WS-RMプロトコルによるメッセージ配信保証
1.
2.
3.
4.
5.
アプリケーションからRM Sourceにメッセージ送信を委譲
RM Sourceはメッセージを保管してから、制御をアプリケーションに戻す
RM SourceはメッセージをRM Destinationに送信
RM Destinationはメッセージを受信すると、保管してから送達確認を送信
RM Destinationはアプリケーションにメッセージを送信
WebSphere Application Server V7
Announcement Workshop 2008
# 17
© IBM Corporation.
WS-RMを使用する上で、WASではWebサービスのSOAPメッセージをローカルのメモリー上、
もしくは別JVMで稼動するMessaging Engine(ME)に保持することができます。ME上にメッ
セージを保管することで、アプリケーション・サーバーの障害時にもメッセージを失うことなく永
続化が可能です。
処理の遷移は以下になります。
１．Webサービス・リクエスター・アプリケーションでWebサービス呼び出しが実行されると、メッ
セージ送信はRM Sourceに委譲されます。
２．RM SourceはSOAPメッセージをメモリー、もしくはMEに保管してから、制御をアプリケー
ションに戻します。
３．RM SourceはSOAPメッセージをRM Destinationに送信します。
（この間はWS-RMプロトコルによるメッセージのやりとりが行われます）
４．RM DestinationはSOAPメッセージを受信すると、メモリー、もしくはMEに保管してから送
達確認を送信します。
５．RM DestinationはWebサービス・プロバイダー・アプリケーションにメッセージを送信します。
17
WS-RMのQoSの設定
WAS
WAS V7
V7 W/S
W/S
WASでは3つのレベルのQoSを提供
QoSの内容
①メッセージ、シーケンス情報の保管方法
②トランザクション・サポートの有無
非管理非パーシスタント
ローカル・メモリー上に情報を保持
トランザクション・サポート無し
サーバー障害時にメッセージ情報を失う
管理非パーシスタント
MEに情報を保持、情報を非同期にデータストアに保管
トランザクション・サポート有り
ME障害時にはメッセージ情報を失う
ME自体はJVM
上で稼動
管理パーシスタント
MEに情報を保持、情報を同期的にデータストアに保管
トランザクション・サポート有り
ME障害時にもメッセージ情報を失わない
DB
メッセージ永続化のためにデータス
トアとしてDBかファイルを指定
WebSphere Application Server V7
Announcement Workshop 2008
# 18
© IBM Corporation.
WASでは、WS-RMのQoS設定として３つのレベルを設けています。
QoSで設定する内容は、①WS-RMのメッセージやシーケンス情報の保管方法と②トランザクション・サポートの有
無の2点です。
・非管理非パーシスタント
メッセージやシーケンス情報はJVMのメモリー上に保持するため、サーバー障害(JVM障害)時に情報を失い、
メッセージのロスに繋がります。また、トランザクションをサポートしていません。
・管理非パーシスタント
メッセージやシーケンス情報をMEに保管し、MEのデータストアに対して非同期に永続化を実施します。サー
バー障害時には情報を失いませんが、ME障害時に情報を失う可能性があります。（ME障害時にデータストアへ
保管されていない情報を失います）トランザクションをサポートしています。
・管理パーシスタント
メッセージやシーケンス情報をMEに保管し、MEのデータストアに対して同期的に永続化を実施します。サー
バー障害時、ME障害時の両方で情報を失うことはありません。トランザクションをサポートしています。
※以下、用語の使い方をまとめています。
非管理：メモリー上に情報を保持。トランザクション・サポート無し
管理：MEに情報を保持。トランザクション・サポート有り
非パーシスタント：サーバー障害、もしくはME障害時に情報を失う可能性があります。
パーシスタント：サーバー障害、ME障害時、共に情報を失うことはありません。
18
（参考）管理非パーシスタントと管理パーシスタントの違い
WAS
WAS V7
V7 W/S
W/S
MEの「メッセージの信頼性」が異なる
管理非パーシスタント：「高信頼性非パーシスタント」
MEはアプリケーションからメッセージの送信／受信要求を受け取ると、メッセージをキャッ
シュ・バッファに書き込んだ時点で、アプリケーションに制御を戻します。メッセージがある
程度、キャッシュ・バッファに滞留した場合のみ書き込みます。
キャッシュ・バッファのサイズ指定可能です。
管理パーシスタント：「保障パーシスタント」（最も信頼性が高くメッセージのロス
はなし）
MEはアプリケーションからメッセージの送信／受信要求を受け付けると、同期的にメッセージ
をデータ・ストアに挿入／削除します。書き込みがうまくいったことを確認してから、アプリ
ケーションに制御を戻します。
共にMEの高可用性は別途考慮が必要
WebSphere Application Server V7
Announcement Workshop 2008
# 19
© IBM Corporation.
管理非パーシスタントと管理パーシスタントの違いを説明します。
共にメッセージやシーケンス情報をMEに保管するという点は同じですが、MEに設定する「メッ
セージの信頼性」のレベルが異なります。
管理非パーシスタントの信頼性は「高信頼性非パーシスタント」でMEのJVM上にある一定の
メッセージが滞留した段階でデータストアにメッセージが保管されます。
管理パーシスタントの信頼性は「保障パーシスタント」でMEはメッセージの送受信と同期的に
データストアに情報を挿入/削除します。データストアへの書き込みが成功してからアプリケー
ションに制御を戻すため、データストアへの情報保管は確実に実行されます。
共にMEを使用する構成となるため、MEの高可用性については別途考慮が必要です。
19
トポロジー構成
WAS
WAS V7
V7 W/S
W/S
非管理非パーシスタント
シングルサーバー構成が対象
クラスター構成のサービスに適用するとアプリケー
ションが始動しない
アプリケーション・サーバー障害時に情報を損失
Webサービス・
リクエスター
RM
Source
Webサービス・
プロバイダー
RM
Destination
メモリー
server1
メッセージのロス
管理非パーシスタント/管理パーシスタント
シーケンス情報を別JVM上のMEで共用
クラスター構成が可能
全クラスターメンバーがMEからシーケンス情報を取得
サーバー障害時に情報を損失しない
Webサービス・
プロバイダー
他のクラスター・メンバーが処理を実施
Webサービス・
リクエスター
WAS
Proxyサーバー
RM
Source
RM
Destination
server1
Webサービス・
プロバイダー
ME
RM
Destination
server2
Cluster
WebSphere Application Server V7
Announcement Workshop 2008
# 20
© IBM Corporation.
WS-RMを使用した場合のトポロジー構成について説明します。
WS-RMのトポロジー構成はQoS設定によって画面に示すように異なります。
・非管理非パーシスタント
シーケンスやメッセージの情報をメモリー上に保管する非管理非パーシスタントは、シングル
サーバー構成を対象としており、クラスター構成を組むことができません。アプリケーション・
サーバー障害時には情報を損失するので、メッセージのロスにも繋がります。最もシンプルな
構成でネットワーク障害時のみに対応可能です。
・管理非パーシスタント/管理パーシスタント
クラスター構成が可能で、シーケンスやメッセージ情報をMEで共用します。サーバー障害時
にもMEに保管された情報によって他のクラスター・メンバーが処理を続行します。
クラスター構成を組む場合、WS-RMプロトコルのメッセージを同一のアプリケーション・サー
バー（クラスター・メンバー）に処理させるためには、Webサービス・リクエスターとWebサービ
ス・プロバイダーの間にIHSなどのWebサーバーではなくWASのプロキシー・サーバーを配置
する必要があります。同一シーケンスの情報を同じアプリケーション・サーバーに送信するア
フィニティ機能をWebサーバーは持っていないためです。
クラスター構成では、ネットワーク障害に加えてアプリケーション・サーバー障害にも対応できま
す。
20
トランザクション・サポート
＜リクエスター側＞
WAS
WAS V7
V7 W/S
W/S
管理パーシスタント/管理非パーシスタントが対象
リクエスター側
非同期型片方向のみトランザクション処理が可能（双方向はサポートされない）
MEへのメッセージのPUTがトランザクションスコープに含まれる
MEへのメッセージPUTが成功した段階でアプリケーションに制御が戻る
server1
1UOW
RequesterApp
server2
ut.begin()
ProviderApp
update
DB
invoke()
ut.commit()
RM Source
Webサービス・リクエスター
トランザクションのコ
ミットのタイミングで
メッセージを送信
RM
Destination
Webサービス・プロバイダー
設定方法
リクエスター側のコーディングでenableTransactionOnewayプロパティを"true"にセットする
Map<String, Object> rc = ((BindingProvider) port).getRequestContext();
rc.put(com.ibm.websphere.webservices.Constants.ENABLE_TRAN_ONEWAY,new Boolean(true));
WebSphere Application Server V7
Announcement Workshop 2008
# 21
© IBM Corporation.
WS-RMを使用した場合のトランザクション・サポートについて説明します。
まず、Webサービス・リクエスター側のトランザクション処理ですが、Webサービス呼び出しが
非同期型片方向の場合のみサポートされています。双方向型の場合、応答メッセージの受信
までをトランザクション処理に含めることはできませんのでサポートされていません。WS-RMの
処理をトランザクショナルに実行したい場合、MEへのメッセージのPUT処理をトランザクショ
ン・スコープに含めることが可能です。トランザクションのコミット処理が完了したタイミングでメッ
セージの送信が実行されます。例えば、リクエスター側のアプリケーション処理にデータベース
更新処理などが含まれている場合、データベース更新処理をMEへのメッセージのPUTを同
一トランザクションの処理として実行することができます。MEのPUT処理に失敗した時に、
データベース更新処理をロールバックすることが可能です。
・設定内容は以下の2点です。
アプリケーション内でトランザクションの開始(begin)・終了(commit)処理を実行します。
Webサービス・リクエスターのenableTransactionOnewayプロパティを"true"にセットします。
21
トランザクション・サポート
＜プロバイダー側＞
WAS
WAS V7
V7 W/S
W/S
管理パーシスタント/管理非パーシスタントが対象
プロバイダー側
非同期型片方向と双方向でトランザクション処理が可能
RM Destinationからアプリケーションへのメッセージのディスパッチがトランザク
ションスコープに含まれる
双方向ではトランザクションがコミットされてから応答メッセージが送信されます
1UOW
server1
RequesterApp
server2
ProviderApp
DB
RM Source
Webサービス・リクエスター
RM
Destination
Webサービス・プロバイダー
設定方法
WS-RMポリシーで「送信順にメッセージを配信」にチェックする
*順序性を保つために、キューにメッセージが保留されるとパフォーマンスのオーバーヘッドとなる
WebSphere Application Server V7
Announcement Workshop 2008
# 22
© IBM Corporation.
Webサービス・プロバイダー側のトランザクション処理について説明します。
プロバイダー側では非同期型片方向と双方向の両方でトランザクション処理が可能です。
RM Destinationからアプリケーションへのメッセージのディスパッチがトランザクション・スコー
プに含まれます。
双方向（同期型）の処理ではトランザクションがコミットされてから応答メッセージが送信されま
す。
・設定方法
WS-RMポリシーの設定で「送信順にメッセージを配信」にチェックをつけます。
（もしくはwsadminツールでinOrderDeliveryをtrueに設定します）
順序性を保つために、キューのメッセージが保留されるのでパフォーマンスのオーバーヘッド
となることに注意してください。
22
（参考）その他考慮点
WAS
WAS V7
V7 W/S
W/S
順序性
WS-RMポリシーで「送信順にメッセージを配信」にチェックをつける
WS-ATとの関係
QoSでMEを使用する場合WS-ATは使用できない
MEを使用しない非管理対象ではWS-ATを使用可能
WS-ATのトランザクション・スコープ
1UOW
ut.begin()
update
update
DB
invoke()
DB
ut.commit()
×
WS-AT&WS-RMプロトコル
メモリー
RM Source
Webサービス・リクエスター
RM
Destination
×
メモリー
Webサービス・プロバイダー
WebSphere Application Server V7
Announcement Workshop 2008
# 23
© IBM Corporation.
その他の考慮点として以下の2点を説明します。
・順序性
WS-RMでRM Sourceが処理した順番通りにRM Destinationに処理を実行させたい場合に
使用します。
・WS-ATとの関係
QoS設定でMEを使用する場合(管理パーシスタント/管理非パーシスタント)は、WS-ATを併用
することはできません。
WS-ATを使用するというのは画面の絵に示すように、Webサービス・リクエスターからWeb
サービス・プロバイダーまでの全ての処理をトランザクション・スコープに含めるということになり
ます。
MEを使用しない非管理非パーシスタントの構成(シングルサーバー構成になります)ではWSATを併用することができます。
○InfoCenter 「Providing transactional recoverable messaging through WSReliableMessaging」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/i
nfo/ae/ae/twbs_wsrm_trans.html
23
WS-RMの運用①
WAS
WAS V7
V7 W/S
W/S
管理コンソールによるシーケンスのモニタリング
RM Destinationが保持
するシーケンス情報
RM Sourceが保持する
シーケンス情報
RM Sourceからの送信でエ
ラーが発生していることを示す
WebSphere Application Server V7
Announcement Workshop 2008
# 24
© IBM Corporation.
WS-RMの運用として、WASの管理コンソールではWS-RMのシーケンス情報をモニタリング
することができます。
ナビゲーション・ツリーから[サービス]＞[高信頼性メッセージングの状態]を選択すると画面のよ
うなページが表示されます。
・メッセージストア：WS-RMで使用するMEの状態を確認します
・インバウンド・シーケンス：RM Destinationが保持するシーケンス情報を確認します
・アウトバウンド・シーケンス：RM Sourceが保持するシーケンス情報を確認します
送信が完了できていないメッセージがあると画面に示すような警告マークが表示されエラーが
発生していることを示します。
24
WS-RMの運用②
WAS
WAS V7
V7 W/S
W/S
トラブルシューティングは管理コンソールから可能
障害が回復すれば処理は正常に実施される
RM Sourceで保持する
メッセージ数
送信済み＋保持するメッ
セージ数
エラー情報
WebSphere Application Server V7
Announcement Workshop 2008
# 25
© IBM Corporation.
WS-RMの処理でエラーが発生した場合のトラブルシューティングは管理コンソールから行うこ
とができます。
例としてアウトバウンドシーケンスのページを画面に示します。
シーケンスごとに、シーケンスID、アプリケーション名、エンドポイントURL、RM Sourceで保持
している（未送信の）メッセージ数、送信済みメッセージ（送信済み＋保持するメッセージ）数、
エラー情報、状況を示します。
シーケンスIDを選択すると、保持しているメッセージのメッセージ番号とメッセージ内容を確認
することができます。エラーが発生した場合などで、保持しているメッセージの送信をキャンセ
ルする場合は、この画面で削除します。
25
（参考）WS-RMの運用③
WAS
WAS V7
V7 W/S
W/S
ZIPファイルでエクスポート（中身はテキスト形式）
新規シーケンスを作成して未送信メッセージを割り振る
WebSphere Application Server V7
Announcement Workshop 2008
# 26
© IBM Corporation.
エラーが発生している場合、未送信メッセージ（保持しているメッセージ）をZIP形式のファイル
でエクスポートすることができます。（"未送信メッセージのエクスポート"ボタン）
また、現在のシーケンスでの送信を止め、新規シーケンスを作成して未送信メッセージを割り
振るということも可能です。（"メッセージの再割り振り"ボタン）
26
会話型Webサービス・セキュリティ
～WS-SecureConversation～
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 27
© IBM Corporation.
会話型のWebサービス・セキュリティとして「WS-SecureConversation(WS-SC)」について説
明します。
まずは、Webサービス・セキュリティの説明を簡単に行い、その後にWS-SecureConversation
の説明となります。
27
Webサービスにおけるセキュリティ
WAS
WAS V7
V7 W/S
W/S
Webサービスのセキュリティを確保するためには以下の方法がある
トランスポート・レベル
SSL（HTTPS）通信とHTTPベーシック認証によるアクセス制御
データは全て暗号化
Webサービス
リクエスター
SSL通信
SSLは２地点間のみの仕組み
SOAP/HTTPのみの環境でしか利用できない
マシン間でのセキュリティ
Webサービス
アプリケーション
SOAP
SOAP
平文
平文
メッセージ・レベル
SOAPメッセージの全体または一部へのデジタル署名の付加/メッセージ自体の暗号化
Webサービス
アプリケーション
Webサービス
リクエスター
SOAP
SOAP
SOAP
平文
暗号化
平文
トランスポート層に非依存
メッセージ・レベルのセキュリティ
サービス単位のセキュリティ
SOAPメッセージをセキュアに扱うた
めの仕様としてWS-Securityが策定
WebSphere Application Server V7
Announcement Workshop 2008
# 28
© IBM Corporation.
Webサービスを使用する環境において、セキュリティを確保するためには、「トランスポート・レ
ベルのセキュリティ」と「メッセージ・レベルのセキュリティ」の２つの方法が挙げられます。
・トランスポート・レベルのセキュリティ
SSL(HTTPS)通信とHTTPベーシック認証によるアクセス制御を行う従来の方法です。SSLは
マシン間の通信データを全て暗号化し、セキュリティを確保しています。2地点間のみの仕組
みであること、SOAP/HTTPのみの環境でしか利用できないといった特徴があります。
・メッセージ・レベルのセキュリティ
SOAPメッセージの全体、または一部に対してデジタル署名の付加やメッセージの暗号化を行
います。このSOAPメッセージをセキュアに扱うための仕様として作成されたのがWS-Security
です。
Webサービスの考えをベースとしていることから、トランスポート層に依存せず、また、サービス
単位でセキュリティをかけることができます。更に、細かくメッセージ・レベルでのセキュリティも
可能です。
28
WS-Securityとは
WAS
WAS V7
V7 W/S
W/S
WS-Security
SOAPメッセージングのセキュリティ強化仕様
OASISでの仕様策定
2004年4月 v1.0リリース / 2006年2月 v1.1リリース
以下のセキュリティ要件に対応
認証(Authentication)
サービスを使用できるクライアントか？
セキュリティ・トークンによる認証
完全性(Integrity)
メッセージが不正に改ざんされていないか？
XML署名とセキュリティ・トークンの組み合わせ
複数のメッセージ要素に対して、柔軟に署名が可能
機密性(Confidentiality)
メッセージの盗聴はされていないか？
XML暗号化とセキュリティ・トークンの組み合わせ
複数のメッセージ要素に対して、柔軟に暗号化が可能
WebSphere Application Server V7
Announcement Workshop 2008
# 29
© IBM Corporation.
WS-Securityの目標は、アプリケーションがセキュアなSOAPメッセージ交換を行えるようにす
ることです。
SOAPメッセージにおける、セキュリティ・トークンの受け渡し、メッセージの完全性、およびメッ
セージの機密性の３つの主要なメカニズムを提供します。
これらのメカニズムは単独で使用することも、統合した手法で使用することもできます。（メッ
セージの署名と暗号化を行い、署名と暗号化で使用される鍵に関連付けられたセキュリティ
トークン階層を提供するなど）また、SOAP仕様のactor/role要素を使用して、複数のセキュリ
ティ・モデルを使用して別々のメッセージ要素に対して署名・暗号化をかけることや、同一の
メッセージ要素に対して署名・暗号化を同時にかけるなど柔軟な設計が可能です。
WS-Securityは明示的な固定されたセキュリティプロトコルについて記述しているわけではあり
ません。将来的なスタンダードへの対応も見据え、拡張可能な形のフレームワークとして設計
されています。
29
（参考）セキュリティ・トークン
WAS
WAS V7
V7 W/S
W/S
セキュリティ・トークンはSOAPメッセージを保護するためのものとしてWSSecurityで定義
SecurityToken : A security token represents a collection (one or more) of claims.
Claim – A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege,
290 capability, etc).
ID、鍵、役割等のclaims（申告）を含む
セキュリティ・ヘッダとしてSOAPメッセージに組み込まれる
WS-Securityでサポートするセキュリティ・トークン
UsernameToken
ユーザー名とパスワードをテキスト形式で含む
SSLとの併用が必要
署名なしセキュリティ・トークン
BinarySecurityToken
X.509証明書、Kerberos V5チケットなど
デジタル署名、暗号化で参照される鍵を含む
署名付きセキュリティ・トークン
Security Token
BinarySecurityToken
UsernameToken
X.509証明書
Kerberosチケット
第3の機関によってBinary
Security Tokenは保証されて
いる
WebSphere Application Server V7
Announcement Workshop 2008
# 30
© IBM Corporation.
セキュリティ・トークンは内部にリクエスターのIDや鍵情報、役割情報などのclaims（申告）とよ
ばれる認証の為の情報を含みます。
WS-Securityはこのセキュリティ・トークンをSOAPヘッダーに組み込む方法を定義しています。
WS-Security1.0/1.1ではサポートされるセキュリティ・トークンとして基本認証に使用される
UsernameTokenおよび任意のバイナリ・セキュリティ・トークンがサポートされます。
バイナリー・セキュリティ・トークンは証明書を含み署名が施されたトークンのため、署名付きセ
キュリティ・トークンとして分類されます。一方でUsernameTokenはユーザー名とパスワードの
みを含む単独なトークンです。そのままではネットワーク上にこれらのトークンの値が平文で流
れてしまうためSSL等と併用する必要があります。また、リプレイ攻撃への対策のため、nonce
およびタイムスタンプを使用してダイジェスト化を行うことが推奨されます。バイナリー・セキュリ
ティ・トークンが含む証明書の公開鍵をデジタル署名・暗号化に利用することができます。
30
(参考)XMLデジタル署名概要
WAS
WAS V7
V7 W/S
W/S
WS-Securityのデジタル署名はXML署名がベース
XML署名はXMLにデジタル署名を埋め込むための標準化仕様
平文からハッシュ関数を使用してメッセージダイジェストを生成
① 署名対象データを正規化した上で、ダイジェスト値を計算する
② ①のダイジェスト値を子要素としてXML署名情報要素(SignedInfo)に入れ、
さらにその署名情報要素に対して署名値を計算する
SOAP
データ
計算
送信！
ダイジェスト
Aさん
AさんのKey
ダイジェスト
比較
復号化
ダイジェスト
計算
計算
SOAP
データ
ダイジェスト
OK！
ダイジェスト
計算
ダイジェスト
AさんのKey
Bさん
ダイジェスト
復号化
比較
OK！
ダイジェスト
WebSphere Application Server V7
Announcement Workshop 2008
# 31
© IBM Corporation.
WS-Securityのデジタル署名はXML署名(http://www.w3.org/Signature/)をベースとする仕
様です。
XML署名はXMLにデジタル署名を埋め込むための仕様で、公開鍵暗号化方式をベースにし
た署名方式です。
以下の流れで署名対象のデータに対して署名を行います。
①署名対象データを正規化した上で、ダイジェスト値を計算し、署名情報要素(SignedInfo)に
格納
※XML文書では内容が同じであってもXML構文に挿入された空白文字や改行などが任意に
加わると表現が異なり、結果としてダイジェスト値が変わり、署名値が異なってしまうから。
②署名情報要素に対して正規化を行った後に、指定した署名アルゴリズムで署名値
(SignatureValue)を計算し文書内に含める。
検証時の流れは署名時の逆に
①署名情報要素(SignedInfo)内のダイジェスト値を検証
②署名情報要素に対して計算された暗号化署名値を検証
オプションとしてKeyInfo要素に署名検証のための鍵情報を含めることができます。
31
(参考)XML暗号概要
WAS
WAS V7
V7 W/S
W/S
データを暗号化しXML文書で表す標準仕様
任意のXML文書、XML要素、XML要素の内容の暗号が可能
XML暗号仕様
W3C「XML Encryption WG」
http://www.w3.org/Encryption/2001/
WS-Securityの暗号化
XML暗号に基づく
SOAPメッセージ(header, body)の全部または一部を暗号化
データの暗号化そのものは、共通鍵暗号方式を使用
共通鍵は事前に送受信者で共有、または、公開鍵で暗号化してメッセージに含めて送付
元の
データ
SOAP
SOAP
暗号化した
データ
暗号化した
データ
暗号化
復号化
元の
データ
送信！
暗号化Key情報
暗号化Key情報
Bさん
Aさん
WebSphere Application Server V7
Announcement Workshop 2008
# 32
© IBM Corporation.
WS-Securityの暗号化はXML暗号(http://www.w3.org/Encryption/2001/)をベースとする仕
様です。
XML暗号は任意のXML文書、要素、値を暗号化してXML文書で表すための仕様で、公開鍵
暗号化方式をベースにすることができます。
公開鍵暗号化方式を使用する場合、以下の流れで対象データに対して暗号化を行います。
①対象データを共通鍵で暗号化
②共通鍵をプロバイダーの公開鍵で暗号化
③リクエストメッセージに暗号化した共通鍵を含め、送信
検証時の流れは、暗号化時の逆に
①プロバイダーは秘密鍵で共通鍵を復号化
②対象データを共通鍵で復号化
共通鍵を何らかの方法で事前に渡すことが可能な場合、公開鍵を間に挟まずに共通鍵のみ
でデータの暗号化・復号化が可能です。
32
WS-Securityのインターオペラビリティ
WAS
WAS V7
V7 W/S
W/S
WS-IよりWS-Securityの相互運用に関する多数のプロファイルが策定
WS-Securityの基本動作に関するプロファイル
Basic Security Profile
WS-Securityで使用するセキュリティ・トークンに関するプロファイル
Username Token Profile/X.509 Token Profile/Kerberos Token Profile
WS-RMとWS-SC、WS-Trustに関するプロファイル
Reliable Secure Profile
WS-Trust 1.3
WS-I Reliable Secure Profile 1.0
WS-ReliableMessaging 1.1
WS-SecureConversation 1.3
WS-I Basic Security Profile 1.1 WS-Security 1.1
Kerberos Token Profile
New
v7
SAML Token Profile
REL Token Profile
WS-I Basic Security Profile 1.0
WS-I Basic Profile 1.1
WS-Security 1.0
Username Token Profile
X.509 Token Profile
WS-I Basic Profile 1.0
WebSphere Application Server V7
Announcement Workshop 2008
# 33
© IBM Corporation.
異なるベンダー実装間でWebサービスによる接続を行う際には、関連する各仕様の厳密でな
い定義部分が相互接続性に影響を与える可能性があります。WSDLやSOAP仕様において
は標準化団体WS-IのBasicProfileによって相互接続のための制約が提言されています。WSSecurityにおいては同団体によってBasicSecurityProfileが規定されています。
WS-Securityで使用されるセキュリティ・トークンについては別にプロファイルが作成されており、
Username Token Profile / X.509 Token Profile / Kerberos Token Profileがあります。
Kerberos Token ProfileのサポートはWAS V7からの新機能です。
BasicSecurityProfileではSAML Token ProfileやREL(Rights Expression Language)
Token Profileについて記述されていますが、WAS V7ではサポートされておりません。
WS-Security V1.0に関して規定されたプロファイルがBasic Security Profile V1.0、 WSSecurity V1.1に関して規定されたプロファイルがBasic Security Profile V1.1になります。
Basic Security Profile 1.1にWS-Trust V1.3/WS-SecureConversation V1.3/WSReliableMessaging V1.3を使用する上での相互接続性の観点での制約を規定したものが
Reliable Secure Profileになります。(2008/10現在 V1.0がWorkingGroupDraftのステータス
です)
33
WS-Secure Conversation/WS-Trust
WAS
WAS V7
V7 W/S
W/S
WS-SecureConversation(WS-SC)
複数のメッセージ交換に渡るセキュリティ提供方法を定義
セキュリティ・コンテキストの作成・共有
WS-Trust
セキュリティ・トークンの発行および交換方法を定義
WS-SC
WS-SC
WS-Security
WS-Security
リクエスター
WS-Trust
WS-Trust
プロバイダー
プロバイダー
リクエスター
暗号化
復号化
SO
AP
+W
S-S
ecu
rit
復号化
暗号化
暗号化
復号化
y
拡張
暗号化
復号化
メッセージレベルの保護を目的とした、
認証、署名および暗号化の方法を定義
暗号化
復号化
公開鍵暗号方式を使用した署名、暗号
化を要求/応答の度に実行
*図では例として暗号化を実施しています。
SCT作成要求
SCT作成応答
復号化
SO
AP
復号化
+W
S-S
C
SO
AP
+W
S-S
C
暗号化
暗号化
復号化
暗号化
複数のメッセージ交換に渡るセキュリティ
提供方法を定義
SCT：セキュリティ・コンテキスト・トークン
WebSphere Application Server V7
Announcement Workshop 2008
# 34
© IBM Corporation.
WS-SecurityはSOAPメッセージ交換をセキュアに行うことを目的とし、認証、署名および暗号
化の方法を定義していますが、将来的な拡張を見据えた仕様としていることから複数のメッ
セージ交換を考慮したものではありません。複数のメッセージ交換が発生すると認証、および
公開鍵暗号方式を使用した署名、暗号化が要求/応答処理の度に実行され、CPU負荷を高め
る要因になります。
WS-SecureConversation(WS-SC)では、そのような問題を解消すべくWS-Securityを拡張し
た複数メッセージ交換に渡るセキュリティ提供方法を定義しています。WS-SCがセキュリティ・
コンテキストの作成・共有方法について定義しているのに対して、WS-Trustではセキュリティ・
トークンの発行および交換方法を定義した仕様になります。別仕様として規定されていますが、
WS-SCを使用する上でWS-Trustは必須機能です。
WS-SecureConversation、WS-Trustは共にOASISで策定された標準仕様です。2007年3
月にV1.3がリリースされています。
34
WS-SCの仕組み① セキュリティ・コンテキスト・トークンの生成
WAS
WAS V7
V7 W/S
W/S
セキュリティ・コンテキスト
リクエスター、プロバイダー間の認証を確立するために使用した鍵や関連プロパティ
WS-SCの通信関係が存続している間、２者間で共有される
共通秘密鍵
セキュリティ・コンテキスト・トークンとは
セキュリティ・コンテキストを含む、セキュリティ・トークン
RSTを受けて、セキュリ
ティ・コンテキスト・トーク
ン(SCT)を作成
プロバイダー
リクエスター
RequestSecurityToken(RST)
RequestSecurityTokenResponse(RSTR)
トラスト・
サービス
SC T
WS-Security
ランタイム
SCTはメモリー
上にキャッシュ
S CT
Webサービス・
プロバイダー
WebSphere Application Server V7
Announcement Workshop 2008
# 35
© IBM Corporation.
WS-SCの仕組みの前半としてセキュリティ・コンテキスト・トークン(SCT)の生成について説明します。
セキュリティ・コンテキストとは、リクエスターとプロバイダー間の認証を確立するために使用した鍵や関連プロパ
ティを示します。WS-SCの通信関係が存続している間、２者間で共有される共通秘密鍵のようなものです。
※SOAPメッセージ内ではセキュリティ・コンテキストを<SecurityContextToken>と表します。
セキュリティ・コンテキスト。トークン(SCT)とは、セキュリティ・コンテキストを含んだセキュリティ・トークンを意味しま
す。
WS-SCは最初にSCTを生成し、リクエスターとプロバイダーの両者間で共有するところからConversationが開始
されます。WS-SCの最初の処理シーケンスを説明します。
①リクエスターからRequestSecurityTokenメッセージ（SOAPメッセージ）が送信されます。
②RSTを受けて、プロバイダーのトラスト・サービスはセキュリティ・コンテキスト・トークン(SCT)を生成します。*
③プロバイダーは生成したSCTをリクエスターに送信します。リクエスターとプロバイダーの両者間でSCTは一定
期間キャッシュされます。
WS-SCの最初に行われるSCTの受け渡し（①と③）処理はWS-Securityの公開鍵暗号方式を使用し、セキュリ
ティを確保します。
*SCTの生成はWS-Trustで規定されており、通常は第３者機関に委ねられるようです。WASの実装ではRSTを
受けたWASのランタイム上のトラスト・サービスがSCTを発行します。
WASにおけるWS-Trustのサポート状況については未サポート部分がいくつかありますので、詳細については以
下リンクのInfoCenterの記述をご参照ください。
○InfoCenter 「Web Services Secure Conversation」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/cwbs_
wssecureconv.html
35
WS-SCの仕組み② 派生鍵
WAS
WAS V7
V7 W/S
W/S
セキュリティ・コンテキスト・トークンから派生した鍵を使用してアプリケー
ション・メッセージにセキュリティをかける
WS-Trustプロトコル
(SCTの受け渡し)は
WS-Securityの公開鍵
暗号方式
リクエスター
プロバイダー
暗号化
復号化
RequestSecurityToken(RST)
RequestSecurityTokenResponse(RSTR)
復号化
トラスト・
サービス
暗号化
S CT
WS-Security
ランタイム
暗号化
復号化
暗号化
復号化
派生鍵
SO
A
+W P
S-S
C
SO
AP
+W
S-S
C
アプリケーション・メッセージはSCTから派生した
派生鍵を使用して暗号化・署名を実行
復号化
WS-Security
ランタイム
暗号化
復号化
暗号化
派生鍵
対称鍵暗号方式
によるパフォーマンスの向上
WebSphere Application Server V7
Announcement Workshop 2008
# 36
© IBM Corporation.
WS-SCの仕組みについて前ページのセキュリティ・コンテキスト・トークン(SCT)の受け渡しに
続いて説明します。
リクエスターとプロバイダーの両者間でSCTを共有し、次の段階から通常の要求/応答処理が
行われます。
WS-Securityでは公開鍵暗号方式が使用されますが、WS-SCではSCTから派生した派生鍵
を使用した対称鍵暗号方式を使用してメッセージの暗号化・署名が実行されます。公開鍵暗
号方式と比較して対称鍵暗号方式は負荷が低く、複数メッセージ交換を行うケースではパ
フォーマンスの向上が見込めます。
派生鍵のしくみについては次ページで詳細に説明しています。
36
（参考）派生鍵
WAS
WAS V7
V7 W/S
W/S
元の鍵に対してハッシュ関数でハッシュを行い派生した鍵
WS-SCではセキュリティ・コンテキスト・トークンを元に派生鍵を作成
メッセージごとに異なる派生鍵を作成
⇒鍵の堅牢性を高める
S CT
ハッシュ
Length,Nonce
WASでは以下の形式で署名と暗号化が実施される
派生鍵
WS-Addressingヘッダー、タイムスタンプ、本文には派生鍵を使用してHMACアルゴリズ
ムで署名
署名エレメント、本文には、AESアルゴリズムを使用した派生鍵で暗号化
WS-Securityヘッダーに<wsc:DerivedKeyToken>エレメントが含まれる
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsc:SecurityContextToken wsu:Id="sct_13" xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsc:Identifier>uuid:680A09B552E9898E141189654995452</wsc:Identifier>
</wsc:SecurityContextToken>
<wsc:DerivedKeyToken wsu:Id="dkt_17" xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:SecurityTokenReference>
<wsse:Reference URI="#sct_13" ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct"></wsse:Reference>
</wsse:SecurityTokenReference>
<wsc:Length>16</wsc:Length>
<wsc:Nonce>iY6Pc4emqRf3f0n+7JZxodf9JCjdPX0PorJPYgUXER2JpddtNbATZ8WPtKduiB8SHXxZpcS+Ztinn4eSHQHAkDX76x8pHuwlzHtc8Ncz0z
LDsQOaXB7IZ+HV6cB/UUV/+3tAwMmEriWuTp/TMKN7/RUS9eiuFeWJD7IR6OyfTfg=</wsc:Nonce>
</wsc:DerivedKeyToken>
LengthとNonceを使用して、メッセージごとに異なる派生鍵を使用
鍵ID
*AES(Advanced Encryption Standard):対称暗号方式
WebSphere Application Server V7
Announcement Workshop 2008
# 37
© IBM Corporation.
派生鍵とは元の鍵に対してハッシュダイジェスト関数でハッシュを行い派生した鍵です。WSSCではセキュリティ・コンテキスト・トークンを元にハッシュダイジェスト関数などを使用して派生
鍵を生成します。
ハッシュ関数にはLengthとNonceの値が使用されますが、Webサービス・プロバイダーに
LengthとNonceの情報を渡すことで、Webサービス・プロバイダー側も同じ派生鍵を生成し、
復号化することが可能になります。
また、ハッシュ関数に使用されるLengthとNonceは毎回異なる値が使用されるので、派生鍵も
メッセージごとに異なるものが使用されることで鍵の安全性が高まります。
WASでは派生鍵を使用した署名にHMACアルゴリズムを使用します。HMACはハッシュ関数
を共有秘密鍵と組み合わせて使用します。ハッシュの計算、署名の検証に共有秘密鍵を使用
するので共有秘密鍵を保持していないと検証ができません。
派生鍵を使用した暗号化にはAESアルゴリズム(対称暗号方式)が使用されます。
37
WASにおけるWS-SCのスコープ
WAS
WAS V7
V7 W/S
W/S
同一リクエスターからのサービス呼び出しは同じsecure conversationを使用
同じセキュリティ・コンテキスト・トークン(SCT)を使用
リクエスター・アプリケーションA
Secured conversation 1
S CT
instance
instance
instance
リクエスター・アプリケーションB
S CT
Service 1
S CT
instance
instance
S CT
Secured conversation 2
WebSphere Application Server V7
Announcement Workshop 2008
# 38
© IBM Corporation.
WASにおけるWS-SCのスコープ、つまり同じセキュリティ・コンテキスト・トークンが使用される
範囲について説明します。
画面の絵に示すように、同一リクエスターからの特定のサービス呼び出しは同じsecure
conversationを使用します。
詳細につきましては、以下のInfoCenterの記述をご参照ください。
○InfoCenter 「Scoping of Web Services Secure Conversation」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/i
nfo/ae/ae/cwbs_wsscscoping.html
38
WS-RMにWS-SCを使用する
WAS
WAS V7
V7 W/S
W/S
WS-RMで、シーケンス上のメッセージ送受信にWS-SCを使用可能
WS-RMシーケンスはSCTの派生鍵によって署名、暗号化
SCTにWS-RMのシーケンスをスコープとして宣言する
WS-RMをセキュアに、
低負荷で実行
＋
リクエスター
（RM Source）
プロバイダー
（RM Destination）
インターオペラビリティ
RequestSecurityToken
RequestSecurityTokenResponse
CreateSequence
CreateSequenceResponse(Identifier=seq1)
WS-I Reliable Secure Profile
の目指すところ
リクエスト1(Identifier=seq1,Message#=1)
リクエスト1送達確認(Identifier=seq1,Message#=1 )
リクエスト2(Identifier=seq1,Message#=2)
SCTの派生鍵によって
対称鍵暗号方式で
署名と暗号化
リクエスト2送達確認(Identifier=seq1,Message#=1~2 )
：
WebSphere Application Server V7
Announcement Workshop 2008
# 39
© IBM Corporation.
WS-I Reliable Secure Profile(RSP)でWS-SCとWS-RMを規定しているのは、WS-RMを使
用した際の複数メッセージ交換をセキュアに、且つ、低負荷で実行することを目的としていま
す。
WS-RMにWS-SCを使用すると、WS-RMのシーケンスにおけるメッセージ交換はセキュリ
ティ・コンテキスト・トークン(SCT)の派生鍵によって署名・暗号化されます。
39
(参考)WS-SCクライアントのキャッシュ
WAS
WAS V7
V7 W/S
W/S
リクエスターとプロバイダーの両方でセキュリティ・コンテキスト・トークンが
キャッシュされる
メモリー上にキャッシュ
クラスター環境では複製ドメインを使用して共用可能（デフォルト・オフ）
WebSphere Application Server V7
Announcement Workshop 2008
# 40
© IBM Corporation.
WS-SCではリクエスターとプロバイダーの両方でセキュリティ・コンテキスト・トークン(SCT)が
JVMのメモリー上にキャッシュされます。WASでは管理コンソールからキャッシュに関する設定
を行うことができます。
また、クラスター環境においては複製ドメインを使用することによって、クラスター・メンバー内で
SCTを複製し共用することができます。
詳細情報につきましては、以下リンクのInfoCenterの記述をご参照ください。
○InfoCenter 「Secure conversation client cache」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/i
nfo/ae/ae/cwbs_wssecureconvclientcache.html
○InfoCenter 「Enable distributed cache and session affinity when using Secure
Conversation」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/i
nfo/ae/ae/twbs_enablesecconvcluster.html
40
Webサービス・ポリシー
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 41
© IBM Corporation.
41
WS-*とポリシーの関係
WAS
WAS V7
V7 W/S
W/S
WebサービスにおけるQoSの設定をポリシー(ルール)として独立に記述
WS-*の設定をDeploymentDescripterではなく、ポリシーに設定
作成したポリシーをWebサービス・アプリケーションに関連付け
ポリシーの表記や
Webサービスに関連付ける方法
を規定したOASIS標準仕様
Web Services Policy
A社
Internet
B社
SOAP/HTTP
プロバイダー
リクエスター
Policy A
B社のサービスに接続する
ために、ポリシーAをアプリ
ケーションにアタッチしよう
WS-Security1.1を使用
X509v3証明書を使用
ポリシーAに則って
サービスに接続し
てください
WebSphere Application Server V7
Announcement Workshop 2008
# 42
© IBM Corporation.
Webサービス・ポリシーとはWebサービスにおけるQoSの設定をポリシーとして独立に記述し
たものです。従来はQoSにあたるWS-*の設定はアプリケーションの
DeploymentDescripter(デプロイメント記述子)ファイルに記述していましたが、アプリケーショ
ンとは分離し、ポリシーとして記述することになります。
QoS内容を記述したポリシーを作成し、Webサービス・アプリケーションに関連付けることで、
QoS設定を施します。
ポリシー内容の表記やWebサービスに関連付ける方法について規定したOASIS標準仕様が
Web Services Policy(WS-Policy)です。
42
Web Services Policy(WS-Policy)とは
New
v7
WAS
WAS V7
V7 W/S
W/S
Webサービスのポリシーに関するOASIS標準仕様
以下の仕様から構成される
WS-Policy Framework 1.5
Webサービスのポリシーを表現するための文法を定義
WS-Policy Attachments 1.5
ポリシーをWebサービスに関連付ける方法を定義
WS-Policy Assertions 1.5
ポリシー内容のアサーション（表明）を定義
各QoSごとにアサーションに関する仕様が作成されている
WS-SecurityPolicy1.2
WS-RM PolicyAssertion1.0/1.1
WS-MetadataExchange
メタデータを取得する方法を規定
ポリシー情報をメタデータとして取得する際に使用
WebSphere Application Server V7
Announcement Workshop 2008
# 43
© IBM Corporation.
WS-PolicyはWebサービスのポリシーに関して規定したOASISの標準仕様ですが、以下の仕
様から構成されます。
・WS-Policy Framework 1.5
・WS-Policy Attachments 1.5
・WS-Policy Assertion 1.5
PolicyAssertionについては各QoSごとに別仕様が策定されており、QoSの表記方法につい
て規定されています。
*WAS V6.1 FeaturePack for WebServicesではポリシーを採用していましたが、WS-Policy
の仕様をサポートしたものではありませんでした。WS-Policyのサポートが明確に表明された
のはWAS V7からになります。
WS-MetadataExchangeはメタデータを取得する方法を規定した仕様ですが、WS-Policyで
はWebサービス・リクエスターがWebサービス・プロバイダーのポリシー情報をメタ・データとし
て取得する際に使用します。
43
WASにおけるWS-Policyの実装
WAS
WAS V7
V7 W/S
W/S
WASではポリシー・セットとしてWS-Policyを実装
Webサービス・アプリケーション(プロバイダー/リクエスター)に対してポリシー・
セットを関連付け
JAX-WSで開発したWebサービス・アプリケーションに対応(JAX-RPCは使用不可)
用語
ポリシー・セット：ポリシーをまとめたもの
ポリシー(タイプ)：QoSを定義したもの
バインディング：ポリシー・セットに対してシステム固有の情報を定義をしたもの
Webサービス・
リクエスター・アプリケーション
①ポリシー・セットに含めるポリシーを選択
②ポリシーセットをアプリケーションに関連付け
③バインディングをセット
attach !!
Policy B
Policy D
B
D
ポリシー・セットA
B
D
バインディング・セット
WebSphere Application Server V7
Announcement Workshop 2008
# 44
© IBM Corporation.
WASではポリシー・セットとしてWS-Policyを実装しています。
Webサービス・アプリケーション(プロバイダー/リクエスター)に対して、ポリシー・セットを関連付
けます。対象となるのはJAX-WSで開発したWebサービス・アプリケーションでJAX-RPCのア
プリケーションではポリシー・セットは使用できません。
ポリシーはQoSを定義したもので、ポリシー・セットは複数（もしくは単一）のポリシーをまとめた
ものです。
バインディングはポリシー・セットに対してシステム固有の情報を定義したものになります。
44
ポリシーとポリシー・セット
WAS
WAS V7
V7 W/S
W/S
ポリシー
使用可能なポリシー（７種類)
HTTPトランスポート ,JMSトランスポート,SSLトランスポート, WS-Addressing
WS-ReliableMessaging, WS-Security, WS-Transaction
ポリシー・セット
WASでデフォルトで用意
アプリケーション・ポリシー・セット
アプリケーションに対するポリシー・セット
デフォルトで11種類のポリシー・セットが定義
Kerberos V5 HTTPS default,LTPA WSSecurity default,SSL SSL WSTransaction,Username
SecureConversation,Username WSSecurity default,WS-I RSP,WS-I RSP ND,WSAddressing
default,WSHTTPS default,WSReliableMessaging persistent
システム・ポリシー・セット
セキュリティー・トークン・サービス(トラスト・サービス)のためのポリシー・セット
デフォルトで3種類のポリシーセットが定義
SystemWSSecurityDefault,TrustServiceSecurityDefault,TrustServiceSymmetricDefault
ポリシーを組み合わせてカスタムでポリシー・セットを作成可能
WebSphere Application Server V7
Announcement Workshop 2008
# 45
© IBM Corporation.
WASで使用可能なポリシーは以下の７種類です。
HTTPトランスポート / JMSトランスポート / SSLトランスポート / WS-Addressing / WSReliableMessaging / WS-Security / WS-Transaction
ポリシー・セットはWASにデフォルトで用意されているものと、ポリシーを組み合わせて作成し
た独自のポリシー・セットの両方を使用することができます。
デフォルトで用意されているポリシー・セットはアプリケーション・ポリシー・セットとシステム・ポリ
シー・セットの2種類で、計14種類です。
デフォルトで用意されているポリシー・セットをコピーして独自にカスタマイズして新規ポリシー・
セットを作成することも可能です。
45
ポリシー・セットの使用方法①
WAS
WAS V7
V7 W/S
W/S
①
②
アプリケーション単位
サービス単位
オペレーション単位
WebSphere Application Server V7
Announcement Workshop 2008
# 46
© IBM Corporation.
ポリシー・セットの使用方法について説明します。
例として、Webサービス・リクエスターにポリシー・セットをアタッチする方法を説明します。
①ナビゲーション・ツリーから[サービス]>[サービス・クライアント]を選択し、サービス・クライアン
トがリストされた画面を表示し、対象のアプリケーションのリンクをクリックします。
②アプリケーション単位/サービス単位/オペレーション単位でポリシー・セットを関連付けること
ができるので、適宜チェックボックスにチェックを付けて、「クライアント・ポリシー・セットの関連
付け」を選択します。
どの単位でポリシー・セットの関連付けが可能かはポリシー・セットに含まれるポリシーによって
異なり、オペレーション単位で関連付けができないものも多くあります。詳細につきましては
InfoCenterでご確認ください。
46
ポリシー・セットの使用方法②
WAS
WAS V7
V7 W/S
W/S
③
WebSphere Application Server V7
Announcement Workshop 2008
# 47
© IBM Corporation.
③関連付け可能なポリシー・セット一覧がプルダウンに表示されるので、選択してポリシー・
セットを関連付けます。
※独自のポリシー・セットを使用したい場合は、事前にポリシー・セットを作成する必要がありま
す。
47
ポリシー・セットの使用方法③
WAS
WAS V7
V7 W/S
W/S
④
WebSphere Application Server V7
Announcement Workshop 2008
# 48
© IBM Corporation.
④ポリシー・セットの関連付けの後に、バインディングの割り当てを行います。「バインディング
の割り当て」ボタンを選択すると、割り当て可能なバインディング一覧が表示されるので、選択
します。独自のバインディング設定を行いたい場合は「新規アプリケーション固有バインディン
グ」を選択します。
48
(参考)HTTPトランスポート・ポリシー
WAS
WAS V7
V7 W/S
W/S
SOAP/HTTPのWebサービス・アプリケーションに対して設定可能
読み取りタイムアウト
書き込みタイムアウト
接続タイムアウト
持続接続を使用
再送有効
WebSphere Application Server V7
Announcement Workshop 2008
# 49
© IBM Corporation.
参考情報としてHTTPトランスポート・ポリシーについて説明します。
ここでの設定内容は、HTTPトランスポートでの設定内容と同一であり、通常はアプリケーショ
ン・サーバー単位で設定するものです。
HTTPトランスポート・ポリシーを使用することで、アプリケーション単位でHTTPトランスポートの
設定を行うことができます。
49
(参考)JMSトランスポート
WAS
WAS V7
V7 W/S
W/S
SOAP/JMSのWebサービス・アプリケーションに対して設定可能
要求タイムアウト
SOAP/JMSの双方向処理で使用
応答が返るまでのタイムアウト値
Webサービス・
リクエスター
1UOW
transaction.begin()
WS.invoke()
transaction.commit()
今まではアプリケーションのコーディングやDeploymentDescripterで設定
アプリケーションの変更や再デプロイすることなく変更が可能に！！
WebSphere Application Server V7
Announcement Workshop 2008
# 50
© IBM Corporation.
参考情報としてJMSトランスポート・ポリシーについて説明します。
SOAP/JMSのWebサービス・リクエスターに対して設定可能なポリシーです。
要求タイムアウトは双方向処理に、チェックボックスの設定は片方向処理に有効な設定になり
ます。
どちらの設定値も今まではアプリケーションのコーディングやDeploymentDescripterで設定し
ていたものなので、ポリシーで設定できることによって、アプリケーションの変更や再デプロイす
ることなく変更することが可能になりました。
※片方向の非同期オペレーションでトランザクション・メッセージングを許可
非同期片方向の処理において、Webサービス・リクエスターの処理とSOAP/JMSのサービス
呼び出しにおけるキューへのメッセージPUTの処理を1UOWのトランザクション処理として実
行したい場合に適用する設定です。
これを設定することによって、SOAP/JMSプロバイダー側のキューからのメッセージGET処理
とMDBのonMessage()メソッドの処理も1UOWのトランザクション処理となります。
（onMessage()メソッドのトランザクション属性はRequiredになっている必要があります。）
50
New
v7
ポリシーの伝播
WAS
WAS V7
V7 W/S
W/S
Webサービス・プロバイダーで設定されるポリシー・セットの情報をリクエスター
に伝播
サービス利用者に必要なQoS情報を伝える
リクエスターは動的にポリシー・セットがアタッチされる
ポリシー・セットの情報はプロバイダーが提供するWSDLに含めることができる
(WS-Policyで規定された標準フォーマット)
HTTP GETリクエスト(endpointURL+"?wsdl")
WS-MetadataExchangeによるGetMetadataリクエスト
A社
Internet
B社
SOAP/HTTP
リクエスター
プロバイダー
Policy A
WS-Security1.1を使用
X509v3証明書を使用
WebSphere Application Server V7
Announcement Workshop 2008
# 51
© IBM Corporation.
Weサービス・プロバイダーで設定されるポリシー・セットの情報をリクエスターに伝播することが
可能です。リクエスターはポリシー・セットを設定する必要なく、プロバイダーに設定されたポリ
シー・セットの情報が動的にリクエスターに設定されます。
プロバイダーが提供するポリシー・セットの情報はWSDLファイルに含めることができます。
WSDLファイルに含まれるポリシー・セットの情報を取得方法は以下の２つです。
・HTTP GETリクエスト：Webサービス・プロバイダーのエンドポイントURLの末尾に「?wsdl」を
追加してWebブラウザーから確認することができます。
・WS-MetadataExchangeによるGetMetadataリクエストによってWSDL情報を取得できます。
（55、56ページ参照）
51
（参考）ポリシーの伝播設定 ＜リクエスター側＞
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 52
© IBM Corporation.
参考情報としてポリシーを伝播させる設定を説明します。（リクエスター側）
ポリシー・セットを関連付ける画面にて、「適用されたポリシー」のリンク（デフォルト"なし"）を選
択します。
クライアントWS-Policy制御プロパティの画面が表示されるので、そこでポリシーを適用しない
（なし）か、もしくは「プロバイダー・ポリシーのみ」（プロバイダーのポリシーセットを使用する）を
選択します。
「プロバイダー・ポリシーのみ」を選択した場合は、ポリシーの取得方法としてHTTP GET要求
かWS-MetadataExchange要求のどちらかを選択します。WS-MetadataExchange要求を選
択した場合は、その要求に対してWS-Securityのポリシー・セットを関連付けることも可能です。
52
（参考）ポリシーの伝播設定
＜リクエスター側＞
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 53
© IBM Corporation.
既にリクエスターにポリシー・セットが関連付けられている場合、「適用されたポリシー」では「ク
ライアント・ポリシーのみ」（プロバイダーのポリシーは使用しない）か、「クライアント・ポリシーと
プロバイダー・ポリシー」のどちらかを選択します。
53
（参考）ポリシーの伝播設定
＜プロバイダー側＞
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 54
© IBM Corporation.
ポリシーを伝播させる設定を説明します。（プロバイダー側）
プロバイダー側はポリシー設定を伝播する側になりますが、「ポリシー共用」で設定をすること
になります。
ポリシー・セットの関連付けを行う画面にて「ポリシー共用」のリンク（デフォルト"使用不可"）を
選択します。
クライアントに対して許可するポリシーの取得方法を設定します。
54
(参考)WS-MetadataExchange:GetMetadataリクエスト
WAS
WAS V7
V7 W/S
W/S
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:To>http://localhost:9083/TestAppOnewayProvWeb/TestOnewayService</wsa:To>
<wsa:MessageID>urn:uuid:131DB4FAE7D29EBF3D1222865209480</wsa:MessageID>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<mex:GetMetadata xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex">
<mex:Dialect>http://schemas.xmlsoap.org/wsdl/</mex:Dialect>
</mex:GetMetadata>
</soapenv:Body>
</soapenv:Envelope>
WebSphere Application Server V7
Announcement Workshop 2008
# 55
© IBM Corporation.
参考情報としてWS-MetadataExchangeのGetMetadataリクエストのSOAPメッセージを載せ
ています。
55
(参考)WS-MetadataExchange:GetMetadataレスポンス
WAS
WAS V7
V7 W/S
W/S
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response</wsa:Action>
<wsa:RelatesTo>urn:uuid:131DB4FAE7D29EBF3D1222865209480</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<mex:Metadata xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:tns="http://oneway.jp.ibm.com">
<mex:MetadataSection Dialect="http://schemas.xmlsoap.org/wsdl/" Identifier="{http://oneway.jp.ibm.com}TestOnewayService">
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsu="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsp="http://www.w3.org/ns/ws-policy" name="TestOnewayService" targetNamespace="http://oneway.jp.ibm.com">
<wsdl:types>
<xsd:schema targetNamespace="http://oneway.jp.ibm.com">
（中略）
</wsdl:service>
<wsp:Policy wsu:Id="548f2fdb-6add-4251-abb2-6c8c66a86d9e">
<wsp:ExactlyOne>
<wsp:All><rmassertion:RMAssertion xmlns:rmassertion="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
<wsp:Policy><rmassertion:DeliveryAssurance wsp:Ignorable="true">
<wsp:Policy><rmassertion:ExactlyOnce></rmassertion:ExactlyOnce></wsp:Policy></rmassertion:DeliveryAssurance></wsp:Policy>
</rmassertion:RMAssertion></wsp:All>
<wsp:All><rmassertion:RMAssertion xmlns:rmassertion="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
<InactivityTimeout Milliseconds="86400000"></InactivityTimeout>
<BaseRetransmissionInterval Milliseconds="15000"></BaseRetransmissionInterval>
<AcknowledgementInterval Milliseconds="3000"></AcknowledgementInterval>
</rmassertion:RMAssertion> </wsp:All><wsp:All></wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsdl:definitions></mex:MetadataSection><mex:MetadataSection
Dialect="http://schemas.xmlsoap.org/wsdl/"><mex:Location>http://localhost:9083/TestAppOnewayProvWeb/TestOnewayService?wsdl</mex:Location>
</mex:MetadataSection></mex:Metadata></soapenv:Body></soapenv:Envelope>
ポリシー情報
WebSphere Application Server V7
Announcement Workshop 2008
# 56
© IBM Corporation.
参考情報としてWS-MetadataExchangeのGetMetadataレスポンスのSOAPメッセージを載
せています。
ポリシー情報を含んだWSDLファイルの情報が返ってきていることがわかります。
56
ポリシー・セットのExport/Import
WAS
WAS V7
V7 W/S
W/S
ポリシー・セットの内容をxml形式のファイルとして扱う
Export/Import可能
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <ps:PolicySet xmlns:ps="http://www.ibm.com/xmlns/prod/websphere/200605/policyset"
xmlns:psa="http://www.ibm.com/xmlns/prod/websphere/200605/policysetattachment" version="7.0.0.0"
type="application" name="Kerberos V5 HTTPS default" description="$KEY_policySetDescription020" default="true">
<ps:PolicyType type="WSSecurity" provides="" enabled="true" />
<ps:PolicyType type="SSLTransport" provides="" enabled="true" />
<ps:PolicyType type="WSAddressing" provides="" enabled="true" />
</ps:PolicySet>
WebSphere Application Server V7
Announcement Workshop 2008
# 57
© IBM Corporation.
ポリシー・セットの内容はXML形式のファイルとしてExportやImportすることができます。
ExportしたファイルをRADなどの開発ツールに取り込んで開発環境でテストすることもできま
す。
57
(参考)WS-Transaction
WAS
WAS V7
V7 W/S
W/S
WS-Transation
Webサービス環境においてトランザクション処理を実現する技術
WS-Coordination/WS-AtomicTransaction/WS-BusinessActivityで構成
WASv7ではV1.0とV1.1の両方をサポート(サーバー単位で選択)
V1.1はJAX-WSアプリケーションのみで使用可能
V1.0はJAX-WSとJAX-RPCの両方で使用可能
JAX-RPCとJAX-WSの通信でWS-Transactionを使用したい場合はV1.0を使用
×
「サーバー」＞server_name＞「トランザクション・サービス」で設定
WS-TX v1.1
Webサービス
リクエスター
Webサービス
プロバイダー
JAX-WS
JAX-RPC
WS-TX v1.0
WebSphere Application Server V7
Announcement Workshop 2008
# 58
© IBM Corporation.
WS-TransactionはWebサービス環境においてトランザクション処理を実現する技術です。
OASISより策定されている標準仕様で、2007年12月にV1.1がリリースされています。実際に
はWS-Coordination / WS-AtomicTransaction / WS-BusinessActivityで構成されています。
WAS V7からのアップデートとしてはWS-Transation V1.1を新たにサポートするようになりまし
た。
V1.0とV1.1の両方をサポートしていますが、V1.1はJAX-WSアプリケーションのみで使用可能、
V1.0はJAX-WSとJAX-RPCの両方で使用可能です。
注意点として、リクエスターとプロバイダーで異なるWS-Transactionのバージョンを使用するこ
とはできません。必ずバージョンは統一するようにしてください。WASのJAX-RPCアプリケー
ションとのやりとりが発生する場合、低レベルのV1.0を選択することになります。
バージョンの選択はアプリケーション・サーバー単位で行います。ナビゲーション・ツリーの
[サーバー]>[server_name]>[トランザクション・サービス]でバージョンを選択します。
58
Summary
WAS
WAS V7
V7 W/S
W/S
WS-I ReliableSecureProfile(RSP)
WS-RMによって信頼性の高いWebサービス通信が可能
WS-SCによってWS-RMシーケンス上のメッセージをセキュアにできる
WS-SCは派生鍵を使用した対称鍵暗号方式で負荷が低い
WS-RM、WS-SCはWS-I RSPによってインターオペラビリティが保証される
Webサービス・ポリシー
QoSの適用は管理コンソールからポリシー・セットを関連付け
ポリシー・セットによってサービス単位で柔軟なアプリケーション管理
WebSphere Application Server V7
Announcement Workshop 2008
# 59
© IBM Corporation.
59
Reference
WAS
WAS V7
V7 W/S
W/S
WAS V7 InfoCenter
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp
WAS V6.1 SOA Webサービス・ワークショップ資料
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_soa_ws//
WS-ReliableMessaging と WS-Polling の関係
http://www-06.ibm.com/jp/developerworks/webservices/library/ws-soa-wsrmwsp.shtml
IBM Redbooks:Web Services Feature Pack for WAS V6.1
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247618.html?Open
WS-I
http://www.ws-i.org/
WS-I Reliable Secure Profile
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=reliablesecure
OASIS Web Services Reliable Messaging
http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.html
OASIS Web Services Secure Conversation
http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.3/wssecureconversation.html
OASIS Web Services Trust
http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html
W3C Web Services Policy 1.5 – Framework
http://www.w3.org/TR/ws-policy/
WebSphere Application Server V7
Announcement Workshop 2008
# 60
© IBM Corporation.
60