Oracle WebLogic Server

Transcription

1 Oracle WebLogic Server WebLogic Server を使用した開発 Oracle ホワイト ペーパー 2014 年 6 月

2 目次 はじめに... 1 Java 標準 APIによる 最新アプリケーションの開発の実現... 2 Java API for WebSocket 1.0: 非常にインタラクティブなアプリケーションの有効化... 3 Java API for JSON Processing 1.0:JSONの解析と処理の簡素化 JAX-RS 2.0:Java API for RESTful Webサービス JPA 2.1:Javaの永続性の進化 Oracle WebLogic Server でのJPA 2.1の使用 革新的な機能 Oracle TopLinkとTopLink Data Service 開発者にとっての使いやすさ 開発者用 zipファイル ディストリビューション 開発ツールのサポート クラス ロードの解析と構成 Oracle Apache Mavenのサポート Oracle Mavenサポートの利用の概要 Oracle Mavenアーティファクト Oracle Maven 同期プラグイン Oracle WebLogic Mavenプラグイン Oracle Maven Archetypes 継続的な統合の実行 結論 参考資料... 37

3 はじめに Oracle WebLogic Server には次のような開発者指向の機能が搭載されており 開発者にとって効率的で優れ た開発プラットフォームです» 高品質な Java EE 実装の提供» サイズの小さいzipベースのディストリビューションにより 標準的なGUIベースのインストーラより高速にダウンロード 設定 使用が可能» WebLogic Serverでは Eclipse JDeveloper NetBeansなどの最先端のIDEとの強固な統合ポイントが確立されているため 開発者が簡単にアプリケーションの開発 デプロイ テスト デバッグを行うことが可能» FastSwap 機能により 再デプロイメント操作を実行することなく 開発中に変更されるクラスを動的に再ロードでき 開発サイクルとテスト サイクルに対する再デプロイメント操作の影響を軽減» Apache Mavenのサポートを組み込み デプロイメント操作をMavenライフ サイクルから実行し 後続のリリースで拡張できるようにするプラグインを最初から含めることによって より多くの構成タスクや運用タスクをサポート» 開発の初期段階でのアノテーションの使用など 革新的な技術の導入により Http PubSub Server 実装による機能豊富なWebアプリケーション開発をサポートし Springなどの主要なオープン ソース フレームワークとの統合ポイントを提供 Oracle WebLogic Server のリリースにより 開発者向けに次のような重要な新機能が提供されました» 複数の主要な新規 Java 標準の追加により REST ベースの Web サービスを公開および使用したり WebSocket 接続を使用してクライアントとサーバー間でデータを双方向で送信したり JSON を使用してデータ ペイロードを表示したり JPA を利用してデータにアクセスしたりするアプリケーションの開発が可能» WebLogic Server Oracle Coherence および Oracle TopLink のコンポーネントを対象とする共通の API およびライブラリ用に オラクル固有の Maven アーティファクト セットを定義» 標準の製品ディストリビューションの一部として Apache Maven の最新バージョンをバンドル» 新しい Apache Maven プラグインである oracle-maven-sync の提供により オラクルが定義したアーティファクトの Maven リポジトリへのインストールを管理» WebLogic Server をローカルにインストールしなくてもすべての運用目標を実行できる 新バージョンの WebLogic Maven プラグインの提供により WebLogic Server を継続的なテスト環境により簡単に統合可能» 開発者が一般的なアプリケーション パターンと連携するためのスタータ プロジェクトの生成に使用できる WebLogic Server および Oracle Coherence の Maven Archetypes セットの提供» 革新的な新しいアプリケーションの開発をサポートする付加価値機能 ( 双方向のネットワーク効率の良い方法でリッチ クライアントと通信するアプリケーションを開発するための WebSocket プロトコル (RFC 6455) のサポートなど ) プログラミングなしでデータへの REST アクセスを可能にする TopLink Data Service( データ変更時のライブデータ通知イベント発行のサポートを含む ) 標準的な Java EE アプリケーション内で一般的な OSGi サービスと OSGi バンドルの使用を提供する OSGi フレームワークの定義および実行機能により アプリケーションでの OSGi の使用をサポート 1 WebLogic Server を使用した開発

4 モバイル アプリケーションのビジネスでの採用 利用の拡大に伴い 開発者は ポータブル サービス およびさまざまなブラウザやデバイスからアクセスできるポータブルなデータ形式を利用しているAPIを提供する方法を模索しています また アプリケーションがこれらのバックエンド サービスと通信してデータをタイムリーかつ効率的に送受信する方法を最適化することも必要です Oracle WebLogic Server には 既存のJava EE 6 実装ベースを補完するJava 標準 APIの更新によって 最新のモバイル アプリケーションの開発を直接サポートし 実現する機能があります WebLogic Server の新規および更新されたJava 標準 APIは次のとおりです» Java API for WebSocket 1.0 新規 WebSocketプロトコルを使用して クライアントとサーバー間の双方向の永続的な接続を作成するアプリケーションを開発するためのJava 標準 APIです アプリケーションで 非常に効率的かつ短い待機時間でデータをやり取りできます» Java API for JSON Processing(JSON-P)1.0 新規 JSON(JavaScript Object Notation) オブジェクトを作成 解析するためのJava 標準 APIです ポータブルな形式でより簡単かつ効率的にアプリケーション間でデータをやり取りできます» Java API for RESTful Services(JAX-RS)2.0 更新 RESTベースのサービスを開発するためのJava 標準 API です 本リリースで更新され RESTサービスをコールしたり フィルタとインターセプタを追加してリクエストとレスポンスを操作したりするための標準クライアントAPIが提供されています また JAX-RS 2.0 仕様のJersey 実装が組み込まれており 使い慣れたJAX-RSプログラミング モデルを使用した Server-Sent Event 通信メカニズムとの連携もサポートされています» Java Persistence API(JPA)2.1 更新 データの永続性を管理するためのJava 標準 APIで Criteria API 経由のバルク更新変更のサポート データベース ストアド プロシージャの呼び出しのサポート スキーマおよびデータベース アーティファクト生成の標準化などの新機能が搭載されています Java 標準 API による 最新アプリケーションの開発の実現 拡大しつつあるHTML5の採用により 開発者は非常にインタラクティブかつ動的なアプリケーションを 以前より大規模に構築できるようになっています このような新しい種類のアプリケーションは 外観が非常に魅力的で さまざまなデバイス フォーム ファクタに対応しているだけでなく 多種多様なソースからリアルタイムで情報を取り込み 非常にインタラクティブかつ便利な方法で表示できます HTML5 および対応するJavaScriptやCSSのテクノロジーの使用と採用の増加によって アプリケーションを一度記述すれば スマートフォン タブレット デスクトップなどのさまざまなデバイスで正しくレンダリングおよび応答し アクセスできるようになりました このような モバイル ベースの非常に動的なアプリケーション世界への急速な移行と 年中無休というグローバルな性質での使用パターンに対応できるよう サーバーからクライアントにデータを送信する既存モデルとは違った これらのクライアントと連携するバックエンド サービスの開発と効率的なスケーリングが必要です Oracle WebLogic Server には WebSocketプロトコルを使った双方向ネットワーク接続と JSONで HTML5アプリケーションの共通語で表示されるデータ ペイロードとの連携をサポートするために特別に提供された新しいJava 標準が追加されており 最新の動的アプリケーションのロールアウトの強固な基盤となります また JAX-RS 2.0やJPA 2.1などの既存の主要 APIが更新されており RESTベースのWebサービスの開発や 効率的なデータ アクセスのための機能がさらに追加されています 2 WebLogic Server を使用した開発

5 Java API for WebSocket 1.0: 非常にインタラクティブなアプリケーションの有 効化 Oracle WebLogic Server では WebSocketプロトコル (RFC 6455) の使用がサポートされています このためクライアントは 接続先のピアからのメッセージの随時送信をサポートするサーバーとの間で 軽量 双方向 かつ永続的な接続を構築できます サーバーからのメッセージ送信とクライアントでのメッセージ受信に 現在一般的に使用されている非効率な手法 ( ポーリングやロング ポーリングのメカニズムなど ) は必要ありません WebSocketプロトコルによる永続的な双方向接続により クライアントやサーバーはいつでもメッセージを相互送信できます このため さまざまなサービスとの間でデータを受信およびやり取りし 非常にインタラクティブで動的なエクスペリエンスをユーザーに提供する必要がある最新アプリケーションの作成に最適なソリューションです WebSocketは 電話のようなものです 電話をかける際は まず番号をダイヤルします 相手が受話器を取って電話を受けると 接続が確立されます 接続がアクティブな間は 双方が好きなときに同時に話したり ( スムーズな会話のためにはお勧めしませんが ) 話しながら相手の話を聞いたりすることができます これが 全二重通信です 一方が電話を切るまでは 会話中であるかどうかに関わらず 接続はアクティブなままです Danny Coward Java WebSocket Programming Oracle Press 2013 WebSocketプロトコルの概要 WebSocketプロトコルの場合 WebSocket 接続はまず WebSocketエンド ポイントに対する標準 HTTPリクエスト (WebSocketプロトコルを使用するように接続をアップグレードするリクエストなど) を行うクライアントで開始されます リクエスト内では サポートされるWebSocket 機能を示す追加情報が渡されます これは ハンドシェイクのオープンと呼ばれます 3 WebLogic Server を使用した開発

