Webサービス～Application～ 1 日本IBMシスエムズ・エンジニアリング(株)

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 17

122

views

Report

Comments

Description

Download Webサービス～Application～ 1 日本IBMシスエムズ・エンジニアリング(株)

Transcript

Webサービス～Application～ 1 日本IBMシスエムズ・エンジニアリング(株)

Webサービス
～Application～
日本IBMシスエムズ・エンジニアリング(株)
Webインフラストラクチャー
平岩梨果
© 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
WASとWebサービス
Webサービスの動向と最新仕様
Webサービスのインターオペラビリティ（相互運用性）
メッセージ交換パターンとトランスポートプロトコル
JAX-WSのプログラミングモデル
Standard SOAP/JMSのサポート
MTOM (Message Transmission Optimization Mechanism)-
WebSphere Application Server V7
Announcement Workshop 2008
#3
© IBM Corporation.
3
WASとWebサービス
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
#4
© IBM Corporation.
4
ＳＯＡのリファレンス・アーキテクチャにみるWASのポジショニング
WAS
WAS V7
V7 W/S
W/S
ビジネス・イノベーション＆最適化サービス
リアルタイムでのビジネス情報による、よりよい意志決定の促進
開発
サービス
ソリューション
資産のデザ
インと構築
のため
の統合環境
インタラクション
・サービス
ビジネス・プロセスの自動化
と統合・調整
人・プロセス・情報の
コラボレーション
ESB
パートナー・サービス
企業間接続
インフォメーション
・サービス
プロセス・サービス
多様なデータやコンテンツの
統一管理
確実なサービ
スやアプリケー
ション、リソー
スの管理
サービス間の接続
ビジネス・アプリケーション
・サービス
堅牢でスケーラブルかつ
セキュアなサービス実行環境
IT
サービス
管理
アクセス・サービス
既存の情報やアプリケーション
資産との接続の促進
インフラストラクチャ・サービス
スループット、可用性、パフォーマンスの最適化
WASが担うのは、“サービス”の実行環境
WebSphere Application Server V7
Announcement Workshop 2008
#5
© IBM Corporation.
上図はSOAのリファレンス･アーキテクチャになります。SOAを実現するうえで必要となるさま
ざまな役割をまとめていますが、そのなかで、WASはビジネス･アプリケーション･サービスすな
わちサービスの実行環境を担っています。また、プロセス･サービスを担うWPSや、ESBの責
務を担うWESBといった製品もWASをベースにしており、今回紹介するWASのWebサービス
の機能が、これらの製品のベースのテクノロジーになっています。
※WASをベースにした製品の出荷は、WASと同じタイミングで最新バージョンが出荷されな
いことにご注意ください。
5
Webサービスでできること
WAS
WAS V7
V7 W/S
W/S
異機種で接続できる（Javaと.NETなど）
プラットフォームや言語に依存しない
接続性
クライアントだけではなく、
コンピュータ同士の利用を前提
再利用
Web
サービス
CICS
(COBOL)
Web
サービス
共通ロジック
WAS
(Java)
Web
サービス
・NET
標準のインターフェース定義
WSDL
異機種間をつなぐ相互運用性
WS-I
非機能要件を実現する標準仕様
WS-*
WebSphere Application Server V7
Announcement Workshop 2008
#6
© IBM Corporation.
Webサービスの特徴について確認します。
SOAで重要なキーワードとなる再利用性を実現するために、Webサービスの接続性という特
徴がとても重要になります。接続性の主なポイントとしては、異機種でつなぐことができたり、ま
たプラットフォームや言語に依存しないといったことが挙げられます。またコンピューター同士
が利用することを想定しているため、人手を介さない自動処理を可能にしています。
また、Webサービスの接続性を可能にしている代表的なテクノロジーがあります。
1：WSDLというインターフェース記述言語を使用しています。
人間もコンピューターにも理解できるXML形式であること。また、明確にインターフェース
定義が決められています。
2：異機種との接続性は、WS-Iという標準化団体の活動によって維持されています。
この団体は、Webサービスの相互運用性を推進するための団体で、プロファイルを提供し
ています。プロファイルについては後述します。
3：非機能要件を実現するための標準仕様としてWS-*があります。WS-*については後述しま
す。
6
Webサービスアプリケーションの基本
WAS
WAS V7
V7 W/S
W/S
Webサービスアプリケーションの特徴
通信メッセージフォーマットはXML(SOAP)
トランスポートプロトコルからは独立
WSDLを使用してリクエスターやプロバイダーコードの自動生成が可能
Webサービスリクエスター/プロバイダーの開発の仕様
JAX-RPC(1.1)とJAX-WS(2.0/2.1)
WSDLとJavaとの
マッピング規定
●実装からWSDLの自動生成
開発
●WSDLから通信用Javaクラスの自動生成
リクエスター
実行
JAX-RPC
JAX-WS
SOAP
プロバイダー
トランスポートに
依存しない
WebSphere Application Server V7
Announcement Workshop 2008
JAX-RPC
JAX-WS
#7
© IBM Corporation.
Webサービスアプリケーションの基本的な特徴について、もう少しテクノロジーの観点からみ
ていきましょう。
まず、メッセージ・フォーマットとしてSOAPを利用しているので、特定の通信プロトコルに依存
することはありません。
主要な技術の記述言語として、技術に対して中立的であるXMLを利用することによって、特
定技術への依存性を排除しています。
インターフェース言語であるWSDLを利用して、ツールによるリクエスターやプロバイダーア
プリケーションの自動生成が可能という特徴があります。
Webサービスの仕様としては、JAX-RPCとその後継であるJAX-WSがあります。JAXWS(2.0)はWAS V6.1FeaturePack for WebServices（以降 WAS V6.1 FPWS）からサ
ポートされ、さらに、WAS V7では、JAX-WS2.1という最新バージョンをサポートしています。
JAX-RPC仕様のバージョンが1.1から2.0に上がると同時に、その名前がJAX-WSに変更に
なっているのは、JAX-RPC仕様が網羅するのはRPCだけではないこと、Webサービスのため
のJava APIであることを明確にするための名称変更です。 JAX-RPCからJAX-WSへの変遷
については、後ほど詳細にご紹介します。
7
Webサービスにおける非機能要件の実現
WAS
WAS V7
V7 W/S
W/S
分散コンピューティング環境では非機能要件が特に重要
WS-*
非機能要件を実現する標準仕様
アプリケーションではなくミドルウェアのレベルで実現
A社
Internet
B社
SOAP/HTTP
リクエスター
プロバイダー
分散環境における
非機能要件の実現
トランザクション処理の
整合性をとりたい！
非機能要件を実現するWS-*の例
非機能要件を実現するWS-*の例
信頼性
WS-ReliableMessaging….
セキュリティ
WS-Security,WS-SecureConversation…
運用管理
WS-Policy,WS-DistributedManagement…
トランザクション
WS-AtomicTransaction,WS-BusinessActivity…
WebSphere Application Server V7
Announcement Workshop 2008
#8
© IBM Corporation.
WebサービスにはアプリケーションのAPIだけではなく、非機能要件を実現するための標準
仕様が用意されています。
インターネットを介した分散コンピューティング環境では、特に非機能要件を考慮することが
重要になります。また、基幹システムの構築を考えた場合にも、機能要件と同じくらい非機能
要件を重要視する必要があるでしょう。例えば、トランザクションの保証を運用での回避やアプ
リケーションの作りこみによって行ったり、セキュリティーや信頼性の確保をトランスポートレベ
ルに依存したSSLで実現することも可能です。しかし、こういった依存性の強いアプリケーショ
ンを増やすことは、アプリケーションの再利用性の観点からもあまり好ましくありません。Web
サービスには、こういった非機能要件を実現するためにWS-*と呼ばれる標準仕様が定められ
ています。WS-*には、信頼性やセキュリティ、運用管理、トランザクションといったカテゴリーに
マッピングされた各種仕様が多くあります。WS-*という技術を使用することは、機能以外のこと
をアプリケーションレイヤーで実装したり、また特定のトランスポートプロトコルに依存するので
はなく、ミドルウェアのレイヤーで実現することにつながります。
8
(参考）Webサービス仕様群のなかのWS-*
WAS
WAS V7
V7 W/S
W/S
Web Service Specifications – Organized Overview
Quality of Service(QoS) ・・・・非機能要件の一部である品質・性能
WS-Reliable
Messaging
WS-TX
（WS-AT,WS-BA)
WS-Policy
WS-Security
WS-SC
WebSphere Application Server V7
Announcement Workshop 2008
#9
© IBM Corporation.
これはWebサービス仕様群のなかのWS-*が位置するレイヤーを示したものです。
Webサービス仕様のレイヤーの中で、WS-*は主にQuality of Serviceを支えるテク
ノロジーになります。Quality of Service（QoS）は非機能要件のなかでも特に品質・
性能を指します。この部分については、この後のセッションWebservice QoS &
Policyで扱います。
9
WASがサポートするWebサービス仕様の変遷
WAS
WAS V7
V7 W/S
W/S
WAS V7でサポートするWebサービス（Application）関連の仕様
JSR 109 1.2
JAX-WS 2.1
New
v7
JAXB 2.1
EJB 3.0*
WebSphere 6.1
Feature Pack for
Web Services
Webサービス実装
MTOM
WebSphere 6.1
WebSphere 6.0
WebSphere 5.1
JAX-RPC (JSR-101)
1.0
JSR-109 1.0
SAAJ 1.1
WS-Security (draft)
WS-I Basic Profile 1.0
UDDI4J version 2.0
(client)
Apache Soap 2.3
enhancements
JAX-RPC (JSR-101)
1.1
JSR-109 1.1 – WSEE
1.1
SAAJ 1.2
WS-Security 1.0
WS-I Basic Profile 1.1
UDDI 3.0
JAXR
WS-TX AT Support
WebSphere 7.0
当セッションで紹介
WS-TX BusinessActivity
WS-I BSP 1.0
WS-Notification
WS-Security
(performance)
SOAP/JMS performance
WS-RF (Resource
Framework)
WS-Addressing (SOAP /
Core)
JAXB 2.0
JAX-WS 2.0
StAX 1.1
SAAJ 1.3
SOAP 1.2
MTOM / XOP
WSSecureConversation
WS-Trust
WSReliableMessaging
WSDistributedManagem
ent (WSDM)
JAXB 2.1
JAX-WS 2.1
JSR 109 1.2
EJB3.0
OASIS WS-TX (AT/BA)
OASIS WS-SX
WSSecureConversation
WS-Trust
WS-SecurityPolicy
OASIS Kerberos Token
Profile
W3C WS-Policy
W3C WS-Addressing
Metadata
WS-MetadataExchange
WS-I BP 1.2 / 2.0 / RSP
※当資料では、Feature Pack for Web Services をV6.1 FPWSと表記
WebSphere Application Server V7
Announcement Workshop 2008
# 10
© IBM Corporation.
WASがサポートしているWebサービス仕様群の変遷になります。Webサービスの標準仕様
は数多く存在しますが、WASがサポートしている仕様は、ここに記されている仕様になります。
WAX V7では、Webサービスのアプリケーション関連の仕様として、新たにいくつかの仕様
の最新バージョンをサポートしています。
WebサービスのAPIであるJAX-WSは、V6.1 FPWSでは2.0でしたが、V7より2.1をサポート
しています。また、XMLとJavaオブジェクトのバインディングのAPIであるJAXBは、ｊJAX-WS
と同様V6.1 FPWSでは2.0でしたが、V7より2.1をサポートします。Webサービスのディプロイ
やパッケージングの方法などを定めたImplementing Enterprise WebServices
(WebServices for Java EE)は、 V6.1 FPWSでは1.1（JSR921）でしたが、V7より1.2
（JSR109）をサポートします。EJB3.0に関しては午前のセッションで扱いましたが、EJB実装
のWebサービスもサポートされています。このセッションではこれらの仕様について解説してい
きます。またMTOMについては、 V6.1 FPWSからサポートされていますが、概要についての
説明、およびJAX-WS2.1によって新規に追加された実装コードについて紹介します。
10
Webサービスの動向と最新仕様
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 11
© IBM Corporation.
11
Webサービスの仕様と変遷（JAX-RPCからJAX-WSへ）
WAS
WAS V7
V7 W/S
W/S
Webサービスリクエスター/プロバイダーの開発の仕様
JAX-RPC(1.1)とJAX-WS(2.0/2.1)
RPCスタイルのJAX-RPCからメッセージ指向のJAX-WSへ
RPCスタイルが主流であったWebサービス仕様がメッセージ指向の取り込み
JAX-WSでは、非同期呼び出しを含めたメッセージ交換パターンの明確化
JAX-WS
(2.0/2.1)
W eb S
ervice
・WebサービスのためのJava
API
・RPCだけではない
Async
Messaging
Messaging
RPC
・ネットワーク上の別プログラム
の機能を自機能同様にコール
・同期呼出し
JAX-RPC
（1.1）
・MOM(メッセージ指向ミドルウェア)
によるN対N統合
・非同期呼出し
メッセージング
WebSphere Application Server V7
Announcement Workshop 2008
# 12
© IBM Corporation.
分散コンピューティングの歴史は、大きく分けて、 RPCスタイルの同期呼び出しとメッセージ
ングによる非同期呼出しに分かれています。RPCは、Remote Procedure Call という名前の
通り、ネットワーク上の別プログラムの機能をローカル上の機能と同様にコールするという技術
で、同期呼出しを基本にしています。もう１つはメッセージ指向ミドルウェア（MOM）製品を利
用したメッセージングの概念になり、非同期処理を実現しています。 RPCスタイルが主流で
あったWebサービス仕様（JAX-RPC）がメッセージ指向を取り込み、JAX-WSという仕様に発
展しています。JAX-WSでは、非同期を含めたメッセージ交換パターンを明確に定義していま
す。
12
JAX-WS2.1（1/2）
WAS
WAS V7
V7 W/S
W/S
JAX-WS(JSR224 Java API for XML-Based Web Services) 2.1
JAX-RPCに替わるJava Webサービスの新規API
従来の同期型に加え、非同期プログラミングモデルをサポート
新Webサービス標準のサポート
SOAP1.2、MTOM、SAAJ1.3、JSR109 (WebServices for Java EE) v1.2
SAAJ1.3
SOAPメッセージの構築・操作
パッケージングやデプロイ、実装方式の規定
JSR109
リクエスター
JAXB
JAXB
SOAP
1.1/1.2
JAXB
JAXB
プロバイダー
アタッチメント
非同期プログラミングを規定
MTOM
WebSphere Application Server V7
Announcement Workshop 2008
# 13
© IBM Corporation.
JAX-WSは、正式名称をJSR224 Java API for XML Based Web Servicesといいます。
JAX-RPCの後継にあたる仕様になります。繰り返しになりますが、従来の同期型に加えて、非
同期呼び出しのプログラミングを新たにサポートしています。JAX-WSの非同期呼び出しの詳
細については、後述します。
また、新しいWebサービス関連の仕様をサポートしています。SOAP1.2は、SOAPの最新
バージョンになります。MTOM（SOAP Message Transmission Optimization Mechanism）
はW3Cにより作成された標準で、Webサービスでバイナリデータ（添付ファイル）をやりとりす
るための仕様になります。SAAJ (SOAP with Attachments API for Java) はSOAPメッセー
ジの作成、読み込み、変更を行うためのAPIになります。今回はSAAJについては触れていま
せんが、SAAJについては『WAS V6.1 SOA Webサービス・ワークショップ』の「JAX-WSによ
るメッセージ指向プログラミング」を参考にしてください。JSR109 V1.2については、後述しま
す。
13
JAX-WS2.1（2/2）
WAS
WAS V7
V7 W/S
W/S
JAX-WS(JSR224 Java API for XML-Based Web Services) 2.1
仕様からJava-XMLデータバインディング規定を分離し、JAXBへ委譲
XMLドキュメントをJavaで扱うための変換処理
アノテーション・サポートによる開発効率・保守効率の向上
ベンダー依存のWebサービスDD/マッピングファイルの排除
JSR181 WebServices Metadata、JSR175 Metadata Facility for Java、JSR250 Common
Annotation
SOAPだけではなく、XML/HTTPバインディングのサポート
ベンダー依存の静的スタブによるプログラミングモデルの排除
JavaとXMLのマッピング
はJAXB仕様に委譲
リクエスター
JAXB
JAXB
XML/HTTP
バインディング
SOAP
/XML
JAXB
JAXB
JAX-WS
プログラミングAPI
WS Metadata
アノテーション
プロバイダー
アノテーションでの
サービス定義
WebSphere Application Server V7
Announcement Workshop 2008
# 14
© IBM Corporation.
JAX-RPCはXMLとJavaのバインディングにおいて独自の実装で行っていましたが、JAXWSでは、JAXBという仕様にその部分を完全に委譲しています。
JAX-WSでは、Web Services Metadata（JSR-181）という仕様をサポートしたことで、アノ
テーションによる定義が可能になっています。JSR-181で定義されたアノテーションをPOJO
なサービスオブジェクトに施すことにより、従来のWebサービスコンポーネントに必要なリモー
トインターフェイス、WSDLファイル、デプロイメント・ディスクリプター（webservices.xml）、およ
びJAX-RPCマッピングファイルに相当する情報を自動生成することができるようになります。
また、JAX-WSはSOAP/HTTPバインディングだけはなく、XML/HTTPバインディングをサ
ポートしています。Javaオブジェクトではなく、XMLそのものを扱いたい場合には、
XML/HTTPバインディングを使用することになります。
14
JAXB2.1
WAS
WAS V7
V7 W/S
W/S
JAXB(Java Architecture for XML Binding) 2.1
JavaクラスとXMLスキーマのデータバインディングを行う仕様
XMLスキーマに準拠し、スキーマ検証をサポート
XMLスキーマ<->Javaオブジェクト
XML文書<->Javaオブジェクト
JAX-WS2.1におけるデフォルトのデータバインディング仕様
開発
オプションでスキーマ検証が可能！
XML
XML
実行
ドキュメント
ドキュメント
スキーマ
ジェネレーター
(schemagenコマンド)
アンマーシャル
XML
XML
Javaオブジェクト
スキーマ
スキーマ
スキーマ
コンパイラー
(xjcコマンド)
Javaクラス
マーシャル
annotation
WebSphere Application Server V7
Announcement Workshop 2008
XML
XML
ドキュメント
ドキュメント
# 15
© IBM Corporation.
JAXBは、XMLドキュメントをJavaオブジェクトとして扱うために、XMLスキーマをJava のクラ
スにマッピングすることによってアプリケーションの開発効率を向上させるためのツールやAPI
をまとめたアーキテクチャです。スキーマとは、XMLドキュメントの中でどのようなタグを使用し
ているか，属性は何かなどを定義しています。
XMLドキュメントをメモリー上のJavaオブジェクトに対応付けることをマーシャル、またJavaオ
ブジェクトからXMLドキュメントを作成することをアンマーシャルと言います。この作業において、
XMLスキーマを利用していることがJAXBの特徴になります。
開発時には、XMLスキーマとJavaのクラスの関係付け（バインディング）をおこなっておくこと
によって、XMLドキュメントとJavaのオブジェクトの対応関係を明確にすることが可能になりま
す。Javaのオブジェクトに対するクラスの関係は，XMLドキュメントに対するスキーマと同じに
なります。
基本的な流れは下記のようになります。
1.Unmarshal：XMLのドキュメントをJavaに読み込んで、Javaでの表現に変換する
2.Access & update：Javaでの表現にアクセスして、内容を変更する
3.Marshal：JavaでのXMLの表現を、再び、XMLに変換する
またJAXB は、xjcスキーマ・コンパイラー・ツール、 schemagen スキーマ・ジェネレーター・
ツール、およびランタイム・フレームワークを提供します。 xjc スキーマ・コンパイラー・ツールで
は、XML スキーマ定義 (XSD) から開始して、 XSD スキーマに定義されたエレメントおよびタ
イプにマッピングする JavaBeans セットを作成することができます。また、JavaBeans セット
から開始し、 schemagen スキーマ・ジェネレーター・ツールを使用して XML スキーマを作成
することもできます。スキーマ・コンパイラーまたはスキーマ・ジェネレーター・ツールのいずれ
かを使用した後、 XMLドキュメントを Java オブジェクトとの間で双方向に変換し、その結果で
ある Java クラスを使用して Web サービスのアプリケーションをアセンブルすることができます。
15
JAXBによるデータバインディングのいいところ①
WAS
WAS V7
V7 W/S
W/S
複合型データ･タイプのマッピング
<xsd:sequence>の順序情報がアノテーションで反映
JAXB
JAX-RPC
@XmlType(name = "Phone", propOrder = {
"areaCode",
"exchange",
"number"
})
public class Phone {
public class Phone {
private String areaCode;
private String exchange;
private String number;
@XmlElement(required = true)
protected String areaCode;
@XmlElement(required = true)
protected String exchange;
@XmlElement(required = true)
protected String number;
...
}
Java型では表現できなかった順序情報
をアノテーションで定義
WebSphere Application Server V7
Announcement Workshop 2008
# 16
© IBM Corporation.
JAXBの主なメリットを取り上げていきます。まず1つ目ですが、複合型（ComplexType）の
マッピングにおいて、XMLスキーマで<xsd:sequence＞で定義された順序情報をアノテーショ
ンで表現することが可能になりました。JAX-RPCでは、これらの要素名をJava型のフィールド
に変換する際、順序性を維持することができませんでしたが、JAXBでは可能になります。
16
JAXBによるデータバインディングのいいところ②
WAS
WAS V7
V7 W/S
W/S
JAX-RPCではコレクション型が直接使用できない
JAXBはJavaコレクション型のマッピングも可能
List,HashMap,Vector,TreeSet
Generics List型では順序の保持も可能に
JAX-RPC
private int[] intArrayField;
public int[] getIntArrayField() {...}
public void setIntArrayField(int[] intArrayField) {...}
public int getIntArrayField(int i) {...}
public void setIntArrayField(int i, int value) {...}
Generics Listにマッピングすることで
setter/getterがシンプルに
順序も保持可能に
JAXB
@XmlElement(type = Integer.class)
protected List<Integer> intArrayField;
public List<Integer> getIntArrayField() {...}
WebSphere Application Server V7
Announcement Workshop 2008
# 17
© IBM Corporation.
2つ目に、コレクション型（List,HashMap,TreeSet）のサポートが挙げられます。JAX-RPCで
は、コレクション型がサポートされておらず、 xsd:anyTypeにマッピングされてしまうため、コレ
クション型を直接扱うことができませんでした。コレクション型を使わずに配列を利用する、もし
くはサービス･インターフェースとしてラッパークラスを用意する、などの対応が必要でした。
（詳細は、『SOA Webサービス及びESB基盤構築ワークショップ資料』の「4.Webサービス・ア
プリケーション開発設計」を参考にしてください。）JAXBでは、コレクション型のマッピングも可
能です。また、Generics List型では、順序も保持することが可能です。
17
JAXBによるデータバインディングのいいところ③
WAS
WAS V7
V7 W/S
W/S
JAX-RPCの場合
クラスでエレメント(要素)とアトリビュート(属性)の区別がつかない
<xs:complexTypename="address">
<xs:sequence>
<xs:elementname=“name" type="xs:string"
/>
<xs:elementname="street" type="xs:string" />
<xs:elementname="city" type="xs:string" />
<xs:elementname="state" type="xs:string"/>
<xs:elementname="zip" type="xs:string"/>
</xs:sequence>
</xs:complexType>
スキーマでは
<xs:complexTypename="address">
明確に区別
<xs:sequence>
<xs:elementname="street" type="xs:string" />
<xs:elementname="city" type="xs:string" />
<xs:elementname="state" type="xs:string"/
></xs:sequence>
<xsd:attributename="name" type ="xsd:string"/>
<xsd:attributename="zip" type ="xsd:string"/>
</xs:complexType>
スキーマ①
<address
<name=“ISE Hanako”/name>
<street>美浜</street>
<city>幕張</city>
<state>千葉</state>
<zip=“097-0012”/zip>
</address>
XMLドキュメント①
スキーマ②
public class Address {
protected String name;
protected String street;
protected String city;
protected String state;
protected String zip;
}
クラス
<address
name=“ISE Hanako”
zip=“097-0012”>
<street>美浜</street>
<city>幕張</city>
<state>千葉</state>
</address>
XMLドキュメント②
WebSphere Application Server V7
Announcement Workshop 2008
# 18
© IBM Corporation.
3つ目に、要素と属性の区別が可能になったことが挙げられます。まず、JAX-RPCの例です。
XMLドキュメント①では、 name,street,city,state,zipがすべて要素として定義されており、ス
キーマ①でもすべて要素として定義されていることがわかります。 XMLドキュメント②では、
street,city,stateが要素、nameとzipが属性として扱われています。またスキーマ②でも、要素
と属性が区別されていることがわかります。しかしJavaクラスでは、すべてフィールド（field）で
表現されてしまい、要素と属性の判別がつかないことがわかります。
18
JAXBによるデータバインディングのいいところ③
WAS
WAS V7
V7 W/S
W/S
JAXBの場合
アノテーションによる厳密な制約指定
エレメント(要素)とアトリビュート(属性)の区別が可能に
<xs:complexTypename="address">
<xs:sequence>
<xs:elementname="street" type="xs:string" />
<xs:elementname="city" type="xs:string" />
<xs:elementname="state" type="xs:string"/
></xs:sequence>
<xsd:attributename="name" type ="xsd:string"/>
<xsd:attributename="zip" type ="xsd:string"/>
</xs:complexType>
スキーマ
<address
name=“ISE Hanako”
zip=“097-0012”>
<street>美浜</street>
<city>幕張</city>
<state>千葉</state>
</address>
public class Address {
@XmlAttribute
protected String name;
@XmlElement
protected String street
;@XmlElement
protected String city;
@XmlElement
protected String state;
@XmlAttribute
protected String zip;}
クラス
XMLドキュメント
WebSphere Application Server V7
Announcement Workshop 2008
# 19
© IBM Corporation.
JAXBでは、Javaでは失われるXMLの要素もしくは属性のどちらで表現されているのかとい
う情報を、アノテーションを使用することによって、Javaのフィールドに付加することが可能にな
ります。
また、必須指定(Required)や、要素の値を取りあえずブランクにしておきたいケースでは、
対象の要素定義に「nillable=“true”」を記述することも可能です。
@XmlElement(required = true, nillable = true)
protected String stringNilField;
19
Implementing Enterprise WebServices (WebServices for Java
EE)
WAS
WAS V7
V7 W/S
W/S
JSR109 (Implementing Enterprise WebServices)
Java EE環境でのWebサービスの実装方式やパッケージング、デプロイ方
式を規定
WAS V6.1 FPWSでは、V1.1(JSR921)までのサポート
WAS V7（JAX-WS 2.1）より、V1.2（JSR109）をサポート
JSR109 V1.2のハイライト
New
v7
JSR109
JAX-RPC<->JAX-WS間の互換性に関する規定も含まれる
EJB3.0のJAX-WS によるWebサービス実装のサポート
クライアント側のJAX-WSアノテーション（@WebServiceRef,@Resource）のサポート
クライアント側のデプロイメントディスクリプターで、サービス参照の定義が可能
アノテーションで定義されたWSDLファイルのロケーションや、サービス参照の定義
を上書きすることも可能
WebSphere Application Server V7
Announcement Workshop 2008
# 20
© IBM Corporation.
Implementing Enterprise WebServices (WebServices for Java EE)では、Java EE環境
でのWebサービスの実装方式や、パッケージング、デプロイ方式を規定しています。V6.1
FPWSでは、V1.1（JSR921）までのサポートでしたが、V7よりV1.2（JSR109）を新しくサポート
しています。
JSR109 V1.2のハイライトを上記に挙げています。それぞれの項目については、後ほど紹介
していきます。
（参考）
JSR･･･Java標準化機関であるJCP（Java Community Process）で提案されている仕様の
ことで、JCPにてJSRがJava標準にふさわしいかどうかを議論し、ここで選ばれることでJava標
準が決められています。そしてJava標準となったJSRはJavaプラットフォームへ実装されること
になります。
JCP･･･Sun Microsystems社が主催する、Java技術に関する標準仕様を定める機関
JSR109･･･http://jcp.org/en/jsr/detail?id=109
JSR921･･･http://jcp.org/en/jsr/detail?id=921
20
主要なWebサービス関連仕様の流れ
2000
2001
2002
2003
5月
6月
SOAP1.1
SOAP1.2
Note
2004
WAS
WAS V7
V7 W/S
W/S
2005
2006
2007
5月
5月
Recommendation
3月
WSDL1.1
Note
W3C
6月
10月
JAX-RPC1.0 JAX-RPC1.1
JSR101
11月(Java EE1.3)
JSR
JAX-WS2.0 JAX-WS2.1
JSR101
JSR224
1月(Java EE1.4)
JSR224
5月(Java EE5)
WebServices for Java EE1.0
WebServices for Java EE1.1WebServices for Java EE1.2
JSR109
JSR921
JSR109
WAS V6.1でのサポート範囲
WAS V6.1FPWSでのサポート範囲
WAS V7 のサポート
WAS V7でのサポート範囲
JAX-WS2.1 + WSDL1.1 + SOAP1.1/SOAP1.2 ＋ WebServices for Java EE1.2
WebSphere Application Server V7
Announcement Workshop 2008
# 21
© IBM Corporation.
Webサービス関連仕様と、WAS V6.1、WAS V6.1 FPWS、WAS V7におけるサポート状況
を表しています。
現在でもSOAP1.1が主流ですが、SOAP1.2はWAS V6.1 FPWSよりサポートされています。
またWSDLのバージョンは、WAS V6から変わらずWSDL1.1のサポートになります。またWAS
V7では、JAX-WSの最新バージョンである2.1と、Java EE環境でのWebサービスの実装方式
やパッケージング、デプロイ方式を規定しているWebServices for Java EE1.2（JSR109）を
新しくサポートしました。
21
Webサービスのインターオペラビリティ（相互運用性）
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7
Announcement Workshop 2008
# 22
© IBM Corporation.
22
WS-I Basic Profile
WAS
WAS V7
V7 W/S
W/S
Webサービスの基本仕様に関するProfile
相互接続性を向上するために各仕様の明確化と修正を進めた規定
Webサービス基本仕様は厳密でなく、解釈により各製品での実装が異なる
Webサービス基本仕様はバージョンアップ時にWS-Iでの規定を取り込む
WS-I Basic Profile 1.1
2004年8月正式公開
WS-I Basic Profile 1.1のハイライト
エンコーディングはDocument/literalかRPC/Literal
プロトコルバインディングはSOAP/HTTP(HTTPS)
SOAP Faultのレスポンスを受け取ったらHTTP 500を返す。
リクエストはHTTP POSTを使用する
WSDL1.1を使用する
実行環境とアプリケーションの双方がWS-Iに準拠する必要がある
WebSphere Application Server V7
Announcement Workshop 2008
# 23
© IBM Corporation.
WS-Iは、異なるプラットフォーム、OS、ミドルウェア、プログラミング言語、およびツールに跨るWeb
サービスの相互運用性を推進するために設立されたオープンな業界の団体です。この団体には、
Webサービスを推進している主要な企業が参加しており、ここで決められた事項は業界標準と言う
ことができます。
SOAPやWSDLを使用したWebサービスは相互運用性が高いと言われてきましたが、実際には製
品間での相互運用性を実現するにはWebサービス開発者による試行錯誤が必要で簡単には実現
できませんでした。例えば、Apache SOAPとMSの.NETを接続させるには、この分野に高度なスキ
ルを持つ人が作成しないと簡単にはWebサービスで接続することができませんでした。WS-Iはこう
した状況を改善するために作られた組織であり、Webサービスの現実的な相互運用性を実現する
ために様々な活動をしています。WS-Iは実際の活動をするにあたって、Webサービス関連の各種
標準を策定しているW3CやOASISと連携しながら活動しています。それ以外の団体とも協調しなが
ら業界の標準となるものを作成しています。WS-Iの活動のメインは、Profileと呼ばれる相互運用性
に関するガイドを作成することです。
WS-I Basic Profile1.1は2004年に正式公開されたプロファイルですが、現役で使用されているプロ
ファイルになります。このバージョンのプロファイルで定義されている主な内容としては、 SOAPメッ
セージを交換する際のデータの形式やSOAPボディの符号化方法となるエンコーディング方式や、
バインディングプロトコル、SOAP Fault発生時のエラーコード、リクエスト時にHTTP POSTを使用
すること、WSDLのバージョンは1.1がベースであることなどを規定しています。
プロファイルを使用することで重要なのは、実行環境とアプリケーションの双方が同じバージョンでな
ければならないということ、逆に同じバージョンのプロファイルに準拠していることで、他ベンダー上
のWebサービスとの相互運用性が確保されるということになります。
（参考）
「WS-I WEB SERVICES INTEROPERABILITY ORGANIZATION」･･･http://www.ws-i.org/
23
WAS V7でのBasic Profileのサポート
WAS
WAS V7
V7 W/S
W/S
WAS V7では、WS-I Basic Profile 1.2/2.0を追加でサポート
WS-I Basic Proifle 1.2
WS-Addressing1.0
MTOM1.0 / XOP
WS-I Basic Proifle 2.0
SOAP1.2
WS-I Reliable Secure Profile 1.0
WS-Trust 1.3
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
X.509 Token Profile
WS-I Basic Profile 1.0/1.1
WS-I Attachment Profile
Username Token Profile
SAML Token Profile
REL Token Profile
WS-I Simple SOAP Profile
WebSphere Application Server V7
Announcement Workshop 2008
# 24
© IBM Corporation.
WAS V7では、新規にWS-I Basic Profile1.2および2.0を追加でサポートしています。
Basic Profile1.2では、WS-Addressing1.0、MTOM1.0を、 Basic Profile2.0ではSOAP1.2
をサポートします。 Basic Profile以外のプロファイルについては、後続のセッションで扱います。
24
JAX-WSとJAX-RPCアプリケーションの相互接続
大前提：WS-I Basic Profileに準拠
JAX-WS と JAX-RPC アプリケーション
WAS
WAS V7
V7 W/S
W/S
JSR109
双方向呼び出しが可能
JAX-RPCではポリシー・セットは使用できない
WAS V7InfoCenter
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.base.doc/info/aes/ae/twbs_devwbsjaxwsclient.html
JAX-RPC 仕様に基づく Web サービス・クライアントは、 Web サービス記述言語
(WSDL) ファイルが Web Services-Interoperability (WS-I) Basic Profile に準拠し
ている場合は、JAX-WS ベースの Web サービスを呼び出すことができます。
JSR109 V1.2 Specificationより
http://jcp.org/en/jsr/detail?id=109
4.2.9 JAX-RPC and JAX-WS Interoperability
Interoperability between a JAX-RPC client and JAX-WS endpoint (or vice-versa)
is governed by the
requirements defined by the WS-I Basic Profile 1.0. As long as both the client
and the server adhere to these
requirements, they should be able to interoperate.
WebSphere Application Server V7
Announcement Workshop 2008
# 25
© IBM Corporation.
JSR109 V1.2には、JAX－RPCとJAX-WSアプリケーションの相互運用性について明記さ
れています。WS-I Basic Profileに準拠することで、JAX-RPCアプリケーション、JAX-WSアプ
リケーションの双方の呼び出しが可能になります。ただ、JAX-WSにはアタッチすることができ
るポリシー･セットは、JAX-RPCアプリケーションにはアタッチできないことに注意してください。
（ポリシー･セットについては後続のセッションで説明します）
25
（参考）Webサービス標準
WAS
WAS V7
V7 W/S
W/S
W3C
XML, XML Schema, XML Namespaces
http://w3.org
XML Encryption, XML Digital Signature
SOAP, WSDL
WS Addressing, Policy
OASIS
WS-Security, WS-Trust
WS-SecureConversation, WS-SecurityPolicy
http://oasis-open.org
BPEL
Reliable Messaging, Transactions
WS-I
Driving interoperable Web services through technical guidance
Basic Profile 1.1 & 1.2 & 2.0
Security Profile
http://ws-i.org
Conformance test tools
WebSphere Application Server V7
Announcement Workshop 2008
# 26
© IBM Corporation.
Webサービス標準を規定している団体と、その団体が規定している主な仕様になります。
26
メッセージ交換パターンとトランスポートプロトコル
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7
Announcement Workshop 2008
# 27
© IBM Corporation.
27
Webサービスにおけるトランスポートプロトコル
WAS
WAS V7
V7 W/S
W/S
Webサービスでは、SOAPを伝送するトランスポートは規定されていない
WAS V7では、JAX-RPC/JAX-WS共に、HTTPとJMSの選択が可能
データ・フォーマット
トランスポート
SOAP
etc...
HTTP
JMS
SOAP/HTTP
SOAP/JMS
SOAP/HTTP
同期処理
WS-Iに準拠
Webサービス
リクエスター
SOAP/HTTP
Webサービス
プロバイダー
SOAP/JMS
メッセージ基盤を使用した信頼性の高い処理を実現
キューを介すため、非同期処理
WS-Iに準拠していない
Webサービス
リクエスター
SOAP/JMS
Webサービス
プロバイダー
メッセージ転送は
MOM製品が保証
WebSphere Application Server V7
Announcement Workshop 2008
# 28
© IBM Corporation.
Webサービスでは、SOAPを伝送するトランスポートは規定されていません。WAS V7では、
JAX-RPC、JAX-WS共にトランスポートプロトコルとして、HTTPおよびJMSをサポートしてい
ます。
SOAP/HTTPとSOAP/JMSの特徴の相違を説明します。SOAP/HTTPが同期通信を行うの
に対して、SOAP/JMSはメッセージ基盤（キュー）を介した処理を行うことにより、結果的に非
同期処理となります。SOAP/HTTPは、一般にWebサービス間の通信で使用されているプロト
コルであり、WS-Iにも規定されるWebサービスの標準のプロトコルです。一方、SOAP/JMSは
WS-Iの準拠はありません。しかしWAS V6.1まではIBMの拡張機能として実装されていました
が、WAS V7よりW3Cで標準化が進められているSOAP over JMS 仕様をベースに実装され
ており、異なるプラットフォームとのインターオペラビリティーが実現できます（後述）。またJMS
を使用した場合には、Webサービス・リクエスター、またはWebサービス・プロバイダーから送
信されたメッセージはQueueまたはTopicにputされ、データベースなどの永続化ストレージに
保管されます。そして、通信に失敗した場合には、通信に成功するまで、永続化ストレージに
保管されます。また、リクエスター上にあるローカルキューにメッセージを送信した時点で、リク
エスター側の処理が一旦完了し、プロバイダーへのメッセージ転送をミドルウェアが保証してく
れるという点で、信頼性が高いという特徴があります。
28
（参考）SOAP/HTTPを使用したWebサービスアプリケーションの仕組み
WAS
WAS V7
V7 W/S
W/S
プロバイダーがJavaBeanの場合
サービス
エンドポイント
リクエスター
プロキシー
WSDL
SOAPクライアント
Webサービスエンジン
プロバイダー
（Java Bean)
Protocol(SOAP)
Transport (HTTP)
Webコンテナ
Webコンテナ
endptEnablerコマンドに
てルーター用WAR作成
プロバイダーがEJBの場合
リクエスター
スタブ
HTTPRouter
WSDL
SOAPクライアント
サービス
エンドポイント
Webサービスエンジン
Protocol(SOAP)
Webコンテナ
Transport (HTTP)
Webコンテナ
プロバイダー
EJB
(Session Bean)
EJBコンテナ
WebSphere Application Server V7
Announcement Workshop 2008
# 29
© IBM Corporation.
ここでWebサービスアプリケーションの仕組みについて確認します。まず、SOAP/HTTPアプ
リケーションになります。
WebサービスリクエスターからのリクエストはJavaプロキシー、SOAPクライアントを経由して、
HTTPクライアントからサーバーへ発行されます。Webサービスプロバイダーでは、HTTPサー
バーがリクエストを受け取った後、Webサービス・エンジンが処理を引き継ぎます。プロバイ
ダーサービスがJavaBeanとして実装されている場合は、Servletを経由して呼び出されますが、
EJB（Session Bean）として実装されている場合は、Web ルーターモジュール内のサーブレッ
ト経由で呼び出されることになります。また、このルーターモジュールは、endptEnablerコマン
ドで作成することが可能です。endptEnablerコマンドについては、後述します。
29
（参考）SOAP/JMSを使用したWebサービスアプリケーションの仕組み
WAS
WAS V7
V7 W/S
W/S
プロバイダーはEJBのみ
JMSRouterとして、MDB(Message Driven Bean)を使用
Webサービスエンジン
リクエスター
WSDL
プロキシー
プロバイダー
EJB
（Session Bean)
MDB
SOAPクライアント
Protocol(SOAP)
JMSRouter
endptEnablerコマンドに
てルーター用JAR作成
JMSSender
Webコンテナ
EJBコンテナ
Queue
WebSphere Application Server V7
Announcement Workshop 2008
# 30
© IBM Corporation.
次にSOAP/JMSのアプリケーションになります。
WebサービスリクエスターからのリクエストはJavaプロキシー、SOAPクライアントを経由して、
JMSセンダーからキューへputされます。Webサービスプロバイダーでは、ルーターモジュー
ルであるMDBがキューよりメッセージを受信して、Webサービスエンジンへ渡すことになります。
最後に、Webサービスエンジンがサービスを実装したSession Beanを呼び出します。なお、
SOAP/JMSではプロバイダーとしてEJBのみをサポートしています。
30
メッセージ交換パターン
WAS
WAS V7
V7 W/S
W/S
リクエスターは、以下の３つの方式でプロバイダーを呼び出すことが可能
同期型（JAX-RPC,JAX-WS）
サービス呼び出し後、レスポンス待ってから処理を続行
片方向型（JAX-RPC*,JAX-WS）
サービス呼び出しのレスポンスは受け取らない
非同期型双方向（JAX-WSのみ）
サービス呼び出し後、レスポンス待たずに処理を続行
非同期型双方向
片方向型
同期型
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
JAX-WS
Only
リクエスト
レスポンス
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
リクエスト
処理
続行
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
リクエスト
処理
続行
レスポンス
*JAX-RPC1.1よりサポート
WebSphere Application Server V7
Announcement Workshop 2008
# 31
© IBM Corporation.
WebサービスリクエスターとWebサービスプロバイダーのメッセージ交換パターンは大きく3
種類に大別できます。同期型、片方向型、非同期型双方向になります。同期型と非同期型双
方向は、メッセージの送受信を行いますが、片方向型は、メッセージを送信するのみで、結果
を受け取りません。JAX-WSではすべてのパターンをサポートしていますが、JAX-RPCでは非
同期型双方向をサポートしていません。（なお、JAX-RPCの片方向型はJAX-RPC1.1よりサ
ポートされています）
同期型は、サービス呼び出し後、レスポンスを待ってから処理を続行することになるため、レ
スポンスが返ってくるまで、リクエスターのスレッドはブロックされます。片方向型は、サービス
呼び出し後のレスポンスを受け取らず、サービス呼び出し後処理を続行することができます。
非同期型双方向は、サービス呼び出し後、レスポンスを待たずに処理を続行しますが、別のス
レッドがプロバイダーからのレスポンスを処理することになります。非同期型双方向について、
もう少し詳しくみていきましょう。
31
JAX-WSによる非同期型双方向呼び出し
JAX-WS
Only
WAS
WAS V7
V7 W/S
W/S
クライアントの非同期プログラミングモデル
リクエスターの処理とは別スレッドでプロバイダーを呼び出すことが可能
JAX-WSクライアントで可能な非同期プログラミング
java.util.concurrent.Executorが別スレッドでオペレーションを実行
ポーリング：サービス呼び出し後、任意箇所でのレスポンス問い合わせ
コールバック：AsyncHandlerがレスポンスを受け取り処理
ポーリング
ﾌﾟﾛﾊﾞｲﾀﾞ
ﾘｸｴｽﾀ
コールバック
リクエスト
リクエスト
処理
続行
ﾌﾟﾛﾊﾞｲﾀﾞ
ﾘｸｴｽﾀ
処理
続行
レスポンス
問い合わせ
レスポンス
(別スレッドのハンドラー
が受け取り、処理)
WebSphere Application Server V7
Announcement Workshop 2008
# 32
© IBM Corporation.
非同期型双方向は、JAX-WSクライアントによる非同期プログラミングによって実現されます。
この非同期プログラミングによって、リクエスターの処理とは別スレッドでプロバイダーを呼び出
すことが可能になります。また、非同期型双方向には、ポーリングとコールバックの2種類ありま
す。ポーリングは、サービス呼び出し後、任意の箇所でレスポンスの問合せを行ってからリクエ
スターの処理が完了します。コールバックは、ハンドラーがレスポンスを受け取り処理すること
になります。ポーリング同様に、リクエスターの呼び出し元クラスで結果を取得することも可能で
す。
これらの別スレッドによる処理は、java.util.concurrent.Executerによって実行されます。
32
メッセージ交換パターンとトランスポートプロトコルの選択
WAS
WAS V7
V7 W/S
W/S
メッセージ交換パターンの選択
同期型、片方向型、非同期型双方向（JAX-WSのみ）
トランスポートプロトコルの選択
HTTP or JMS
同期型
片方向型
SOAP
Request
SOAP
Request/Reply
SOAP
プロバイダー
Application
リクエスター
Request/Reply
非同期型双方向
Tranport
JMS
HTTP
WebSphere Application Server V7
Announcement Workshop 2008
# 33
© IBM Corporation.
また、アプリケーションレイヤーにおけるメッセージ交換パターンとは別に、トランスポートレイ
ヤーでは、HTTPもしくはJMSを選択することが可能です。メッセージ交換パターンとトランス
ポートプロトコルの組み合わせについてみていきたいと思います。
33
同期型
WAS
WAS V7
V7 W/S
W/S
サービス呼び出し後、レスポンスを待ってから処理を続行
即時性が求められる処理
例外の即時検知が可能
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
SOAP/HTTP
リクエスト
レスポンス
SOAP/JMS
リクエスト
レスポンス
<portType name="Test2">
<operation name="echo">
<input message="tns:echo"/>
<output message="tns:echoResponse"/>
</operation>
</portType>
WebSphere Application Server V7
Announcement Workshop 2008
# 34
© IBM Corporation.
同期型になります。このパターンを使用するユースケースとしては、下記のような場合が考え
られます。
・照会処理などリアルタイムで結果を求められるケースで使用
・即時処理が必要なケースで使用
・例外が発生した場合、クライアントにエラーが返り、例外の検知が可能
・照会処理のみであれば単純リトライ
・リソース更新を伴う場合、処理状況の確認が必要
リクエスターとプロバイダーそれぞれでリソースの更新処理が発生し、かつそれらの処理をト
ランザクション処理とする場合（１つのトランザクションスコープで囲まれるケース）、プロトコルと
してはSOAP/HTTPを使用し、WS-AtomicTransaction（WS-AT）を採用する必要があります。
WS-ATについては、『WebSphere Application Server 最新動向ワークショップ（2007年4月
版）』の「WAS V6.1におけるWebサービス分散トランザクションのサポート」を参考にしてくださ
い。
34
片方向型
WAS
WAS V7
V7 W/S
W/S
サービス呼び出しのレスポンスは受け取らない
実行結果をすぐに求められないケース（バッチなど）
エラーが返らない（業務での対応が必要になる）
通信の信頼性が求められる
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
SOAP/HTTP
リクエスト
処理
続行
SOAP/JMS
リクエスト
処理
続行
<portType name="Test3">
<operation name="echo">
<input message="tns:echo"/>
</operation>
</portType>
WebSphere Application Server V7
Announcement Workshop 2008
# 35
© IBM Corporation.
片方向型になります。このパターンを使用するユースケースとしては、下記のような場合が考
えられます。
・実行結果をすぐに求められないケースで使用
・バッチなど即時処理が必要でないケース
・例外が発生してもクライアントにエラーが返らないため、成功/失敗の確認が業務で必
要
・通信の信頼性が求められる
なお、上記のような特徴からこのケースでは、プロトコルとして信頼性の高いSOAP/JMSを採
用することをお勧めします。デフォルトでは、リクエスターの更新処理とキューへのメッセージ
送信処理、キューからのメッセージ受信処理とプロバイダーの更新処理はそれぞれトランザク
ション処理として扱われませんが、片方向型の場合のみ、enableTransactionalOneWayプロ
パティを設定することにより、トランザクション処理として扱うことが可能になります。
また、JAX-WSアプリケーションでは、SOAP/HTTPを使用する場合にも、WS-RMと併用す
ることで信頼性をあげることが可能になります。WS-RMについては後続セッションで説明しま
す。
（参考）
「JAX-RPCのenableTransactionalOneWay」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/twbs_j
msonewayreq.html
「JAX-WSのenableTransactionalOneWay」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/twbs_j
mstransactreqstd.html
35
非同期型双方向
WAS
WAS V7
V7 W/S
W/S
サービス呼び出し後、レスポンスを待たずに処理を続行
実行結果は必要だが、長時間かかるので同期型は使用しない
JAX-WS
Only
クライアントは先に別の処理をしたい
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
リクエスト
処理
続行
SOAP/HTTP
レスポンス
リクエスト
処理
続行
SOAP/JMS
レスポンス
WebSphere
<portType name="Test2">
<operation name="echo">
<input message="tns:echo"/>
<output message="tns:echoResponse"/>
# 36
Application Server V7 </operation>
</portType>
Announcement Workshop 2008
© IBM Corporation.
非同期型双方向になります。このパターンを使用するユースケースとしては、下記のような場
合が考えられます。
・実行結果は必要だが、長時間処理なので同期型は使えない。先に別の処理を進め
たい。
コールバック
・サービス側の処理が終了したら、サービス側からコールバックハンドラーを実行
・クライアントは先に処理を進めることができる
ポーリング
・クライアントからサービスの結果を取得する
36
片方向型と同期型voidの違い
WAS
WAS V7
V7 W/S
W/S
片方向型
リクエスターにはXMLのレスポンスメッセージは返らずHTTPステータスコー
ドのみが返る
例外メッセージが戻る可能性もない。
同期型＆レスポンスがVoid
空のsoap:bodyを含むレスポンスが返る。
例外が戻ってくる可能性がある。
@WebService
<portType name="Test2">
public class Test3 {
<operation name="echo">
public void echo(String input) {
<input message="tns:echo"/>
}
<output message="tns:echoResponse"/> }
</operation>
</portType>
void型
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
リクエスト
処理は
ブロック
空のレスポンス
or例外
片方向型
<portType name="Test3">
<operation name="echo">
<input message="tns:echo"/>
</operation>
</portType>
@WebService
public class Test3 {
@Oneway
public void echo(String input) {
}
}
ﾌﾟﾛﾊﾞｲﾀﾞｰ
ﾘｸｴｽﾀｰ
リクエスト
処理
続行
WebSphere Application Server V7
Announcement Workshop 2008
# 37
© IBM Corporation.
片方向型では、WSDLのOperationにoutput messageを定義しません。これは、WSDL1.1
の仕様で決められています。片方向型の場合には、リクエスターにはXMLのレスポンスメッ
セージは返らず、HTTPステータスコードのみが返ります。なお、例外メッセージが返ることもあ
りません。またリクエスターは、サービスを呼び出した直後に処理を続行することが可能です。
同期型のWSDLを使用（output messageの定義あり）し、void型を使用している場合には、
空のsoap:bodyを含むレスポンスが返ります。また例外が戻る可能もあります。またリクエス
ターは、サービスのレスポンスが返ってくるまで処理がブロックされることに注意してください。
JAX-RPCアプリケーションでボトムアップ開発をする場合、Webサービスウィザードで「ボイド
を戻す」の設定を“片方向”にすることで片方向型のWSDLが生成されます。
JAX-WSアプリケーションでボトムアップ開発をする場合、@Onewayアノテーションを使用し
て明示的に片方向であることを宣言している場合には、片方向型のWSDLが生成されます。
片方向型のプログラミングモデルの詳細については、『WAS V6.1 SOA Webサービス・ワー
クショップ』の「JAX-WSによるメッセージ指向プログラミング」を参照してください。
37
JAX-WSのプログラミングモデル
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 38
© IBM Corporation.
38
JAX-WSプログラミングの特徴-アノテーションによるEoD
WAS V7 W/S
WAS V7 W/S
アノテーションによってコードがシンプルに
アノテーションによって、デプロイメント・ディスクリプターは不要に
JAX-RPC 1.1 Webサービスプロバイダー例
public interface HelloService extends Remote {
public String sayHello(String name) throws RemoteException;
}
public class HelloServiceBean implements SessionBean {
public String sayHello(String name) {
return "Hello "+ name + " from HelloServiceBean";
}
}
マッピング
DD
ファイル
JAX-WS 2.1 Webサービスプロバイダー例
@WebService
public class HelloServiceBean {
public String sayHello(String name) {
return "Hello "+ name + " from HelloServiceBean";
}
}
JAX-RPC 1.1 Webサービス・リクエスター例
try {
Context ic = new InitialContext();
//JNDIルックアップ
MyHelloService myHelloService = (MyHelloService)
ic.lookup("java:comp/env/service/MyJAXRPCHello");
HelloIF helloPort = myHelloService.getHelloIFPort();
// ... サービス呼び出し ...
helloPort.sayHello();
} catch (NamingException ex) {
// ...
マッピング
} catch (RemoteException ex) {
DD
ファイル
：
JAX-WS 2.1 Webサービス・リクエスター例
public class MyComponent {
@WebServiceRef(MyHelloService.class)
HelloIF helloPort;
public void myMethod() {
// 直接ポートからサービス呼び出し
helloPort.sayHello();
}
WebSphere Application Server V7
Announcement Workshop 2008
# 39
© IBM Corporation.
JAX-WSアプリケーションは、アノテーションを使用することによって、コードをシンプルにし
てます。 JAX-WS は Java プログラミング言語 (JSR 175) 仕様のメタデータ機能、Java
Platform (JSR 181) 仕様の Web サービス・メタデータ、および JAX-WS 2.0 (JSR 224) 仕
様によって定義されたアノテーション (Java Architecture for XML Binding (JAXB) アノテー
ションを含みます) に基づいてアノテーションをサポートします。
WebServices Meta Deta（JSR181）では、JAX-WSプログラミングモデルで利用される基本
的なアノテーション規定しています。
@WebService, @WebMethod, @OneWay, @WebParam, @WebResult
@SOAPBinding, @HandlerChain (全てjavax.jwsパッケージ)
以下のアノテーションに関してはJAX-WS（JSR224）内で規定しています。
@WebServiceProvider, @WebServiceClient, @WebFault, @WebEndpoint
@ServiceMode, @RequestWrapper, @ResponseWrapper, @BindingType
@WebServiceRef (全てjava.xmlパッケージ)
また、JAX-WSアプリケーションでは、マッピング情報などはこのアノテーションで設定するた
め、JAX-RPCでは必要だったデプロメイント・ディスクリプターやマッピングファイルが必須で
はなくなりました。
39
JAX-WS 2.1のプログラミングモデル-全体像
リクエスター
プロバイダー
SEI ベースエンドポイント
動的プロキシーによる呼び出し
Service
Service
@WebService
Client
クライアントコード
クライアントコード
SEI
SEI
@BindingType
動的
動的
Proxy
Proxy
クライアントコード
クライアントコード
ServiceImpl
ServiceImpl
Bean
Bean
SEI
SEI
SOAP/HTTP
JAXB
JAXB
JAXB
JAXB
クラス
クラス
クラス
クラス
JAXB
JAXB
JAXB
JAXB
クラス等
クラス等
クラス
クラス
WAS
WAS V7
V7 W/S
W/S
@WebService
JAXB
JAXB
JAXB
JAXB
クラス
クラス
クラス
クラス
ServiceImpl
ServiceImpl
Bean
Bean
Dispatch
Dispatch
XML/HTTP
DispatchAPIによる呼び出し
@WebService
Provider
JAXB
JAXB
JAXB
JAXB
クラス等
クラス等
クラス
クラス
Provider ベースエンドポイント
Javaのオブジェクトとし
て扱いたいか、XMLそ
のものを扱いたいか
WebSphere Application Server V7
Announcement Workshop 2008
# 40
© IBM Corporation.
JAX-WSのプログラミングモデルでは、リクエスター、プロバイダーそれぞれ2パターンありま
す。リクエスターには動的プロキシーによる呼び出しとDispatchAPIによる呼び出しがあり、プ
ロバイダーには、SEIベースエンドポイントとProviderベースエンドポイントがあります。それぞ
れを組み合わせて使用することも可能ですが、基本的にXMLドキュメントをJavaのオブジェクト
として扱いたい場合には、動的プロキシーによる呼び出し×SEIベースエンドポイントでよく、
ツールによる自動生成クラスを利用できるという点で開発生産性が高いといえます。逆にXML
そのものを扱いたい場合には、 DipatchAPIによる呼び出し×Providerベースエンドポイントを
使用することになりますが、自動生成クラスは使用しないため開発の難易度も上がります。バイ
ンディングタイプとしてXML/HTTPバインディングを使用する場合には、DipatchAPIによる呼
び出し×Providerベースエンドポイントを使用する必要があります。
40
Provider
プロバイダーのプログラミング・モデル
WAS
WAS V7
V7 W/S
W/S
2種類のエンドポイントをサポート
SEI ベースエンドポイント
SEI(サービス・エンドポイント・インタフェース)経由で、サービス実装にアクセス
@WebServiceアノテーションによる宣言
OutBean hello(InBean inbean);
SEI
SEI
SOAP
ServiceImpl
ServiceImpl
Bean
Bean
@WebService
JAXB
JAXB
JAXB
JAXB
クラス
クラス
クラス
クラス
Provider ベースエンドポイント
JAX-WS 2.0 から新規追加されたXMLメッセージレベルの操作が可能なサービス
XMLもしくはSOAPメッセージを受け付けることが出来る
JAXB
@WebServiceProviderアノテーションによる宣言
JAXB
JAXB
JAXB
クラス等
クラス等
クラス
XML処理は開発者側の責任でコーディングが必要
クラス
ServiceImpl
ServiceImpl
メッセージ構造の検証は開発者コード側の責任
ツールによる自動生成は必要なし
SOAP
/XML
Bean
Bean
@WebService
Provider
T invoke(T message);
WebSphere Application Server V7
Announcement Workshop 2008
# 41
© IBM Corporation.
プロバイダーのプログラミングモデルには、2種類あります。
SEIベースエンドポイントは、JAX-RPCのSEI実装に似ています。ただし、JAX-RPC とは異
なり、 SEI はオプションになります。ボトムアップ開発の場合、関連付けられた SEI を持たない
JAX-WSサービスは、暗黙的な SEI を持っていると見なされます。それに対して、関連付けら
れた SEI を持つサービスは、明示的な SEI を持っていると見なされます。なお、トップダウン
開発の場合には、SEIは自動作成されます。 SEIベースエンドポイントは、@WebServiceアノ
テーションによって、宣言する必要があります。
Providerベースエンドポイントは、JAX-WSで新規に導入されたAPIです。SOAPはもちろん、
XMLメッセージレベルの操作が可能な点が大きな特徴です。 Providerベースエンドポイントは、
@WebserviceProviderアノテーションによって、宣言する必要があります。また、開発ツール
による自動生成を使用せず、XMLのメッセージ検証は、開発者の責任によって行う必要があり
ます。
@WebServiceアノテーションと@WebServiceProviderアノテーションは同時に利用するこ
とができません。
プログラミングモデルの詳細については、『WAS V6.1 SOA Webサービス・ワークショップ』
の「JAX-WSによるメッセージ指向プログラミング」を参照してください。
41
プロバイダー実装としてEJB3.0をサポート
Provider
New
v7
WAS
WAS V7
V7 W/S
W/S
WAS V7より、EJB3.0のWebサービス実装をサポート
EJB3.0のWebサービス化における条件
Stateless Session Beanであること
EJB3.0（もしくはそれ以上）のモジュールにパッケージすること
endptEnabler コマンドでルーター・モジュールを作成済みであること
SOAP/HTTP 及び SOAP/JMS のいずれのトランスポートも使用可能
RAD V7.5を使用して開発する場合
Webサービスウィザードでは以下の開発方法をサポート
JAX-RPC ＆ EJB3.0
ボトムアップおよびトップダウン開発
JAX-WS & EJB3.0
Stateless
トップダウン開発
SOAP/HTTP
SOAP/JMS
Router
EJB3.0
WebSphere Application Server V7
Announcement Workshop 2008
# 42
© IBM Corporation.
WAS V7より、プロバイダーの実装としてEJB3.0をサポートしました。JSR109 V1.2により規
定されています。EJB3.0のWebサービス化における条件としては、以下の３つになります。
・Stateless Session Beanであること
・EJB3.0のモジュールにパッケージすること
・ルーターモジュールが作成されていること
ルーターモジュールが必要な理由は、SOAP/HTTPアプリケーションの仕組み、SOAP/JMS
アプリケーションの仕組みで紹介したように、それぞれルーターモジュール経由でサービス実
装にアクセスする必要があるからです。endptEnablerコマンドについては、次ページ以降で説
明します。
トランスポートプロトコルとしては、SOAP/HTTP,SOAP/JMS共にサポートします。
開発ツールとしてRAD V7.5を使用している場合、JAX-WSでは、EJB3.0のボトムアップ開
発をサポートしていない点にご注意ください。
42
Provider
endptEnablerコマンドについて
WAS
WAS V7
V7 W/S
W/S
EARファイル内の一連のWebサービスで使用可能
Webサービスに対応するEJBモジュールを含むEARファイル上で実行
endptEnablerコマンドによって作成される各ルーター・モジュールが、特定のトランス
ポート用のWebサービス・エンドポイントを提供
HTTP：HTTPルーター・モジュールを追加して、WebサービスがHTTPトランスポート経由で要
求を受信することが可能
JMS：JMSルーター・モジュールを追加して、Webサービスがキューやトピックから要求を受信
することが可能
宛先の種類やアクティベーションスペックのJNDI名（もしくはリスナー・ポート）などを指
定
HTTPRouter
サービス
エンドポイント
プロバイダー
(EJB)
JMSRouter
サービス
エンドポイント
EJB
ビジネス・ロジック
WebSphere Application Server V7
Announcement Workshop 2008
# 43
© IBM Corporation.
enptEnablerコマンドは、EARファイル内の一連のWebサービスモジュールで使用できるコ
マンドになります。また、ルーター・モジュールが必要になるEJBモジュールで使用することに
なります。
enptEnablerコマンドによって作成されるルーター・モジュールは、トランスポートによって異
なります。
HTTPの場合には、HTTPルーター・モジュールを作成し、WebサービスがHTTPトランス
ポート経由で要求を受信することが可能になります。
JMSの場合には、JMSルーター・モジュールを作成し、Webサービスが指定されたキューも
しくはトピックから要求を受信することが可能になります。そのため、JMSルーター･モジュール
作成時には、宛先の種類（キュー or トピック）やルーターモジュールであるMDBの起動に
必要なアクティベーション・スペックの定義が必要になります。
43
endptEnablerコマンドの使用
Provider
WAS
WAS V7
V7 W/S
W/S
RADV7.5のWebサービスウィザードを使用して開発する場合、バックグ
ラウンドで実行されるため特に意識する必要はない
ただし、EJB3.0のJAX-WSサービスのボトムアップ開発用のWebサービス
ウィザードは用意されていない
以下の手順で作成が可能
@WebService or @WebServiceProviderおよび@Statelessアノテーションを使用したコードを作成
endptEnablerコマンドを明示的に発行
endptEnaberコマンドを明示的に発行する方法
WASの“InstallDir”/binディレクトリ
RADのエンタープライズ・エクスプローラー/サービスビューから、サービス名
を右クリック⇒生成⇒ルーター・モジュール（endptEnabler)の作成
WebSphere Application Server V7
Announcement Workshop 2008
# 44
© IBM Corporation.
endptEnablerコマンドの使用についてですが、RAD V7.5のWebサービスウィザードを使用
して開発する場合には、ウィザード実行中にバックグラウンドで実行されるため意識する必要
はありません。実際の画面については、次ページに添付しています。
ただし、JAX-WSサービスにおけるEJB3.0のボトムアップ開発においては、Webサービス
ウィザードが用意されていません。その場合には、Webサービス実装のアノテーション
（@WebService or @WebServiceProvider）およびStateless Session Beanのためのアノ
テーション（@Stateless）を使用したコードを用意し、endptEnablerコマンドを明示的に発行
することになります。
enptEnablerコマンドは、WAS、RADそれぞれで用意されています。
44
(参考）RADウィザードでのルーターモジュール作成
Provider
WAS
WAS V7
V7 W/S
W/S
Webサービスウィザードを使用する場合、
endptEnablerコマンドをバックグラウンドで
発行されているため、意識して発行する必要
はない
JAX-WSのボトムアップ開発では不可
※ウィザードの最終画面
サービスビュー/エンタープライズビューか
らサービス名を右クリック→「ルーター・
モジュール（endptEnabler）の作成」を明
示的に発行
WebSphere Application Server V7
Announcement Workshop 2008
# 45
© IBM Corporation.
RAD V7.5を使用した場合の、Webサービスウィザードを使用してendptEnablerコマンドが
バックグランウンドで実行される箇所、明示的に発行した場合のそれぞれの画面になります。
45
Requester
リクエスターのプログラミング・モデル
WAS
WAS V7
V7 W/S
W/S
2種類のサービス呼び出し方法をサポート
動的プロキシー経由の呼び出し
JAX-RPC 1.1と同様に、プロキシー経由でサービスにアクセスする呼び出し方法
JAX-RPCの静的スタブとは異なり、事前生成ではなく、実行時ServiceからgetPortした際に動的生
成(ポータビリティの向上)
Service
Service
getPort
クライアントコード
クライアントコード
JAXB
JAXB
JAXB
JAXB
クラス
クラス
クラス
クラス
動的
動的
Proxy
Proxy
SEI
SEI
SOAP
outBean hello(InBean inbean);
Dispatch経由の呼び出し
JAX-WS 2.0 から新規追加されたXMLメッセージレベルの操作が可能なリクエスター
XML/HTTPリクエストを送信することが出来る
自動生成コードは使用せず、実装コードで適切なXMLメッセージを構築
XMLメッセージ構造を正確に把握している必要がある
SOAP
XML
JAXB
JAXB
JAXB
JAXB
クラス等
クラス等
クラス
クラス
クライアントコード
クライアントコード
Dispatch
Dispatch
SOAP
XML
T invoke(T message);
WebSphere Application Server V7
Announcement Workshop 2008
# 46
© IBM Corporation.
JAX-WSクライアントのプログラミングモデルは、Dispatchクライアント API と、動的プロキ
シークライアント API の両方をサポートします。 Dispatchクライアントが、Serviceを動的に生
成するのに対して、動的プロキシークライアントは、事前生成された静的Serviceを使用します。
Dispatchクライアントおよび動的プロキシークライアントは、共に同期型呼び出し、片方向型
呼び出しと非同期型双方向呼び出しが可能です。
動的プロキシークライアントは、提供されるSEIに基づく Web サービスを呼び出します。
JAX-RPC1.1と同様にプロキシー経由で呼び出しますが、JAX-RPCの静的スタブとは異なり、
実行時にServiceからgetPort()してプロキシーを取得することになります。
Dispatch クライアントの開発は、Probiderベースエンドポイントの開発同様、ツールによる自
動生成は使用しません。そのため、実装のためにはXML 構成体に詳しい必要があり、上級
XML 開発者向けになります。メッセージ交換パターンに応じて、それぞれ必要なInvokeメソッ
ドを使用します。
同期型：Object invoke(T);
片方向型：void invokeOneway(T);
ポーリング：Response<T> invokeAsync(T);
コールバック：Future<?> invokeAsync(T, AsyncHandler);
プログラミングモデルの詳細については、『WAS V6.1 SOA Webサービス・ワークショップ』
の「JAX-WSによるメッセージ指向プログラミング」を参照してください。
46
動的プロキシーを利用したリクエスターのコード
Requester
WAS
WAS V7
V7 W/S
W/S
@WebserviceRefによるResource Injection（リソース注入）が可能
New
v7
JAX-RPCのようにJNDIルックアップは必要ない/WebサービスDD不要
Servletなどリソース注入をサポートしているコンポーネントクラスで実装
管理クライアントのみで使用可能
@WebServiceRef(HelloJAXWS_Service.class)
HelloJAXWS port;
ポートを取得するためのサービス
クラスを指定
protected void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
HelloJASWSポートのプロキ
シーを直接クライアントのクラ
try
スにインジェクション
//サービスの実行
message = port.invoke(input);
}catch(Exception e){
//例外処理
}
直接Portから
サービス呼び出し
WebSphere Application Server V7
Announcement Workshop 2008
# 47
© IBM Corporation.
JSR109 V1.2の規定により、JAX-WSクライアントサイドにおいて、Webサービス参照のた
めの@WebServiceRefアノテーションが使用可能になりました。@WebServiceRefの属性に
そのポートを取得するためのサービスクラス（この場合、HelloJAXWSServiceクラス）を指定
することで、HelloJAXWSポートのプロキシーを直接クライアントのクラスにインジェクションする
ことができます。そして、ポートから直接サービス呼び出しすることが可能です。
また、変数Serviceに対してHelloJASWSServiceをインジェクションし、
HelloJAXWSServiceクラスに用意されているHelloJAXWSポートのプロキシーを取得するた
めのgetHelloJAXWSSOAP()メソッドを利用して、HelloJAXWSポートのプロキシーを取得す
ることも可能です。その場合のコードは下記になります。
@WebServiceRef
HelloJAXWS_Service service;
public static void main(String args[]) {
HelloJAXWS port = service.getHelloJAXWSSOAP();
message = port.invoke(input);
}
@WebServiceRefを使用する上での注意点は、Java EE5の仕様で規定されたEJBや
Servletといった特定のクラスのみで使用することが可能な点になります。詳しくは、Java EE5
の仕様を参照してください。
また、@WebServiceRefアノテーションを使用したコードは、管理クライアントのみで使用で
きます。管理クライアントについては後述します。
47
（参考）動的プロキシーを利用したリクエスターのコード
Requester
WAS
WAS V7
V7 W/S
W/S
wsimportで生成されたServiceを使用して動的プロキシーを取得
事前生成された静的Serviceを使用
JAX-RPCのようにJNDIルックアップは必要ない/WebサービスDD不要
//静的サービスインスタンスの生成
HelloJAXWS_Service service = new HelloJAXWS_Service();
//動的プロキシーの取得
HelloJAXWS proxy = service.getHelloJAXWSSOAP();
//サービスの実行
try{
message = proxy.invoke(input);
}catch(UserException me){
//例外処理
}
静的Serviceのnew
静的Serviceのget[ポート名]メソッドで
SEIを実装したプロキシーを取得
サービス呼出し(同期型)
WebSphere Application Server V7
Announcement Workshop 2008
# 48
© IBM Corporation.
こちらのJAX-WSクライアントのコードは、リソース注入を使用しないコードになります。WAS
V6.1FPWS、WAS V7共に使用することができます。
静的ServiceであるHelloJAXWSServiceクラスには、HelloJAXWSポートのプロキシーを取
得するためのgetHelloJAXWSSOAP()メソッドが用意されているため、これを利用して
HelloJAXWSポートのプロキシーを取得します。プロキシーが取得できたら、後は目的のサー
ビスメソッド（ここではinvoke(userinfo)メソッド）を呼び出します。
なお、JAX-WSクライアントでも、JAX-RPCと同様にJNDIルックアップによるサービス参照を
することも可能です。
48
Requester
（参考）管理クライアントと非管理クライアント
WAS
WAS V7
V7 W/S
W/S
管理クライアント
JSR 109 により定義されるJava EE 用 Web サービスのクライアント
Java EE コンテナー内で稼働する必要がある
エンタープライズ・アーカイブ (EAR) ファイルとしてパッケージ
JSR 109 API とデプロイメント情報を使用して Web サービスを検索、呼び出し
非管理クライアント
Java EE コンテナー内で稼働せず、JAX-WS ランタイムを使用して Web サービスを呼び出す J2SE ク
ライアント
WSDL ファイルを直接検査し、JAX-WS API を直接使用して Web サービスの呼び出しを作成すること
が可能
デプロイメント情報を含まない JAR ファイルとしてパッケージ
JSR109に従います。で
もコンテナーが必要です
Java EEコンテナー
なしで動けます
管理クライアント
非管理クライアント
WebSphere Application Server V7
Announcement Workshop 2008
# 49
© IBM Corporation.
Java EE 用 Web サービスのクライアントはJSR109 により定義され、管理対象クライアント
と呼ばれます。このクライアントはJava EE コンテナー内で稼働する必要があります。このクラ
イアントは、エンタープライズ・アーカイブ (EAR) ファイルとしてパッケージされる必要がありま
す。Web サービスの管理対象クライアントでは JSR 109 API とJSR109で規定されたデプロ
イメント情報を使用して Web サービスを検索し、呼び出すことになります。
Java EE コンテナー内で稼働せずに、JAX-WS ランタイムを使用して Web サービスを呼び
出す J2SE クライアントは、管理対象外クライアントと呼ばれます。 Web サービスの管理対象
外クライアントは、WSDL ファイルを直接検査し、JAX-WS API を直接使用して Web サービ
スの呼び出しを作成することができ、独立型の Java クライアントになります。このクライアントは、
デプロメイント情報は必要なく、JAR ファイルとしてパッケージされます。
49
クライアントDDによるアノテーション定義のオーバーライド
Requester
WAS
WAS V7
V7 W/S
W/S
JAX-WSでは、WSDLファイルのロケーションやサービス参照は基本
的にアノテーションで定義
WebサービスDDの作成はオプション
クライアントのWebサービスDDで、サービス参照の設定が可能
@WebServiceRefアノテーションの定義を上書きすることが可能
New
v7
WebサービスDDを使用している場合は、Java EE環境にデプロイの必要あり
WebSphere Application Server V7
Announcement Workshop 2008
# 50
© IBM Corporation.
JSR109 V1.2の規定により、クライアントのデプロメイント・ディスクリプターにより、サービス参
照の定義をすることが可能になりました。さらに、@WebserviceRefや@Resourceといったア
ノテーションで定義された内容を上書きすることが可能です。
デプロメイント･ディスクリプターを使用している場合には、Java EEコンテナー上で稼動させ
る必要があります。
50
非同期型双方向プログラミングモデル
Requester
WAS
WAS V7
V7 W/S
W/S
リクエスター側での呼び出し方に依存
動的プロキシー
クライアント開発時に非同期オプションを選択することで、SEIにオペレーションごとに
ポーリングとコールバック用の２タイプの非同期メソッドが追加される
Dispatch
非同期用のinvokeAsyncメソッドを使用
ポーリング：Response<T> invokeAsync(T);
コールバック：Future<?> invokeAsync(T, AsyncHandler);
非同期メソッドのタイプ
ポーリング
メソッドコール時には処理結果を待たないが、後の任意の箇所で取得する方法
Response.isDone()でレスポンス取得状況を確認し、レスポンスが返っていればget()メ
ソッドで取得
コールバック
イベントドリブンで呼ばれるAsyncHandlerクラスのhandleResponseメソッド内にレスポ
ンス処理ロジックを記述
ポーリングモデル同様にサービス呼出し元クラスで結果を取得することも可能
WebSphere Application Server V7
Announcement Workshop 2008
# 51
© IBM Corporation.
非同期型双方向プログラミングは、リクエスターの呼び出し方に依存します。
動的プロキシーを利用する場合には、クライアント開発時に、Webサービスウィザードで「生
成されたクライアントの非同期呼び出しを使用可能にする」にチェックをいれることで、SEIにオ
ペレーションごとのポーリングとコールバック用のメソッドが追加されます。
Dispatchクライアント使用する場合には、非同期用のinvokeAsyncメソッドを使用します。
ポーリングは、メソッドコール時には処理結果を待ちませんが、後で任意の箇所で取得するこ
とになります。Response.isDone()でレスポンス取得状況を確認し、レスポンスが返っている場
合には、Response.get()メソッドで結果を取得することになります。ポーリングの場合の返り値
はResponse＜T＞になります。
コールバックは、レスポンスが返るとイベントドリブンで呼ばれるAsyncHandlerクラスの
handleReponseメソッド内に、レスポンス結果の処理ロジックを記述することになります。コー
ルバックはの返り値はFuture＜？＞になります。
なお、ポーリング同様にサービス呼び出し元クラスで結果を取得する場合には、
Future.isDone()でレスポンス取得状況を確認し、Response.get()メソッドで結果を取得します。
プログラミングモデルの詳細については、『WAS V6.1 SOA Webサービス・ワークショップ』
の「JAX-WSによるメッセージ指向プログラミング」を参照してください。
51
Standard SOAP/JMSのサポート
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 52
© IBM Corporation.
52
New
v7
Standard SOAP/JMSのサポート
WAS
WAS V7
V7 W/S
W/S
WAS V6.1まではIBM拡張の実装で提供
異なるベンダーとの通信は保証されない
IBM proprietary SOAP/JMS
IBM
only
Service
Client
IBM
only
WAS V7より Worldwide Web Consortium (W3C) のSOAP/JMS 仕様が
（相互運用性のためのガイドラインを提供）ベース
SOAP over Java Message Service 1.0（SOAP/JMS)勧告に向けて標準化が進め
られている
http://www.w3.org/Submission/SOAPJMS/
WebSphere以外のJava EE 実行環境とSOAP/JMS通信が可能に！
standard SOAP/JMS
Any
Web service
environment
IBM
Client
Service
WebSphere Application Server V7
Announcement Workshop 2008
# 53
© IBM Corporation.
WAS V6.1まで、SOAP/JMSはIBM拡張で実装されており、異なるベンダーとの通信は保証
されていませんでした。WAS V7より、W3標準のSOAP/JMSをベースに実装されています。こ
れにより、WebSphere以外(異なるベンダー）のJava EE実行環境で、SOAP/JMSを使用した
通信が可能になります。繰り返しになりますが、SOAP/JMSはWS-Iには準拠していないため、
すべてのWebサービス環境で相互運用性が保証されているわけではありません。（例 .NET
など）
（参考）
http://www.w3.org/Submission/SOAPJMS/
SOAP-JMS Binding Working GroupによるSOAP/JMS1.0勧告に向けてのスケジュール
・June 2008: First public draft
・September 2008: Last Call draft
・December 2008: Candidate Recommendation draft
・March 2009: Proposed Recommendation draft
・April 2009: W3C Recommendation
53
Standard SOAP/JMSの使用
WAS
WAS V7
V7 W/S
W/S
Standard SOAP/JMS
JAX-RPCおよびJAX-WSのどちらもサポート
クライアントとWebサービスは、JMSキューもしくはJMSトピックを利用して通信
EJBコンテナー
Webサービス
リクエスター
Router
MDB
Queue
SOAP/JMS
Queue
Web
サービス
プロバイダー
(Stateless
Session
Bean)
SOAP/JMSにおけるベスト・プラクティス
WAS V7より、IBM拡張のSOAP/JMSは非推奨
Standard SOAP/JMSを使用することが推奨
WAS V6.1以前の製品上のクライアントアプリケーションから呼び出す必要がある場合、
IBM拡張のSOAP/JMSを使用
WebSphere Application Server V7
Announcement Workshop 2008
# 54
© IBM Corporation.
Standard SOAP/JMSを使用することで、クライアントとサーバーが異なるベンダーで構成さ
れる混合環境においても、JMSトランスポートを使用したSOAPメッセージのやりとりの相互運
用性を保証してします。また、JAX-RPCおよびJAX-WS共にサポートされます。
選択方針になりますが、基本的にはStandard SOAP/JMSを使用するようにしてください。
IBM拡張の実装については、WAS V7以降非推奨になります。ただし、WAS V6.1以前の製
品上のクライアントから呼び出す必要がある場合には、IBM拡張のSOAP/JMSを使用するよう
にしてください。
54
（参考）JAX-WSによる非同期型双方向×SOAP/JMS
WAS
WAS V7
V7 W/S
W/S
非同期型双方向とSOAP/JMS
JAX-WSクライアントは、非同期プログラミング（コールバック or ポーリン
グ）
要求メッセージは、ルーターモジュール（MDB）経由でプロバイダー処理
応答メッセージは、JMS非同期応答メッセージリスナー経由で処理
SOAP/JMS
コールバック
リクエスト
処理
続行
Request Destination
JMSによるメッセージ送信
リクエスト
JMSによるメッセージ受信
Reply Destination
レスポンス
JMS
Listener
Service
Messaging Provider
Client
JMSによるメッセージ受信
レスポンス
ルーター
モジュール
（MDB）
JMSによるメッセージ送信
(メッセージ受信後、別スレッドの
ハンドラーが受け取り、処理)
■デフォルトでは、Replyキューとして一時キューを使用
WebSphere Application Server V7
Announcement Workshop 2008
# 55
© IBM Corporation.
非同期型双方向とSOAP/JMSプロトコルを組み合わせた場合のアーキテクチャになります。
非同期型双方向では、コールバックとポーリングを使用することができます。
要求メッセージは、Requestキューを介し、ルーターモジュール（MDB）経由でStateless
Session Beanで実装されたプロバイダー処理を行います。
応答メッセージは、Replyキューを介してJMS非同期応答リスナー経由で、リクエスターに戻
ります。コールバックの場合には、メッセージ受信後にハンドラーが起動することになります。
なおReplyキューは、デフォルトでは一時キューが使用されることになります。
55
Standard SOAP/JMS のエンドポイントURLの指定
WAS
WAS V7
V7 W/S
W/S
WSDLの<port＞タブで指定
SOAP/JMSでは、WSDLファイルが必須
WSDLファイルの作成がオプションであるJAX-WSアプリケーションでも必要
☺WSDLファイルの抜粋
<wsdl:service name="HelloBeanService">
<wsdl:port binding="impl:HelloBeanJMSSoapBinding" name="HelloBeanJMS">
<wsdlsoap:address location="jms:jndi:jms/soapjmsQueue?jndiConnectionFactory
Name=jms/soapjmsQCF&targetService=HelloBeanJMS"/>
</wsdl:port>
</wsdl:service>
locationは、”jms”接頭辞で始まる
※WSDLを公開する際、“HelloBeanJMS”PortがJMSPortであることを識別
「jndi:」に、JMSキューのJNDI名がつづく
「jndiConnectionFactory」にName=でキュー接続ファクトリーのJNDI名がつづく
WebSphere Application Server V7
Announcement Workshop 2008
# 56
© IBM Corporation.
Standard SOAP/JMSのエンドポイントURLの指定方法になります。アドレスは、WSDLの
<port>タブで定義されます。ボトムアップ開発時には、Webサービスウィザードに沿って宛先
のJNDI名やキュー接続ファクトリー名を入力すると、標準の規定に則って出力されます。
また、SOAP/JMSではWSDLファイルが必須になります。JAX-WSアプリケーションでは
WSDLの作成がオプションとなっていますが、SOAP/JMSの場合には必ず用意する必要があ
ります。
locationが、”jms”という接頭辞ではじまりますが、これによりWSDLを公開する際、このポート
がJMSポートであることを識別します。”jndi:”に続き、JMSキューのJNDI、
“jndiConnectionFactory”に、キュー接続ファクトリーのJNDI名が続きます。最後にプロバイ
ダーのサービス名が入ります。これらは必須の項目になります。
参考までに、IBM拡張のSOAP/JMSバインディングのWSDLの抜粋を添付します。
<wsdl:service name=“HelloBeanService">
<wsdl:port binding="impl:HelloBeanJMSSoapBinding" name=“HelloBeanJMS">
<wsdlsoap:address
location="jms:/queue?destination=jms/soapjmsQueue&connectionFactory=jms/so
apjmsQCF&targetService=HelloBeanJMS"/>
</wsdl:port>
</wsdl:service>
56
Standard SOAP/JMS のエンドポイントURL
WAS
WAS V7
V7 W/S
W/S
Standard SOAP/JMSエンドポイントURLの構文
jms:jndi:<desination-jndi-name?><property>=<value>&<property>=･･･
jms：トランスポートタイプ
jndi:宛先キューもしくはトピックのJNDI名の明記
URL定義をサポートするためのプロパティ
☺宛先に関するプロパティ（必須）
Property name
Description
jndiConnectionFactoryName
メッセージングエンジンへの接続を確立するために使用されるコ
ネクションファクトリーのJNDI名
targetService
リクエストがディスパッチされるポート名の特定
☺JNDIに関するプロパティ（オプション）
☺JMSに関するプロパティ（オプション）
jndiInitialContextFactory
priority
jndiURL
deliveryMode
replyToName
timeToLive
WebSphere Application Server V7
Announcement Workshop 2008
# 57
© IBM Corporation.
Standard SOAP/JMSエンドポイントURLの構文になります。ボトムアップ開発時に生成され
たWSDLに情報を付加する際、トップダウン開発時にはこの構文に則って記述する必要があり
ます。
57
MTOM（Message Transmission Optimization Mechanism）
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7
Announcement Workshop 2008
# 58
© IBM Corporation.
58
MTOMによるバイナリーデータ転送
WAS
WAS V7
V7 W/S
W/S
MTOM (Message Transmission Optimization Mechanism)
2005年1月26日にW3C勧告として公開
WS-I Basic Profile 1.2に組み込まれる
SOAP1.1/SOAP1.2いずれのバインディングも規定
SOAPメッセージにバイナリーデータの添付を行うテクノロジー
XOPを利用したバイナリーデータの送受信を可能とする
SwA (SOAP with Attachments)と異なり.NETとの互換性あり
WS-Securityと併用可能（XMLInfosetに対応）
デフォルトで、HTTP Chunkingを採用
イメージデータ
イメージデータ
プロバイダー
リクエスター
MTOM
SwA
SOAPMessage
Base64
DIME
WebSphere Application Server V7
Announcement Workshop 2008
# 59
© IBM Corporation.
分散コンピューティング環境では、バイナリーデータを使用したやりとりも頻繁に行われること
が想定されます。バイナリーデータを扱う技術としては、歴史的に多くの技術がありました。ま
ず代表的なものにBase64がありますが、Base64Encodeを使用して文字列として送るため、
SOAPのメッセージサイズが大きくなってしまうという問題がありました。そこで、SOAPにデータ
を添付するという解決を行ったDIMEやSwAというテクノロジーが登場しました。しかし、SwAは、
添付データにWS-Securityが使用できない、.NETとの互換性がないといった問題点がありま
した。またDIMEは、W3Cでの有効期限が切れており、実質採用できない技術となっています。
MTOMはこれらの問題をすべて解決してます。またMTOMの特徴として、XML-binary
Optimized Packaging (XOP) を使用することによるバイナリー・メッセージ送信の最適化を提
供し、XMLInfosetの概念を取り入れています。
またWAS V7より、デフォルトでHTTP Chunkingを採用しています。
59
MTOMの使用方法
WAS
WAS V7
V7 W/S
W/S
プロバイダ側
プロバイダ側のバインディングとして以下のいずれかを指定
@BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING)
@BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
リクエスタ側
javax.xml.ws.soap.SOAPBinding#setMTOMEnabled()を使用
Service#addPort()を使用してMTOMを有効化（Dispatchのみ）
MTOMFeatureを使用
New
v7
base64Binary、もしくはhexBinaryで定義されたフィールドが自動的にMIMEの別
パートとしてパッケージングされる。
WebSphere Application Server V7
Announcement Workshop 2008
# 60
© IBM Corporation.
MTOMのプログラミングモデルになります。Webサービスウィザードを使用して、「MTOMの
使用可能可」を設定することも可能です。詳細は、『WAS v6.1 SOA Webサービスワーク
ショップ資料』の「MTOM」を参考にしてください。
プロバイダーのプログラミングモデルでは、サーバーのエンドポイント実装クラスで、
@BindingTypeアノテーションを設定することで、応答メッセージをMTOMにすることが可能で
す。値としては、SOAP1.1を使用するか、SOAP1.2を使用するかによって2種類用意されてい
ます。
リクエスターのプログラミングモデルとしては、3種類あります。MTOMFeatureを使用する方
法は、WAS V7よりサポートされました。これは、JAX-WS 2.1から使用できるようになった
Featureクラスを使用した設定方法になります。Dispatchクライアントでは、
SOAPBinding.setMTOMEnabled()を使用、もしくは
Service.addPort(SOAPBinding.SOAP11HTTP_MTOM_BINDING）を使用、もしくは
MTOMFeatureを使用することができます。動的プロキシークライアントでは、
SOAPBinding.setMTOMEnabled()もしくは、MTOMFeatureクラスが使用できます。
60
（参考）リクエスタでのコーディング例
WAS
WAS V7
V7 W/S
W/S
Dispatchの場合
setMTOMEnabled() を使った例
SOAPBinding binding = (SOAPBinding)dispatch.getBinding();
binding.setMTOMEnabled(true);
addPort()を使用した例
Service svc = Service.create(serviceName);
svc.addPort(portName,SOAPBinding.SOAP11HTTP_MTOM_BINDING,endpointUr
l);
MTOMFeatureを使用した例
New
v7
MTOMFeature mtom = new MTOMFeature();
Service svc = Service.create(serviceName);
svc.addPort(portName,SOAPBinding.SOAP11_HTTP_BINDING,endpoin
tUrl);
Dispatch<Source> dsp =
svc.createDispatch(portName,Source.class,Service.Mode.PAYLOAD,
mtom);
WebSphere Application Server V7
Announcement Workshop 2008
# 61
© IBM Corporation.
61
（参考）リクエスタでのコーディング例
WAS
WAS V7
V7 W/S
W/S
動的プロキシの場合
setMTOMEnabled()を使った例
Service svc = Service.create(serviceName);
MtomSample proxy =
svc.getPort(portName,MtomSample.class);
BindingProvider bp = (BindingProvider) proxy;
SOAPBinding binding =
(SOAPBinding)bp.getBinding();
binding.setMTOMEnabled(true);
MTOMFeatureを使用した例
New
v7
MTOMFeature mtom = new MTOMFeature();
MtomSample proxy = svc.getPort(portName,MtomSample.class,
mtom);
WebSphere Application Server V7
Announcement Workshop 2008
# 62
© IBM Corporation.
62
Summary
WAS
WAS V7
V7 W/S
W/S
WAS V7では、Webサービス仕様の最新バージョン（JAX-WS2.1、
JAXB2.1）をサポート
WAS V7では、JSR109 V1.2をサポート
EJB実装によるJAX-WSアプリケーションの作成が可能
JAX-WSクライアントにおいて、サービス参照のためのアノテーション
（@WebServiceRef）が使用可能
WAS V7では、IBM拡張で実装されていたSOAP/JMSが、W3C準拠の
Standard SOAP/JMSに変更
WebサービスのトランスポートプロトコルはHTTP or JMSの選択が可能
メッセージ交換パターン（同期型、片方向型、非同期型双方向）の選択が
可能
JAX-WSでは、非同期型プログラミング（コールバック、ポーリング）を
サポート
JAX-WS2.1では、Featureクラスのサポート
例）MTOMFeature
WebSphere Application Server V7
Announcement Workshop 2008
# 63
© IBM Corporation.
63
Reference
WAS
WAS V7
V7 W/S
W/S
WAS V6.1 SOA Webサービスワークショップ資料
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_soa_ws/
EJB 3.0 Feature Pack for WAS V6.1 ワークショップ資料
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_ejb3fep_ws/
SOA Webサービス及びESB基盤構築ワークショップ資料
http://www.ibm.com/developerworks/jp/websphere/library/esb/soainfra_ws/
WAS V6.1 WebSphere Application Server 最新動向ワークショップ（2007年4月版）
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_updatews/
WebSphere Application Server V6.1による基幹システム設計ワークショップ資料
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_guide/
JSR-000244 JavaTM Platform, Enterprise Edition 5 Specification
http://jcp.org/aboutJava/communityprocess/final/jsr244/index.html
JSR-000109 Implementing Enterprise Web Services
http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index.html
The Java API for XML-Based Web Services (JAX-WS) 2.1
http://jcp.org/en/jsr/detail?id=224
The Java API for XML-Based RPC(JAX-RPC)1.1
http://jcp.org/en/jsr/detail?id=101
WSDL 1.1
http://www.w3.org/TR/wsdl
Basic Profile 1.1
http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Basic Profile 1.2
http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html
WAS V7 Information Center
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.html
WebSphere Application Server V7
Announcement Workshop 2008
# 64
© IBM Corporation.
64

Webサービス ～Application～ 1 日本IBMシスエムズ・エンジニアリング(株)

Comments

Description

Transcript

Webサービス～Application～ 1 日本IBMシスエムズ・エンジニアリング(株)