1.2. プログラミング・開発ガイド

1.2.1. Webサービスを開発する前に

このマニュアルを読む前に、まずはWebサービスの基本技術であるXML、SOAP、WSDL、そしてUDDIについてある程度理解してください。その後、このマニュアルを読んでWebサービスを開発する前に、SOAPの持っているいくつかの性質、WS-Iの意味、Java EE のWebサービスランタイム（実行基盤）の特長、Webサービス周辺の技術を知っておく必要があります。ここではまず、これらのキーワードについて説明します。また、以前のバージョンのプロジェクトの移行手順についてもここで説明します。

1.2.1.1. SOAP仕様のバージョン

Java EE が対応しているSOAP仕様のバージョンは、1.2と1.1です。この2つのバージョン間にはゆるい互換性しかなく、ある特定の条件下でなければ接続できません。1つのWebサービスを開発して両方のバージョンに対応することができないことに注意してください。

1.2.1.2. JAX-WSとJAX-RPC

JAX-WSとJAX-RPCはSOAPやWSDLに関するランタイムです。JAX-RPCは旧互換のために存在しており、新規に WebサービスやWebサービスのクライアントを作るときはJAX-WSを利用してください。JAX-WSは、JAX-RPCの後継仕様です。そのため、JAX-RPCの多くの問題点が解決されており、機能も充実しています。ただし、SOAP 1.1のRPC/encodedを使用する場合は、JAX-RPCを利用しなければなりません。また、JAX-WSがSOAP 1.2と1.1の両方に対応しているのに対し、JAX-RPCはSOAP 1.1にしか対応していないので注意してください。

1.2.1.3. DocumentとRPC

SOAP仕様では、DocumentとRPCという2つのメッセージ形式が定義されています。Documentは任意の書式と内容を持つXML文書をSOAPメッセージに封入するという定義です。相互接続性の点で有利なため、通常はDocument形式を選択することをおすすめします。RPCはその名の通りSOAPでRPCを実現するための定義で、SOAP仕様でSOAPメッセージに封入するXML文書の書式（XMLスキーマ）とXML文書の内容に使用できるデータの形式（型）が規定されています。XML文書の書式を意識せず、従来のRPCの感覚で開発できるという利点があり、多くのWebサービスがRPCで作られてきたという歴史がありますが、現在は相互接続性の点で不利なため、RPC形式の新規利用は減っています。
JAX-RPCはJavaとXMLの対応づけの方法が限られており、RPCに沿ったSOAPメッセージしか送受信できません。JAX-RPCが対応しているDocument形式とは、WSDLにRPCのXMLスキーマ定義を丁寧に書き出すことを意味しています。それに対し、JAX-WSは完全に任意の書式を持つXML文書を封入したSOAPメッセージの送受信、およびWSDLの解釈ができます。

1.2.1.4. literalとencoded

Document/literal、RPC/literal、RPC/encodedという表現がよく用いられます。literalとはSOAPメッセージに封入するXML文書の個々の内容について型の定義を書かないことを意味します。つまり、WSDLでXML文書の書式をあらかじめ決めておき、要素の内容（TEXT）や属性の値が何の型なのかをSOAP通信する前に知っておかなければならないということです。一方、encodedはSOAPメッセージに封入するXML文書の個々の内容について型の定義を書くことを意味します。これは、SOAP仕様で決められたXMLスキーマを暗黙のうちに利用し、厳密にインタフェースを決めなくてもすぐにRPCが実現できるようにするための仕掛けです。しかし、インタフェースを厳密に定義せずに動的にXML処理するには処理速度に難があり、JavaBeanのような構造体や配列を用いたときの相互接続性に問題があることがわかり、literalが推奨されるようになりました。現在はWSDLが普及し、静的にXML文書を処理する仕組みが採用されることが多いためliteralにすることに問題はなく、encodedにしてわざわざ型の定義をSOAPメッセージ中に書くことが不自然であると考えられるようになりました。
このような経緯から、JAX-RPCの後継であるJAX-WSはDocument/literalとRPC/literalのみに対応しています。JAX-RPCはDocument/literal、RPC/literal、RPC/encodedすべてに対応しています。

