Comments
Transcript
Webサービス基盤設計 1 WASV6.1による基幹システム設計Workshop
WASV6.1による基幹システム設計Workshop Webサービス基盤設計 1 当セッションの目的 Webサービスの基盤設計のポイントを理解する WAS上で、Webサービス・アプリケーションを稼動させる場合のインフ ラ、非機能要件の設計ポイントの理解 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー、トランザクション設計 Webサービスのアプリケーション設計・開発は除く 2 2 Agenda Webサービス基盤概説 Webサービス基盤設計 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー、トランザクション設計 WAS V6.1 Feature Pack for Web Services 3 3 Webサービス基盤概説 4 4 Webサービスとは XMLベースの分散コンピューティング技術 サービスのインターフェースをWSDLで公開 サービスの利用性の向上 メッセージ・フォーマットとしてSOAPを使用 特定の通信プロトコルへの依存性を排除 XMLを言語として使用 特定技術への依存性を排除 WSDLと実装言語とのマッピングによって実装言語に依存しない(Javaと.NETなど) XMLで記述された インターフェース Webサービス サービス リクエスター Program (アプリ開発者が作成) Webサービス サービス Runtime (J2EE環境など たとえばWASが提供) 実装言語⇔XML WSDL ファイル SOAP Message Webサービス サービス プロバイダー Program (アプリ開発者が作成) Webサービス サービス Runtime (J2EE環境など たとえばWASが提供) XML⇔実装言語 5 Webサービスという用語に決まった定義は存在しませんが、XML言語をベースとした分散コンピューティ ング技術と言うことができます。 特徴としては、サービスの利用性の向上があります。サービスのインターフェースをWSDLで公開するこ とによって、Webサービス・リクエスター(サービスを利用する側)はWebサービス・プロバイダー（サービスを 提供する側）の実装内容や場所を気にすることなくWSDLの情報のみに従ってサービスを呼び出すことが できます。 メッセージ・フォーマットとしてSOAPを利用しているので、特定の通信プロトコルに依存することはありま せん。 主要な技術の記述言語として、技術に対して中立的であるXMLを利用することによって、特定技術への 依存性を排除しています。例えば、WebサービスのリクエスターとプロバイダーではWSDLと実装言語はラ ンタイム環境でマッピングが行われ、XMLと実装言語の変換が行われます。こうすることで、例えば、Java で記述されたWebサービス・リクエスターと、.NETテクノロジーで実装されているWebサービス・プロバイ ダーとの通信も可能となります。 SOA(Service Oriented Architecture)とは、「サービス」の組み合わせによってアプリケーションを構成す るシステム構築の考え方になります。 5 なぜWebサービスを使用するのか? (1/2) 現行のシステムの呼び出し システムのOS、言語、通信プロトコルなどの実装に依存 クライアントとビジネスロジックは密結合となっている システム間の連携は非常に困難 業務C CICS (COBOL) 3270 エミュレーター × WAS (Java) JMS 業務B × Rich Client HTTP WAS (Java) 業務A Browser Client 6 Webサービスを適用するメリットを示すために、現在多く構成されているWebシステムを例として説明しま す。 現在の多くのWebシステムではクライアントとビジネスロジックの間には固有の実装規約が存在しており、 双方でOS、言語、通信プロトコルなど全て決まった実行環境でのみ稼動することができます。 例えば、業務Cのシステムを異なる言語を実装する業務Bのクライアントから呼び出すことは容易ではあ りません。業務Cの実装言語の稼働環境が必要となり、また業務C用のクライアントを新たに開発すること になります。 業務ごとにそのシステムは密に結合しており、業務Aと業務Bのような他システムとの連携が難しいのが 現状と言えるでしょう。 6 なぜWebサービスを使用するのか? (2/2) Webサービスの適用 クライアントはWSDLを取得すれば他業務のシステムにアクセス可能 インターフェースのみに依存し、実装には依存しない（疎結合） サービスの再利用による、SOAの促進 業務C WAS (Java) Web サービス CICS (COBOL) Browser Client 業務B Web サービス WAS (Java) Web サービス Rich Client 業務A WAS (Java) Browser Client WAS (Java) 共通ロジック 7 クライアントとビジネスロジックが密結合となっているシステムとは対照的に、インターフェースのみに依 存し実装に依存しない疎結合モデルを実現している技術がWebサービスになります。 クライアントはサービスが提供するWSDLを取得し、それに合わせて開発を行います。サービスが稼動す るOSや実装言語には依存せずインターフェースのみに依存するので、他業務のシステムへの連携も比 較的容易に実現できます。 7 WASはWebサービス基盤を提供 WAS 6.1はJ2EE 1.4に準拠 J2EE 1.4の仕様にWebサービスの仕様が含まれる JAX-RPC, WSDL, SOAP, ・・・ WAS 6.1上でWebサービス・アプリケーションを稼動させることで J2EE 1.4標準に準拠したWebサービスを稼動させることができる WAS 6.1 WS-FPの サポート範囲 WAS 6.1のサポート範囲 J2EE 1.4 仕様 Servlet 2.4 仕様 EJB 2.1 仕様 JSP 2.0 仕様 Webサービス仕様・標準 JAX-RPC 1.1 Web Services for J2EE 1.1 SAAJ 1.2 SOAP 1.1 WSDL 1.1 Webサービス仕様・標準 JAX-WS 2.0 JAXB 2.0 ・・・・・・ WS-I BP 1.1 MTOM 1.0 ・・・・・・ Webサービス仕様・標準 WS-Security 1.0 WS-AT 1.0 WS-I BSP 1.0 ・・・・・・ 8 WAS 6.1はJ2EE 1.4に準拠した製品となっていますので、J2EE 1.4におけるWebサービス関連APIを使 用してWebサービスを実装しています。 J2EE 1.4ではWebサービスに関わるサポートを主要なものとしているため、多くのWebサービス関連の仕 様が新規に追加されています。 WASやJ2EEがサポートするWebサービス仕様の詳細は下記のリンクを参照ください。 WAS V6.1 InfoCenter「仕様および API 資料-Webサービス」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/r ovr_specs.html WAS V6.1 WS-FP InfoCenter「Specifications and API documentation-Web services」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.wsfep.multiplatform.d oc/info/ae/ae/rovr_specs.html J2EE 1.4 specification http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf 8 WAS上でのWebサービス稼動の概要 WASはWebサービスのリクエスター、プロバイダーのどちら の稼働環境としても使用可能 Webサービス Webサービス・ サービス・リクエスター ユーザー・ アプリケーション (EAR) Java Java Bean Bean Webサービス Webサービス・ サービス・プロバイダー ユーザー・ アプリケーション Java (EAR) Bean Java Bean EJB EJB Webサービス Stubコード Webサービス Stubコード Webサービス エンジン Webサービス エンジン Browser Client HTTP WASランタイム WASランタイム HTTPトランスポート HTTPトランスポート HW/OS HW/OS SOAP 9 WASは、Webサービスのリクエスター、プロバイダーのどちらの実行環境としても使用可能です。リクエス ターとプロバイダーでは、チューニング項目などが異なりますので、ご注意ください。詳細は後述します。 9 インフラの観点からのWebアプリケーションとWebサービスの類似点 WebサービスのアプリケーションもEAR EARの中にStubコードやWebサービスのDDが含まれる デプロイ方法も同様 Webサービス Webサービス・ サービス・リクエスター ユーザー・ アプリケーション (EAR) Java Java Bean Bean Webサービス Webサービス・ サービス・プロバイダー ユーザー・ アプリケーション (EAR) Java Java Bean Bean DD EJB Webサービス Stubコード Webサービス エンジン WAS/RADの ツールで生成 WASランタイム HTTPトランスポート HW/OS Webサービス Stubコード Webサービス エンジン DD EJB ランタイムの ランタイムの責任 ・Webサービス・リクエストの 送受信 ・SOAPとJavaデータの変換 ・Webサービスのロジックを 実装しているJavaBeanまた はEJBの呼び出し WASランタイム SOAP HTTPトランスポート HW/OS •WebサービスはWebアプリケーションの延長線上 •Webアプリケーションのインフラ、運用管理の知識・スキルが そのまま使用可能 10 インフラ構築の観点から見た場合、Webサービス・アプリケーションの稼動とWebアプリケーションの稼動 とは異なるものではなく、これまでのWebアプリケーションの延長線上にあると考えることができます。具体 的には、Webサービスのアプリケーションも、これまでのWebアプリケーションと同様に、EARパッケージと してパッケージングされます。また、そのEARの管理コンソールやwsadminスクリプトを使用してのデプロイ 方法もほとんど同様です。 したがって、Webサービス・アプリケーションをWAS上で稼動させる場合にも、ほとんどの部分はこれまで のWebアプリケーションの知識やスキルで対応が可能です。 10 インフラの観点からのWebアプリケーションとWebサービスの相違点 リクエスターの意識 リクエスターの管理やチューニングが必要 サーバー間通信 リクエスト、レスポンス・データがWebアプリケーションと比較し、複雑、 巨大になりがち プロバイダーの処理時間が長くなることもある インターオペラビリティーの検討 .Net プロバイダー .Net リクエスター WAS リクエスター XML(SOAP) Axis リクエスター WAS プロバイダー Axis プロバイダー 11 インフラの観点から見た、WebアプリケーションとWebサービス・アプリケーションの相違点です。 まず、Webアプリケーションの場合、リクエスターは、ブラウザーであることが一般的であり、リクエスター 側の設定や運用管理ということにあまり注意を払いませんが、Webサービス・アプリケーションにおいては、 Webサービス・リクエスターもサーバー・アプリケーションとして稼動しますので、リクエスターとしての設定 に注意する必要があります。 また、Webサービスは、サーバー間通信となりますので、リクエストやレスポンス・データがWebアプリケー ションと比較して、複雑、巨大になりがちです。これにより、パフォーマンスなどに影響を与える場合があり ます。また、プロバイダー側の処理時間が長くなる場合もありますので、その場合は、リクエスター側のタイ ムアウト設定などにも注意する必要があります。 また、Webサービスの特徴は、異機種間での相互通信が可能になることです。ただし、Webサービスの 仕様は、日々進歩していますし、各実装ベンダー間での仕様の実装方法の違いなどにより、必ずしもす べての実装ベンダー間で簡単にデータの送受信を行えるわけではありません。 WAS 6.1 InfoCenter「Web サービスに関するよくある質問」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/r wbs_faq.html 11 インターオペラビリティーの考慮 WS-I (Web Services Interoperability Organization) Webサービスの相互運用性（インターオペラビリティ）を推進するため の団体 2002年2月発足 活動内容 各種Profileの作成（インターオペラビリティのガイド） テスト・ツールの作成 サンプル・アプリケーションの実装 なぜWS-Iが必要だったか？ 準拠さえすれば、異機種間 環境でも、連携できる Webサービスの各種仕様だけではインターオペラビリティが十分でなかったため WAS V6.1が対応するWS-I Profileのバージョン WS-I Profile WAS6.1 Web Services Interoperability Organization (WS-I) Basic Profile V1.1 Web Services-Interoperability Organization (WS-I) Attachments Profile V1.0 Web Services Interoperability Organization (WS-I) Basic Security Profile V1.0 リクエスター、プロバイダー間の製品が準拠するProfileのバージョンに注意 12 WS-Iは、異なるプラットフォーム、OS、ミドルウェア、プログラミング言語、およびツールに跨るWebサービ スの相互運用性を推進するために設立されたオープンな業界の団体です。この団体には、以下のような Webサービスを推進している主要な企業が参加しており、ここで決められた事項は業界標準と言うことが できます。 IBM、Microsoft、BEA、HP、SUN、Oracle、SAP、インテル、富士通、その他140社以上が参加 SOAPやWSDLを使用したWebサービスは相互運用性が高いと言われてきましたが、実際には製品間で の相互運用性を実現するにはWebサービス開発者による試行錯誤が必要で簡単には実現できませんで した。例えば、Apache SOAPとMSの.NETを接続させるには、この分野に高度なスキルを持つ人が作成し ないと簡単にはWebサービスで接続することができませんでした。WS-Iはこうした状況を改善するために 作られた組織であり、Webサービスの現実的な相互運用性を実現するために様々な活動をしています。 WS-Iは実際の活動をするにあたって、Webサービス関連の各種標準を策定しているW3CやOASISと連携 しながら活動しています。それ以外の団体とも協調しながら業界の標準となるものを作成しています。 WS-Iの活動のメインは、Profileと呼ばれるインターオペラビリティーに関するガイドを作成することです。 それ以外にもサンプルや相互運用性をテストするツールを作成しています。 参考「WS-I WEB SERVICES INTEROPERABILITY ORGANIZATION」 http://www.ws-i.org/ 12 Webサービス基盤設計 1 2 3 4 5 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー、トランザクション設計 13 13 トポロジー設計：SOAP/HTTPとSOAP/JMSの選択基準 WASは、SOAPメッセージのトランスポート・プロトコルとして、 HTTPとJMSをサポート SOAP/HTTPとSOAP/JMSの比較 SOAP/HTTP SOAP/JMS 標準 標準ではない 標準準拠 信頼性 同期・非同期通信のサポート 低 高 同期 同期・非同期 Webサービス サービスServer サービス Webサービス サービスClient サービス Webコンテナー Router Webサービス リクエスター Servlet SOAP/HTTP EJBコンテナー Webサービス リクエスター Router MDB Queue Queue Web サービス プロバイダー (Stateless Session Bean) SOAP/JMS 14 SOAP/HTTPとSOAP/JMSの特徴の相違を説明します。 SOAP/HTTPは、一般にWebサービス間の通信で使用されているプロトコルであり、WS-Iにも規定される Webサービスの標準のプロトコルです。一方、SOAP/JMSは、IBMの拡張機能であり、標準の仕様が定義 されているわけではありませんので、異なるプラットフォームとのインターオペラビリティーはありません。し かし、JMSプロトコルは、SOAP/HTTPよりも、高い信頼性を得ることができます。JMSを使用した場合、Web サービス・リクエスター、またはWebサービス・プロバイダーから送信されたメッセージはQueueまたはTopic にputされ、データベースなどの永続化ストレージに保管されます。そして、通信に失敗した場合には、通 信に成功するまで、永続化ストレージに保管されます。また、リクエスター上にあるローカルキューにメッ セージを送信した時点で、リクエスター側の処理が一旦完了し、プロバイダーへのメッセージ転送をミドル ウェアが保証してくれるという点でも、信頼性が高いといえます。 また、SOAP/JMSでは、プロトコルレベルで非同期通信を実現することができ、one-wayのRequestを使用 することにより、リクエスターとプロバイダーをより疎結合にすることができます。つまり、リクエスターがoneway Requestを送信するときにプロバイダーがアクティブでなくてもかまいません。また、one-way Request の送信宛先にTopicを使用することにより、複数のサーバーに同時に送信できます。 SOAP/JMSを使用する場合の注意点としては、インターオペラビリティーが得られないことの他には、メッ セージの送受信用にQueueまたはTopicの作成が必要になります。また、Webサービスの実装はStateless Session EJBである必要があり、Java beanで実装されたクラスにSOAP/JMSで直接アクセスすることはでき ません。 SOAP/JMSでのWebサービスアクセスに関しては、下記のInfoCenterの記載も参照ください。 WAS V6.1 InfoCenter「Java Message Service API を使用した Web サービス要求のトランスポート」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae /twbs_jmstransport.html また、以下のDeveloperWorksの記事も参考になりますので、参照ください。 DeveloperWorks記事「WebSphere JAX-RPC Web services: Protocol and location transparency」 http://www.ibm.com/developerworks/webservices/library/ws-soa-jaxrpc/ 14 （参考）SOAP/JMSの相互運用性（Interoperability） WAS V6.1まではIBM拡張の実装で提供 相互運用性（Interoperability）は保証されない IBM proprietary SOAP/JMS IBM only Service Client W3CでSOAP IBM only over JMSとして標準化が進められている http://www.w3.org/Submission/SOAPJMS/ WebSphere以外のWebサービス環境とSOAP/JMS通信が可能に！ standard SOAP/JMS Any Web service environment IBM Client Service 15 先程のページにてSOAP/JMSではインターオペラビリティーが得られないとご説明しましたが、W3Cで標 準化が進められています。 15 トポロジー設計：SOAP/HTTP SOAP/HTTPは、通常のWebアプリケーションと同様 リクエスター、プロバイダーともにWASのクラスタリング機能により、 高可用性、高拡張性を確保 WAS Cluster WAS Cluster Router Servlet Web Server Plug-in Router Servlet Router Servlet 負荷分散装置 Web Service リクエスター (WASなど など) など Web Server (IHSなど など) など Web Service Web Service Web Service Web Service プロバイダー (WASなど など) など Webサービス・プロバイダーの前段には、必ずしもIHSを配置しなくてもよい 16 通信プロトコルとして、SOAP/HTTPを使用する場合のトポロジー設計は、通常のWebアプリケーション と同様です。 Webサービス・リクエスター、Webサービス・プロバイダーともにWASのクラスタリング機能により、高可用 性、高拡張性を確保することができます。Webサービス・リクエスト・データはHTTPプロトコルでラップされ ますので、負荷分散装置の設定や、Webサーバーの設定においては通常のWebアプリケーション(サー ブレット)へのアクセスと同様の設定となります。 また、Webサービス・リクエスターとWebサービス・プロバイダー間にFirewallが存在せず、WASがリッス ンする9080番などのポート番号に、Webサービス・リクエスターから直接アクセスできる場合や、Webサー バー上でのアクセス・ログの取得などが必要ない場合には、Webサービス・リクエスターから、負荷分散装 置のみを経由し、IHSを使用しない構成とすることもできます。 16 トポロジー設計：SOAP/JMS SOAP/JMSは、メッセージングの高可用・高拡張性機能 WASのクラスタリング機能による、メッセージング・エンジンの高可用 性、高拡張性の機能を使用 WAS Cluster WAS Cluster Replyキュー Web Service リクエスター (WASなど など) など Requestキュー ME1 ME1 ME2 ME2 Router MDB Router MDB Web Service Web Service Web Service プロバイダー (WASなど など) など MEのフェイル・オーバーやパーティショニングを行う場合、 WebサービスとMEのクラスターを分離するか否か、 リクエスターとプロバイダーが所属するBusメンバーなどの設定により 考慮点があるので、メッセージングの知識が必要 17 通信プロトコルとして、SOAP/JMSを使用する場合のトポロジー設計は、メッセージングのインフラ構成が 必要になります。 JMSプロバイダーとしては、デフォルトのメッセージング（WAS V6.1のサービス統合バス。以下、SIBus） や、WebSphere MQ を使用することができますが、上記では「デフォルトのメッセージング」を前提としてい ます。 SOAP/JMSを使用する場合も、Webサービス・リクエスター、Webサービス・プロバイダーともにWASのク ラスタリング機能により、高可用性、高拡張性を確保することができます。メッセージング・エンジンのフェイ ルオーバー構成をとることで、宛先の高可用性を、メッセージング・エンジンのパーティショニング構成によ り、高拡張性構成とすることができます。ただし、SOAP/JMSを使用する場合には、メッセージング・エンジ ンのフェイルオーバーやパーティショニングの設定と合わせて、Webサービス・リクエスターとWebサービ ス・プロバイダーが同一のセルに所属するか否かや、メッセージング・エンジンが稼動するクラスターと Webサービス・プロバイダー・アプリケーションが稼動するクラスターを分離するか否かなどを検討する必 要があります。 17 SOAP/JMS使用時のリソース定義 SOAP/JMSアプリケーションを稼動させるためには、WAS上 に下記リソースの定義が必須 Webサービス・アプリケーション(SOAP/JMS) にはこれらリソースへの 参照を定義しておく 【デフォルトのメッセージングを使う場合に必要なリソース定義】 設定箇所 リソース 名前、備考 - SIBus （名前は任意） - バス・メンバー プロバイダーのアプリケーションサーバーとの兼用も可能 - Request用キュー宛先 （名前は任意） リクエスター Request用JMSキュー接続ファクトリー （名前は任意） リクエスター/プ ロバイダー Request用JMSキュー （名前は任意） プロバイダー JMS活動化仕様 （名前は任意） （キューはRequest用JMSキュー名を指定） プロバイダー Reply用JMSキュー接続ファクトリー WebServicesReplyQCF(固定名） デフォルトでは、Reply用のキューは自動生成される一時キュー 18 JMSプロバイダーとしては、デフォルトのメッセージング（WAS V6.1のサービス統合バス。以下、SIBus） や、WebSphere MQ を使用することができますが、上記では「デフォルトのメッセージング」を前提としてい ます。 尚、JMSプロバイダーにWebSphere MQ を採用する場合、JMS活動化仕様ではなくリスナー・ポートが使 用されます。 設定の詳細は、下記のRedbookを参照ください。 Redbook「Web Services Handbook for WebSphere Application Server 6.1」の「Appendix B. Additional material – Setting up messaging for the JMS Web service」(p.744-756) http://publib-b.boulder.ibm.com/abstracts/sg247257.html?Open 尚、デフォルトでは、SOAP/JMSのRequest-Reply型の通信を行う場合には、Replyキューとしては、一時 キューが使用されます。Replyキューとして永続キューを使用する場合には、下記のInfoCenter、または、 Technoteを参照ください。 WAS V6.1 InfoCenter「SOAP over JMS を使用した Web サービス用永続 replyTo キューの構成」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.d oc/info/exp/ae/twbs_jmspermreplyto.html Technote「How to configure a permanent replyTo queue when using SOAP over JMS to invoke a web service in WebSphere Application Server V6.1.x」 http://www.ibm.com/support/docview.wss?rs=180&uid=swg21240541 18 Webサービス・リクエストの宛先指定 Webサービス・リクエスター側の宛先指定 1. Webサービス・リクエスターのStubを生成するときに使用するWSDLファイル に定義 Webモジュールの場合、デフォルトで<war_module>/WEB-INF/wsdl/に配置 <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ･･･ xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" ･･･> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ･･･ xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" ･･･> <wsdl:types> <wsdl:types> ･･･ ･･･ </wsdl:types> </wsdl:types> name="myOperationRequest"> <wsdl:message <wsdl:message name="myOperationRequest"> ･･･ ･･･ </wsdl:message> </wsdl:message> ･･･ ･･･ <wsdl:portType name="MyWebService"> <wsdl:portType name="MyWebService"> ･･･ ･･･ </wsdl:portType> </wsdl:portType> <wsdl:binding name="MyWebServiceSoapBinding" type="impl:MyWebService"> <wsdl:binding name="MyWebServiceSoapBinding" type="impl:MyWebService"> ･･･ ･･･ </wsdl:binding> </wsdl:binding> <wsdl:service name="MyWebServiceService"> <wsdl:service name="MyWebServiceService"> <wsdl:port binding="impl:MyWebServiceSoapBinding" name="MyWebService"> <wsdl:port binding="impl:MyWebServiceSoapBinding" name="MyWebService"> <wsdlsoap:address location="http://MyServer.ise.ibm.com/MyService/services/MyWebService"/> <wsdlsoap:address location="http://MyServer.ise.ibm.com/MyService/services/MyWebService"/> </wsdl:port> </wsdl:port> </wsdl:service> </wsdl:service> </wsdl:definitions> </wsdl:definitions> 2. 管理コンソールの、アプリケーションの設定で上書き可能(後述)(オプション) 3. Webサービス・リクエスターの実装コードでも上書き可能(オプション) javax.xml.rpc.Stubインタフェースの「ENDPOINT_ADDRESS_PROPERTY」属性を設定 19 Webサービス・リクエスターから呼び出すWebサービス・プロバイダーの宛先（エンドポイント・アドレス）指 定について、説明します。 まず、Webサービス・リクエスターのアプリケーションを作成するときに使用するWSDLファイルの <service>要素内に呼び出すWebサービス・プロバイダーのURLアドレスを記述しますので、その設定が Webサービス・リクエスターのStubコードを作成するときに取り込まれます。 また、後述しますが、この呼び出すWebサービス・プロバイダーのアドレスは、デプロイ後に管理コンソー ルから設定を変更することが可能です。また、Webサービス・リクエスターのソースコードの中でも、この呼 び出すアドレスをコーディングによって変更することが可能です。 尚、SOAP/JMSを使用する場合のアドレス指定は下記のように、「jms」で開始され、使用する宛先と接続 ファクトリーを指定します。 <wsdlsoap:address location="jms:/queue?destination=java:comp/env/jms/Queue&connectionFactory=java:comp/env/j ms/QCF&targetService=ContractManagerJMS"/> SOAP/JMSのエンドポイントURLの構文の詳細は、下記のInfoCenterの記載を参照ください。 WAS V6.1 InfoCenter「Java Message Service エンドポイント URL の構文」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/r wbs_jmsurl.html 19 Webサービス基盤設計 1 2 3 4 5 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー、トランザクション設計 20 20 パフォーマンス設計：概要 SOAP/HTTP 基本的にはWebアプリのチューニングと同様 キューイング・ネットワーク（IHSのMaxClients、Webコンテナーのスレッド・プール数など） JVMヒープ SOAP/JMS メッセージングのチューニングも必要 JMS接続ファクトリー 活動化仕様（アクティベーション・スペック） メッセージの信頼性レベル WAS Cluster WAS Cluster Web Service Router Servlet Web Server Plug-in 負荷分散装置 Webサービス サービス リクエスター (WASなど など) など リクエスター側にHTTP接続の コネクションプールがある Web Server (IHSなど など) など Router Servlet Router Servlet Web Service Web Service Webサービス サービス プロバイダー (WASなど など) など 21 パフォーマンスの設計、チューニングを行う場合の基本となるのは、SOAP/HTTPの場合も、SOAP/JMS の場合も、Webアプリケーションのパフォーマンス設計の知識です。SOAP/HTTPの場合は、IHSの MaxClientsやWebコンテナーのスレッド・プール数を調整して、同時リクエスト数を調整します。また、Web サービス・アプリケーションもJVM上で稼動するWebアプリケーションですので、JVMヒープの使用状況も 常に確認してください。 SOAP/JMSを使用する場合には、同時にメッセージングに関するチューニングも必要になります。JMS接 続ファクトリーや活動化仕様の設定により、同時に処理できるメッセージ数を調整します。また、メッセージ の信頼性レベルなどもパフォーマンスに影響します。 尚、次ページで説明しますが、Webサービス特有の特徴として、Webサービス・リクエスターのアウトバウ ンドのHTTPトランスポートは、接続プールを持ち、これによりパフォーマンスが向上します。 アクティベーション・スペック（ActivationSpec JavaBean）とは、レガシーやEnterprise Information System(EIS)から、アプリケーション・サーバーのEJBを呼び出す為の仕組みとしてJava Connector Architecture Specification（JCA）1.5から採用されたものです。 21 パフォーマンス設定：HTTPアウトバウンド接続プール(1/2) HTTPアウトバウンド HTTPアウトバウンド接続 アウトバウンド接続プール 接続プール Webサービス・リクエスターが、接続オブジェクトをプールして再利用すること により、作成/切断のオーバーヘッドを軽減 WASV6.1.0.13以降は、 デフォルト値は25 接続プールの管理プロパティー プロパティー名 意味 com.ibm.websphere.webservices.http.maxConnection プールされる接続の最大数 デフォルト 50 com.ibm.websphere.webservices.http.connectionTimeout 使用中の接続が最大数に達している場合の待機時間 300 sec com.ibm.websphere.webservices.http.connectionIdleTimeout 未使用でアイドル状態の接続オブジェクトを破棄にフラグ する時間 5 sec com.ibm.websphere.webservices.http.connectionPoolCleanUpTime 接続オブジェクトを監視し、タイムアウトをチェックする間隔 180 sec トランスポート・チャネル スレッド Application Server HTTPアウトバウンド ・コネクター IHS ConnectionPool KeepAlive 80 Web サービス プロバイダー 9080 SOAP/HTTP Webサービス・ プロバイダー Webサービス・リクエスター 22 Webサービス・リクエスターは、接続オブジェクトをプールして再利用することにより、作成/切断のオー バーヘッドを軽減します。（接続の確立は、コストのかかる処理であり、接続プールを使用すると、接続の 作成/切断のオーバーヘッドが回避されて、パフォーマンスが向上します。） Webサービス・リクエスターはWebサービス・リクエストを実行するとき、WebサービスのHTTPアウトバウン ド・コネクターが接続プールより空いている接続オブジェクトを取得します。応答を受信すると、コネクター は接続オブジェクトを解放します。 WASV6.1.0.13以降は、webservices.http.maxConnectionのデフォルト値が25に変更されました。また、 Webコンテナー・スレッド・プールのサイズの半分以下に設定することが推奨されています。 設定値の詳細は下記のInfoCenterを参照ください。 WAS V6.1 InfoCenter「Web サービス・アプリケーションのための、追加 HTTP トランスポート・プロパ ティー」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/r wbs_httptransportprop.html 22 パフォーマンス設定：HTTPアウトバウンド接続プール(2/2) HTTPアウトバウンド接続プールの設定における注意 Webサービス・リクエスターのスレッド・プールとの関係 Webサービス・リクエストの同時実行数を増加させるためには、HTTPアウトバウン ド接続プールのmaxConnection値の増加が必要 Webコンテナーのスレッド・プールを増加させるだけでは、Webサービス・リクエスト の同時実行数は増加しない プロバイダー側のKeepAlive設定との関係 リクエスター側のコネクション・プールでは、プロバイダー側からのKeepAliveタイム アウトによるコネクションの切断を検知できない すでに接続がcloseされている場合、java.io.IOExceptionが発生 プロバイダー側のKeepAliveタイムアウト値よりも、connectionIdleTimeout値を小さ くする コンポーネント プロパティー名 デフォルト Webサービス・リクエスター(WAS) com.ibm.websphere.webservices.http.connectionIdleTimeout 5 sec Webサービス・プロバイダーの前段のIHS （リクエスターからのプ ロバイダーへIHSを経由した接続をする場合に影響） KeepAliveTimeout （httpd.conf） 10 sec Webサービス・プロバイダー（WAS） （リクエスターからのプロバイ ダーへIHSを経由せずに直接接続する場合に影響） パーシスタント・タイムアウト (HTTPインバウンド・チャネル) 30 sec デフォルト値を使用している場合には、問題ない IHSのKeepAliveTimeout値を変更している場合に注意 23 HTTPアウトバウンド接続プールの設定値の注意点を説明します。 まず、Webサービス・クライアントからの同時Webサービス・リクエストを増加させたい場合には、Webサー ビス・クライアントのWebコンテナーのスレッドプールを増加させるだけでは、最大でもHTTPアウトバウンド 接続プール以上のWebサービス・リクエストは行われません。Webサービス・リクエストの同時実行数を増 加させる場合には、Webコンテナーのスレッドプールと合わせて、HTTPアウトバウンド接続プールの最大 数を増加させる必要があります。 また、HTTPアウトバウンド接続プール設定の注意点として、KeepAliveのタイムアウト値との関係がありま す。HTTPアウトバウンド接続プールにプールされた接続オブジェクトは、Webサービス・プロバイダー側か らのコネクションの切断を検知できませんので、HTTPアウトバウンド接続プールに未使用の接続が保持さ れる時間の設定値であるconnectionIdleTimeout値の設定を、IHSやWebサービスを提供する側の KeepAliveタイムアウト値よりも小さく設定する必要があります。もし、プロバイダー側のKeepAliveタイムアウ ト値を小さく設定する必要がある場合には、HTTPアウトバウンド接続のKeepAlive接続をOFFにすることも 検討してください。 この現象については、下記のTechnoteを参照ください。 Technote「WSWS3228E: Possible end of stream encountered.」 http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21245844 23 パフォーマンス：Webサービス・キャッシュ Webサービス・キャッシュとは オブジェクトをキャッシュしてパフォーマンスを向上させる仕組み cachespec.xml という構成ファイルに定義するのみで、DDやコードを 変える必要がない アプリケーション・サーバー・プロセス内で動作する仕組み Webサービス・クライアント・キャッシュ リクエスターでリモートWebサービスからの応答を一定時間保管し、パフォーマンス向上 Webサービス・サーバー・キャッシュ プロバイダーでWebサービス応答を一定時間保管し、パフォーマンス向上 IHS Web サービス・ リクエスター End User Webサービス クライアント キャッシュ キャッシュ AppServer ノード1 Webサービス・リクエスター IHS Webサービス サーバー キャッシュ Web サービス・ プロバイダー キャッシュ AppServer ノード2 Webサービス・プロバイダー 24 WASには、キャッシュ（オブジェクトをアプリケーションサーバ内でキャッシュすることでパフォーマンスを 向上させる機能）の仕組みが提供されています。 キャッシュできる対象は、Javaのオブジェクトであり、Webサービスについてもオペレーション単位でキャッ シュ対象とすることができます。 WAS V6以降で、Webサービス・リクエスター、Webサービス・プロバイダー両方でキャッシュサービスを利 用できます。 Web サービス・クライアント・キャッシュは、アプリケーション・サーバー上で ハンドラーとして提供されて います。このキャッシュ・ハンドラーは、アプリケーション・クライアントから流れてくる SOAP 要求をインター セプトします。さらに キャッシュ・ハンドラーは、ターゲット Web サービスに基づいてキャッシュ・ポリシーを 識別します。いったんポリシーが見つかると、すべてのキャッシュ ID 規則が、有効な規則が検出されるま で 1 つずつ評価されます。 考慮点として、以下の点が挙げられます。 ・SOAP/HTTP(s) のアプリケーションでのみ使用可能 （参考） WAS V6.1 InfoCenter「Web サービス・クライアント・キャッシュの構成」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf o/ae/ae/tdyn_wsclientcache.html IBM Redbook 「WebSphere Version 6 Web Services Handbook Development and Deployment」 Chapter 24 Web Services Caching http://www.redbooks.ibm.com/redbooks/pdfs/sg246461.pdf 24 （参考）ハンドラー SOAPメッセージの内容を操作することが可能 アプリケーションの実装とは別に、メッセージに対する処理を実施 暗号化、複合化、ロギング、認証、キャッシングなどの共通処理に利用 柔軟な配置 リクエスター、プロバイダー側どちらでも配置可能 要求、応答メッセージを別々に処理可能 複数のハンドラーを組み合わせることが可能 ディプロイメント記述子（DD）にて設定 Webサービス サービス・ サービス・プロバイダー AppServer Request Handler SOAP/XML Request Handler Request Handler Webサービス・ リクエスター Response Handler SOAP/XML Response Handler Response Handler Webサービス・ Webサービス・ プロバイダー Webサービス・ プロバイダー プロバイダー 25 Webサービスでデータを送受信する間にSOAPメッセージをインターセプトして様々な共通処理を実現 することができます。主な用途としては、暗号化、複合化、ロギング、認証、キャッシングなど、アプリケー ションの実装とは別に共通に利用したい処理への利用に向きます。 また、ハンドラーは、複数のハンドラーを組み合わせて設定したり、要求・応答それぞれ別の処理を定義 することが可能です。 作成したハンドラーは、ディプロイメント記述子を使って設定します。 ・Webサービスのプロバイダー側では、webservices.xml（WebサービスDD） ・Webサービスのリクエスター側では、web.xml（WebDD） 25 パフォーマンス：モニタリング(TPV) Tivoli Performance Viewer(TPV)を使用して、Webサービスに 関連する統計情報やパフォーマンス情報を取得可能 要求数 平均応答時間 平均送受信メッセージサイズ 項目の名前 意味 LoadedWebServiceCount ロードされた Web サービスの数 ReceivedRequestCount サービスが受信した要求の数 DispatchedRequestCount サービスがディスパッチまたは配布した要求の数 ProcessedRequestCount サービスが正常に処理した要求の数 単位 ResponseTime 正常要求への平均応答時間 ミリ秒 RequestResponseTime ディスパッチ要求を準備する平均応答時間 ミリ秒 DispatchResponseTime 要求をディスパッチする平均応答時間 ミリ秒 ReplyResponseTime ディスパッチ後の応答を準備する平均応答時間 ミリ秒 PayloadSize 受信した要求または応答の平均有効搭載量（要求と応答の合計） バイト RequestPayloadSize 要求の平均有効搭載量 バイト ReplyPayloadSize 応答の平均有効搭載量 バイト 26 Tivoli Performance Viewerを使用して、Webサービスの統計情報やパフォーマンス情報を取得すること ができます。 具体的には、Webサービス・リクエストの要求数、平均応答時間、平均の送受信メッセージのサイズなど を取得することができます。 取得できるカウンター項目の詳細は下記のInfoCenterの記載を参照ください。 WAS V6.1 InfoCenter「Web サービスのカウンター」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/r prf_datacounter16.html 26 パフォーマンス：モニタリング（要求メトリック） 要求メトリックを使用して、1リクエストごとのWebサービス・リ クエスト、Webサービス・プロバイダー処理時間を取得 プロバイダー側Log プロバイダー側Log [07/07/14 16:25:53:800 JST] 00000023 PmiRmArmWrapp I PMRM0003I: [07/07/14 16:25:53:800 JST] 00000023 PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=11,event=1 – parent:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=11,event=1 – current:ver=1,ip=9.170.233.130,time=1184387328061,pid=388,reqid=1378,event=1 type=Web Services Provider current:ver=1,ip=9.170.233.130,time=1184387328061,pid=388,reqid=1378,event=1 type=Web Services Provider detail=wsprovider:WSServerBean.serverProcess?transport=http&namespace=http://httpserver.wspt&input=serverProcessRequest elapsed=17014 detail=wsprovider:WSServerBean.serverProcess?transport=http&namespace=http://httpserver.wspt&input=serverProcessRequest elapsed=17014 リクエスター側Log リクエスター側Log [07/07/14 16:25:52:343 JST] 0000002e PmiRmArmWrapp I PMRM0003I: [07/07/14 16:25:52:343 JST] 0000002e PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=10,event=1 – parent:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=10,event=1 – current:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=11,event=1 type=Web Services Requestor current:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=11,event=1 type=Web Services Requestor detail=wsrequestor:WSServerBean.serverProcess?transport=http¶meters=inputInt,inputData elapsed=17062 detail=wsrequestor:WSServerBean.serverProcess?transport=http¶meters=inputInt,inputData elapsed=17062 [07/07/14 16:26:02:421 JST] 0000002e PmiRmArmWrapp I PMRM0003I: [07/07/14 16:26:02:421 JST] 0000002e PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=10,event=1 – parent:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=10,event=1 – current:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=10,event=1 type=URI detail=/WSPTHTTPClient/WSClientServlet elapsed=32140 current:ver=1,ip=9.170.233.131,time=1184396332781,pid=5388,reqid=10,event=1 type=URI detail=/WSPTHTTPClient/WSClientServlet elapsed=32140 AppServer AppServer Web サービス リクエスター Request Handler (5 s sleep) SOAP/XML Response Handler (10 s sleep) SOAP/XML Request Handler (5 s sleep) Web サービス プロバイダー Response (2 s sleep) Handler (10 s sleep) TPV Webサービスの項 目 ResponseTime RequestResponseTime DispatchResponseTime ReplyResponseTime 上記リクエ スト時の値 17034 ms 5007 ms 2003 ms 10024 ms プロバイダー側の要求メトリックでの経過時間 リクエスター側の要求メトリックでの経過時間 27 要求メトリックを使用して、1リクエストごとのWebサービス・リクエストの経過時間を取得することができま す。 上記は要求メトリックのログを取得したときの例です。計測対象コンポーネントとして、「WebServices」を 選択することで、Webサービス・リクエスター側とWebサービス・プロバイダー側でそれぞれ、リクエストの 経過時間を取得することができます。 プロバイダー側の要求メトリックのログとリクエスター側の要求メトリックのログを付き合わせるときには、プ ロバイダー側の親(parent)のpid,reqidと、リクエスター側の子(current)のpid,reqidでつき合わせを行いま す。 尚、プロバイダー側の経過時間は、プロバイダーのユーザーが定義したWebサービス・ハンドラーを含 んだ時間となり、リクエスター側の経過時間は、リクエスターのユーザーが定義したWebサービス・ハンド ラーは含まない時間となります。 また、TPVでは、複数のリクエストの時間が平均された時間となりますが、ResponseTimeの測定値は、 Webサービス・プロバイダーのサービス実装、ハンドラー処理を含んだ時間となり、 RequestResponseTimeの測定値は、リクエスト・ハンドラーの処理を含む時間、 DispatchResponseTimeはハンドラー処理を含まないサービス実装の処理の時間、 ReplyResponseTimeはレスポンス・ハンドラーの処理時間を含む時間となります。 27 （参考）パフォーマンス：アプリケーション設計 JavaオブジェクトとXMLの変換処理の負荷を考慮 アプリケーション設計における注意 送受信データ・サイズを小さめに SOAP/XMLの構造をシンプルに element数を少なく、elementの階層を浅く 通信回数は少なく データ・サイズを小さくと言っても、小さいデータを大量に送受信するのではなく、大きな データを1回送受信した方がよい Webサービス サービスClient サービス Webサービス サービスServer サービス Serialization De-Seriazation SOAP/XML Object→XML XML→Object Web サービス リクエスター Web サービス プロバイダー De-Seriazation XML→Object Serialization SOAP/XML Object→XML WASのバージョンアップにともない、パフォーマンス向上 28 まず、パフォーマンスを検討するうえで重要な点は、アプリケーション設計と関連する項目になりますが、 JavaオブジェクトとXMLの変換処理は負荷のかかる処理です。同一JVM内のロジックを呼び出したり、EJB 呼び出しを行うよりも、Webサービスのパフォーマンスは悪くなります。しかし、パフォーマンスは少し悪くな りますが、Webサービスには、異言語、異ベンダー間でのインターオペラビリティーを実現することができま す。 特に、JavaからSOAP(XML)にデータ変換を行う処理は負荷のかかる処理ですので、できるかぎり上記の ような点に注意してください。 ただし、WASのバージョンごとに、XMLのシリアライズ・デシリアライズ処理のパフォーマンスは大きく向 上しています。 (参考資料) Technote「Web services performance is slow」 http://www.ibm.com/support/docview.wss?rs=180&uid=swg21232476 28 Webサービス基盤設計 1 2 3 4 5 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー、トランザクション設計 29 29 運用管理：パッケージング(サービス・プロバイダー) RADまたはWASのツール(ウィザード)を使用してアプリケーションを作成 すると、以下のようなStubクラスやデプロイメント・ディスクリプターがEAR の中に含まれる SEI（Webサービスのメソッドを宣言するインタフェース） Webサービス実装クラス（Webサービスのビジネスロジックを実装) オブジェクト・マッピングファイル（要求メッセージ） オブジェクト・マッピングファイル（返答メッセージ） WSDL JAX-RPCマッピングファイル Webサービスデプロイメント記述子の拡張ファイル Webサービスデプロイメント記述子 30 JavaBeanを元に作成したWebサービス・プロバイダーのアプリケーションのクラスファイル、デプロイメン ト・ディスクリプターの定義ファイルです。 ・SEI(Service Endpoint Interface):Webサービスとして公開するメソッドをJavaのインターフェースとして定義 します。Webサービスのリクエスター側の視点からWebサービスの定義を表します。java.rmi.Remoteイン ターフェースを継承する必要があります。 ・Webサービス実装クラス：ビジネス・ロジックを実装、またはビジネス・ロジックを呼び出す実装クラスです。 ・オブジェクト・マッピングファイル：Webサービスの要求メッセージでJavaオブジェクトを使用している場合 に、シリアライザーとデシリアライザーとなるオブジェクトのマッピングファイルです。 ・WSDL：WebサービスのインターフェースをXMLで定義したファイルです。 ・JAX-RPCマッピング・ファイル：WSDLとJavaのインターフェースのマッピング情報を定義します。 ・Webサービスデプロイメント記述子の拡張ファイル：Webサービス用のIBM拡張デプロイメント記述子です。 ・Webサービスデプロイメント記述子：Webサービス用のデプロイメント記述子で、Web services for J2EEの 仕様で定められた内容を表します。 30 webservices.xml (WebサービスDD) webservices.xmlの設定内容 サービス名 WSDLファイルのロケーション JAX-RPCマッピングファイルのローケーション ポート・コンポーネント情報 ポート・コンポーネント名 SEIの完全修飾名 Webサービス実装クラス名 31 Webサービスデプロイメント記述子には、下記のような項目が設定されます。 ・サービス名 ・WSDLファイルのロケーション ・JAX-RPCマッピング・ファイルのロケーション ・ポート・コンポーネント情報 ・ポート・コンポーネント名 ・SEIの完全修飾名 ・Webサービス実装クラス名 また、Webサービス・ハンドラーやWSセキュリティーの設定もWebサービス・エディター（webservices.xml とIBM拡張のWebサービス・デプロイメント記述子を含む）で設定します。 31 運用管理：パッケージング(サービス・リクエスター) RADまたはWASのツール(ウィザード)を使用 してリクエスター・アプリケーションを作成する と、以下のようなStubクラスやデプロイメント・ ディスクリプターがEARの中に含まれる Stubクラス オブジェクト・マッピングファイル（要求メッセージ） オブジェクト・マッピングファイル（返答メッセージ） Webサービス・リクエストコード実装クラス JavaオブジェクトとXML要素 JavaオブジェクトとXML要素 のマッピング情報 のマッピング情報 WebSphere製品固有のWeb WebSphere製品固有のWeb サービス・ランタイム情報 サービス・ランタイム情報 ・要求タイムアウト ・要求タイムアウト ・SSL構成 ・SSL構成 ・WS-Security構成情報 ・WS-Security構成情報 WSDL JAX-RPCマッピングファイル Webサービス・リクエスターのデプロイメント記述子の拡張ファイル Webサービス・リクエスターの設定ファイルは、webデプロイメント記述子 32 に含まれる Webサービス・リクエスターのアプリケーションのクラスファイル、デプロイメント・ディスクリプターの定義 ファイルです。 JAX-RPCマッピングファイルには、JavaオブジェクトとXML要素のマッピング情報が含まれ、メッセージタ イプや各パラメータについてのマッピングが定義されています。 ibm-webservicescleint-bnd.xml, ibm-webservicesclient-ext.xmi ファイルには、要求タイムアウト、SSL構 成、WS-Security構成情報など、 WebSphere 製品固有の Web サービス・ランタイム情報が含まれていま す。 32 web.xmlに含まれるWebサービス・リクエスター関連項目 WSバインディングの項目で、IBM拡張の要求タイムアウト設定である 「同期タイムアウト」なども設定できる 33 Webサービス・リクエスターの定義情報は、webデプロイメント・ディスクリプター(web.xml)に設定されます。 尚、IBM拡張部分は、「ibm-webservicesclient-bnd.xmi」、「ibm-webservicesclient-ext.xmi」ファイルに記 述されます。 RADのweb.xmlエディターでWebサービス・リクエスターの設定項目を確認・設定する場合には、「参照」、 「WSハンドラー」、「WS拡張」、「WSバインディング」タブを確認します。 33 運用管理：デプロイ 通常のWebアプリケーションのデプロイと同様 管理コンソール、またはwsadminにてデプロイ 「Webサービスのデプロイ」のチェックを 「Webサービスのデプロイ」のチェックを 入れると、wsdeployコマンドが実行され 入れると、wsdeployコマンドが実行され ます。 ます。 (※ RADウィザードで作成したEARファイ (※ RADウィザードで作成したEARファイ ルであれば不要) ルであれば不要) 34 Webサービスアプリケーションは、J2EEアプリケーションであり、WASの管理コンソールからデプロイしま す。 「Webサービスのデプロイ」というチェックボックスはデフォルトでオフ（チェックなし）になっています。 このチェックボックスをONにすると、アプリケーションのデプロイ時にwsdeployコマンドが実行されます。 wsdeployコマンドはWebSphere製品に固有のデプロイメント・クラスをEARファイルやアプリケーション・ク ライアントのJARファイルに追加します。wsdeployコマンドは、少なくとも1回実行する必要があります。ただ し、RADウィザードでEARファイルを作成している場合はwsdeployコマンドが実行されていますので、WAS へのデプロイ時に実行させる必要はありません。 wsdeployコマンドの実行によって以下のような処理が行われます。 ・EARファイル内の各モジュールの検査 ・モジュールにWebサービス・プロバイダー・インプリメンテーションが含まれている場合、WSDL2Javaコマ ンドが「deploy-server」のロールで実行される ・モジュールにWebサービス・リクエスター・インプリメンテーションが含まれている場合、WSDL2Javaコマン ドが「deploy-client」のロールで実行される ・WSDL2Javaコマンドによって生成されるファイルがコンパイルされて再パッケージ される また、wsadminコマンドからWebサービスアプリケーションをデプロイする場合には、deploywsオプションを 指定して下さい。 「Webサービスのデプロイ」オプションの詳細は、下記のInfoCenterの記載を参照ください。 WAS V6.1 InfoCenter「アプリケーション・サーバーへの Web サービス・アプリケーションのデプロイ」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/t wbs_deployapp2.html 34 運用管理：管理コンソールからの管理 管理コンソールからできるWebサービスの管理 サービス・プロバイダー デプロイメント・ディスクリプターの表示 WSDLファイルの取得 サービス・リクエスター デプロイメント・ディスクリプターの表示 エンドポイント・アドレスの変更 要求タイムアウト値の変更 35 管理コンソールからできるWebサービス・アプリケーションの管理項目としては、プロバイダー側のWeb サービス・デプロイメント・ディスクリプターの内容を表示することができます。 管理コンソールで[アプリケーション]-[エンタープライズ・アプリケーション]-[サービス・プロバイダー・ア プリケーション名]-[モジュール：モジュールの管理]-[モジュール名]-[Webサービス・プロパティー]のサブ 項目で選択します。 WSDLファイルの取得は、管理コンソールから、[アプリケーション]-[エンタープライズ・アプリケーション][サービス・プロバイダー・アプリケーション名]-[WSDLファイルの公開]を選択します。名前は、「WSDLファ イルの公開」となっていますが、WSDLファイルをzip化し、ローカルのディスクにダウンロードする機能です。 エンドポイントのアドレスのURL接頭部は、サーバー固有の値などに変更してWSDLファイルを提供するこ とができます。 サービス・リクエスター側では、 [アプリケーション]-[エンタープライズ・アプリケーション]-[サービス・リク エスター・アプリケーション名]-[モジュール：モジュールの管理]-[モジュール名]-[Webサービス・プロパ ティー]のサブ項目で、IBM拡張のWebサービス・クライアント・デプロイメント・ディスクリプターの表示や、 呼び出すエンドポイント・アドレスや要求タイムアウト値を変更することができます。 管理コンソールから行うことのできるWebサービス・アプリケーションの管理の詳細は下記のInfoCenterの 記載を参照ください。 WAS V6.1 InfoCenter「デプロイされた Web サービス・アプリケーションの管理」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/t wbs_admindeploy.html WAS V6.1 InfoCenter「Web サービス・クライアント・バインディングの構成」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/t wbs_clientbindings.html WAS V6.1 InfoCenter「管理コンソールを使用した WSDL ファイルの公開」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/t wbs_adminwsdl.html 35 運用管理：エンドポイント・アドレスの変更(1/2) サービス公開後、以下のような理由でエンドポイントが変更 になる可能性がある サーバー名変更 ドメイン変更 使用ポート変更 上記変更が行われた場合、Webサービス・リクエスターで接 続先であるエンドポイントを変更する 新エンドポイントにリ 新エンドポイントにリ クエストするよう変 クエストするよう変 更が必要。 更が必要。 Web サービス リクエスター 【エンドポイント変更】 (旧) http://www1.ibm.com/Ctx/services/Svc ↓↓↓ (新) http://www2.ibm.com/Ctx/services/Svc Web サービス プロバイダー End User 36 サービス・リクエスターの設定変更について説明します。サービスの公開後、サーバー名の変更などに より、エンドポイント・アドレスが変更になる場合があります。このようなときには、Webサービス・リクエスター のアプリケーションを再作成し、再デプロイを行う必要はなく、Webサービス・リクエスターの「Webサービ ス・クライアント・バインディング」の設定変更により、呼び出すエンドポイント・アドレスを変更することができ ます。 また、テスト時などに、TCP MonitorツールでSOAPメッセージをモニターする場合に、このエンドポイン ト・アドレスの変更により、一時的に呼び出しアドレスを変更するためにも利用できます。 36 運用管理：エンドポイント・アドレスの変更(2/2) WSDLやWebサービス・リクエスターのStubコードを変更する ことなくエンドポイントアドレスを変更可能 37 エンドポイント・アドレスの変更方法です。[アプリケーション]-[エンタープライズ・アプリケーション]-[サー ビス・リクエスター・アプリケーション名]-[モジュール：モジュールの管理]-[モジュール名]-[Webサービス・ プロパティー：Webサービス・クライアント・バインディング]を選択し、「ポート情報：編集」のリンクをクリックし ます。「オーバーライドされたエンドポイントURL」の項目に上書きするエンドポイントのURLアドレスを指定 します。 尚、エンドポイントURLは、Webサービス・リクエスター・アプリケーション内のコードでも明示的に指定す ることができます。その場合には、管理コンソール上で指定したアドレスよりも、アプリケーション・コード内 で指定したエンドポイント・アドレスが優先されますので、ご注意ください。 37 運用管理：要求タイムアウトの設定(1/2) 要求タイムアウト プロバイダー側でなんらかの理由で応答が返ってこない場合、リクエ スターがいつまでも待ち続けないように設定する WASでは、リクエスター側にサービス呼び出しのタイムアウト時間を 設定することができる Webサービスへの接続を開始してから設定時間以上経過すると、 SocketTimeoutExceptionが発生して、リクエスター側で RemoteException がスローされる デフォルトでは300秒 タイムアウトを検知した時、リクエスターはシステム要件に応じた対応 を行う タイムアウトエラー 時間をあけて リトライして下さい。 End User Web サービス リクエスター タイム アウト Web サービス プロバイダー プロセス 障害 38 Webサービス・プロバイダー側での処理が異常に時間がかかる場合や、ネットワーク障害が発生した場 合などにリクエスター側が待ち続けてしまうことのないよう、一定の時間待ったらタイムアウトするような構成 が望ましいです。 WASでは、リクエスター側でのWebサービス呼び出しのタイムアウトの仕組みを実装しており、デフォルト ではサービス呼び出し後、300秒経過すると、 SocketTimeoutExceptionが発生して、 RemoteExceptionが スローされます。 38 運用管理：要求タイムアウトの設定(2/2) 要求タイムアウトの設定方法 エンドポイント変更を行う画面にて、要求タイムアウトも設定できる IBM拡張Webサービス・クライアントDDでも設定可能 その設定を管理コンソールから上書ける 39 エンドポイント・アドレスの変更、要求タイムアウトの設定項目の詳細は下記のInfoCenterの記載を参照く ださい。 WAS V6.1 InfoCenter「Web サービス・クライアントのポート情報」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/u wbs_portattribute.html 尚、IBM拡張Webサービス・クライアントDDでの設定方法の詳細は下記のInfoCenterの記載を参照くだ さい。 WAS V6.1 InfoCenter「ibm-webservicesclient-bnd.xmi assembly properties」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/r wbs_assembpropclient.html WAS V6.1 InfoCenter「Configuring the Web services client bindings in the ibm-webservicesclientbnd.xmi deployment descriptor」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/t wbs_configibmclientdd.html 39 Webサービス基盤設計 1 2 3 4 5 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー設計、トランザクション設計 40 40 問題判別：tcpmon(1/2) SOAPメッセージのトレース リクエスターとプロバイダーの切り分けのためにも、SOAPメッセージ の取得は有用 tcpmonツール WASに同梱される特定のポートへのtcpパケットをキャプチャーする ツール Listenするポートは、実際のWebサービス・プロバイダーのポート(またはホスト)と 分離する必要がある 送受信で流れるSOAPメッセージをキャプチャー可能 RADやASTのTCP/IPモニターと同様にSOAPメッセージを取得できる Web サービス リクエスター Web サービス プロバイダー End User 41 Webサービスの問題判別を行う場合には、SOAPメッセージを取得することがとても有用です。 リクエストとレスポンスのSOAPメッセージを取得することで、サービス・リクエスターとサービス・プロバイ ダーのどちらが想定外のメッセージを送信しているか判別することができます。 41 問題判別：tcpmon(2/2) WASインストール・ディレクトリーで下記のコマンドを実行し、tcpmonツールを起動 D:¥WAS61>bin¥setupCmdLine.bat D:¥WAS61>java¥bin¥java -Djava.ext.dirs="%WAS_EXT_DIRS%;%WAS_HOME%¥plugins" com.ibm.ws.webservices.engine.utils.tcpmon <local_listen_port> <remote_server> <remote_port> リクエスターのエ ンドポイント・アド レスをモニター・ア ドレスに変更する リクエスト・ メッセージ 改行なし プロバイダーの ホスト名、ポート 番号を指定する レスポンス・ メッセージ 42 tcpmonツールは、上記コマンドで起動できます。 上記のように、送信SOAPメッセージ、受信SOAPメッセージをキャプチャーできます。 tcpmonの使用方法の詳細は、下記のRedbookに詳しく記述されていますので参照ください。 Redbook「Web Services Handbook for WebSphere Application Server 6.1」の「WebSphere Application Server TCP/IP Monitor」(p.330-331) http://publib-b.boulder.ibm.com/abstracts/sg247257.html?Open 42 問題判別：WASのトレース WASのトレース WASのトレース・ストリングとして、下記を指定することで、trace.logに 送受信SOAPメッセージをロギング 「com.ibm.ws.webservices.trace.MessageTrace=all」 [07/07/17 19:43:28:080 JST] 0000001f ManagerAdmin I TRAS0018I: トレース状態 トレース状態が 状態が変更されました 変更されました。 されました。 新しいトレース しいトレース状態 トレース状態は 状態は、 [07/07/17 19:43:28:080 JST] 0000001f ManagerAdmin I TRAS0018I: トレース状態 トレース状態が 状態が変更されました 変更されました。 されました。 新しいトレース しいトレース状態 トレース状態は 状態は、 *=info:com.ibm.ws.webservices.trace.MessageTrace=all です。 です。 *=info:com.ibm.ws.webservices.trace.MessageTrace=all です。 です。 [07/07/17 19:44:41:696 JST] 0000001f MessageTrace 3 WSWS3569I: インバウンド HTTP SOAP 要求: 要求 [07/07/17 19:44:41:696 JST] 0000001f MessageTrace 3 WSWS3569I: インバウンド HTTP SOAP 要求: 要求 コンテンツ・タイプ: text/xml; charset=utf-8 コンテンツ・タイプ: text/xml; charset=utf-8 メッセージ内容: メッセージ内容: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><reqmetrics:arm_correlator xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><reqmetrics:arm_correlator rm_correlator="ver=1,ip=9.170.233.131,time=1184644031515,pid=5600,reqid=20,event=1" soapenv:actor="reqmetricsURI" rm_correlator="ver=1,ip=9.170.233.131,time=1184644031515,pid=5600,reqid=20,event=1" soapenv:actor="reqmetricsURI" xmlns:reqmetrics="http://websphere.ibm.com"/><wsa:To>http://localhost:9082/EntSysSampProWeb/services/HelloService</wsa:To><wsa:Action>sayHello</ xmlns:reqmetrics="http://websphere.ibm.com"/><wsa:To>http://localhost:9082/EntSysSampProWeb/services/HelloService</wsa:To><wsa:Action>sayHello</ wsa:Action><wsa:MessageID>uuid:D3C7A643-0113-4000-E000-15E009AAE983</wsa:MessageID></soapenv:Header><soapenv:Body><p495:sayHello wsa:Action><wsa:MessageID>uuid:D3C7A643-0113-4000-E000-15E009AAE983</wsa:MessageID></soapenv:Header><soapenv:Body><p495:sayHello xmlns:p495="http://sample.ent.ise.com"><id>100</id><inputData><name>Y.N</name></inputData></p495:sayHello></soapenv:Body></soapenv:Envelope> xmlns:p495="http://sample.ent.ise.com"><id>100</id><inputData><name>Y.N</name></inputData></p495:sayHello></soapenv:Body></soapenv:Envelope> [07/07/17 19:44:42:116 JST] 0000001f MessageTrace 3 WSWS3572I: アウトバウンド HTTP SOAP 応答: 応答 [07/07/17 19:44:42:116 JST] 0000001f MessageTrace 3 WSWS3572I: アウトバウンド HTTP SOAP 応答: 応答 コンテンツ・タイプ: text/xml; charset=utf-8 コンテンツ・タイプ: text/xml; charset=utf-8 メッセージ内容: メッセージ内容: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To><wsa:Action> xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To><wsa:Action> http://sample.ent.ise.com/HelloService/sayHelloResponse</wsa:Action><wsa:MessageID>uuid:D3C7A204-0113-4000-E000http://sample.ent.ise.com/HelloService/sayHelloResponse</wsa:Action><wsa:MessageID>uuid:D3C7A204-0113-4000-E0000B0C09AAE982</wsa:MessageID><wsa:RelatesTo>uuid:D3C7A643-0113-4000-E0000B0C09AAE982</wsa:MessageID><wsa:RelatesTo>uuid:D3C7A643-0113-4000-E00015E009AAE983</wsa:RelatesTo></soapenv:Header><soapenv:Body><p495:sayHelloResponse 15E009AAE983</wsa:RelatesTo></soapenv:Header><soapenv:Body><p495:sayHelloResponse xmlns:p495="http://sample.ent.ise.com"><sayHelloReturn><helloName>Hello, xmlns:p495="http://sample.ent.ise.com"><sayHelloReturn><helloName>Hello, Y.N !</helloName><provProsTime>1184669081696</provProsTime></sayHelloReturn></p495:sayHelloResponse></soapenv:Body></soapenv:Envelope> Y.N !</helloName><provProsTime>1184669081696</provProsTime></sayHelloReturn></p495:sayHelloResponse></soapenv:Body></soapenv:Envelope> Webサービス・エンジンの問題 「com.ibm.ws.webservices.engine.*=all」 43 WASのトレース・ストリングとして、上記の設定を行うことで、trace.logに送受信のSOAPメッセージを記録 することができます。 トレース・ストリングの設定は、管理コンソールで、[サーバー]-[アプリケーション・サーバー]-[アプリケー ション・サーバー名]-[トラブルシューティング：ログ詳細レベルの変更]の「構成」タブまたは「ランタイム」タ ブで設定します。 また、WASのWebサービス・エンジンの問題と思われる場合には、トレース・ストリングとして、 「com.ibm.ws.webservices.engine.*=all」を指定することで、Webサービス・エンジンの処理の詳細を trace.logに記録することも可能です。 WASのWebサービス関連のトレースの取得方法の詳細については、下記のInfoCenterやTechnoteの記 載を参照ください。 WAS V6.1 InfoCenter「Web サービスのトレース」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/t wbs_tracewbscomp.html Technote「MustGather: Web services engine and tooling problems for WebSphere Application Server V6.1, V6, V5.1 and V5.」 http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21198363 Technote「MustGather: Web services security (WS-Security) problems with WebSphere Application Server」 http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21199335 Redpaper「WebSphere Application Server V6.1 Web Services Problem Determination」 http://www.redbooks.ibm.com/abstracts/REDP4306.html?Open 43 Webサービス基盤設計 1 2 3 4 5 トポロジー設計 パフォーマンス設計 運用管理 問題判別 セキュリティー設計、トランザクション設計 44 44 セキュリティー設計(1/2) 要件に応じてメッセージ・レベルとトランスポート・レベルのセ キュリティーを組み合わせる メッセージレベル：XMLメッセージに対するセキュリティー トランスポートレベル：通信経路自体のセキュリティー それぞれのレベルで対応できるセキュリティー要件は異なる SOAP データ・フォーマット HTTP JMS SOAP/HTTP SOAP/JMS トランスポート メッセージ・レベル etc... トランスポート・レベル 認証・機密性 IPSec, SSL.. 機密性 認証 <メッセージ 暗号化> 完全性 <デジタル署名> WS-Security 45 Webサービス環境でのセキュリティーは、メッセージ・レベルとトランスポート・レベルの2つのレイヤーに 分けて考えることができます。 ・メッセージレベル ：XML/SOAPメッセージに対するセキュリティ ・トランスポートレベル：プロトコル・レイヤーに応じて通信経路を流れるデータパケット自体を暗号化 メッセージレベルでのセキュリティにはWS-Securityが、トランスポートレベルでのセキュリティにはIPSec やSSLなどがあります。それぞれのレベルで対応できるセキュリティ要件は異なり、柔軟性や設定箇所、成 熟度など各々特徴があります。要件に応じて複数のセキュリティー・ソリューションを組み合わせることで強 固なセキュリティー環境を構築することができます。 認可など一部のセキュリティー要件に関しては、現状Webサービス環境での仕様としては標準化途中の 段階であり、言語・ベンダー固有のセキュリティー・ソリューションを選択する必要があります。 45 セキュリティー設計(2/2) トランスポート・ トランスポート・レベル・ レベル・セキュリティー SSL等、通信経路自体のセキュリティ 従来の成熟したセキュリティ・ソリューション メッセージ要素に対する暗号化・署名はできない ポイント間のみのセキュリティ→ESBなどの中間ノードでの複合/再暗号化が 必要 トランスポート・プロトコルに依存 複合化/再暗号化 リクエスター 仲介ノード HTTPS プロバイダー HTTPS メッセージ・ メッセージ・レベル・ レベル・セキュリティー XMLメッセージ自体をセキュア化することでEndtoEndのセキュリティを確保 WS-Security等のセキュリティ標準仕様による相互運用性の向上 リクエスター XML 仲介ノード プロバイダー XML 46 トランスポートレベルのセキュリティーはプロトコルレイヤーに応じて通信経路を流れるデータパケット自 体を暗号化します。これは従来のWebアプリケーション環境において広範に採用されているソリューション であり、実績や異機種環境での接続性などがメリットとしてあげられます。また、H/Wアクセレーターなどパ フォーマンス向上の為の手法も成熟している点もメリットとして挙げられます。デメリットとしては以下があり ます。 ・暗号化の単位がアプリケーションもしくは通信経路の単位となり、柔軟な使い分けが望めません。 ・途中でSOAPメッセージに対する処理を行う仲介ノードが入るケースなどは必ず複合化処理が必要とな ります。つまり、End to Endでメッセージの機密性が保たれるわけではなく、ポイント間のみを保証するソ リューションといえます。 ・SSLでいえば、通常はHTTP以外のトランスポート・プロトコルに対して適用することはできません。 これらのデメリットをカバーするため、SOA環境においてはWS-Securityをはじめとするメッセージレベ ルのセキュリティを考慮に入れる必要があります。メッセージレベルのセキュリティーではSOAPメッセージ の任意の箇所に対して柔軟に暗号化・署名をかけることができます。SOAPメッセージそのものに対して 暗号化・署名を施すことによって、リクエスターからプロバイダーまで一貫してセキュリティが保証されること になります。トポロジー上、途中でトランスポートレベル・セキュリティのターミネート処理が入ったとしても、 その機密性、完全性は保証されると言えます。 トランスポートレベルのセキュリティとメッセージレベルのセキュリティを組み合わせればより強固なセキュ リティ基盤を構築することが可能です。SOA環境で必須の要件と言える相互運用性の面からもWSSecurityをはじめとするWebサービスのセキュリティー仕様の重要性は高まってきています。 Webサービスの通信をSSL化する方法の詳細は、下記のテクニカル・フラッシュにまとまっていますので、 ご参照ください。 テクニカル・フラッシュ「WebサービスアプリケーションのSSL構成 WASV6, V6.1 設定ガイド (WAS-07014)」 http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-000B3D93 WASのWebサービスのWS-Security設定の詳細は、下記のDeveloperDomainの記事にまとまってい ますので、ご参照ください。 DeveloperDomain記事「Webサービス・セキュリティー・ガイド」 http://www-06.ibm.com/jp/software/websphere/developer/was/wv61/guide/ws_security.html 46 トランザクション設計：Webサービスにおけるトランザクション リクエスターと リクエスターとプロバイダーを プロバイダーを跨った、 った、トランザクション処理 トランザクション処理を 処理を実施 SOAPメッセージによるコーディネータ間のトランザクション管理を実現 コーディネーター：分散環境におけるトランザクション処理の調整を行う WebServiceリクエスター WebServiceプロバイダー SOAP/HTTP AS AS JTAの技術 JTAの技術 TM トランザクション・スコープ WebServiceリクエスター AS coordinator WebServiceプロバイダー SOAP/HTTP AS WS-Transactionの技術 WS-Transactionの技術 coordinator トランザクション・スコープ 47 アプリケーションでトランザクション処理を行う場合、トランザクション・スコープの範囲によってその処理 内容は異なります。アプリケーション・サーバーごとにトランザクション管理を行うコンポーネントが存在しま すが、コンポーネントが複数の場合、コンポーネント同士の調整が必要となりトランザクション処理は複雑 になります。 Webサービス環境においては、トランザクション管理を行うコンポーネントを「コーディネーター」と呼びます。 J2EEにおけるトランザクション仕様であるJTA(Java Transaction API)の「トランザクション・マネージャー」と 同じように考えることができます。上図にWebサービス環境におけるトランザクション・スコープの例を示し ます。 Webサービス・プロバイダー内でトランザクションの開始/終了が行われる場合（トランザクション・スコー プがWebサービス・プロバイダーで閉じている場合）は、JTAに則った挙動となります。トランザクション・マ ネージャーによってACID属性を維持したトランザクション処理が実行されます。 一方、Webサービス・リクエスターでトランザクションが開始され、Webサービス・プロバイダーでの処理を 経て、トランザクションが終了される場合は、コーディネーター同士でトランザクションの調整が必要となり ます。トランザクション・コンテキストの伝達などトランザクションの調整をSOAPメッセージを介して実現する 技術がWS-Transactionになります。 47 トランザクション設計：WS-Transaction Webサービス Webサービス環境 サービス環境において 環境においてトランザクション においてトランザクション処理 トランザクション処理を 処理を実現する 実現する技術 する技術 下記の3つの技術（仕様）によって構成される Web Services Coordination (WS(WS-Coordination) 分散アプリケーション間の調整を行うフレームワーク Web Services Atomic Transaction (WS(WS-AtomicTransaction) AtomicTransaction) 短時間で終了するアトミック・トランザクションを調整するプロトコル 複数のアプリケーション・サーバー間のアクションをまとめる アクションの結果から振る舞いを決定（"all-or-nothing"） Web Services Business Activity (WS(WS-BusinessActivity) BusinessActivity) ロング・ランニング・トランザクションを調整するプロトコル ビジネスの例外（処理のキャンセルや予約状況の更新等）を処理するため、ビジネスロジッ クに適用 例外発生時はコンペンセーション（補償）によって、逆向きの処理を実施 48 Webサービス環境においてトランザクション処理を実現する仕様を総じてWS-Transactionと呼びます。 実際はWS-Coordination、WS-AtomicTransaction(WS-AT)、WS-BusinessActivity(WS-BA)の３つの仕様 から構成されています。 WS-Coordinationは、トランザクションの調整に必要なコーディネーション・コンテキスト(識別子やコー ディネーションに必要な情報)の作成や、調整プロトコルの決定に使用されるコーディネーターの技術で す。 WS-AtomicTransaction(WS-AT)は、分散配置されたコーディネータ間で、短期間実行される2PCのトラ ンザクション調停を行うためのプロトコルです。Webサービス・リクエスター、Webサービス・プロバイダーに おけるリソース・マネージャーへの処理を１つのトランザクション・スコープに含めることが可能です。トラン ザクション内で実行されるリソースへの処理は全て実行されるか、全く実行されない（“all-or-nothing”）と いう属性を持つためにアトミック・トランザクションと呼ばれます。 WS-BusinessActivityはWebサービス環境において、ロング・ランニング・トランザクションを実現するプロ トコルです。WS－ATが短時間で終了するアトミック・トランザクションであるのに対して、WS-BAは長期間 実行されるアクティビティや、ビジネスの例外（処理のキャンセルや予約状況の更新など）を処理するため のビジネス・ロジックの適用に対応しています。 コンペンセーション(補償処理)とは、既に実行された処理に対して逆向きとなる操作を行うことで、処理 が実行されなかったかのような状態に戻すこと 48 WAS V6.1 Feature Pack for Web Services 49 49 WAS V6.1 Feature Pack for Web Servicesとは WAS V6.1上にFeature Packという形式の追加モジュールを インストール 正式サポートされる追加モジュール WASV6.1のライセンスでサポート Feature Pack一覧 Feature Pack for WebServices(FPWS)：正式版公開中 Feature Pack for Web 2.0(FPWEB2.0)：正式版公開中 Feature Pack for EJB 3 (FPEJB)：正式版公開中 50 WASV6.1より提供されるようになったFeature Packは、WAS V6.1上に特定のテーマに沿った最新の 機能を追加するものです。WAS V6.1がインストールされているマシン上に、追加インストールを行って拡 張機能を追加するもので、 Bug Fixとは異なります。リリースアップやバージョンアップではなく新しく Feature Packというパッケージを提供する事で、新機能を必要とするお客様のみが機能拡張出来るよう、 柔軟性をもたせています。これによって、V6.1の現状機能を維持し安定したいお客様と、Webサービスの 最新機能を早期適用したいお客様の、双方の要望に応える事が出来るようになりました。 今後も順次FeaturePackのリリースが予定されています。Feature Packのダウンロードなどは、下記の サイトをご利用ください。 Technote「Announcing: Feature Pack for Web Services for WebSphere Application Server V6.1」 http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21264563 「WebSphere software early programs」 https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere.shtml 50 WS-FPで拡張される主要な機能のポイント インターオペラビリティの インターオペラビリティの向上 非同期プログラミングモデル 非同期プログラミングモデル のサポート WS-Iの最新Profileをサポート 最新の各種仕様をサポート トランスポート・レベルではなくプログラミングモデルの レベルで非同期呼び出しが可能（JAX-WS） 開発容易性の 開発容易性の向上 アノテーションによる開発でコードがシンプルに（JAX-WS） メッセージ送受信 メッセージ送受信における 送受信における 信頼性の 信頼性の確保 Webサービスランタイムのレベルで信頼性・セキュリティを 確保（WS-RM、WS-SC） 構成管理方法の 構成管理方法の向上 バイナリーデータの バイナリーデータの転送 その他 その他 管理コンソールのWebサービス設定項目の追加 ポリシーベースの設定方法を採用（WS-Policy） 簡単にバイナリーデータ転送ができ、.NETとのインターオペ ラビリティも確保（MTOM） XMLバインディングのサポート（JAXB） 高速なXMLパーサーの採用（StAX） 51 WAS V6.1のFeature Pack for Web Servicesによって追加される主な機能の特徴を簡単にご紹介しま す。 1つ目は、WS-I profileや各種仕様の最新バージョンをサポートする事で、WASV6.1が備えているイン ターオペラビリティを更に向上させている点です。 2つ目は、SOAP/JMSというトランスポート・レベルではなくプログラミングモデルで非同期呼び出しを行 えるようになった点です。 3つ目は、アノテーションによってコードがシンプルになり、DDが不要になったり、UT時にJ2EEコンテナ が不要になるなど、開発が容易になった点です。 4つ目は、WS-RM、WS-SCのサポートにより、信頼性の高いメッセージの送受信が可能になった点で す。 WS-RM(Reliable Messaging)とは、Webサービスで信頼性の高いメッセージング送信を行う仕組みに なります。WS-RMプロトコルを使用し、RM SourceとRM Destinationが確実なメッセージング配信を行い ます。WS-SC(Secure Conversation)とは、複数のメッセージング交換に渡るセキュリティ提供方法が定 義されています。 5つ目は、構成管理方法の向上で、Webサービスに関する要件、設定、機能をポリシーとして記述しア プリケーションにアタッチする事ができるようになった点や、管理コンソールの設定画面の拡張が挙げられ ます。 6つ目は、これまで歴史的に.NetとJavaで異なっていたバイナリーデータの添付方式について、両方の ベンダーが合意したMTOM(Message Transmission Optimization Mechanism)という仕様をサポートし、 XOPを利用したバイナリーデータの送受信を可能にした点です。 その他、XMLバインディングをサポートしHTTPプロトコルでのXML送受信が可能になった点、これまで のDOMやSAXとは異なる新しいXMLのパーシング仕様であるStAX XMLパーサーをサポートしている点 が挙げられます。 51 (参考)WS-FPがサポートする仕様 仕様 WAS6.1 WSFP Java API for XML-based RPC (JAX-RPC) V1.1 V1.1 Java API for XML Web Services (JAX-WS) - V2.0 Java Architecture for XML Binding (JAXB) - V2.0 Streaming API for XML (StAX) - V1.0 SOAP with Attachments API for Java (SAAJ) V1.2 V1.2,V1.3 SOAP V1.1 V1.1,V1.2 XML-binary Optimized Packaging (XOP) - V1.0 Web Services Interoperability Organization (WS-I) Basic Profile V1.1 V1.1 WSDL V1.1 V1.1 Web Services-Interoperability Organization (WS-I) Attachments Profile V1.0 V1.0 Web Services Addressing (WS-Addressing) V1.0 V1.0 WS-Security V1.0 V1.0,V1.1 Web Services Interoperability Organization (WS-I) Basic Security Profile V1.0 V1.0 Web Services Secure Conversation (WS-SC) - V1.0 Web Services Reliable Messaging (WS-RM) - V1.0,V1.1 Web Services Trust Language - V1.0 Message Transmission Optimization Mechanism (MTOM) - V1.0 52 上記は、WSFPがサポートする主な仕様のバージョンです。 重要な仕様としては、JAX-WS、JAXB、StAX、WS-SC、WS-RM、WS-Policy、MTOMなどが挙げられ ます。 尚、WSFPやWAS V6.1がサポートするWebサービス仕様の詳細は下記のInfoCenterの記載を参照く ださい。 WSFP InfoCenter「Specifications and API documentation」 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.wsfep.multiplatfor m.doc/info/ae/ae/rovr_specs.html 52 まとめ Webサービスの基盤設計は、Webアプリケーションの延長線 であり、Webアプリケーションと大きく異なるわけではない Webサービス基盤設計において、Webアプリケーションと比較 して注意する部分は下記の点 インターオペラビリティー Webサービス・リクエスターのチューニング項目 Webサービス・リクエスターにおけるプロバイダーの宛先指定、タイム アウト設定 問題判別におけるSOAPメッセージのキャプチャー 53 53 参考資料 WAS V6.1 InfoCenter http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp WAS V6.1 Feature Pack for Web Services InfoCenter http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm. websphere.wsfep.multiplatform.doc/info/welcome_nd.html Redbook「 Redbook「Web Services Handbook for WebSphere Application Server 6.1, SG24SG24-72577257-00」 00」 http://publib-b.boulder.ibm.com/abstracts/sg247257.html?Open 54 54