6 図 1 WebSocket のハンドシェイクのオープン サーバーで接続リクエストの受入れが可能である場合は 接続をアップグレードできることと アップグレード先のプロトコル およびWebSocket 固有の情報を示すHTTPレスポンスが返されます このレスポンスは ハンドシェイク レスポンスのオープンと呼ばれます 図 2 WebSocket のハンドシェイク レスポンスのオープン このリクエスト / レスポンスのやり取りが正常に完了すると 同じネットワーク アドレスとポートを使って HTTP 接続がWebSocket 接続に置き換えられます WebSocket 接続が確立されると クライアントとサーバー間で自由にWebSocketを送受信できます 一方が明示的に接続を終了するか 外的要因 ( 非アクティブによるネットワーク タイムアウトや基盤となるネットワークの問題など ) によって接続が終了されるまで 接続は有効なままです データは 一連のWebSocketメッセージとして WebSocket 接続経由で送信されます 各 WebSocketメッセージはデータ フレーム内で送信されます 長いメッセージは複数のフレームに分けられて順番に送信され 受信者側で再構築されて元のメッセージが再生成されます 4 WebLogic Server を使用した開発

7 図 3 WebSocket のやり取り WebSocketアプリケーションの開発 JSR-356 Java API for WebSocket 1.0の仕様では WebSocketアプリケーションをJavaで作成するための標準プログラミングAPIが導入されています このAPIでは WebSocketエンド ポイントの概念が導入されています WebSocketエンド ポイントによって 会話の一方の処理と 必要に応じたメッセージの送受信 および強制されたライフ サイクル アクティビティへの応答が行われます WebSocket 接続のサーバー側は ServerEndpointと呼ばれます ServerEndpoint 実装の作成については 2つのアプローチが仕様で定義されています アノテーション ベースのアプローチでは エンド ポイント自体の構成と適切に定義されたライフ 2つめのアプローチはプログラム的なAPIを使用するもので 必要なライフ サイクル メソッドの提供と エンド ポイント インスタンスの動的な定義や構成に使用されるベース クラスとインタフェースが開発者に提供されます WebSocketエンド ポイントを公開するアプリケーションに送信される主要なライフ サイクル イベントは次のとおりです» Connection Opened( 接続を開く ): このイベントは WebSocketエンド ポイントが ピアとの接続を開くように要請された場合に発生します この際 開発者はセッションとやり取りして 場合によってはWebSocketエンド ポイントが使用する初期化タスクを実行できます» Message Received( メッセージを受信 ): ピアからのメッセージを受信しました このメッセージはテキスト メッセージ バイナリ メッセージ またはpongメッセージで 完全フォームまたは部分的フォームで受信されます» Error Occurred( エラーの発生 ):WebSocket 接続でエラーが発生しました 開発者は» Connection Closed( 接続を閉じる ): ピアで接続が終了されました 開発者は 5 WebLogic Server を使用した開発

8 アノテーション ベースのプログラミング モデルを使用した場合 アプリケーション自体をWebSocketエンド ポイントとして提示し ライフ サイクルに参加してメッセージを送受信するアプリケーションは 数行のコードのみの非常に簡単なクラスで表すことができます たとえば 通常のエコー WebSocketについて少し異なる点として 次のクラスではWebSocketクライアントからメッセージを受信し リバース フォームで返信します 図 4 WebSocket ServerEndpointとしてのクラスを示します このクラスは WebSocket 実装で 受信するWebSocketメッセージの処理に使用されるメソッドを示します この簡単な例では メソッドでテキスト メッセージ全体を受信しています 追加のメソッド定義を使用して バイナリ メッセージを受信したり 両方のメッセージ タイプの部分的フォームを処理したりすることができます 図 のメソッド フォーム プログラム的なAPIを使用するため エンド ポイント クラスを拡張してWebSocketエンド ポイントを定義できます エンド ポイント クラスによって 同等の一連のライフ サイクル メソッドが定義されます このメソッドを上書きして WebSocketでイベントのオープン エラー 終了を処理できます 6 WebLogic Server を使用した開発

9 ピアからメッセージを受信するために onmessageメソッドを提供するmessagehandlerクラスが作成されます このメソッドは エンド ポイントでメッセージが受信されると起動されます アノテーション付きモデルと同様に MessageHandlerと必要なonMessageメソッドでは 複数のフォームのうちの1つを使用して 全体または部分的なメッセージとして受信されるテキスト メッセージやバイナリ メッセージを処理できます 図 6 プログラム的なエンド ポイントの簡単な例 プログラム的なAPIを使用する場合 エンド ポイントの構成は ServerApplicationConfigインタフェースの実装によって提供されます この実装では ServerEndpointConfigインスタンスが作成されます このインスタンスには クライアントのアクセス用に エンド ポイントのクラスやURI が含まれます ServerEndpointConfigクラスでは より複雑なタスク ( サブプロトコル ネゴシエーションやオリジン サーバーのチェックなど ) も処理できます 7 WebLogic Server を使用した開発

10 図 7 プログラム的な WebSocket エンド ポイント WebSocketのエンコーダとデコーダ JSR-356 Java API for WebSocket 1.0の仕様では WebSocketメッセージとして送受信できるJavaオブジェクトのタイプが指定されています たとえば文字列 プリミティブ ( およびそれらに対応するオブジェクト ) バイト配列を含むバイナリ メッセージ タイプなどです カスタムJavaオブジェクトを使用する場合 この仕様によってエンコーダとデコーダのコンポーネントの概要が定義されます これを実装することで カスタムJavaオブジェクトを WebSocketメッセージとして送信できる形式に変換したり戻したりすることができます このAPIを使用してJavaオブジェクトをJSONフォームに変換したり戻したりするエンコーダとデコーダの例については Java API for JSON Processing の項を参照してください WebSocketクライアント現在使用されている もっとも代表的なWebSocketクライアントは Webアプリケーションで作成されるもので HTMLページとJavaScriptを組み合わせてユーザー向けのアクティブ ページが作成されます このような場合 WebSocketクライアントは W3C WebSocket JavaScript APIを使用して開発されます クライアント側の開発者は この小さくて便利なJavaScript APIを使用して サーバーとのWebSocket 接続を開き その接続経由でメッセージを送信し WebSocket 接続で発生するイベントに応答する手段を獲得します これらのイベントには 接続時のデータ受信 接続の終了 エラーの検出などが含まれます このイベント ベースのプログラミング モデルによって 開発者は データの受信時に ( リクエストを出してレスポンスを待つのではなく ) データに対応するアプリケーションを作成できます 非同期のAjaxプログラミング スタイルでは 非同期レスポンスの受信時にHTTPリクエストが作成され コールバック関数によって処理されます これを使用してきた開発者にとって WebSocket APIは非常に使い慣れたものですが より効率的で高機能なWebSocketプロトコルを使用できるというメリットがあります たとえば 保有しているエコー WebSocketエンド ポイントをコールする簡単なWebSocketクライアント アプリケーションでは 以下のようにコールを行って 接続を開いたり onmessageコールバック関数経由でメッセージの送受信を行ったりします 8 WebLogic Server を使用した開発

11 図 8 JavaScript WebSocket API の使用例 このタイプの WebSocket API をコールする HTML クライアントを使用すると ピア間で接続を開いたりメッ セージの送受信を行ったりすることができます 図 9 HTML WebSocket クライアント 9 WebLogic Server を使用した開発

12 Java API for WebSocket Protocol 1.0 仕様の開発によって Javaで直接 WebSocketクライアントのプログラミングをサポートすることも ある程度重要になってきました このためJSR-356 仕様では サーバー側のプログラミング モデルの提供だけでなく WebSocketアプリケーションのクライアント側の作成にも取り組んでいます この仕様では 両方の接続側の開発にそれほど大きな違いはありません ただし一般的に ServerEndpointは接続リクエストに対して準備済みで待機するWebSocketエンド ポイントであり 同時に複数の接続をホストできるのに対し ClientEndpointではそのピアに対する接続が作成され 同時に接続できるピアは1つだけという点が異なります ClientEndpointのライフ サイクルやイベント モデルは通常 一般的なWebSocketエンド ポイントと同じで アノテーションやプログラム的なモデルを使用して定義できます 図 10 Java WebSocket クライアントの簡単な例 クライアントが実行されてサーバー ピアに接続されると そのクライアントはエンド ポイントのライフ サイクル イベントに従い サーバー ピアとやり取りする場合は 必要に応じてアノテーション付きメソッドが呼び出されます 10 WebLogic Server を使用した開発