1.2.1.5. wrapped と unwrapped

Document形式のWebサービスでは、WSDLで定義するオペレーション名と、ペイロード（SOAP Bodyの中身）のルート要素名の関係を表すwrappedとunwrappedという用語があります。wrappedとは、ペイロードのルート要素名がWSDLで定義したWebサービスのオペレーション名と一致することを表します。この関係はSOAP仕様のRPC形式との互換性がある可能性があることを意味します。RPC形式と完全に互換性があるかどうかは、WSDLに記述されたXMLスキーマがSOAP仕様のRPCと互換性があるかどうかを調べなければなりません。一方、unwrappedは、ペイロードのルート要素名がWSDLで定義したWebサービスのオペレーション名と一致しないことを表します。
どちらにせよペイロードに書かれるXMLの書式はWSDLの中で定義されたXMLスキーマに従うため、wrappedかunwrappedかということがSOAPメッセージに影響を与えることはありません。

1.2.1.6. WS-I

WS-IはWeb Services InteroperabilityOrganizationの略称で、Webサービスの相互接続性を向上させるためにはどうしたらよいかということを様々な角度から検証している団体です。W3CやOASISなどの仕様策定団体で策定されたWebサービスの基本仕様を元にしたガイドライン、サンプルアプリケーション、テストツールなどを提供しています。Java EE 5ではWS-Iが示している各種ガイドラインに沿った実装を行うことができなければならないとしています。JAX-WSを利用してWebサービスを開発すると、WS-Iが示しているガイドラインを意識しなくてもそれに沿った実装ができる仕組みになっています。JAX-RPC利用時でも、WebOTX ASとWebOTX Developerでは開発時にWS-I Basic Profileへの対応を簡単にするWS-Iモードをウィザードとコマンドに設けているため安心です。

1.2.1.7. SAAJ

SAAJはJAX-WSやJAX-RPCの基盤として位置づけられているSOAPメッセージを扱うための低レベルAPIです。通常、SOAPはJAX-WSやJAX-RPCを使えば特にXMLを意識することはありませんが、何らかの理由でXMLレベルでSOAPを扱いたいときにSAAJを利用します。SAAJはSOAPメッセージをJavaで扱うためのAPIです。SAAJを使うと、SOAPメッセージの内容を取り出したり、SOAPメッセージをゼロから作成したり、作成したSOAPメッセージをHTTPにて送付することができます。また、JAX-WSやJAX-RPCと同様にHTTPの添付ファイルを扱えるほか、HTTP（MIME）ヘッダへアクセスできます。

1.2.1.8. Fast Infoset、Fast Web Services

Fast Infoset は、W3Cで標準仕様となっているXML Information SetのインスタンスをASN.1バイナリエンコーディングするバイナリXMLフォーマットの一種で、ITU-T Rec. X.891 、ISO/IEC 24824-1という二つの標準仕様として規格化されています。バイナリXMLは、通常のテキストで表記するXMLに比べ、サイズが圧縮され、解析処理速度が向上します。ただし、可読性がなくなる、XMLスキーマに対して妥当にならないためXMLスキーマバリデーションができない、ということに注意が必要です。
WebOTXのSOAPランタイムは、JAX-WS、JAX-RPC共に、SOAPエンベロープをFast Infosetで表現する部分でFast Web Services 仕様 (ITU-T Rec X.892) に対応しています。HTTP/SOAPメッセージにFast Web Services を適用すると、XML解析処理速度が向上し、システムのパフォーマンス向上に貢献します。また、通常のHTTP/SOAPよりもメッセージサイズが圧縮されるため、通信効率が向上し、ネットワーク環境に与える負荷が軽減されます。WebOTXのSOAPランタイムでは、簡単な設定またはコーディングのみでSOAPエンベロープをFast Infosetにすぐ切り替えられます。また、WebOTX同士でなくてもFast Web Services、Fast Infosetに対応したSOAPランタイムを持つプラットフォームであれば、相互運用ができます。

1.2.1.9. RSS/Atom、REST/RESTful

