Embed Size (px)
Citation preview
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 参考資料 ................................................................................................................................................. 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の使用をサポート
1 | WebLogic Serverを使用した開発
モバイル・アプリケーションのビジネスでの採用、利用の拡大に伴い、開発者は、ポータブル・サービス、およびさまざまなブラウザやデバイスからアクセスできるポータブルなデータ形式を利用している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サービスの開発や、効率的なデータ・アクセスのための機能がさらに追加されています。
2 | WebLogic Serverを使用した開発
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機能を示す追加情報が渡されます。これは、ハンドシェイクのオープン と呼ばれます。
3 | WebLogic Serverを使用した開発
図1 WebSocketのハンドシェイクのオープン
サーバーで接続リクエストの受入れが可能である場合は、接続をアップグレードできることと、アップグレード先のプロトコル、およびWebSocket固有の情報を示すHTTPレスポンスが返されます。このレスポンスは、ハンドシェイク・レスポンスのオープン と呼ばれます。
図2 WebSocketのハンドシェイク・レスポンスのオープン
このリクエスト/レスポンスのやり取りが正常に完了すると、同じネットワーク・アドレスとポートを使って、HTTP接続がWebSocket接続に置き換えられます。WebSocket接続が確立されると、クライアントとサーバー間で自由にWebSocketを送受信できます。一方が明示的に接続を終了するか、外的要因（非アクティブによるネットワーク・タイムアウトや基盤となるネットワークの問題など）によって接続が終了されるまで、接続は有効なままです。
データは、一連のWebSocketメッセージとして、WebSocket接続経由で送信されます。各WebSocketメッセージはデータ・フレーム内で送信されます。長いメッセージは複数のフレームに分けられて順番に送信され、受信者側で再構築されて元のメッセージが再生成されます。
4 | WebLogic Serverを使用した開発
図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（接続を閉じる）：ピアで接続が終了されました。開発者は
5 | WebLogic Serverを使用した開発
アノテーション・ベースのプログラミング・モデルを使用した場合、アプリケーション自体をWebSocketエンド・ポイントとして提示し、ライフ・サイクルに参加してメッセージを送受信するアプリケーションは、数行のコードのみの非常に簡単なクラスで表すことができます。
たとえば、通常のエコーWebSocketについて少し異なる点として、次のクラスではWebSocketクライアントからメッセージを受信し、リバース・フォームで返信します。
図4 WebSocketのアノテーションの例
@ServerEndpointというアノテーションは、ServerEndpointとしてのクラスを示します。このクラスはWebSocket実装で、アクセス用のURIとして指定した値によって検出およびインスタンス化されます。
@OnMessageというアノテーションは、受信するWebSocketメッセージの処理に使用されるメソッドを示します。この簡単な例では、メソッドでテキスト・メッセージ全体を受信しています。追加のメソッド定義を使用して、バイナリ・メッセージを受信したり、両方のメッセージ・タイプの部分的フォームを処理したりすることができます。
図5 @OnMessageのメソッド・フォーム
プログラム的なAPIを使用するため、エンド・ポイント・クラスを拡張してWebSocketエンド・ポイントを定義できます。エンド・ポイント・クラスによって、同等の一連のライフ・サイクル・メソッドが定義されます。このメソッドを上書きして、WebSocketでイベントのオープン、エラー、終了を処理できます。
6 | WebLogic Serverを使用した開発
ピアからメッセージを受信するために、onMessageメソッドを提供するMessageHandlerクラスが作成されます。このメソッドは、エンド・ポイントでメッセージが受信されると起動されます。アノテーション付きモデルと同様に、MessageHandlerと必要なonMessageメソッドでは、複数のフォームのうちの1つを使用して、全体または部分的なメッセージとして受信されるテキスト・メッセージやバイナリ・メッセージを処理できます。
図6 プログラム的なエンド・ポイントの簡単な例
プログラム的なAPIを使用する場合、エンド・ポイントの構成は、ServerApplicationConfigインタフェースの実装によって提供されます。この実装では、ServerEndpointConfigインスタンスが作成されます。このインス タ ン ス に は 、 ク ラ イ ア ン ト の ア ク セ ス 用 に 、 エ ン ド ・ ポ イ ン ト の ク ラ ス や URI が 含 ま れ ま す 。ServerEndpointConfigクラスでは、より複雑なタスク（サブプロトコル・ネゴシエーションやオリジン・サーバーのチェックなど）も処理できます。
7 | WebLogic Serverを使用した開発
図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を使用した開発
図8 JavaScript WebSocket APIの使用例
このタイプのWebSocket APIをコールするHTMLクライアントを使用すると、ピア間で接続を開いたりメッセージの送受信を行ったりすることができます。
図9 HTML WebSocketクライアント
9 | WebLogic Serverを使用した開発
Java API for WebSocket Protocol 1.0仕様の開発によって、Javaで直接WebSocketクライアントのプログラミングをサポートすることも、ある程度重要になってきました。このためJSR-356仕様では、サーバー側のプログラミング・モデルの提供だけでなく、WebSocketアプリケーションのクライアント側の作成にも取り組んでいます。この仕様では、両方の接続側の開発にそれほど大きな違いはありません。ただし一般的に、ServerEndpointは接続リクエストに対して準備済みで待機するWebSocketエンド・ポイントであり、同時に複数の接続をホストできるのに対し、ClientEndpointではそのピアに対する接続が作成され、同時に接続できるピアは1つだけという点が異なります。
ClientEndpointのライフ・サイクルやイベント・モデルは通常、一般的なWebSocketエンド・ポイントと同じで、アノテーションやプログラム的なモデルを使用して定義できます。
図10 Java WebSocketクライアントの簡単な例
クライアントが実行されてサーバー・ピアに接続されると、そのクライアントはエンド・ポイントのライフ・サイクル・イベントに従い、サーバー・ピアとやり取りする場合は、必要に応じてアノテーション付きメソッドが呼び出されます。
10 | WebLogic Serverを使用した開発
図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アプリケーションに、必要に応じてフォールバック・モードを使用できるようにするコンテキスト・パラメータが提供される必要があります。
11 | WebLogic Serverを使用した開発
図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を使用して出力ソースに書き込むことができます。
12 | WebLogic Serverを使用した開発
ストリーミング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が使用されています。
13 | WebLogic Serverを使用した開発
図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サービスは当然増えてきます。
14 | WebLogic Serverを使用した開発
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つは、開発者が、やり取りしているリソースのレベルで設計および
15 | WebLogic Serverを使用した開発
作業できるという点です。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を使用した開発
Server 12.1.3のサンプル・セットで提供されています。
図16 JAX-RSトラフィック・ロギング・フィルタ
インターセプタはフィルタとは違い、エンティティの入力ストリームと出力ストリームの操作によってエンティティを変更できるように設計されています。このためには、ReaderInterceptorやWriterInterceptorのインタフェースの実装を使用して、エンティティへの必要な変更を行います。
Oracle WebLogic Server 12.1.3のサンプル・セットに付属しているインターセプタの例は、XORエンコーディング・メカニズムを使用するエンティティ・ストリームの軽量なエンコーディングを示したものであるため、第三者にとって分かりやすいものではなく、ReaderInterceptorとWriterInterceptorの両方のインタフェースを実装しているクラスを使用して実行されます。
17 | WebLogic Serverを使用した開発
図17 JAX-RSインターセプタの例
18 | WebLogic Serverを使用した開発
非同期のサポート
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 | WebLogic Serverを使用した開発
図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を使用した開発
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形式にエンコードされます。
21 | WebLogic Serverを使用した開発
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固有のライブラリが含まれています。
22 | WebLogic Serverを使用した開発
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を使用した開発
図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のもっとも人気の高い永続化サービスには、次のようなものがあります。
24 | WebLogic Serverを使用した開発
» リレーショナル：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のデータソースとワーク・マネージャにもアクセスできます。
25 | 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ディストリビューションの解凍
26 | WebLogic Serverを使用した開発
提供される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を使用した開発
図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アプリケーションの開発サポートが含まれています。
28 | WebLogic Serverを使用した開発
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などを使用する必要があるとします。このためには、システムのクラスパスからこれらのクラスをフィルタリングするように、フィルタリング・クラス・ローダーを構成します。代わりに、これらのクラスはアプリケーションのライブラリからバンドルされてロードされます。
29 | WebLogic Serverを使用した開発
Oracle WebLogic Server には、ク ラス ・ ロード の問 題 を分析 およ び 解決す るた め の、Web ベー スのClassloader Analysis Toolが用意されています。上記のようなケースで、アプリケーションで使用されているオープンソース・ソフトウェアとOracle WebLogic Serverのソフトウェアが競合している可能性がある場合、このツールは、このようなクラス競合の検出を支援し、競合を解決するフィルタリング・クラス・ローダー構成を提案します。オープンソース・ソフトウェア・ライブラリを使ったアプリケーション開発プロジェクトでは、クラス・ローダーの問題を早期に検出して解決できるよう、開発プロセスでこのツールを使用することを推奨します。
また、アプリケーションでオープンソース・ソフトウェアを使用している場合は、これらのアプリケーションをアップグレードする際、または既存のアプリケーションを新しいバージョンのOracle WebLogic Serverにアップグレードする際にも、このツールを使用する必要があります。このようなアップグレードでは、サーバーまたはアプリケーションで使用されているオープンソース・ソフトウェア自体のバージョンがアップグレードされることがあります。そのため、アプリケーションで使用されているオープンソース・ソフトウェアのバージョンがサーバーで使用されているバージョンと異なってしまい、アップグレード前には存在しなかったクラス競合の問題が生じる可能性があります。Classloader Analysis Toolを使用すると、アップグレード・プロセスでこのような問題を特定して解決できます。
Oracle Apache Mavenのサポート
Oracle WebLogic Server 12.1.3には、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を使用した開発
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 12.1.3では、依存性管理モデルに対応するため、一連の一般的なAPI、ライブラリ、クライアント・ユーティリティのMaven POMファイルと、WebLogic Server、TopLink、およびCoherenceのコンポーネントからのMavenプラグインが提供されています。このプラグインにより、これらのコンポーネントをアーティファクトとしてMavenリポジトリにインストールできます。
また、WebLogic Serverのインストールで多くのアーティファクトを使用できる場合、各アーティファクトのリポジトリへのインストール・タスクを個別に手動で実行するのは煩雑で、エラーも発生しやすくなります。このため、リリースの一部として、特殊なMavenプラグインであるoracle-maven-syncが提供されています。このプラグインによって、ローカルの（またはリモートの）Mavenリポジトリに所定のWebLogic Serverインストール・ディレクトリからアーティファクトを移入するタスクが自動化されます。
31 | WebLogic Serverを使用した開発
Oracle Maven同期プラグイン
Oracle WebLogic Server 12.1.3には、特定の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を使用した開発
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を使用した開発
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を使用した開発
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を使用した開発
のチーム（小規模の場合もあります）を採用し、各チームでアプリケーションの一部分を構築します。次に、これらの部分を統合してアプリケーション全体を作成します。
多くの最新アプリケーションは、モジュール・アーキテクチャに基づいています。つまり、複数の開発者がシステム全体の様々な部分を構築し、これらを最終的に統合してビジネス・アプリケーションのニーズを満たすということです。以下のような特徴から、主流の開発アプローチとなっています。
» 変更の影響を軽減するアプリケーション・コンポーネントの疎結合
» 情報テクノロジー開発の長期的な目標であるサービスの再利用
» ビジネス・ニーズの変化に合わせアプリケーションの動作を簡単に変更できる柔軟性と俊敏性
この新しいパラダイムの中で、多くの開発組織は反復的な開発方式も採用して、旧来のウォーターフォール方式との置き換えを進めています。反復的で俊敏な開発手法では、従来のウォーターフォール方式と比べ、小さい単位の機能を頻繁に提供することに重点を置いています。この新しいアプローチが登場したことで、エラーがより少なく、より見つけやすくなり、今日のようにビジネス要件が継続的かつ頻繁に変わる環境には特に適しています。
これらの技法の多くには、継続的な統合の採用という特徴もあります。組織はソフトウェアの構築とテストの自動化に非常に関心を持っており、これには継続的統合が役立ちます。
継続的統合は、細かい頻繁な品質管理作業によって、品質の向上と迅速なソフトウェア提供を模索するソフトウェア・エンジニアリングの実践です。主な特徴は次のとおりです。
» バージョン管理システムにより、変更が追跡されます。
» すべての開発者が毎日、主要なコード行、ヘッド、トランクにコミットします。
» 製品がすべてのコミット操作上に構築されます。
» ビルドは、自動的かつ迅速である必要があります。
» 本番同様の環境に自動的にデプロイメントできる必要があります。
» 自動的にテストできる必要があります。
» ビルドが破損した場合に全員が確認できるよう、すべてのビルド結果が公開されます。
» 開発者、テスター、その他の調査担当者が、成果物を簡単に使用できます。
Oracle WebLogic Server 12.1.3では、このようにMavenやその他のテクノロジーのサポートが進化しているため、継続的統合技法を採用してアプリケーションを開発する企業をサポートします。たとえば、次のような機能があります。
» Oracle Enterprise Pack、Eclipse、Oracle NetBeans、Oracle JDeveloperなどのさまざまな開発ツールの、共通のバージョン管理システムの統合
» Maven、ビルドおよびプロジェクト管理システムを使用してコマンドラインからプロジェクトを構築できるため、ビルドのスクリプト化と自動化が可能
» Maven Archetypesから新しいプロジェクトの作成が可能
» Mavenリポジトリから、必要な依存性をダウンロードすることが可能
36 | WebLogic Serverを使用した開発
» プロジェクトのパラメータ化により、ビルドを別の環境（テスト、QA、SIT、本番など）で使用することが可能
» Mavenビルドのライフ・サイクルにプロジェクトのテストを含めることが可能
» Mavenリポジトリに、WebLogic Serverソフトウェアのインストール・ディレクトリから、オラクルが提供する依存性を移入することが可能
» Hudsonのような継続的統合サーバーの制御化で、Mavenビルドを実行可能
» WebLogic Serverを含める継続的統合環境の作成プロセスによる、包括的ドキュメントのプロビジョニング
結論
Oracle WebLogic Server 12.1.3は、実績のある信頼性の高いJava EE 6実装のいくつかの仕様に特殊な更新を追加して最新のWebおよびリッチ・クライアント・アプリケーションの開発をサポートすることで、開発者を継続的にサポートしています。また、最適化されたzipディストリビューション、さまざまな開発ツールのサポート、およびそのMaven関連機能の追加による一般的な開発ライフ・サイクルへの統合により、引き続き開発者をサポートしていきます。
参考資料
» Oracle Fusion Middleware 12c（12.1.3）のドキュメント・ライブラリ：http://www.oracle.com/technetwork/jp/middleware/fusion-middleware/documentation/index.html
» JSR-339 Java API for RESTful Web Services 2.0：https://jcp.org/en/jsr/detail?id=339
» JSR-338 Java Persistence API 2.1：https://jcp.org/en/jsr/detail?id=338
» JSR-356 Java API for WebSocket 1.0：https://www.jcp.org/en/jsr/detail?id=356
» JSR-353 Java API for JSON Programming 1.0：https://jcp.org/en/jsr/detail?id=353
» Jersey 2.5 User Guide：https://jersey.java.net/nonav/documentation/2.5
» EclipseLinkドキュメント（JPA 2.1用）：http://wiki.eclipse.org/EclipseLink/Release/2.5/JPA21
» Java EE 7 Tutorial：http://docs.oracle.com/javaee/7/tutorial/doc/home.htm
» Java WebSocket Programming、Danny Coward、Oracle Press 2013
» EclipseLink MOXy and the Java API for JSON Processing - Object Model APIs：http://blog.bdoughan.com/2013/07/eclipselink-moxy-and-java-api-for-json.html
37 | WebLogic Serverを使用した開発
Oracle WebLogic Server 12.1.3
WebLogic Serverを使用した開発
2014年6月
Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.
海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200
www.oracle.com
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の登録商標です。0614