13 図 11 WebSocket クライアントの実行 WebLogic Server での WebSocket プロトコルの使用 JSR-353 および Java API for WebSocket 1.0 仕様の登場により WebLogic Server 固有の API を含む WebSocket プ ロトコル (RFC 6445) をサポートしていた Oracle WebLogic Server の以前の WebSocket 実装は こ のリリースでは非推奨となっています 新規のすべての開発アクティビティでは Java 標準 API である javax.websocket.* を使用します Oracle WebLogic Server での WebSocket 実装は JSR-353 Java API for WebSocket 1.0 仕様に基づいており エ ンジンとして Tyrus リファレンス実装が使用されます WebLogic のネットワークおよびスレッド サービスとの 統合により 社内ベンチマークで高レベルなパフォーマンスとスケーラビリティが測定され 同じベンチマーク テストの実行時に使用された一連のメトリック全体で 前の実装より優れたパフォーマンスが示されました WebSocket クライアントのエミュレーション WebSocket プロトコルは サーバーからブラウザ クライアントへのデータ プッシュが可能であるため HTML5 に不可欠なものであると予想され WebLogic Server を使用してデプロイされる多くの最新 Web アプリケーションで 一般的に使用される要素になります ただし WebSocket 接続の使用によって 問題が発生する可能性も想定されます WebSocket 接続が許可されないネットワーク仲介機能 ( ファイアウォールやプロキシなど ) があったり 使用するブラウザ プラットフォームが WebSocket をサポートしていなかったりする場合があるためです いずれの場合も 開発者は自身の特定のデプロイメント環境が WebSocket 接続をサポートするかどうかを把握し サポートしない場合は 他の HTTP ベースの手法 ( ロング ポーリングによるサーバー プッシュ オペレーションのエミュレーションなど ) を使用する必要があります 開発者にとっては このような WebSocket の環境やブラウザ サポートの違いに対応するため このようなフォールバックの場合の選択やプログラミングがますます複雑になっています このユースケースをサポートするため Oracle WebLogic Server には WebSocket フォールバック機能があり 開発者はサーバー側 (JSR-356 経由 ) とクライアント側 (WebSocket JavaScript API 経由 ) の両方で WebSocket プロトコルを使用できます ただしこの場合 WebSocket メッセージの送信に使用される実際の転送メカニズムは ネイティブの WebSocket 接続の使用から HTTP ベースのロング ポーリング メカニズムの使用に 透過的にネゴシエーションされる可能性があります これは WebSocket プロトコルと関連するプログラミング モデルの機能を利用するアプリケーションを構築できる開発者にとって 分かりやすいものです WebSocket 接続を定期的または確実に確立できない状態を処理する明示的なソリューションを提供する必要はありません WebSocket のフォールバック機能は 2 つのコンポーネントで構成されます 1 つは orasocket.js と呼ばれるクライアント側の JavaScript ライブラリで WebSocket プロトコルのクライアント側のやり取りを HTTP のロング ポーリング ベースの接続経由で処理します もう 1 つは WebLogic Server に統合されているサーバー側のアダプタで HTTP ベースのデータ フレーム変換を処理し 標準の WebSocket メッセージとして WebSocket エンジンにルーティングします WebSocket フォールバック機能を有効にするには orasocket.min.js という JavaScript ライブラリがアプリケーションと HTML5 クライアント ページに含まれており ロードできる必要があります また WebSocket アプリケーションを含む Web アプリケーションに 必要に応じてフォールバック モードを使用できるようにするコンテキスト パラメータが提供される必要があります 11 WebLogic Server を使用した開発

14 図 12 web.xml での WebSocket フォールバックの有効化 Java API for JSON Processing 1.0:JSON の解析と処理の簡素化 Oracle WebLogic Server には JSR-353 リファレンス実装が含まれており Java API for JSON Processing 1.0(JSR 353) 仕様が完全にサポートされています JSON Processing の API と実装は WebLogic Server インスタンスにデプロイされるすべてのアプリケーションで使用できます JSON(JavaScript Object Notation) は軽量なデータ交換形式で インターネット経由で相互通信するアプリケーションでのデータのシリアライズおよびデシリアライズ用の一般的な形式として 広く使用されています このようなアプリケーションは 異なるプログラミング言語で作成され まったく異なる環境で実行されることがあります JSON は オープンな標準であり 読取りと書込みが簡単で 他の表現よりコンパクトなため このような使用例に適しています RESTful Web サービスでは通常 リクエストとレスポンス内のデータの形式として JSON が広く利用されています 通常 JSON 表現は対応する XML 表現よりコンパクトです JSON には終了タグがないためです Java API for JSON Processing は JSON テキストの処理 ( 解析 生成 変換 問合せ ) に便利です JSON データの生成および解析用に XML ドキュメントで使用されるものと似た 2 つのプログラミング モデルがあります» オブジェクト モデル API: オブジェクト モデル API によって メモリ内の JSON データを示すツリーが作成されます このツリーはナビゲート 分析 変更できます このアプローチはもっとも柔軟であり ツリーのすべてのコンテンツへのアクセスが必要な処理に使用できます ただし ストリーミング モデルより低速で より多くのメモリ量が必要な場合があります このオブジェクト モデルでは ツリー全体を迅速にナビゲーションして JSON 出力が生成されます» ストリーミング API: ストリーミング API では JSON データの 1 つの要素を一度に読み取るイベント ベースのパーサーが使用されます パーサーによってイベントが生成され オブジェクトや配列の開始 / 終了時 鍵や値の検索時には処理が停止されます 各要素はアプリケーション コードごとに処理または破棄することができ パーサーは次のイベントに進みます このアプローチは 要素の処理に残りのデータからの情報が不要なローカル処理に適しています ストリーミング モデルでは 1 つの要素を一度に使う関数コールにより 所定のストリームに JSON 出力が生成されます オブジェクト モデル API オブジェクト モデル API は JSON オブジェクトおよび配列構造の不変のオブジェクト モデルを提供する高レベルな API です これらの JSON 構造は JsonObject および JsonArray という Java タイプを使用するオブジェクト モデルとして表されます インタフェース javax.json.jsonobject にはマップ ビューがあり ゼロ以上の名前 / 値ペアの 順不同のコレクションにモデルからアクセスできます 同様に インタフェース JsonArray にはリスト ビューがあり ゼロ以上の連続した値にモデルからアクセスできます オブジェクト モデル API では ビルダー パターンを使用してこれらのオブジェクト モデルが作成されます クラス JsonObjectBuilder および JsonArrayBuilder には それぞれタイプ typejsonobject および JsonArray のモデルを個別に作成するメソッドがあります これらのオブジェクト モデルは クラス JsonReader を使用して入力ソースから作成することもできます 同様に これらのオブジェクト モデルは クラス JsonWriter を使用して出力ソースに書き込むことができます 12 WebLogic Server を使用した開発

15 ストリーミングAPI ストリーミングAPIは インタフェースJsonParserとJsonGeneratorで構成されます インタフェース JsonParserには JSONをストリーミングで解析するメソッドが含まれます インタフェースJsonGenerator には JSONを出力ソースにストリーミングで書き込むメソッドが含まれます JsonParserでは プル解析プログラミング モデルを使用して JSONデータに対し 前方 / 読取り専用アクセスを行うことができます このモデルでは アプリケーション コードにより パーサー インタフェースでスレッドが制御されメソッドがコールされ パーサーを前方に移動したり 現在のパーサーの状態から JSONデータを取得したりすることができます JsonGeneratorには JSONを出力ソースに書き込むメソッドがあります このジェネレータによって 名前 / 値ペアがJSONオブジェクトに 値がJSON 配列に書き込まれます ストリーミングAPIは 大量のJSONデータを効率的に処理できるよう設計された 低レベルのAPIです Oracle WebLogic Server でのJSONの使用 Oracle WebLogic Server のコンテキスト内では Java API for JSON Parsingによって JSONペイロードを使用するための標準的で簡単かつ便利なAPI が提供されます これは特に ブラウザ ベースの WebSocketクライアントとのメッセージのやり取りでJSONが一般的に使用される WebSocket 対応のアプリケーションに適しています 図 13 Java API for JSON Processing を使用する WebSocket デコーダの例 対応するエンコーダ コンポーネントによって AuctionMessageオブジェクトがWebSocketメッセージとして送信できるフォームに変換されます ここでは ペイロード形式としてJSONが使用されています 13 WebLogic Server を使用した開発

16 図 14 Java API for JSON Processing を使用した WebSocket エンコーダの例 Java API for JSONの仕様にはJSONの使用のサポートが含まれるため 開発者は標準的かつ比較的シンプルな APIでJSONペイロードを使用できますが JSONを使用する別のアプローチとして Oracle TopLink MOXy 機能の利用があります これと同時にメッセージに使用されているクラスに宣言的 標準的なJAXBアノテーションを指定すると 手動の解析やコード生成を書き込まずに JavaオブジェクトとJSON 表現の間を自動的に変換できます 詳しくは Blaise Doughanのブログ エントリ ( moxyand-java-api-for-json.html) を参照してください JAX-RS 2.0:Java API for RESTful Web サービス モバイル アプリケーションのアクセスのしやすさと それに伴う使用の拡大により ユーザーは ソーシャル メディア ポスト 写真 ニュース記事 スポーツの結果 株価 通貨評価 オンライン ゲームなどのソースから 膨大な量の情報にアクセスできるようになりました これと同時に アプリケーションやサービス用のリモートAPIの提供への関心も高まっています 通信チャネルがインターネットであることを考えると RESTアーキテクチャのスタイルに従うWebサービスは当然増えてきます 14 WebLogic Server を使用した開発