SOAPはXML文書をやり取りするための「封筒」として作られました。そして、セキュリティ、高信頼性、トランザクションなどSOAPとWSDLをビジネスシーンで活用するための付加仕様（いわゆるWS-**）が続々と決められています。一方、XML文書の書式が標準規格で決まっていてXML文書の内容が明確である、XML文書で情報をHTTPまたはHTTPSで送受信するだけである、という場合、SOAPとWSDLの組み合わせでは使い勝手やパフォーマンスが悪いのでもっと簡単にXMLを扱いたいという場面が増えていることも確かです。そこで、RSS/Atomフィード、REST/RESTfulなどの新しい手段が続々登場しています。XMLで実現したい内容をよく見極めて、手段を選択してください。
RSS/Atomフィード、REST/RESTfulはサーブレットで実装します。サーブレットの中ではXMLを直接処理しなければなりませんが、Java EE 5 ではXMLを処理するためのAPIとしてJAXPが用意されているため、Javaで簡単にDOM、SAX、StAXを利用することができるので安心です。

1.2.1.10. Ajax

Ajaxは、Webブラウザに搭載されているJavaScriptのHTTP通信機能を使ってサーバと非同期にXMLをやり取りする仕組みのことです。JavaScriptのHTTP通信は同期と非同期、プレーンテキストとXMLに対応していすが、Ajaxはその機能の一部を集めて一般名称として再呼称したものです。AjaxではDOM APIが使えるほか、SOAPやRSS/Atomフィードを扱うためのモジュールがたくさん公開されています。これからWebアプリケーションを作るとき、Ajaxは重要な選択肢になります。ただし、Ajax (JavaScript) はブラウザによって機能や動作が違うことがあること、ドメイン境界を越えられないこと、などの様々な制限があることに留意しておく必要があります。

1.2.1.11. SOA、SaaS、ASP、クラウドコンピューティング、WebOS

Webサービスの実用化が進み、Webサービスの登場よりも前に生まれていたサービス指向のアプリケーション設計手法であるSOAが見直されるようになりました。SOAは設計手法の一つであるため、Webサービス、SOAP、XMLなどとの直接のかかわりはなく、Webサービス＝SOAではありません。
SaaSやASPは、ソフトウェア（アプリケーション）の（ユーザが）必要な機能のみを（ユーザが）選択して提供すること、それを利用してソフトウェア（アプリケーション）を提供することです。自分で作りこみ、巨大なシステムを抱え込まずとも、提供されているサービスを呼び出し、カスタマイズし、組み合わせれば自分が作りたいアプリケーションが作れてしまうという大変便利な仕組みです。組み合わせる（融合させる）という部分を特に「マッシュアップ」と呼ぶこともあります。しかし、サービス提供元（サービスプロバイダ）の信頼性、サービスそのものの信頼性、セキュリティ、サービス連携の難しさなど、よいところばかりで問題がないというわけではありません。また、ASPはもちろんのこと、SaaSも提供形態をWebサービスとは特定していません。
クラウドコンピューティングとは、ハードウェア、OS、ネットワークインフラ、ミドルウェア、ストレージ、データベースなどのあらゆるリソースを仮想化して提供するという思想のことで、SaaS形式のサービスを安価に開発、提供できる基盤技術として注目を集めています。ただし、クラウドコンピューティングは大規模システムの構築にはやや不向きという傾向があるほか、情報漏えいや認証連携などのセキュリティ面の課題が残されているため、導入には注意が必要です。なお、ハードウェア、OS、ネットワークインフラを合わせるとネットワーク上の仮想OSと見なせることから、これを特に「WebOS」と呼ぶことがあります。

1.2.1.12. UDDI、JAX-R

UDDIは、Webサービスの内容やインタフェースを登録、公開、参照するための手段です。また、Webサービスの内容やインタフェースを登録しておくリソースをUDDIレジストリと言います。 Java EE に含まれるJAX-RはUDDIレジストリのようなリソースにアクセスするためのAPIを整備したものです。

1.2.1.13. JAX-RS

