Oracle WebLogic Server 12.1.3
WebLogic Serverを使用した開発
Oracleホワイト・ペーパー | 2014年6月
目次
はじめに ... 1
Java標準APIによる、最新アプリケーションの開発の実現 ... 2
Java API for WebSocket 1.0：非常にインタラクティブなアプリケーショ
ンの有効化 ... 3
Java API for JSON Processing 1.0：JSONの解析と処理の簡素化 ... 12
JAX-RS 2.0：Java API for RESTful Webサービス ... 14
JPA 2.1：Javaの永続性の進化 ... 23
Oracle WebLogic Server 12.1.3でのJPA 2.1の使用 ... 24
革新的な機能 ... 24
Oracle TopLinkとTopLink Data Service ... 24
開発者にとっての使いやすさ ... 26
開発者用zipファイル・ディストリビューション ... 26
開発ツールのサポート ... 28
クラス・ロードの解析と構成 ... 29
Oracle Apache Mavenのサポート ... 30
Oracle Mavenサポートの利用の概要 ... 31
Oracle Mavenアーティファクト ... 31
Oracle Maven同期プラグイン ... 32
Oracle WebLogic Mavenプラグイン ... 32
Oracle Maven Archetypes ... 35
継続的な統合の実行 ... 35
結論 ... 37
はじめに
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 12.1.3のリリースにより、開発者向けに次のような重要な新機能が提供されました。 » 複数の主要な新規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の使用をサポート
モバイル・アプリケーションのビジネスでの採用、利用の拡大に伴い、開発者は、ポータブル・サービス、 およびさまざまなブラウザやデバイスからアクセスできるポータブルなデータ形式を利用しているAPIを提 供する方法を模索しています。また、アプリケーションがこれらのバックエンド・サービスと通信してデー タをタイムリーかつ効率的に送受信する方法を最適化することも必要です。Oracle WebLogic Server 12.1.3 には、既存のJava EE 6実装ベースを補完するJava標準APIの更新によって、最新のモバイル・アプリケーショ ンの開発を直接サポートし、実現する機能があります。
WebLogic Server 12.1.3の新規および更新された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 12.1.3には、WebSocketプロトコルを使った双方向ネットワーク接続と、JSONで HTML5アプリケーションの共通語で表示されるデータ・ペイロードとの連携をサポートするために特別に提 供された新しいJava標準が追加されており、最新の動的アプリケーションのロールアウトの強固な基盤とな ります。また、JAX-RS 2.0やJPA 2.1などの既存の主要APIが更新されており、RESTベースのWebサービスの 開発や、効率的なデータ・アクセスのための機能がさらに追加されています。
Java API for WebSocket 1.0
：非常にインタラクティブなアプリケーションの有
効化
Oracle WebLogic Server 12.1.3では、WebSocketプロトコル（RFC 6455）の使用がサポートされています。 このためクライアントは、接続先のピアからのメッセージの随時送信をサポートするサーバーとの間で、軽 量、双方向、かつ永続的な接続を構築できます。サーバーからのメッセージ送信とクライアントでのメッ セージ受信に、現在一般的に使用されている非効率な手法（ポーリングやロング・ポーリングのメカニズム など）は必要ありません。 WebSocketプロトコルによる永続的な双方向接続により、クライアントやサーバーはいつでもメッセージを 相互送信できます。このため、さまざまなサービスとの間でデータを受信およびやり取りし、非常にインタ ラクティブで動的なエクスペリエンスをユーザーに提供する必要がある最新アプリケーションの作成に最適 なソリューションです。 WebSocketは、電話のようなものです。電話をかける際は、まず番号をダイヤルします。相手が受話器を 取って電話を受けると、接続が確立されます。接続がアクティブな間は、双方が好きなときに同時に話した り（スムーズな会話のためにはお勧めしませんが）、話しながら相手の話を聞いたりすることができます。 これが、全二重通信です。一方が電話を切るまでは、会話中であるかどうかに関わらず、接続はアクティブ なままです。
Danny Coward、Java WebSocket Programming、Oracle Press 2013
WebSocketプロトコルの概要
WebSocketプロトコルの場合、WebSocket接続はまず、WebSocketエンド・ポイントに対する標準HTTPリ クエスト（WebSocketプロトコルを使用するように接続をアップグレードするリクエストなど）を行うクラ イアントで開始されます。リクエスト内では、サポートされるWebSocket機能を示す追加情報が渡されます。 これは、ハンドシェイクのオープン と呼ばれます。
図1 WebSocketのハンドシェイクのオープン サーバーで接続リクエストの受入れが可能である場合は、接続をアップグレードできることと、アップグ レード先のプロトコル、およびWebSocket固有の情報を示すHTTPレスポンスが返されます。このレスポンス は、ハンドシェイク・レスポンスのオープン と呼ばれます。 図2 WebSocketのハンドシェイク・レスポンスのオープン このリクエスト/レスポンスのやり取りが正常に完了すると、同じネットワーク・アドレスとポートを使っ て、HTTP接続がWebSocket接続に置き換えられます。WebSocket接続が確立されると、クライアントと サーバー間で自由にWebSocketを送受信できます。一方が明示的に接続を終了するか、外的要因（非アク ティブによるネットワーク・タイムアウトや基盤となるネットワークの問題など）によって接続が終了され るまで、接続は有効なままです。 データは、一連のWebSocketメッセージとして、WebSocket接続経由で送信されます。各WebSocketメッ セージはデータ・フレーム内で送信されます。長いメッセージは複数のフレームに分けられて順番に送信さ れ、受信者側で再構築されて元のメッセージが再生成されます。
図3 WebSocketのやり取り
WebSocketアプリケーションの開発
JSR-356 Java API for WebSocket 1.0の仕様では、WebSocketアプリケーションをJavaで作成するための標準 プログラミングAPIが導入されています。このAPIでは、WebSocketエンド・ポイントの概念が導入されてい ます。WebSocketエンド・ポイントによって、会話の一方の処理と、必要に応じたメッセージの送受信、お よび強制されたライフ・サイクル・アクティビティへの応答が行われます。 WebSocket接続のサーバー側は、ServerEndpointと呼ばれます。ServerEndpoint実装の作成については、2つ のアプローチが仕様で定義されています。アノテーション・ベースのアプローチでは、エンド・ポイント自 体の構成と適切に定義されたライフ・サイクル・メソッドが、@OnOpen、@OnMessageなどのアノテー ションを使用して指定されます。2つめのアプローチはプログラム的なAPIを使用するもので、必要なライ フ・サイクル・メソッドの提供と、エンド・ポイント・インスタンスの動的な定義や構成に使用されるベー ス・クラスとインタフェースが開発者に提供されます。 WebSocketエンド・ポイントを公開するアプリケーションに送信される主要なライフ・サイクル・イベント は次のとおりです。 » Connection Opened（接続を開く）：このイベントは、WebSocketエンド・ポイントが、ピアとの接続 を開くように要請された場合に発生します。この際、開発者はセッションとやり取りして、場合によって はWebSocketエンド・ポイントが使用する初期化タスクを実行できます。 » Message Received（メッセージを受信）：ピアからのメッセージを受信しました。このメッセージはテ キスト・メッセージ、バイナリ・メッセージ、またはpongメッセージで、完全フォームまたは部分的 フォームで受信されます。 » Error Occurred（エラーの発生）：WebSocket接続でエラーが発生しました。開発者は » Connection Closed（接続を閉じる）：ピアで接続が終了されました。開発者は
アノテーション・ベースのプログラミング・モデルを使用した場合、アプリケーション自体をWebSocketエ ンド・ポイントとして提示し、ライフ・サイクルに参加してメッセージを送受信するアプリケーションは、 数行のコードのみの非常に簡単なクラスで表すことができます。 たとえば、通常のエコーWebSocketについて少し異なる点として、次のクラスではWebSocketクライアント からメッセージを受信し、リバース・フォームで返信します。 図4 WebSocketのアノテーションの例 @ServerEndpointというアノテーションは、ServerEndpointとしてのクラスを示します。このクラスは WebSocket実装で、アクセス用のURIとして指定した値によって検出およびインスタンス化されます。 @OnMessageというアノテーションは、受信するWebSocketメッセージの処理に使用されるメソッドを示し ます。この簡単な例では、メソッドでテキスト・メッセージ全体を受信しています。追加のメソッド定義を 使用して、バイナリ・メッセージを受信したり、両方のメッセージ・タイプの部分的フォームを処理したり することができます。 図5 @OnMessageのメソッド・フォーム プログラム的なAPIを使用するため、エンド・ポイント・クラスを拡張してWebSocketエンド・ポイントを 定義できます。エンド・ポイント・クラスによって、同等の一連のライフ・サイクル・メソッドが定義され ます。このメソッドを上書きして、WebSocketでイベントのオープン、エラー、終了を処理できます。
ピアからメッセージを受信するために、onMessageメソッドを提供するMessageHandlerクラスが作成され ます。このメソッドは、エンド・ポイントでメッセージが受信されると起動されます。アノテーション付き モデルと同様に、MessageHandlerと必要なonMessageメソッドでは、複数のフォームのうちの1つを使用し て、全体または部分的なメッセージとして受信されるテキスト・メッセージやバイナリ・メッセージを処理 できます。 図6 プログラム的なエンド・ポイントの簡単な例 プログラム的なAPIを使用する場合、エンド・ポイントの構成は、ServerApplicationConfigインタフェースの 実装によって提供されます。この実装では、ServerEndpointConfigインスタンスが作成されます。このイン ス タ ン ス に は 、 ク ラ イ ア ン ト の ア ク セ ス 用 に 、 エ ン ド ・ ポ イ ン ト の ク ラ ス や URI が 含 ま れ ま す 。 ServerEndpointConfigクラスでは、より複雑なタスク（サブプロトコル・ネゴシエーションやオリジン・ サーバーのチェックなど）も処理できます。
図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 JavaScript WebSocket APIの使用例
このタイプのWebSocket APIをコールするHTMLクライアントを使用すると、ピア間で接続を開いたりメッ セージの送受信を行ったりすることができます。
Java API for WebSocket Protocol 1.0仕様の開発によって、Javaで直接WebSocketクライアントのプログラミ ングをサポートすることも、ある程度重要になってきました。このためJSR-356仕様では、サーバー側のプ ログラミング・モデルの提供だけでなく、WebSocketアプリケーションのクライアント側の作成にも取り組 んでいます。この仕様では、両方の接続側の開発にそれほど大きな違いはありません。ただし一般的に、 ServerEndpointは接続リクエストに対して準備済みで待機するWebSocketエンド・ポイントであり、同時に 複数の接続をホストできるのに対し、ClientEndpointではそのピアに対する接続が作成され、同時に接続で きるピアは1つだけという点が異なります。 ClientEndpointのライフ・サイクルやイベント・モデルは通常、一般的なWebSocketエンド・ポイントと同 じで、アノテーションやプログラム的なモデルを使用して定義できます。 図10 Java WebSocketクライアントの簡単な例 クライアントが実行されてサーバー・ピアに接続されると、そのクライアントはエンド・ポイントのライ フ・サイクル・イベントに従い、サーバー・ピアとやり取りする場合は、必要に応じてアノテーション付き メソッドが呼び出されます。
図11 WebSocketクライアントの実行
WebLogic Server 12.1.3でのWebSocketプロトコルの使用
JSR-353およびJava API for WebSocket 1.0仕様の登場により、WebLogic Server固有のAPIを含むWebSocketプ ロトコル（RFC 6445）をサポートしていた、Oracle WebLogic Server 12.1.2の以前のWebSocket実装は、こ のリリースでは非推奨となっています。新規のすべての開発アクティビティでは、Java標準APIである javax.websocket.*を使用します。
Oracle WebLogic Server 12.1.3での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 12.1.3には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アプリケーションに、必要に応じてフォールバッ ク・モードを使用できるようにするコンテキスト・パラメータが提供される必要があります。
図12 web.xmlでのWebSocketフォールバックの有効化
Java API for JSON Processing 1.0
：JSONの解析と処理の簡素化
Oracle WebLogic Server 12.1.3には、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を使用して出力ソースに書き込むことができます。
ストリーミングAPI ストリーミングAPIは、インタフェースJsonParserとJsonGeneratorで構成されます。インタフェース JsonParserには、JSONをストリーミングで解析するメソッドが含まれます。インタフェースJsonGenerator には、JSONを出力ソースにストリーミングで書き込むメソッドが含まれます。 JsonParserでは、プル解析プログラミング・モデルを使用して、JSONデータに対し、前方/読取り専用アク セスを行うことができます。このモデルでは、アプリケーション・コードにより、パーサー・インタフェー スでスレッドが制御されメソッドがコールされ、パーサーを前方に移動したり、現在のパーサーの状態から JSONデータを取得したりすることができます。JsonGeneratorには、JSONを出力ソースに書き込むメソッド があります。このジェネレータによって、名前/値ペアがJSONオブジェクトに、値がJSON配列に書き込まれ ます。 ストリーミングAPIは、大量のJSONデータを効率的に処理できるよう設計された、低レベルのAPIです。
Oracle WebLogic Server 12.1.3でのJSONの使用
Oracle WebLogic Server 12.1.3のコンテキスト内では、Java API for JSON Parsingによって、JSONペイロード を使用するための標準的で簡単かつ便利なAPIが提供されます。これは特に、ブラウザ・ベースの WebSocketクライアントとのメッセージのやり取りでJSONが一般的に使用される、WebSocket対応のアプ リケーションに適しています。
図13 Java API for JSON Processingを使用するWebSocketデコーダの例
対応するエンコーダ・コンポーネントによって、AuctionMessageオブジェクトがWebSocketメッセージと して送信できるフォームに変換されます。ここでは、ペイロード形式としてJSONが使用されています。
図14 Java API for JSON Processingを使用したWebSocketエンコーダの例
Java API for JSONの仕様にはJSONの使用のサポートが含まれるため、開発者は標準的かつ比較的シンプルな APIでJSONペイロードを使用できますが、JSONを使用する別のアプローチとして、Oracle TopLink MOXy機 能の利用があります。これと同時にメッセージに使用されているクラスに宣言的、標準的なJAXBアノテー ションを指定すると、手動の解析やコード生成を書き込まずに、JavaオブジェクトとJSON表現の間を自動的 に変換できます。
詳しくは、Blaise Doughanのブログ・エントリ（http://blog.bdoughan.com/2013/07/eclipselink- moxy-and-java-api-for-json.html）を参照してください。
JAX-RS 2.0
：Java API for RESTful Webサービス
モバイル・アプリケーションのアクセスのしやすさと、それに伴う使用の拡大により、ユーザーは、ソー シャル・メディア・ポスト、写真、ニュース記事、スポーツの結果、株価、通貨評価、オンライン・ゲーム などのソースから、膨大な量の情報にアクセスできるようになりました。これと同時に、アプリケーション やサービス用のリモートAPIの提供への関心も高まっています。通信チャネルがインターネットであること を考えると、RESTアーキテクチャのスタイルに従うWebサービスは当然増えてきます。
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 12.1.3は、Java EE 6の仕様に従い、JAX-RS 1.1を完全にサポートしています。JAX-RS 1.1の仕様では、開発者がPOJOやEJBのステートレスSession Beanを使用して、REST Webサービスを簡単に 作成できます。この場合、装飾ベースのアプローチによって、 実行時にリソースとなるクラスに@Path、@GET、@POSTなどのアノテーションを指定します。Java EEプ ラットフォームとの統合により、これらのリソースを含むアプリケーションを、クライアントがコールおよ び利用できるREST Webサービスとしてデプロイおよび公開できます。JAX-RS 1.1の仕様では、HTTPリクエス トから関連情報を自動的に抽出し、 @PathParam、@QueryParam、@FormParamなどのアノテーションを使用してリソースに渡す方法の定義も サポートされています。また、リソースで、@Producesや@Consumesを使用して生成、使用されるデータ 形式（MediaTypes）の規定もサポートされています。
Oracle WebLogic Server 12.1.3では、開発者が最新の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つは、開発者が、やり取りしているリソースのレベルで設計および
作業できるという点です。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、フィルタとインターセプタ
Server 12.1.3のサンプル・セットで提供されています。
図16 JAX-RSトラフィック・ロギング・フィルタ
インターセプタはフィルタとは違い、エンティティの入力ストリームと出力ストリームの操作によってエン ティティを変更できるように設計されています。このためには、ReaderInterceptorやWriterInterceptorのイ ンタフェースの実装を使用して、エンティティへの必要な変更を行います。
Oracle WebLogic Server 12.1.3のサンプル・セットに付属しているインターセプタの例は、XORエンコーディ ング・メカニズムを使用するエンティティ・ストリームの軽量なエンコーディングを示したものであるため、 第三者にとって分かりやすいものではなく、ReaderInterceptorとWriterInterceptorの両方のインタフェース を実装しているクラスを使用して実行されます。
非同期のサポート JAX-RS 1.1の場合、クライアントとサーバー間の相互作用モデルは同期モデルに基づいていました。このモ デルでは、クライアントからサーバーに対してリクエストが出されると、サーバーでは、初回接続を受信し たスレッドと同じスレッドを使用して、ターゲット・リソースでリクエストが処理されます。最終的に、レ スポンスが完了して書き込まれると、リクエストがリリースされます。 JAX-RS 2.0では、非同期の相互作用の概念が追加されました。これにより、リソース自体で一時停止を実行でき るため、クライアント接続処理の実行時に、この処理をリソースから切り離すことができます。Servlet 3.0の仕 様に精通した開発者にとって、JAX-RS 2.0でサポートされている非同期モデルは使い慣れたものでしょう。 非同期処理が特に関係するのは、結果を出すのにそれほど時間がかからないと分かっているリソース・リク エストが発生する場合や、レスポンスが将来的に必ず作成される場合です。このような場合に非同期プログ ラミングを使用すると、システムのスケーラビリティと全体的なスループットの向上に役立ちます。受信リ クエストを処理するスレッドが解放され、リソースで独立して作業を完了できるためです。 図18 非同期メソッドの例
Oracle WebLogic Server 12.1.3でのJAX-RS 2.0の使用
Oracle WebLogic Server 12.1.3内での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 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ディスクリプタ・ファイルが 提供される必要があります。
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について詳しくは、http://www.w3.org/TR/eventsourceを参照してください。 Server-Sent Eventが一般的に使用されるのは、ブラウザ・クライアントがJavaScript EventSourceオブジェク トを使用してサーバーとの接続を開き、接続上で発生しうるさまざまなイベントのコールバック関数を登録 する場合です。これにより、クライアントとサーバー間の接続が確立され、以後はサーバーがクライアント にいつでもデータを送信できます。データがクライアントに到達すると、EventSourceでonmessageイベン トが発生し、コールバックでデータを受信できます。イベント・データがJSON形式の場合、ブラウザ内で 使用できるJSONパーサーによって、ペイロードがすぐにJavaScript形式にエンコードされます。
JAX-RSクライアントAPIは、Sse-Featureの使用によるServer-Sent Eventモデルもサポートしています。Sse-FeatureをClientBuilderで登録して、機能を使用できます。サーバーからのイベントは、EventInputオブジェ クトからInboundEventsをプルするか、EventSourceオブジェクトでEventListenerを使用することで取得でき ます。
Oracle WebLogic Server 12.1.3で提供される、Jersey 2.xの実装によるServer-Sent Eventのプログラミング・ モデルは、JAX-RSスタイルのプログラミング・モデルに基づいています。アノテーションは、Server-Sent Event URIの公開と、@Producesタイプが必要なServer-Sent 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 12.1.3
Jersey 2.xの実装では、ブロードキャストの概念もサポートされています。ブロードキャストでは、サーバー が複数のクライアントに対して同時にメッセージを送信できます。この場合、リソースはクライアント接続 リクエストを特別なクラス（SseBrodcaster）に保存できます。SseBrodcasterでは、それ自体に保存されて いる現在接続中のすべてのクライアントに対して特定のメッセージが送信される、ブロードキャスト操作を 公開できます。
Oracle WebLogic Server 12.1.3のJersey Server-Sent Event機能を使用したアプリケーションの開発プロセスは、 JAX-RS 2.0機能を使用する場合と同様に、jax-rs- 2.0.war共有ライブラリのデプロイメントと参照が必要です。 この共有ライブラリには、Server-Sent Eventモデルの使用をサポートするため、Jersey固有のライブラリが 含まれています。
JPA 2.1
：Javaの永続性の進化
JPA 2.1の仕様はコミュニティのフィードバックに基づいて進化を続けており、主要なAPIを実際のプロジェ クトで使用する際に開発者が順守する要件をサポートしています。オラクルは引き続きJPAの仕様をリード し、オープンソースのEclipseLinkプロジェクトを通じて、リファレンス実装を提供します。 JPA 2.1のリリースでは、次のような厳選された新機能のサポートが追加されています。 » 標準的な移植可能スキーマの生成：標準化された移植可能なプロパティ・セットを定義して、永続ユニッ トのスキーマ生成の実行方法（DDLアクションの実行タイプ、スクリプト・ファイルの生成と実行など） を定義します。 » ストアド・プロシージャの呼出し：新しいStoredProcedureQuery APIと名前付きストアド・プロシージャ 問合せにより、データベース・ストアド・プロシージャ・コールの実行がサポートされるようになりまし た。このため、データベース内で直接実行されるコードを、正式なAPIを使ってコールすることができま す。 » クライテリアAPIによるバルク更新とバルク削除：新しいCriteriaUpdateクラスとCriteriaDeleteクラスが提 供され、クライテリアAPIを使ったバルク更新およびバルク削除の問合せの実行がサポートされます。 » 動的名前付き問合せ：永続ユニットに対する、名前付き問合せの動的な作成と追加をサポートします。 » コンバータ：属性のタイプと値から対応するデータベースのタイプと値への変換を制御する機能が追加さ れています。 図23 ストアド・プロシージャの名前付き問合せ図24 バルク・クライテリアAPI
Oracle WebLogic Server 12.1.3
でのJPA 2.1の使用
Java EE 6でデフォルトのJPA実装として定められているとおり、Oracle WebLogic Server 12.1.3はJPA 2.0をサ ポートしています。
Oracle WebLogic Server 12.1.3内での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_1.0.0.0_2-1.jarファイル。このファイルは、$ORACLE_HOME/wlserver/modulesディ レクトリにインストールされます。
JPA 2.1の機能を有効にするには、PRE_CLASSPATH環境変数を定義します。この変数には、WebLogic Server サーバーの起動前にこれらのライブラリが含まれます。
革新的な機能
Oracle TopLink
とTopLink Data Service
Oracle TopLink 12.1.2は、Oracle WebLogic 12.1.2インフラストラクチャに完全に統合されています。Oracle TopLinkはオープンソースEclipse Persistence Servicesプロジェクト（EclipseLink）に基づいており、開発作 業と保守作業を軽減して企業アプリケーションの機能を高める実行時機能を備えた、高度なオブジェクト永 続化フレームワークです。TopLinkは、幅広いJava EEアーキテクチャとJava SEアーキテクチャで使用するた めに設計されています。TopLinkのもっとも人気の高い永続化サービスには、次のようなものがあります。
» リレーショナル：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 12.1.3には、WebLogic Spring Integration機能でSpring 4.0.xリリースを使用するため のサーティフィケーションが追加されています。
OSGI
Oracle WebLogic Server 12.1.3でのOSGIの使用は、WebLogic Serverランタイムの一部としてOSGIフレーム ワークを登録およびインスタンス化する機能によってサポートされます。Apache Felix OSGIの実装は、デ フォルトのOSGIフレームワークとして提供されます。OSGIフレームワークを使用できるため、サーバー・ レベルのバンドルとして、または標準的なJava EEアーカイブ（war、ear、jar）内に組み込まれたバンドルと してOSGIバンドルをデプロイし、JNDIバインディング経由で利用できるようにして、アプリケーションを探 して使用します。WebLogic ServerにデプロイされるOSGIバンドルは、OSGI Common Services（ロギング・ サービスなど）にアクセスして使用できます。また、ランタイム・サーバーで使用できるWebLogic Server のデータソースとワーク・マネージャにもアクセスできます。
開発者にとっての使いやすさ
開発者用zipファイル・ディストリビューション
小サイズでダウンロードしやすく、迅速に起動できる製品を求める開発者の要望が高まっているため、最近 のWebLogic Serverのいくつかのリリースでは、zipファイル形式を利用できるようになっています。zipファ イル・ディストリビューションには、WebLogic Server製品のすべての機能が簡単なzipファイル形式で含ま れており、完全インストールに通常含まれる重要度の低いコンポーネント（JDKのバンドル、Eclipseベース の開発ツール、ネイティブ・ライブラリなど）は除外されています。このように簡素化してパッケージ化す ることで、ダウンロード用のファイル・サイズが約180MBに減り、一般的な速度のネットワークでは、5分 以内でダウンロードできるようになりました。 図25 オラクルのWebサイトからのzipファイルのダウンロード オラクルのWebサイトからzipファイルをダウンロードすれば、zipのコンテンツを抽出し、1つの構成スクリ プトを実行し、サーバーを起動して新しいドメインを作成することによって、WebLogic Serverのインスタ ンスを迅速に作成して起動できます。 図26 開発者用zipディストリビューションの解凍提供されるconfig.shまたはconfig.cmdのスクリプトを使用して、使用するインストールの準備をしたり、構 成プロセスの一部としてオプションで新しいドメインを作成したりします。
図27 zipファイル・ディストリビューションの構成スクリプトの実行
構成スクリプトの実行が完了すると、製品インストールが完了します。オプションでドメインが作成されて いると、すぐに実行して使用できます。
zipファイル・ディストリビューションによるWebLogic Serverのインストールには、すべてのJava EE APIと コンテナ・セットが含まれます。これは、DataSourcesやJMSの機能（Distributed Destination、ストア・ア ンド・フォワード、WLSTやMavenのアーティファクトやプラグインなどのクライアント・ユーティリティ など）を含む高度なWebLogicサービスです。zipファイル・ディストリビューションの重要な要素として、 アプリケーションの管理やサーバーへのデプロイをブラウザから効率的に実行できる、標準的なWebLogic Serverコンソールが含まれています。 zipファイル・ディストリビューションを使用して、開発とテスト用の1つのサーバー・ドメインを迅速に作 成できます。また、複数の管理対象サーバーを含むクラスタが含まれるドメインを作成できるという点も重 要です。さらに、新しい動的クラスタ・モデルを使用して、構成可能な管理対象サーバーの数で、クラスタ を作成することもできます。
図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 12.1.3には、Java EE 6アプリケーション開発全体のサポート、WLSTスクリプト作成のサポー ト、およびWebLogic Server独自のManaged Coherence Server機能で提供されているGrid Archive（GAR）の パッケージ化のサポートなどの、Oracle Coherenceアプリケーションの開発サポートが含まれています。
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 12.1.3を使用したアプリケーション開発が例外的にサポートされています。これには、アプリケー ションをデプロイおよびテストするWebLogic Serverインスタンスの起動、停止、デバッグを、NetBeansで 実行できる機能が搭載されています。このデプロイと保存の同時実行機能により、ほぼシームレスな開発お よびテスト・サイクルが実現され、ソース・コードの変更をサーバーに自動的に再デプロイして、すぐにテ ストできるようにします。Oracle NetBeansは、これらすべての機能と最新のアプリケーション・プログラミ ング・モデル（さまざまなHTML5およびJavaScript指向のフレームワークなど）のサポートの強化を組み合 わせた、強力な開発ツールです。
Oracle JDeveloper 12.1.3は、Oracle WebLogic Server 12.1.3アプリケーションの開発をサポートするように更 新されています。コードの編集、テスト、デバッグ、プロファイリング機能を備えた完全な開発環境を提供 し 、 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などを使用する必要があるとしま す。このためには、システムのクラスパスからこれらのクラスをフィルタリングするように、フィルタリン グ・クラス・ローダーを構成します。代わりに、これらのクラスはアプリケーションのライブラリからバン ドルされてロードされます。