17 RESTful Webサービスは RESTの原理に従って構築されるサービスで インターネットで快適に使用できるように設計されています RESTful Webサービスは アーキテクチャ上のスタイルの制約に従うサービスです たとえば リソースがURIで完全にアドレス可能であったり 統一されたインタフェース経由でやり取りされたりする必要があるといった制約があります RESTful Webサービスは ( 通常は )HTTPプロトコル上に構築されており GET POST PUT DELETEなどの一般的なHTTPメソッドにマッピングされる操作が実装されていて それぞれリソースを作成 取得 配置 削除しています RESTベースのWebサービスが幅広く採用されているのは このようなHTTP 中心のアプローチにより ステートレスな相互作用モデルとデータ形式の独立性が確保されているためです Java API for RESTful Webサービスの仕様は Javaプラットフォーム用のRESTful Webサービスを開発するための 標準ベースのアプローチです Oracle WebLogic Server は Java EE 6の仕様に従い JAX-RS 1.1を完全にサポートしています JAX-RS 1.1の仕様では 開発者がPOJOやEJBのステートレスSession Beanを使用して REST Webサービスを簡単に作成できます この場合 @POSTなどのアノテーションを指定します Java EEプラットフォームとの統合により これらのリソースを含むアプリケーションを クライアントがコールおよび利用できるREST Webサービスとしてデプロイおよび公開できます JAX-RS @FormParamなどのアノテーションを使用してリソースに渡す方法の定義もサポートされています また 使用されるデータ形式 (MediaTypes) の規定もサポートされています Oracle WebLogic Server では 開発者が最新のJAX-RS 2.0 仕様をデフォルトのJAX-RS 1.1 実装より優先して使用できるため RESTベースのWebサービスのサポートがさらに強化されています これは デプロイ可能な共有ライブラリ およびデプロイ済みのアプリケーションで使用できる共有ライブラリの導入によるものです JAX-RS 2.0 API ライブラリ Jersey 2.x 実装 およびその他の多くのJersey 機能が含まれている $ORACLE_HOME/wlserver/common/deployable-libraries/jax-rs-2.0.warは WebLogic Server 環境にデプロイでき これを利用する多くのアプリケーションによって参照されます これにより開発者は JAX-RS 2.0で定義されているREST Webサービスの最新機能を Oracle WebLogic Serverでデプロイおよび実行されるアプリケーションで使用できます クライアントAPI JAX-RS 2.0の仕様でもっとも重要な新機能の1つは JAX-RSクライアントAPIです これは REST Webサービスとの通信用の自由度の高いJavaベースのAPIです この新しい標準的なクライアントAPIは HTTPプロトコル経由で公開されるWebサービスを簡単かつ単純に利用できるように設計されており 開発者はベンダーや環境の間で移植できるクライアント側のソリューションを 簡単かつ効率的に実装できます JAX-RSクライアントAPIを使用すると HTTPプロトコル経由で公開されるWebサービスを利用できます また JAX-RSを使って実装されるサービスに限定されません JAX-RSに精通した開発者なら このクライアントAPIが主に公開するサービスを補完するものであることが分かるでしょう サービス自体でクライアント APIを利用する場合や サービスをテストする場合は特にそうです このクライアントAPIの直接的な利点の1つは 開発者が やり取りしているリソースのレベルで設計および 15 WebLogic Server を使用した開発

18 作業できるという点です HTTPプロトコル自体のレベルで作業したり リソースの使用を必要とする 低レベルなHTTPのやり取りを構築および解析したりする必要はありません たとえば 低レベルなHTTPクライアント ライブラリの場合 大量の入力済みHTMLフォーム パラメータと一緒にPOSTリクエストを送信し JAXB Beanにデシリアライズされたレスポンスを受信することは 簡単ではありません Jerseyでサポートされている新しいJAX- RSクライアントAPIでは このタスクが非常に簡単です HttpUrlConnectionを使用してコードを記述する必要があった場合 開発者はカスタム コードを記述してPOSTリクエスト内で送信されるフォーム データをシリアライズし レスポンスの入力ストリームをJAXB Beanにデシリアライズする必要がありました Jersey 2.5 User Guide このクライアントAPIは 自由度が高くなるように設計されており メソッド呼出しの組合せにより リクエストの構成とRESTリソースへの送信をたった数行のコードで実行できます クライアントAPIはすべての HTTPリクエストをサポートしているため クライアントはREST Webサービスとやり取りしてリソースの取得 配置 ポスト 削除を行うことができます コールのプロパティ パラメータ オブジェクトの追加は 同じスタイルの自由度の高いAPIを使用して行われます たとえば RESTサービスからランダムな割当て制限を取得するには 数行のコードのみが必要です 図 15 クライアントAPIの例クライアントAPIを使用して あらゆるREST Webサービスとやり取りできます JAX-RSベースのWebサービスの使用に限定されることはありません クライアントAPIを使用して JavaクライアントからREST Web サービスとやり取りし これをコマンドライン クライアントやServlet EJB JAX-RS Webサービス自体などのJava EEコンポーネントとして これらのコンポーネントに対し REST Webサービスを使用するための簡単で移植可能なソリューションを提供します インターセプタとフィルタ JAX-RSリソースのリクエストとレスポンス間の実際の相互作用シーケンスへの参加を含む開発者の要件をサポートするため JAX-RS 2.0の仕様にフィルタとインターセプタの概念が追加されました フィルタによって インバウンドとアウトバウンドのリクエストやレスポンスを変更できます ( ヘッダー エンティティおよびその他のリクエストやレスポンスのパラメータの変更を含む ) リクエストやレスポンスのパラメータ ( ヘッダーなど ) を変更する場合は フィルタを使用できます たとえば 生成されるレスポンスごとに "X-Powered-By" というレスポンス ヘッダーを追加するとします このヘッダーを各リソース メソッドに追加する代わりに レスポンス フィルタを使用してこのヘッダーを追加します Jersey User Guide フィルタとインターセプタリソースで作成されるすべてのリクエストとレスポンスを記録するフィルタの例は Oracle WebLogic 16 WebLogic Server を使用した開発

19 Server のサンプル セットで提供されています 図 16 JAX-RS トラフィック ロギング フィルタ インターセプタはフィルタとは違い エンティティの入力ストリームと出力ストリームの操作によってエンティティを変更できるように設計されています このためには ReaderInterceptorやWriterInterceptorのインタフェースの実装を使用して エンティティへの必要な変更を行います Oracle WebLogic Server のサンプル セットに付属しているインターセプタの例は XORエンコーディング メカニズムを使用するエンティティ ストリームの軽量なエンコーディングを示したものであるため 第三者にとって分かりやすいものではなく ReaderInterceptorとWriterInterceptorの両方のインタフェースを実装しているクラスを使用して実行されます 17 WebLogic Server を使用した開発

20 図 17 JAX-RS インターセプタの例 18 WebLogic Server を使用した開発

21 非同期のサポート JAX-RS 1.1の場合 クライアントとサーバー間の相互作用モデルは同期モデルに基づいていました このモデルでは クライアントからサーバーに対してリクエストが出されると サーバーでは 初回接続を受信したスレッドと同じスレッドを使用して ターゲット リソースでリクエストが処理されます 最終的に レスポンスが完了して書き込まれると リクエストがリリースされます JAX-RS 2.0では 非同期の相互作用の概念が追加されました これにより リソース自体で一時停止を実行できるため クライアント接続処理の実行時に この処理をリソースから切り離すことができます Servlet 3.0の仕様に精通した開発者にとって JAX-RS 2.0でサポートされている非同期モデルは使い慣れたものでしょう 非同期処理が特に関係するのは 結果を出すのにそれほど時間がかからないと分かっているリソース リクエストが発生する場合や レスポンスが将来的に必ず作成される場合です このような場合に非同期プログラミングを使用すると システムのスケーラビリティと全体的なスループットの向上に役立ちます 受信リクエストを処理するスレッドが解放され リソースで独立して作業を完了できるためです 図 18 非同期メソッドの例 Oracle WebLogic Server でのJAX-RS 2.0の使用 Oracle WebLogic Server 内でのJAX-RS 2.0のサポートは オプションの機能です JAX- RS 2.0を利用するには 任意のWebLogic Serverターゲットに共有ライブラリをデプロイする必要があります また 個々のアプリケーション レベルで 共有ライブラリを含めるために参照を作成する 関連するWebLogicデプロイメント ディスクリプタの可用性が求められます 使用するアプリケーションにJAX-RS 2.0サポートを提供する共有ライブラリは $ORACLE_HOME/wlserver/ common/deployable-libraries/jax-rs-2.0.warとして提供されます このライブラリは 使用可能な任意のデプロイメント メカニズム ( 管理コンソール コマンドライン ユーティリティ WebLogic Mavenプラグインなど ) や WLSTスクリプトを使用してデプロイできます 19 WebLogic Server を使用した開発

22 図 19 JAX-RS 2.0 共有ライブラリのデプロイ jax-rs-2.0.war 共有ライブラリ自体に JAX-RS 2.0 機能を有効にするためのいくつかのライブラリが含まれます たとえば JAX-RS 2.0 APIライブラリ Jersey 実装やその他の機能拡張 WebLogic Serverの統合ライブラリ 関連するfiltering-classloader 定義で使用するためにライブラリを設定するweblogic.xmlデプロイメント ディスクリプタなどです 図 20 JAX-RS 2.0 共有ライブラリの内容 WebLogic Server へのデプロイ時に JAX-RS 2.0 の機能を使用するには アプリケーションによって jax-rs:2.0 共有ライブラリ用に library-ref エントリが定義されている 関連する weblogic ディスクリプタ ファイルが 提供される必要があります 20 WebLogic Server を使用した開発