JAX-RS (Java API for RESTful Web Services) は、JSR 311で規定されています。この JSR 311 は、REST スタイルの Web サービスの開発を単純化する一連の API を提供することを目的にしています。JAX-RS は従来の SOAP ベースの Web サービスに代わる有効な手段とされています。

1.2.1.14. マイグレーション

旧バージョンのWebOTX、他社製アプリケーションサーバ、オープンソースソフトウェアなどを使ってWebサービスを構築した方が、WebOTX Application Server V9.xにアップグレードまたは移行する手順を説明します。
WebOTX V8.xからのアップグレード
V8で使用しているWebサービスアプリケーションは、WebOTX Application Server V9.xに配備する場合、特に作業は必要ありません。お持ちのWebサービスアプリケーションはそのまま配備して使用できます。
WebOTX V7.xからのアップグレード
WebOTX V8.x以降では WebOTXV7.x までに使用していた「Webサービスプロジェクト」が廃止になりました。 そのため、WebOTX V7.x までに使用していた「Webサービスプロジェクト」は次の手順で WebOTX V9.xの プロジェクトに移行してください。

WebOTX Developer’s Studio のメニューから、ファイル > インポート を選択し、 プロジェクトのインポートダイアログを起動します。
一般 > 既存プロジェクトをワークスペースへを選択し、 次へ をクリックします。
旧バージョンで生成した既存プロジェクトを選択し、 完了 をクリックします。


図1.2.1.13-1

プロジェクトのビルドパスを修正します。上記プロジェクトを選択し、右クリックメニュー プロパティー を選択します。


図1.2.1.13-2


プロジェクトの Javaのビルド・パス ページで、ライブラリーを次のように修正します。
次のライブラリーを削除します。


図1.2.1.13-3

修正したプロジェクトを選択し、右クリックメニュー マイグレーション を選択します。


図1.2.1.13-4

プロジェクト名に変換後のプロジェクトの名前を指定します。プロジェクトは、デフォルトでは
<WebOTX_DIR>\Studio\workspace\指定したプロジェクト名
というフォルダに作成されます。もし、別の場所に作成したい場合は、 デフォルトの使用 をOFFにして、任意の場所を絶対パスで指定します。
以上の設定を終了したら、 完了 をクリックして、マイグレーションを開始します。


図1.2.1.13-5

マイグレーションで生成した Migration_web_01 プロジェクトを選択し、右クリックメニュー プロパティー を選択して、 Javaのビルド・パス ページで、ライブラリーの追加 > サーバー・ランタイムで、次のライブラリーを追加して、OK をクリックします。
WebOTX Application Server v9(Local Default)が定義されていない場合、以下のライブラリーを追加します。


図1.2.1.13-6

なお、V7.x で作成済みのWebサービスアプリケーションはそのまま V9.x に配備して使用することができます。
WebOTX V6.xからのアップグレード
V6.x で使用している「Webサービスプロジェクト」は、V7.x からの移行と同様に変換が必要です。「WebOTX V7.xからのアップグレード」を参照して下さい。
V6ランタイムを使用したWebサービスをWebOTX Application Server V9.xに配備する場合、特に作業は必要ありません。お持ちのWebサービスアプリケーションはそのまま配備して使用できます。
V5ランタイムを使用したWebサービスはWebOTX Application Server V9.xでは動作しません。WebOTXDeveloper V9.xのWebサービス作成ウィザードでWebサービス化をやり直してください。
WebOTX V5.x、V4.xからのアップグレード
WebOTX V5.x、V4.x用に作成したWebサービスはWebOTX Application Server V9.xでは動作しません。WebOTX Developer V9.xのWebサービス作成ウィザードでWebサービス化をやり直してください。
他社製品やオープンソースソフトウェアからの移行
WebOTX V5.1、V4.2、V4.1からのアップグレードと同じ方法で移行してください。
Web Service Director 1.0/1.0a からの移行
Web Service Director 1.0または1.0aのプロジェクトをWebOTX Developer V9.xのプロジェクトに移行することはできません。WebOTX Developer V9.xのWebサービス作成ウィザードでWebサービス化をやり直してください。