23 Figure 21 JAX-RS 2.0 を使用するための weblogic.xml の例 Jersey 2 の Server-Sent Event JAX-RS 2.0 API をサポートするために Jersey 2.x 実装を追加すると 開発者は モバイル クライアントやリッチ クライアントを使用するための追加機能を使用できます この便利な機能によって Server-Sent Event モデルを使用する場合に JAX-RS スタイルのアプローチを利用できます これにより サーバーにデプロイされるアプリケーションが サーバーからクライアントに非同期的にデータをプッシュできます Server-Sent Event で 特定の MIME タイプを使用してクライアントからサーバーへの接続を確立する場合 サーバーからクライアントに対していつでもデータを送信できます 何らかのリクエスト フォームや クライアントからのその後のやり取りは不要です サーバーで新しいデータ イベントが発生すると サーバーからクライアントにデータが直接送信されます 実際に Server-Sent Event モデルは クライアントとサーバー間の 一方向のパブリッシュ サブスクライブ モデルのソリューションです 図 22 Server-Sent Event のやり取りの例 ほとんどの最新ブラウザでは W3C の EventSource JavaScript API によって Server-Sent Event の概念がサポートされています この API について詳しくは を参照してください Server-Sent Event が一般的に使用されるのは ブラウザ クライアントが JavaScript EventSource オブジェクトを使用してサーバーとの接続を開き 接続上で発生しうるさまざまなイベントのコールバック関数を登録する場合です これにより クライアントとサーバー間の接続が確立され 以後はサーバーがクライアントにいつでもデータを送信できます データがクライアントに到達すると EventSource で onmessage イベントが発生し コールバックでデータを受信できます イベント データが JSON 形式の場合 ブラウザ内で使用できる JSON パーサーによって ペイロードがすぐに JavaScript 形式にエンコードされます 21 WebLogic Server を使用した開発

24 JAX-RSクライアントAPIは Sse-Featureの使用によるServer-Sent Eventモデルもサポートしています Sse- FeatureをClientBuilderで登録して 機能を使用できます サーバーからのイベントは EventInputオブジェクトからInboundEventsをプルするか EventSourceオブジェクトでEventListenerを使用することで取得できます Oracle WebLogic Server で提供される Jersey 2.xの実装によるServer-Sent Eventのプログラミング モデルは JAX-RSスタイルのプログラミング モデルに基づいています アノテーションは Server-Sent Event Event MIMEタイプであることの宣言に使用されます このリソースをリクエストするクライアントには EventOutputリソースが返されます これは Jerseyでは特別なケースとして扱われ クライアントとの接続を終了せず 必要なHTTPヘッダーを書き込んでレスポンスを返して クライアントで接続を開いたままにしておき 接続経由でServer-Sent Eventデータが送信されるのを待ちます Server-Sent EventとWebSocketテクノロジーの比較 Server-Sent EventはHTML 5の仕様の一部であり WebSocketテクノロジーも含まれます いずれの通信モデルでも サーバーはクライアントに対し 一方的にデータを送信できます ただし Server-Sent Eventではサーバーからクライアントに対する一方向の通信が確立されるのに対し WebSocket 接続では サーバーとクライアント間で双方向の全二重通信チャネルが提供され 双方向通信によるユーザーのやり取りが促進されます WebSocketとServer-Sent Eventのテクノロジーの主な違いは次のとおりです 1. Server-Sent Eventではクライアントにデータがプッシュされるだけですが WebSocketテクノロジーではクライアントとの間でデータを送受信できます 2. シンプルなServer-Sent Event 通信モデルはサーバーのみの更新に適しています WebSocketテクノロジーではサーバーのみの更新に追加のプログラミングが必要です 3. Server-Sent Eventでは標準のHTTP 経由で送信されるため 動作に特別なプロトコルやサーバー実装は不要です WebSocketテクノロジーの場合 HTTP 接続からWebSocket 接続にアップグレードするには サーバーがWebSocketプロトコルを理解する必要があります Oracle WebLogic ServerのRESTful Webサービスの開発と保護 Oracle WebLogic Server Jersey 2.xの実装では ブロードキャストの概念もサポートされています ブロードキャストでは サーバーが複数のクライアントに対して同時にメッセージを送信できます この場合 リソースはクライアント接続リクエストを特別なクラス (SseBrodcaster) に保存できます SseBrodcasterでは それ自体に保存されている現在接続中のすべてのクライアントに対して特定のメッセージが送信される ブロードキャスト操作を公開できます Oracle WebLogic Server のJersey Server-Sent Event 機能を使用したアプリケーションの開発プロセスは JAX-RS 2.0 機能を使用する場合と同様に jax-rs- 2.0.war 共有ライブラリのデプロイメントと参照が必要です この共有ライブラリには Server-Sent Eventモデルの使用をサポートするため Jersey 固有のライブラリが含まれています 22 WebLogic Server を使用した開発

25 JPA 2.1:Java の永続性の進化 JPA 2.1の仕様はコミュニティのフィードバックに基づいて進化を続けており 主要なAPIを実際のプロジェクトで使用する際に開発者が順守する要件をサポートしています オラクルは引き続きJPAの仕様をリードし オープンソースのEclipseLinkプロジェクトを通じて リファレンス実装を提供します JPA 2.1のリリースでは 次のような厳選された新機能のサポートが追加されています» 標準的な移植可能スキーマの生成 : 標準化された移植可能なプロパティ セットを定義して 永続ユニットのスキーマ生成の実行方法 (DDLアクションの実行タイプ スクリプト ファイルの生成と実行など) を定義します» ストアド プロシージャの呼出し : 新しいStoredProcedureQuery APIと名前付きストアド プロシージャ問合せにより データベース ストアド プロシージャ コールの実行がサポートされるようになりました このため データベース内で直接実行されるコードを 正式なAPIを使ってコールすることができます» クライテリアAPIによるバルク更新とバルク削除 : 新しいCriteriaUpdateクラスとCriteriaDeleteクラスが提供され クライテリアAPIを使ったバルク更新およびバルク削除の問合せの実行がサポートされます» 動的名前付き問合せ : 永続ユニットに対する 名前付き問合せの動的な作成と追加をサポートします» コンバータ : 属性のタイプと値から対応するデータベースのタイプと値への変換を制御する機能が追加されています 図 23 ストアド プロシージャの名前付き問合せ 23 WebLogic Server を使用した開発

26 図 24 バルク クライテリア API Oracle WebLogic Server での JPA 2.1 の使用 Java EE 6 でデフォルトの JPA 実装として定められているとおり Oracle WebLogic Server は JPA 2.0 をサポートしています Oracle WebLogic Server 内での JPA 2.1 のサポートはオプション機能であり My Oracle Support Web サイトからダウンロードする正式な Oracle Patch のアプリケーションを使用するか サーバーを起動して JPA 2.1 の実装をアクセス可能にするための CLASSPATH の設定を手動で変更することで 明示的に有効化できます JPA 2.1 のサポートに必要なファイルは デフォルトの WebLogic Server インストールに含まれますが デフォルトでは有効になっていません JPA 2.1 のサポートと有効化のために提供されるファイルは 次のとおりです» JPA 2.1 API が含まれる javax.persistence_2.1.jar ファイル このファイルは $ORACLE_HOME/oracle_common/ modules ディレクトリにあります» WebLogic Server で JPA 2.1 のサポートを統合および有効化するためのファイルが含まれる com.oracle. weblogic.jpa21support_ _2-1.jar ファイル このファイルは $ORACLE_HOME/wlserver/modules ディレクトリにインストールされます JPA 2.1 の機能を有効にするには PRE_CLASSPATH 環境変数を定義します この変数には WebLogic Server サーバーの起動前にこれらのライブラリが含まれます 革新的な機能 Oracle TopLink と TopLink Data Service Oracle TopLink は Oracle WebLogic インフラストラクチャに完全に統合されています Oracle TopLink はオープンソース Eclipse Persistence Services プロジェクト (EclipseLink) に基づいており 開発作業と保守作業を軽減して企業アプリケーションの機能を高める実行時機能を備えた 高度なオブジェクト永続化フレームワークです TopLink は 幅広い Java EE アーキテクチャと Java SE アーキテクチャで使用するために設計されています TopLink のもっとも人気の高い永続化サービスには 次のようなものがあります 24 WebLogic Server を使用した開発

27 » リレーショナル :Java Database Connectivity(JDBC) を使用してアクセスするリレーショナル データベースへの 標準のJava Persistence API(JPA) 仕様を使用したJavaオブジェクトの永続性を可能にします TopLink は Oracle Virtual Private Database XML DB XMLType フラッシュバック Oracle Databaseのストアド プロシージャおよびファンクションに特化してサポートし 業界をリードするすべてのデータベースに高度な機能を提供します» TopLink Grid: 大規模なクラスタへのJPAアプリケーションのスケールアップとOracle Coherenceキャッシュ オブジェクトの問合せを並列化するためのグリッドの処理能力の活用をサポートする Oracle Coherenceとの統合を可能にします» JSONおよびXMLバインディング :Oracle TopLink MOxYはTopLinkによって提供される強力な機能で ドメイン クラスでのアノテーションによるJava Architecture for XML Binding(JAXB) アプローチを使って JavaオブジェクトとJSON/XMLドキュメント間の変換を処理します HTML5やモバイル クライアント用のアプリケーションの開発でもっとも重要なTopLink Data Servicesのサポートには RESTfulデータ サービスの使用が含まれます 予測可能で一貫性のあるRESTサービスによって TopLink Data ServicesでJPAエンティティを容易に自動的に公開できるようになったため JavaScriptを使用するHTML5クライアントまたはモバイル クライアントで Oracle WebLogic Server 経由でRESTを使用し データベースに格納されているデータを容易に取得して操作できるようになりました JPAアプリケーションの開発者は RESTfulインタフェースを既存のエンティティに宣言的に公開でき 追加のプログラミングは必要ありません JSONとXMLの両方で カスタマイズ可能なバインディングがサポートされています Oracle Databaseの通知のリスニング RESTfulインタフェースの自動更新などの強力な機能も利用できます Spring Oracle WebLogic Serverは Spring Frameworkで開発したアプリケーションを引き続きサポートします このためには アプリケーション自体の内部のサード パーティ ライブラリとしてSpringを組み込んで使用するか WebLogic Server Spring Integration 機能を明示的に使用して WebLogic Serverで実行中のSpringアプリケーションに追加機能を提供します Oracle WebLogic Server には WebLogic Spring Integration 機能でSpring 4.0.xリリースを使用するためのサーティフィケーションが追加されています OSGI Oracle WebLogic Server でのOSGIの使用は WebLogic Serverランタイムの一部としてOSGIフレームワークを登録およびインスタンス化する機能によってサポートされます Apache Felix OSGIの実装は デフォルトのOSGIフレームワークとして提供されます OSGIフレームワークを使用できるため サーバー レベルのバンドルとして または標準的なJava EEアーカイブ (war ear jar) 内に組み込まれたバンドルとしてOSGIバンドルをデプロイし JNDIバインディング経由で利用できるようにして アプリケーションを探して使用します WebLogic ServerにデプロイされるOSGIバンドルは OSGI Common Services( ロギング サービスなど ) にアクセスして使用できます また ランタイム サーバーで使用できるWebLogic Server のデータソースとワーク マネージャにもアクセスできます 25 WebLogic Server を使用した開発

28 開発者にとっての使いやすさ 開発者用 zip ファイル ディストリビューション 小サイズでダウンロードしやすく 迅速に起動できる製品を求める開発者の要望が高まっているため 最近のWebLogic Serverのいくつかのリリースでは zipファイル形式を利用できるようになっています zipファイル ディストリビューションには WebLogic Server 製品のすべての機能が簡単なzipファイル形式で含まれており 完全インストールに通常含まれる重要度の低いコンポーネント (JDKのバンドル Eclipseベースの開発ツール ネイティブ ライブラリなど ) は除外されています このように簡素化してパッケージ化することで ダウンロード用のファイル サイズが約 180MBに減り 一般的な速度のネットワークでは 5 分以内でダウンロードできるようになりました 図 25 オラクルの Web サイトからの zip ファイルのダウンロード オラクルのWebサイトからzipファイルをダウンロードすれば zipのコンテンツを抽出し 1つの構成スクリプトを実行し サーバーを起動して新しいドメインを作成することによって WebLogic Serverのインスタンスを迅速に作成して起動できます 図 26 開発者用 zip ディストリビューションの解凍 26 WebLogic Server を使用した開発

29 提供される config.sh または config.cmd のスクリプトを使用して 使用するインストールの準備をしたり 構 成プロセスの一部としてオプションで新しいドメインを作成したりします 図 27 zip ファイル ディストリビューションの構成スクリプトの実行 構成スクリプトの実行が完了すると 製品インストールが完了します オプションでドメインが作成されていると すぐに実行して使用できます zipファイル ディストリビューションによるWebLogic Serverのインストールには すべてのJava EE APIとコンテナ セットが含まれます これは DataSourcesやJMSの機能 (Distributed Destination ストア アンド フォワード WLSTやMavenのアーティファクトやプラグインなどのクライアント ユーティリティなど ) を含む高度なWebLogicサービスです zipファイル ディストリビューションの重要な要素として アプリケーションの管理やサーバーへのデプロイをブラウザから効率的に実行できる 標準的なWebLogic Serverコンソールが含まれています zipファイル ディストリビューションを使用して 開発とテスト用の1つのサーバー ドメインを迅速に作成できます また 複数の管理対象サーバーを含むクラスタが含まれるドメインを作成できるという点も重要です さらに 新しい動的クラスタ モデルを使用して 構成可能な管理対象サーバーの数で クラスタを作成することもできます 27 WebLogic Server を使用した開発

30 図 28 zip ファイル ディストリビューションからの WebLogic 管理コンソール 既知の環境に対して アプリケーション テスト用のサイクルの構築と分解を継続的に行っている開発者にとって インストール先のディレクトリを削除するだけで完全にアンインストールできるというzipファイル ディストリビューションの性質は重要です 完全インストーラのディストリビューションで通常使用されるレジストリ エントリやその他のメタデータ ストアを削除するために アンインストーラ プロセスを実行する必要はありません 開発ツールのサポート Oracle WebLogic Serverでは アプリケーション開発者向けに アプリケーション構築用のさまざまなIDEが用意されています Eclipse 統合開発環境を好むJava EE 開発者向けに Oracle Enterprise Pack for Eclipseには Oracle WebLogic ServerでのJava EEの開発とデプロイメントに必要なすべてのツールが用意されています Oracle Enterprise Pack for Eclipse には Java EE 6アプリケーション開発全体のサポート WLSTスクリプト作成のサポート およびWebLogic Server 独自のManaged Coherence Server 機能で提供されているGrid Archive(GAR) のパッケージ化のサポートなどの Oracle Coherenceアプリケーションの開発サポートが含まれています 28 WebLogic Server を使用した開発

31 Oracle NetBeansは 最新のJava EE 仕様のサポートで業界をリードする オープンソースのIDE 実装です Java EEリファレンス実装であるGlassfishオープンソースに基づいたOracle Glassfish Serverと Oracle WebLogic Serverの両方をサポートしています NetBeansとGlassfishを使ってJava EE 6アプリケーションを開発するよう試みたことがある開発者は Oracle WebLogic Serverアプリケーションの開発にNetBeansを使用するという 自然な進化を体感するでしょう Oracle NetBeansの最新リリースでは Oracle WebLogic Server を使用したアプリケーション開発が例外的にサポートされています これには アプリケーションをデプロイおよびテストするWebLogic Serverインスタンスの起動 停止 デバッグを NetBeansで実行できる機能が搭載されています このデプロイと保存の同時実行機能により ほぼシームレスな開発およびテスト サイクルが実現され ソース コードの変更をサーバーに自動的に再デプロイして すぐにテストできるようにします Oracle NetBeansは これらすべての機能と最新のアプリケーション プログラミング モデル ( さまざまなHTML5およびJavaScript 指向のフレームワークなど ) のサポートの強化を組み合わせた 強力な開発ツールです Oracle JDeveloper は Oracle WebLogic Server アプリケーションの開発をサポートするように更新されています コードの編集 テスト デバッグ プロファイリング機能を備えた完全な開発環境を提供し Oracle Application Development Framework ( Oracle ADF ) をサポートしているため Oracle WebLogic Serverでエンタープライズ級のアプリケーションを迅速に構築およびデプロイできます クラス ロードの解析と構成 クラス ロードはアプリケーション サーバーの複雑な領域であり 正しく理解されていないことが多い領域です ただし Oracle WebLogic Serverには アプリケーションのクラス ロードを簡単に構成するための さまざまなメカニズムが用意されています まず Oracle WebLogic Serverでは 複数のアプリケーションでライブラリを共有できるため このようなアプリケーションのデプロイが簡素化されます これは ライブラリがアプリケーションとは異なるペースで進化する場合に役立ちます また アプリケーションごとにライブラリをデプロイする必要がなくなります 次に Oracle WebLogic Serverには アプリケーション レベルのライブラリが用意されています これらのライブラリは各アプリケーションにデプロイされ 標準のJava EEクラス ロード階層でロードされます つまり これらのライブラリはサーバーにデプロイされている他のアプリケーションと共有されず 各アプリケーションがライブラリの独自コピーを受け取ります 同じサーバーにデプロイされているアプリケーションで 同じライブラリの異なるバージョンを使用する必要がある場合に便利です また Oracle WebLogic Serverでは フィルタリング クラス ローダーのサポートにより クラス ロードを簡素化しています このクラス ローダーは クラス自体はロードしませんが クラスが親クラス ローダーによってロードされるのを防ぎます フィルタリング クラス ローダーを使用すると アプリケーションによってシステム レベルのクラスを上書きできます これは 他のアプリケーション サーバーでは実行するのが難しい操作です この機能は アプリケーションで使用されているオープンソースのソフトウェア コンポーネントが Oracle WebLogic Serverに組み込まれているこれらのソフトウェア コンポーネントの異なるバージョンと競合する可能性があるユースケースで重要です たとえば アプリケーションで異なるバージョンのXerces Spring Commons-Logging Log4jなどを使用する必要があるとします このためには システムのクラスパスからこれらのクラスをフィルタリングするように フィルタリング クラス ローダーを構成します 代わりに これらのクラスはアプリケーションのライブラリからバンドルされてロードされます 29 WebLogic Server を使用した開発

32 Oracle WebLogic Serverには クラス ロードの問題を分析および解決するための Web ベースの Classloader Analysis Toolが用意されています 上記のようなケースで アプリケーションで使用されているオープンソース ソフトウェアとOracle WebLogic Serverのソフトウェアが競合している可能性がある場合 このツールは このようなクラス競合の検出を支援し 競合を解決するフィルタリング クラス ローダー構成を提案します オープンソース ソフトウェア ライブラリを使ったアプリケーション開発プロジェクトでは クラス ローダーの問題を早期に検出して解決できるよう 開発プロセスでこのツールを使用することを推奨します また アプリケーションでオープンソース ソフトウェアを使用している場合は これらのアプリケーションをアップグレードする際 または既存のアプリケーションを新しいバージョンのOracle WebLogic Server にアップグレードする際にも このツールを使用する必要があります このようなアップグレードでは サーバーまたはアプリケーションで使用されているオープンソース ソフトウェア自体のバージョンがアップグレードされることがあります そのため アプリケーションで使用されているオープンソース ソフトウェアのバージョンがサーバーで使用されているバージョンと異なってしまい アップグレード前には存在しなかったクラス競合の問題が生じる可能性があります Classloader Analysis Toolを使用すると アップグレード プロセスでこのような問題を特定して解決できます Oracle Apache Maven のサポート Oracle WebLogic Server には Apache Mavenベースのプロジェクトでの使用をサポートするための 重要な機能が含まれます このリリースの機能は Mavenで使用する場合の次の領域を対象としています WebLogic Mavenプラグイン WebLogic Serverでのタスクを実行するMavenプラグインの実装です これらのタスクには インストールとドメインの構成 サーバー インスタンスの起動と停止 WLSTスクリプトの実行によるリソースの作成と構成 アプリケーションのデプロイと管理のためのデプロイメント操作 Webサービスの構築やディストリビューション用のアプリケーション アーカイブのプリコンパイルのためのアプリケーション開発タスクなどがあります» Oracle/WebLogic Mavenアーティファクト WebLogic Serverインストールからの開発で使用される一般的なAPIやライブラリを示すMavenリポジトリにインストールできる オラクルが定義した一連のMaven アーティファクトです» WebLogic Maven Archetypes 数種類の一般的なJava EEプロジェクト (JSF CDI MDBのアプリケーションなど ) を作成し WebLogicアーティファクトとWebLogic Mavenプラグインを使用するための構成 (pom.xml) を備えた 一連のMaven Archetypesです» Oracle Maven 同期プラグイン オラクルが定義した調整セットを使用して WebLogic ServerのインストールからMavenリポジトリにアーティファクトを移入する 独自ソリューションです 30 WebLogic Server を使用した開発

33 Oracle Maven サポートの利用の概要 WebLogic ServerとMavenを使用する場合 アクティビティの一環として開発チームが使用しているMaven リポジトリにOracle Maven 同期プラグインをインストールします Oracle Mavenアーティファクトは Oracle Maven 同期プラグインによってMavenリポジトリにインストールされます OracleアーティファクトがMavenリポジトリにインストールされたら 開発プロジェクトは 必要なAPIや実装ライブラリを含む関連アーティファクトの依存性を宣言し 関連プロジェクトのPOMファイルでさまざまなOracle Mavenプラグインをプラグインとして宣言し これらのプラグインを利用して具体的な動作を実行することで これらのアーティファクトを利用できます Oracle MavenプラグインをWebLogic Serverで使用すると さまざまな便利な開発関連タスクを実行できます たとえば 製品のインストール 新規ドメインの作成とサーバーの起動 必要なリソース ( データソース JMS 宛先など ) の作成 アプリケーションをテストするためのデプロイメント操作の実行などです Coherence Mavenプラグインは Grid Archive(GAR) のパッケージ化操作に役立ちます たとえば 必要なデプロイメント ディスクリプタの生成 ドメイン クラスのPOF (Portable Object Format) マッピング ファイルの生成 デプロイメント用のGARファイルのパッケージ化などです まったく新しいプロジェクトを担当する開発者の場合 Oracle Maven Archetypesを使用して 関連リソース デプロイメント ディスクリプタ 実際のコード例 プロジェクトのパッケージ化およびデプロイ用のほぼ構成済みのMaven POMなどを含むプロジェクトを作成できます Archetypesは さまざまな種類の WebLogic ServerプロジェクトやCoherence GARプロジェクト用に存在します Oracle Maven アーティファクト Mavenでは その依存性管理メカニズムをサポートするため プロジェクトに必要なアーティファクトを保存および取得するためのリポジトリの概念が使用されています アーティファクトはMavenのパッケージ化の構成メンバーであり ( クラスとリソースを含む ) 標準的なアーカイブと ( 座標と呼ばれる ) 一連のメタデータを組み合わせています 最終的に座標によって 参照および取得できる Mavenリポジトリに名前空間が定義されます アーティファクトは インストール操作によってMavenリポジトリに作成されます この操作では 特定のアーカイブ ファイルと アーティファクトの名前とバージョンを決定してリポジトリに保存するメタデータが使用されます アーティファクトがリポジトリに保存されると Mavenの依存性管理メカニズムによって プロジェクトからアクセスできます Oracle WebLogic Server では 依存性管理モデルに対応するため 一連の一般的なAPI ライブラリ クライアント ユーティリティのMaven POMファイルと WebLogic Server TopLink およびCoherenceのコンポーネントからのMavenプラグインが提供されています このプラグインにより これらのコンポーネントをアーティファクトとしてMavenリポジトリにインストールできます また WebLogic Serverのインストールで多くのアーティファクトを使用できる場合 各アーティファクトのリポジトリへのインストール タスクを個別に手動で実行するのは煩雑で エラーも発生しやすくなります このため リリースの一部として 特殊なMavenプラグインであるoracle-maven-syncが提供されています このプラグインによって ローカルの ( またはリモートの )Mavenリポジトリに所定のWebLogic Serverインストール ディレクトリからアーティファクトを移入するタスクが自動化されます 31 WebLogic Server を使用した開発

34 Oracle Maven 同期プラグイン Oracle WebLogic Server には 特定のWebLogic Serverインストール ディレクトリから Mavenリポジトリに対し オラクルが定義した一連のMavenアーティファクトを移入するプロセスを簡素化するMaven プラグインが含まれます この同期プラグインは 特定のディレクトリを検索し アーティファクトの構築に必要な2 種類のファイル ( 標準的なMaven POMファイルと対応するロケーション ファイル ) を探します ロケーション ファイルには POMに対応するjarファイルの 実際のロケーションのポインタが含まれます 同期プラグインでは 次にMavenのインストール操作が実行されます この際 POMファイルと対応するjar ファイルの使用により 使用中のリポジトリに最終的なアーティファクトが作成されます 同期プラグインを使用するには まずMavenリポジトリにインストールする必要があります 同期プラグインのインストール プロセスでは プラグインをリポジトリに手動でアップロードするため Mavenの installゴールが使用されます 同期プラグインを一度インストールすれば これを使用して WebLogic Serverインストールからアーティファクトを そのpushゴールを使用するMavenリポジトリにインストールできます 図 29 Oracle Maven アーティファクトのリポジトリへのインストール Oracle WebLogic Maven プラグイン WebLogic Maven プラグインは Oracle Maven 環境のコンポーネントです このプラグインにより 32 WebLogic Server を使用した開発

35 WebLogic ServerをMavenプロジェクトのライフ サイクルに統合して プロジェクトのテスト用のプラットフォームとして使用できます WebLogic Mavenプラグインには WebLogic ServerをMavenプロジェクト内で使用できるようにする 次のゴールがあります» WebLogic Serverバージョンのインストール ドメインの作成 サーバーの起動 / 停止などの インフラストラクチャ タイプの操作の実行» JMSコネクションのファクトリと宛先 データソース ユーザーやグループなどのリソースの作成などの 操作コマンドの実行» アプリケーションのデプロイメント アンデプロイメント 再デプロイメントなどの デプロイメント関連の操作» パッケージ化関連の操作の開発 たとえば アプリケーション アーカイブをプリコンパイルしてデプロイメント時間を最適化したり Webサービスに必要な特定の種類のリソースを生成およびパッケージ化したりする操作 WebLogic Mavenプラグインは (Oracle Mavenアーティファクト セットからの依存性として宣言される ) 一連のWebLogic Serverライブラリを使用して 同じ構成情報を使用するローカルやリモートのWebLogic Serverインスタンスに対する大部分のゴールを実行する 標準的なMavenプラグインです WebLogic Mavenプラグインでは ローカルやリモートのインスタンスを使用できるため ローカルのテスト インストールや リモート ターゲットに対するMavenプロジェクトのテストを実行できます リモート ターゲットの場合 テストはリモートのWebLogic Serverインスタンスのファームに対して実行されます また 継続的な統合環境内から ターゲット プラットフォームとしてWebLogic Serverを組み込むことができます この場合 プロジェクトの変更はソース コード リポジトリにコミットされるため テストはオンデマンドで実行されます インストールおよびライフ サイクルのゴール仮想マシンの新しいハードウェアにサーバーをオンデマンドで作成する必要がある状況や テストを適切な環境で確実に実行するために必要なテスト スイート用の新しいサーバー インスタンスを使用する状況に対応するため WebLogic Mavenプラグインは ターゲット マシンへのWebLogic Server 製品のインストールをサポートしています このためには 開発者用 zipファイル ディストリビューションか 汎用のJava ベースのインストーラを使用します 汎用のJavaベースのインストーラを使用するには インストールを実行する関連ディレクトリの詳細を提供するレスポンス ファイルを指定する必要があります installゴールの便利な機能は インストール バイナリ自体をローカルのファイル参照 HTTPベースの参照 または Maven 座標として指定し Mavenリポジトリから引き出せるという点です この後者の機能により WebLogic Serverのインストール バイナリに名前を付け Mavenリポジトリにインストールして 開発プロジェクト全体で共用できます インストール解除プロセスをサポートする uninstallゴールもあります 33 WebLogic Server を使用した開発

36 WebLogic Server 製品のインストール後に create-domainゴールを使用して ドメインを作成できます このゴールによって デフォルトのドメイン テンプレートから名前付きドメインが作成され ゴールにパラメータとして提供されるユーザー名とパスワードを使用して構成されます より複雑なドメイン作成要件については ( 後で説明する )WLSTゴールを使用して WLSTオフライン ゴールを使用するドメインを作成できます このカテゴリでの最終的なゴールは サーバーの起動および停止のゴールです これらのゴールを使用して 特定のドメインのAdminServerを起動および停止し Mavenプロジェクトから WebLogic Serverランタイム プロセスを直接制御できます 図 30 WebLogic Maven プラグインの最小限の POM 定義 デプロイメントとリソースの管理 WebLogic Mavenプラグインのゴールの大部分は MavenプロジェクトからターゲットのWebLogic Serverドメインに対して実行される デプロイメントおよび関連するリソース管理の操作に関するものです これらの操作は 継続的なデプロイメントを行ってきた組織が プロジェクトをテストしたり 場合によっては本番環境にデプロイしたりするためのものです デプロイメント関連のゴールは アクションのデプロイ アンデプロイ 再デプロイの実行をサポートしています これらのゴールは アーカイブ または展開したディレクトリとしてのアプリケーションのデプロイメントをサポートしています 後者は ローカルのWebLogic Serverインストール ( またはネットワーク経由でアクセスできるディレクトリ共有 ) のみに適用できます リモート インストールのデプロイメントは ターゲット サーバーへのアーカイブのアップロードを指示するdeployゴールで指定されるパラメータによって制御できます 小規模でないアプリケーション デプロイメントの場合は サーバー リソースの構成が必要です WebLogic Serverには Jythonスクリプト言語に基づく強力なスクリプト機能があります 管理者は長年 この機能を使用して 再利用および繰り返し可能なスクリプトを作成し サーバー ベースのリソースの作成 テスト ターゲット化を行ってきました WLST 環境は データソース 接続プール JMSのコネクション ファクトリおよび宛先 セキュリティ関連の構成 ( ユーザー グループ 資格証明のマッピングなど ) の使用を完全にサポートしています また ドメイン クラスタ マシン サーバーおよび関連リソースで構成される完全な環境の作成もサポートしています WebLogic Mavenプラグインによって Mavenプロジェクトのコンテキスト内から同じWLSTスクリプトを簡単に使用でき Mavenのライフ サイクル全体の一部として プロジェクト関連のリソースを作成 構成 管理できます 34 WebLogic Server を使用した開発

37 WebLogic Mavenプラグインは標準的なMavenプラグインであり そのゴールをMavenのライフ サイクルにマッピングできます このため プロジェクト実行の特定の時点でゴールが自動的に実行され 必要に応じてゴールを正しい順序で実行できます これにより アプリケーション デプロイメントの完了に必要なリソースを確保して テストを実行できます 図 31 デプロイメント ゴールとライフ サイクルのバインディング 開発とプリコンパイル WebLogic Mavenプラグインで提供されるゴールの仕上げは 一般的なWebサービス開発作業の実行をサポートするWebサービスのゴールです このゴールでは 開発プロジェクト用のリソースの生成が必要です たとえば JAX-WSベースのアプリケーションのコンパイルとパッケージ化を行うゴールによって補完される WSDL 定義からのJavaスケルトンやWebサービス クライアントなどです WebLogic Serverアプリケーション コンパイラ ユーティリティも アーカイブで実行されるパッケージ化後の操作をサポートするゴールとして公開されています この操作ではアーカイブでJSPとEJBがプリコンパイルされるため このような種類のコンポーネントが多数含まれるアプリケーションのデプロイメント時間が短縮されます Oracle Maven Archetypes Maven Archetypesは Mavenの非常に便利な機能です Maven Archetypesによって 簡単な構成とサンプル コードが含まれる基本的なプロジェクトから すべての開発プロジェクトの基本となる一貫性のある一般的な基盤を提供する詳細なプロジェクトに至るプロジェクトをテンプレートから作成できます Oracle Mavenアーティファクトで提供されるアーティファクト セットには いくつかのArchetypeが含まれます これらのArchetypesを使用して いくつかの一般的なアプリケーション パターンの簡単な開始プロジェクトを作成できます これらのプロジェクトには Oracle Mavenアーティファクトの関連する依存性で構成された実用コード Webページ POMファイルが含まれます POMファイルもWebLogic Mavenプラグインで事前構成されており 必要なデプロイメントとリソース作成の操作を実行できるため プロジェクトのデプロイとテストが可能です 継続的な統合の実行 企業が自社のビジネス ニーズに対応するアプリケーションを開発する場合 通常は共同で作業する開発者 35 WebLogic Server を使用した開発

38 のチーム ( 小規模の場合もあります ) を採用し 各チームでアプリケーションの一部分を構築します 次に これらの部分を統合してアプリケーション全体を作成します 多くの最新アプリケーションは モジュール アーキテクチャに基づいています つまり 複数の開発者がシステム全体の様々な部分を構築し これらを最終的に統合してビジネス アプリケーションのニーズを満たすということです 以下のような特徴から 主流の開発アプローチとなっています» 変更の影響を軽減するアプリケーション コンポーネントの疎結合» 情報テクノロジー開発の長期的な目標であるサービスの再利用» ビジネス ニーズの変化に合わせアプリケーションの動作を簡単に変更できる柔軟性と俊敏性この新しいパラダイムの中で 多くの開発組織は反復的な開発方式も採用して 旧来のウォーターフォール方式との置き換えを進めています 反復的で俊敏な開発手法では 従来のウォーターフォール方式と比べ 小さい単位の機能を頻繁に提供することに重点を置いています この新しいアプローチが登場したことで エラーがより少なく より見つけやすくなり 今日のようにビジネス要件が継続的かつ頻繁に変わる環境には特に適しています これらの技法の多くには 継続的な統合の採用という特徴もあります 組織はソフトウェアの構築とテストの自動化に非常に関心を持っており これには継続的統合が役立ちます 継続的統合は 細かい頻繁な品質管理作業によって 品質の向上と迅速なソフトウェア提供を模索するソフトウェア エンジニアリングの実践です 主な特徴は次のとおりです» バージョン管理システムにより 変更が追跡されます» すべての開発者が毎日 主要なコード行 ヘッド トランクにコミットします» 製品がすべてのコミット操作上に構築されます» ビルドは 自動的かつ迅速である必要があります» 本番同様の環境に自動的にデプロイメントできる必要があります» 自動的にテストできる必要があります» ビルドが破損した場合に全員が確認できるよう すべてのビルド結果が公開されます» 開発者 テスター その他の調査担当者が 成果物を簡単に使用できます Oracle WebLogic Server では このようにMavenやその他のテクノロジーのサポートが進化しているため 継続的統合技法を採用してアプリケーションを開発する企業をサポートします たとえば 次のような機能があります» Oracle Enterprise Pack Eclipse Oracle NetBeans Oracle JDeveloperなどのさまざまな開発ツールの 共通のバージョン管理システムの統合» Maven ビルドおよびプロジェクト管理システムを使用してコマンドラインからプロジェクトを構築できるため ビルドのスクリプト化と自動化が可能» Maven Archetypesから新しいプロジェクトの作成が可能» Mavenリポジトリから 必要な依存性をダウンロードすることが可能 36 WebLogic Server を使用した開発

39 » プロジェクトのパラメータ化により ビルドを別の環境 ( テスト QA SIT 本番など) で使用することが可能» Mavenビルドのライフ サイクルにプロジェクトのテストを含めることが可能» Mavenリポジトリに WebLogic Serverソフトウェアのインストール ディレクトリから オラクルが提供する依存性を移入することが可能» Hudsonのような継続的統合サーバーの制御化で Mavenビルドを実行可能» WebLogic Serverを含める継続的統合環境の作成プロセスによる 包括的ドキュメントのプロビジョニング 結論 Oracle WebLogic Server は 実績のある信頼性の高いJava EE 6 実装のいくつかの仕様に特殊な更新を追加して最新のWebおよびリッチ クライアント アプリケーションの開発をサポートすることで 開発者を継続的にサポートしています また 最適化されたzipディストリビューション さまざまな開発ツールのサポート およびそのMaven 関連機能の追加による一般的な開発ライフ サイクルへの統合により 引き続き開発者をサポートしていきます 参考資料» Oracle Fusion Middleware 12c(12.1.3) のドキュメント ライブラリ : JSR-339 Java API for RESTful Web Services 2.0: JSR-338 Java Persistence API 2.1: JSR-356 Java API for WebSocket 1.0: JSR-353 Java API for JSON Programming 1.0: Jersey 2.5 User Guide: EclipseLinkドキュメント (JPA 2.1 用 ): Java EE 7 Tutorial: Java WebSocket Programming Danny Coward Oracle Press 2013» EclipseLink MOXy and the Java API for JSON Processing - Object Model APIs: 37 WebLogic Server を使用した開発

40 Oracle WebLogic Server WebLogic Serverを使用した開発 2014 年 6 月 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問い合わせ窓口 : 電話 : ファクシミリ : Copyright 2014, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は その内容に誤りがないことを保証するものではなく また 口頭による明示的保証や法律による黙示的保証を含め 商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません オラクルは本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクルの書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません OracleおよびJavaはOracleおよびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です IntelおよびIntel XeonはIntel Corporationの商標または登録商標です すべてのSPARC 商標はライセンスに基づいて使用されるSPARC International, Inc. の商標または登録商標です AMD Opteron AMDロゴおよびAMD Opteronロゴは Advanced Micro Devicesの商標または登録商標です UNIXは The Open Groupの登録商標です