2013年3月29日

[JavaFX] Why, Where, and How JavaFX Makes Sense

原文はこちら。
http://www.oracle.com/technetwork/articles/java/casa-1919152.html

著者について
Björn Müllerは、ヨーロッパのRich Internet Clientの領域のパイオニアの一人であり、大規模かつ長期間使われるアプリケーションシステムのためのクライアントフレームワークに特化したドイツのソフトウェア会社CaptainCasa GmbhのCEOです。

CaptainCasaとは、ビジネスアプリケーションのための共通フロントエンドインフラストラクチャであるCaptainCasa Enterprise Clientの開発およびこの製品を利用している、中規模のビジネスアプリケーションソフトウェアベンダーのオープンコミュニティです。
CaptainCasa
http://www.captaincasa.com/
ビジネスアプリケーションには以下のような傾向があります。
  • Big—たくさんの画面があります。
  • Complex—数多くのルールによってアプリケーション処理が進行します。
  • Used by employees—アプリケーションの主な利用者は日常業務で利用する社員です。もちろん、(臨時利用や匿名利用など)他の利用者もいますが、主要な利用者ではありません。
  • Long-term-oriented—アプリケーションのライフサイクルは長く、現在作成すると、将来の7年にわたって販売される可能性があります。そしてお客様先で10年以上使われる可能性があります。そのため、17年という典型的なライフサイクルを考慮に入れる必要があります。
CaptainCasa Enterprise Clientを使っている企業は、金融、リソース管理、物流、製造、人事、管理などの種々の領域に対しソフトウェアソリューションを提供しています。CaptainCasaコミュニティは2007年に創設され、その時点ではクライアントとしてSwingベースの実装を使うことに決定しました。ちょうどこのタイミングで、JavaFXベースに移行しています。それが今回の記事の内容です。

Everything in HTML5! Or Is a Window Still Open for Native Front Ends?

Should You Succumb to Fads?
2007年当時、「Adobe Flexを使わないなんて…」と言われていました。開発者向けコンファレンスではAdobeのセッションは満杯でした。時間が経ち、Steve Jobsからの一通のメールでこの流行は終わりました。
1年前、Google Web Toolkitが流行しました。現在Googleは世界に向け、Dynamic Webのための新しい言語であるDartに注力している、と発表し、次の流行はそちら方向に進んでいます。
フロントエンドの領域では流行に注意する必要があります。つまり、ころころ変わるということです。
Figure 1
図1 Web UIの流行と大規模ビジネスアプリケーションのライフサイクルの比較
もちろん、マネージャーは常に流行に乗りたいと思っています。「すべてはHTM5だ!」何回我々はこの明確でシンプルな宣告を聞いたことでしょう。こう主張する者が、HTML5とは本当は何なのか知らないことはわかっていても…。
全く流行を避ける必要はないのです!理にかなった場所、タイミングでトレンドを採用すべきです、例えば、たくさんのシナリオのためにHTML画面を必要としているけれども、他のシナリオではネイティブアプリケーションが必要です。だからこうしたテクノロジーを効率的にな方法で含めることができるよう、アーキテクチャをオープンにしておく必要があります。
とはいえ、アプリケーションアーキテクチャの主要な機能については、最新の流行に従って決定すべきではありません。ビジネスアプリケーションのライフサイクルは確実に今日の誇大広告のライフサイクルに比べて長いのです。アプリケーションの主要な画面を5年毎に適応させるための予算はとらないでしょうし、たびたびアプリケーションの主要な部分をアップデートしても感心してくれるお客様がいるとは思えません。

Once Again There Are Technical Problems
JavaScriptやHTML、CSSがHTML5ページの構成要素です。そしてすべての開発者が夜中に寝転がりながらおきまりの問題について想像を巡らす可能性があります。
  • ブラウザの非互換性
  • パフォーマンスの問題
  • ひどいスクリプト言語
状況は現在も悪化しています。
  • ブラウザの数は増加しています。例えば、デスクトップ向けには、Internet Explorer、Firefox、Chrome、およびSafari。そしてタブレットやスマートフォンにはその同等のものといった具合で、ブラウザの機能と実装は分離されています。
  • JavaScriptは、ますます複雑になっています。それはもはや一部のUIプロセスを結び付けるために使われる言語ではなく、現在では、ローカルファイルシステムへのアクセスができるような、一般的なクライアント開発目的で使われる言語を目指しています。
すべての複雑さを隠蔽するか、少なくとも、管理しやすくなるフレームワークを使う打開策があるはずです。この複雑さを処理するために、これらのフレームワークは、独自に複雑である必要があります。
フレームワークは多々ありますが、いくつかは、現在の流行、いくつかは、以前の流行、一部は将来の誇大広告でしょう。それらの多くは消えるか、または開発やサポートが終わることでしょう。
アプリケーションのフロントエンドで何か動作しない場合にはどうしましょう。例えば、Firefoxでのみ発生するバグがありますが、Internet Explorerでは起こらない、もしくはその逆もあり得ますね。きっとフレームワークを作った面々と非常に密接にコンタクトをとる必要があるでしょう。お客様はソリューションを期待しているので、よりよいソリューションを提供したいと考えるはずです。

Is "Zero Installation" the Only Efficient Type of Installation?
フロントエンドの実装において、2つのオプションがあります。
  • 特定のフロントエンドの複雑さに従うか、複雑さを避けるか、つまりフレームワークの手助けを借りて、もしくは借りずにHTML5を使う場合。その場合、開発モデルが暗示する複雑性や課題を管理し、開発や保守リソースを割り当てる必要があります。通常全く使い物にならないのは、ソリューションで使う必要のあるブラウザを決定することです(例えば、「Firefoxでのみ動作します」)。企業はブラウザの設定を持つ傾向があるため、企業のビジネスが成功するために考慮する必要があります。
  • 対して、洗練されたアプリケーションのフロントエンドを展開する場合。(最近ではアプリと呼ばれる)簡単にインストール可能なプログラムは、クライアントOS上で動作します。
両方のアプローチは共に機能的であり、効率的であることは証明されています。
  • たくさんHTML5のコンテンツがあり、HTML5が実行可能なソリューションであることを証明できます。
  • 今日ほど数多くのネイティブアプリケーションをインストールしてきたことはありません。。スマートフォンやタブレットデバイスでは、アプリをダウンロードしてインストールすることがデフォルトです。デスクトップコンピュータ上で行われるインストール方法は全くの時代遅れです。
HTML5を利用しなければエンドユーザーに新しい機能を提供できない、と言われた場合は疑ってかかって下さい。そんなわけありません。何千ものアプリケーションや一日あたり何百万ものインストールを見れば、代替案はあるものです。
幸いなことに、Java(FX)は正しい方向へ向かっています。つまり、自己完結型バンドル(これらをJavaアプリと呼びましょう)として、Javaベースのプログラムをデプロイすることが可能なのです。これらのJavaアプリがユーザーのデスクトップ上で直接実行します。Javaランタイム環境(JRE)を個別にインストールする必要はありませんし、管理者権限を設定する必要もありません。

Conclusion from a Business Application Point of View
CaptainCasaコミュニティにおける結論は以下の通りです。
従業員のための典型的な画面は複雑で、伝えなければならない情報がたくさんあり、たくさんの操作の手段(キーボード、マウス、マウスの右ボタン、ショートカット)、デスクトップ環境との緊密な統合(ファイルシステムや、MS Officeのようなサードパーティ製アプリケーション)、そして時には周辺機器と直接統合(スキャナ、カードリーダ、プリンタ)があります。通常これらの画面では、アプリケーションの中核を形成し、アプリケーション全体と同じライフサイクルを有することが想定されています。画面は顧客の環境に対しユーザのクライアントシステムに最小限の依存性をもって、確実に動作する必要があります。これらの画面には、ネイティブ・クライアント・アプリケーションのローカルインストールが最適です。
その上で、不特定ユーザー向けの画面があります。その場合、インストールが不要であることが必須です。こうした画面の多くはかなりシンプルです(しかし当然ながらきれいですよ)。こうした画面は特定の利用シナリオにあわせて設計されることが多いため、ライフサイクルは主要な画面に比べて通常はかなり短くなります。この場合には、HTML5の利用が理に適っています。画面の複雑性が増すにつれ、ブラウザの互換性などを確保するために余計な労力が必要になることがわかっています。すべてのアプリケーション画面に対し一つのフレームワークで標準化するのではなく、正しいフレームワークを正しいユーザーインターフェースのカテゴリに対して選択することが不可欠であると信じています。すべてに対し一つのフレームワークで標準化することは理想的なソリューションですが、これまでのところ、こうしたソリューションは手に入れ難いものです。従って、リーズナブルなソリューションは、二つのフレームワークの強みを組み合わせて利用することです。

Everything Is Possible! But at What Cost?
これはHTML5に関する一般的な質問です
 「フロントエンド環境としてHTML5を使う上で機能的な制限はありますか?」
この質問に対しマネージャーが期待する答えは、
「いいえ、ないですよ」
HTML5をすべての画面で利用すると非常に楽になるからです。でも、もっと正確な答えは、
「(ほぼ)すべてがHTML5で実現できます」
なのです。コストと効率の問題に過ぎません。
一般的なビジネスアプリケーションの開発グループはそれほど大規模ではありません。多くの中規模の企業の開発リソースは限られており、シンプルかつ効率的なソフトウェア開発のアプローチを渇望しています。この状況から以下の要件が出てきます。
  • 均質な開発ツールや開発言語
  • フレームワークの長期信頼性
  • 複雑さを管理できるよう、クライアントサイトのランタイムシナリオの数を制限できる機能
  • デバッグ、ログ、プロファイルの機能
  • 大事なことを言い忘れていたが、技術革新に対応する、近代的かつ柔軟なUI環境
エンドユーザーは期待を膨らませています。彼らは適切なタイミング、適切な場所で、アニメーション、トランジション、およびインタラクティブなグラフィックなグラフィックスを見たいと思っています。それに対し開発者は、特定のタスク、例えばUIコントロールの作成や既存のコントロールからくみ上げるというタスクの複雑性を隠す開発環境を探しています。
どうにかしてこのすべてをHTML5で実現するとしても、どれぐらいコストが必要でしょうか。HTML5を使用することが、大規模で複数年にわたるプロジェクトを管理するための最も効率的な戦略であるかどうか、アプリケーションのライフサイクルを網羅するとは考えにくい単一のフレームワークに依存することが理にかなっているかどうか、これらを小規模な開発グループは考え直すべきです。 "アプリ"の考え方は、作成したフロントエンドがクライアント環境で動作するより効率のよいアプローチとはなり得ないのでしょうか。

JavaFX for Employee Screens

Reasons for Choosing JavaFX
これまでの経験で、従業員向けデスクトップ画面をネイティブテクノロジーで実装することは有効なアプローチであり、JavaFXは目的に適っていることがわかっています。
  • JavaFXは、主要なデスクトップオペレーティングシステム(Windows、Linux、およびMac OS X)で提供されている
  • いくつかの痛みを伴う変化を経験してきたが、その進化からそのベンダーのコミットメントのレベルがわかる
  • Swingの後継として、多くのJava開発者が利用しており、その数は増加しています。その将来にかかわらず、強力な開発者コミュニティの恩恵を受けるはず。
  • Swingに比べて、それは、明確できれいなアーキテクチャと多くの強化機能を提供している(例えば、スタイリング、イベント管理、トランジション、シーングラフなど)。
  • アニメーション、マルチタッチなどを使う最新のユーザーインターフェイスを開発することができる
  • Javaという、明確できれいな言語に基づいている
  • デバッグ、分析、プロファイル、およびクライアントアプリケーションのログを記録するために必要なすべてのプロフェッショナルJavaツールを提供している
  • 前提条件不要で、クライアント側でアプリのような簡単なインストールが可能である
手短に言えば、今日こうした機能をすべて提供しているネイティブUI環境はJavaFXだけであると信じています。

Experiences with JavaFX
2012年中頃からJavaFXで開発してきました。以下にわかったことをまとめました。
  • Stability—重大な問題でつまずいていません。JavaFXはいくつかの些細な画面よりはるかにたくさん処理することを前提としており、コントロールを組み立てる方法は非常に洗練されていると信じています。当社の全体的なメッセージは、"It's stable." (安定しています)です。現在、クライアントプラットフォームとしてWindowsに注力していて、まだMac OS XまたはLinux上でJavaFXを評価していないことに注意してください。
  • Standard control library—我々のニーズはJavaFXで提供されるもので満たされています。Swingに対する決定的な優位性は、ブラウザコンポーネント(WebView)とHTMLエディタコンポーネントです。現在唯一欠けている重要な機能は、すべての標準コントロールに対するリッチテキストのサポートですが、JavaFX 8で対応することが発表されました。
  • Extensibility—我々は自作の複雑なコントロールを実装することに慣れているので、既存コントロールの拡張性は、非常に重要です。これが全然問題にならないことが証明されている。
  • Third-party libraries—例えば、以前のSwingLabsからのPDF RendererやOpen Street Map Viewerや、Apache-BatikプロジェクトからSVG Viewerなど、いくつかのサードパーティ製のコンポーネントは、Swingで容易に利用できます。JavaFX用のこうしたコンポーネントはまだ利用できません。つまりJavaFXを使う場合は回避策を見つけなければなりません。
  • Development process—現在Eclipseを使っていますが、他のJava IDEと同様、プロフェッショナルなツールを備えており(デバッガ、メモリプロファイラ、パフォーマンスプロファイラなど)、Java FXアプリケーションを開発するために利用できます。画面を作成するためにビジュアルツールを使っていないので、そちら方面の評価は行っていません。
  • Performance—当社の全体的な印象ですが、多くのコンポーネントで作成した画面を描画する際、JavaFXはSwingと同じぐらい高レベルの性能が出ています。そして、トランジションやアニメーション(Swingの場合、この領域では提供している機能が限定されています)の領域では、JavaFXはずっといい性能を出しています。全体的に、性能は問題ありません。
  • Support—Oracle Technology NetworkのJavaFXフォーラムで質問をすると、多くの場合、わずか数時間後に、回答を受け取るでしょう。JIRAにバグを投稿すると、バグが処理されます。

The Architecture Around JavaFX

ここまでで、弊社の従業員向け画面のUIテクノロジー環境としてJavaFXを選択した理由を理解いただいたと思いますので、JavaFX UIがCaptainCasa enterprise clientフレームワークで使われているアーキテクチャの背景を再考しましょう。
本質的な質問はこれです。
「あなたのクライアントアプリケーションはどれほどFat/Thinですか?」
fat clientとthin clientという用語に対する混乱を避けるために、以下を一読下さい。

Thick Client Architecture
Thick Clientは、UI以外にいろいろやらなければならないことがあります。つまり、Thick Clientはアプリケーション·ロジックのかなりの量を保持しています。専門用語では、UIからのイベントとデータ入力をクライアント側のアプリケーション機能で直接(事前に)処理します。クライアントはサーバーへ通信することが時々あります、例えば特定のAPIを呼び出し、入力したデータを転送します。
Figure 2
図2 Thick Client ArchitectureはUIのやりとりに加え、アプリケーションロジックを処理します。
Thick Clientが必要なユースケースは以下のような場合です。
  • ユーザーにローカルデスクトップで操作させ、サーバーとの通信を最小限にしたい、さらにユーザーにネットワーク接続させたくない場合。
  • 非常に多くのユーザーが想定されるため、サーバーをステートレスにする必要があるようなユースケースを扱っている場合。全体のやりとりと処理状態をクライアント側で保持する。
JavaFXはThickデスクトップクライアント開発のための最適な環境です。すべての制御処理は、JavaFX APIを介して行われ、Java APIを介してすべてのアプリケーションの処理が行われています。同じタスクを実施するにあたり、HTML5(HTML、CSS、JavaScript)と比較してみましょう。しかし、thick clientにもいくつかの制限事項があります。
  • フロントエンドにアプリケーションがある、ということは、大規模なアプリケーションであれば、かなり大きなフロントエンドになる可能性があります。ロジック内のバグを修正するためにかなり頻繁にアップデートすることになるでしょう。
  • Webサービスなどの多くのサーバーAPIは、フロントエンドのニーズを満たすように定義する必要があります。
  • そして、再三再四マスターデータにアクセスしなくてよいように、こうしたサーバーAPIを効率的に呼び出すために、複雑度が高まる可能性があります。
  • 典型的には、いくつかのクライアント·アプリケーション·ロジックとそれに対応するサーバー·アプリケーション·ロジックが同じサーバAPIにマップされ、両タイプのロジックは整合する必要があります。そのため、クライアント側とサーバー側の両方で同じロジックが2度実装されることがあります。
一般的にThick Clientのアプローチは、単純なシナリオで有効です。例えば、JavaFXアプリケーションとして電子メールクライアントを実装したい場合は、メール表示およびメール送信のための数少ないUIだけがあり、対応するロジックを非常にはっきりしています。
数百もの画面があるビジネスアプリケーションであれば、Thick Clientのアプローチは複雑すぎます。Thick Clientとして実装されているSAPビジネスアプリケーションのクライアントを想像してみて下さい。

Thin Client Architecture
対して、Thin Clientです。このタイプのアーキテクチャでは、クライアントは単にサーバーから送信されたXML記述のような抽象フォームを描画するだけです。このフォームを(JavaFXコンポーネントで)描画し、ユーザー入力をサーバーに返してサーバーで処理をします。
Figure 3
図3 Thin Client Architectureでは抽象フォームはサーバーから描画エンジンに到達し、処理のためにサーバーへ戻ります。
このシナリオでは、サーバはフォーム(XML)を作り、ユーザー入力を処理するものです。アプリケーションのインタラクション・ロジックの点では、これはフォームの業務処理をサーバー側で実施することを意味します。クライアントは描画しているフォームの背後のビジネスセマンティクスは知りません。フォームが注文書や休暇申請なのかどうか、クライアントは全く知りません。
Thin Clientアーキテクチャの場合、インフラストラクチャが必要です。
  • クライアント側には描画クライアント
  • フォームやレイアウトを送信し、クライアントからのユーザー入力を処理するサーバーインフラストラクチャ
  • 気の利いたサーバー・クライアント間のプロトコル—常にHTMLの全体レイアウトを送信するのではなく、変更点のみ送信する
しかしこのインフラストラクチャを持つ場合、利点は以下の通りです。
  • クライアントはアプリケーション処理から解放される。つまり、修正すべきアプリケーションのバグはサーバー側にしか存在しないため、クライアントの定常的な再配信はない。
  • クライアントサイズは小さくなる。アプリケーションのサイズから解放される。
  • サーバーとクライアント間は一つのインターフェース(レイアウトチャネル)だけ。クライアント側のロジックがアクセスするために無数の細かいサーバーAPIを呼び出す必要はない。
  • インタラクション処理(今回の場合はサーバー側)はサーバー側アプリケーションと非常に密接である。
  • 開発箇所はサーバー側1カ所のみで、すべてのコーディングはここで完了する。「フロントエンドチーム」と「サーバーチーム」に開発チームを分ける必要はない。
Preliminary Conclusions
正しいアーキテクチャを選択することが重要です。
Thick Clientアプローチの場合、最も高速に実現できます。単にJavaFXを使い、開発を始めるだけです。ただ、より複雑なシナリオになると限界があります。
Thin Clientアプローチの場合、一般に大きく複雑になる傾向にあるビジネスアプリケーションに適しています。このようなアプリケーションでは、開発効率の向上しつつ、実行時のオペレーションコストが削減できます。

JavaFX in Front of JavaServer Faces: CaptainCasa

Thin Clientアーキテクチャを使う場合、自分でフレームワークを作るか、既存のインフラストラクチャを使う選択肢があります。
CaptainCasaは既存のThin Clientインフラストラクチャであり、クライアント側にJavaベースのクライアントアプリを、サーバー側にJSFベースの処理を提供します。

JSF Being Used for a JavaFX Client
"JavaFX with JSF": 初見だといささか奇妙に感じるかもしれません。というのも、JSFはHTMLインフラストラクチャとして知られていますが、当初よりJSFは、具体的なHTMLブラウザクライアントから抽象化されたJava EEサーバーの標準であり、他のレンダリング·インフラストラクチャのサポートもします。そのため、完璧にフィットするのです!
JSFはサーバー側のインタラクション・フレームワークです。基本的な処理は、次のとおりです。
  • サーバー側では、レイアウトをコンポーネントのオブジェクトツリーとして保持します。通常宣言的なXMLコードによりツリーが構築されますが、実行時に操作することができます。
  • サーバーは再帰的にツリーをたどって、レイアウトをクライアントに送信します。ツリーに定義された各コンポーネントは、コンテンツを特定の形式の文字列にレンダリングします。HTMLの場合、各コンポーネントは対応するHTML表現にレンダリングします。ツリーをすべてたどり終えると、その結果一つのレイアウト記述に結合され、これをクライアント側へ送信します。CaptainCasa Enterprise Clientの場合、各コンポーネントは自身を特定のXML文にレンダリングします。レンダリング中にデルタ·プロセスは終了時にXMLのページが変更のあったコンポーネントツリーの部分だけを保持するよう指定します。 
  • JavaFXクライアントはXMLを受信し、描画します。再度、デルタ管理が変更された部分だけ更新されていることを保証します。
  • ユーザーがデータ入力します。フィールドに入力されると、クライアントは変更を登録し、サーバーにすべての変更を送信する重要なイベントを待機します。イベントはボタンをクリックしたり、メニュー項目を選択したり、特定のフィールドで実施した変更の場合があります。
  • サーバーはリクエストを受け取り、すべての変更をJSFコンポーネントツリーの対応するコンポーネントに渡され、そこからアプリケーション処理ロジックに転送されます。
おわかりのように、JSFをいつものように使用しますが、この場合、デフォルトのシナリオのように、ブラウザではなくJavaFXの描画クライアントが描画します。ネットワークの観点からは、HTMLの代わりに特定のXMLがネットワーク上を流れる以外は、CaptainCasaのJavaFXクライアントと通常のブラウザとの間には構造上の違いはありません。

XML Layout Is (and Must Be!) Abstracted from the Client Rendering Infrastructure
Swingを使用して、2007年にCaptainCasa Rich Enterpriseクライアントの開発に着手しました。現在、フォームに追加可能な約100個のコントロールを提供しています。今日、JavaFXで私たちのクライアントを再実装しようとしています。
どちらの実装でも、もともとSwingから取り出したXMLレイアウト定義を活用しています。結果として、JavaFXのクライアントは、Swingクライアントと同じレイアウト記述を使用しており、クライアントは相互に互換性があります。
アーキテクチャの重要な概念として、以下のことを考えています。
  • サーバーサイドでは、やりとりは安定したサーバーサイドコントロール群(JSFコンポーネント)を使います。これらはクライアントサイドのレンダリングテクノロジーからは独立しています。
  • したがって、CaptainCasaの既存ユーザーは現在のSwingクライアントからJavaFXクライアントへ素早く切り替えることができます。
まとめると、クライアントサイドで異なるレンダリングテクノロジーへ移行することにより、深刻な問題になったり、サーバーサイドでの再実装の手間が必要になることはありません。
図4と図5はSwingベースのクライアントとJavaFXベースのクライアントの描画の差を例示しています。
Figure 4
図4 Swingベースのクライアントで描画
Figure 5
図5 JavaFXベースのクライアントで描画
図4はあるページをこれまでのSwingベースのクライアントで描画したもの、図5はJavaFXベースのクライアントで描画したものです。色や角などが違いますが、これは異なる画面スタイルのアプリケーションゆえのことです。実際のところ両画面の挙動は同じです。

まとめ

  • JavaFXかHTML5か
    これが明確な回答です。
    「従業員向けデスクトップ画面にはJavaFXを、簡単なユースケースや匿名のユースケースではHTML5を使うべき」
  • JavaFXってどうよ?
    問題は見当たりませんでしたので、本当に満足しています。
  • JavaFXまわりのアーキテクチャは?
    簡単なユースケースではJavaFXを直接実装し始めてもいいですが、ビジネスアプリケーションのユースケースであれば、Thin Client Architectureを使う、もしくは定義すべきでしょう。
  • JavaFXとJSFは?
    非常にフィットします。JavaFXに加え、Java EE標準を利用するサーバーコンポーネントをベースにするThin Clientです。
  • CaptainCasaは?
    この「JavaFX on JSF」フレームワークをビジネスアプリケーションの従業員向け画面に利用することができます。

参考

CaptainCasa
http://www.captaincasa.com/

[Java] Java Applet & Web Start - Code Signing

原文はこちら。
http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

概要

2013年2月19日のJava Critical Patch Update (CPU)で、Oracleは次のJava CPUリリースであるOracle Java SE 7 Update 21 (Java SE 7u21)を2013年4月16日に提供する予定と発表しました。
Updated February 2013 Critical Patch Update for Java SE Released
https://blogs.oracle.com/security/entry/updated_february_2013_critical_patch
2013年4月16日、セキュリティ修正と共に、Java SE 7u21では重要なセキュリティ機能も提供します。最も重要なのは、最高のユーザー体験のために、ブラウザ内で実行するためJavaプラグインを利用するJavaアプレットとWeb Startアプリケーションは信頼された証明書で署名されなければならない、という要件です。Javaはコードの署名をサポートしていますが、Java Se 7u21まではオプションの機能でした。アプリケーションコードの署名により、多数のセキュリティ上のメリットをユーザーに提供します。
Overview—What Is Java Plug-in? What Does It Support?
http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/overview.html
Java SE 7u21ではJavaコントロール・パネルのセキュリティスライダーのセキュリティレベルを変更します。JavaアプレットやJava Web Startテクノロジーを使用するアプリケーション(ネットワークやWebブラウザで実行時にエンドユーザーに配信するアプリケーション)の作者ならびにベンダーは、最高のユーザー体験のため、コードを信頼された証明書で署名する必要があります。具体的には、クライアントのWebブラウザで実行される全てのJavaコードはユーザーにプロンプトを表示します。画面に表示されるメッセージの種類はリスク(コードの署名、未署名とか、コードが権限昇格を要求しているとか、JREのセキュリティレベルがセキュリティベースラインよりも上だったり下だったり)によって変わります。低リスクのシナリオでは非常に小さなダイアログが現れ、そのダイアログには、今後同じベンダーによる類似のダイアログを表示しないためのチェックボックスが含まれています。高リスクのシナリオ、例えば未署名のjarを実行する場合、リスクが増えるためにユーザーのインタラクションが必要になるでしょう。
ユーザー体験の最小の変更でさえ、面倒なことが時々あります。この変更によりどれほどユーザー体験に影響するかを考慮してきました。現在のWebブラウザのJavaセキュリティの状況を考慮すると、コード署名がJavaユーザーを守るための重要なセキュリティコントロールです。

FAQ

どんな変更が導入されるのでしょうか。

Java SE 7u21ではJavaブラウザプラグインの挙動が変わり、アプリケーション作者やベンダーに信頼された認証局から発行された証明書でコードを署名することが推奨されます。開発者の方には、今すぐこのリリースおよび将来のリリースのためにコードを署名することを推奨します。
これらの手順は大幅にデスクトップユーザーのリスクを低減するでしょう。Javaコントロールパネルの[LOW]セキュリティ設定(例えばlowやカスタム)を除去し、Javaに組み込んでいるセキュリティ修正をユーザーが何かの事情で完全に停止することができないようにしています。最新のJREと、(自己署名や未署名ではなく)信頼済みの認証局によって署名された必要なコードと組み合わせることで、ユーザーを保護します。

なぜこの変更が重要なのでしょうか。

Webブラウザで実行するJavaは攻撃者にとって人気のあるターゲットです。2012年下旬の7u10で、Oracleは、「信頼された」アプレットのみを実行できるようにしたユーザーが構成可能な設定を導入しました。信頼されたアプレットは信頼された認証局が発行した証明書によって署名されたものであり、最終的にはエンドユーザーが承認したものです。コード署名によってユーザーがアプレット提供者のIDでユーザーの信頼が向上し、アプレットの安全のためにアプレット提供者の説明責任を強化することに役立ちます。

こうした変更によってアプリケーションが壊れませんか?

7u21の変更により、アプリケーションが壊れることはないはずですが、開発者が各アップデートリリースにて、全てのアプリケーションが適切に動作することを確認するべきです。プラットフォームはJavaアプリケーションの実行を否定しませんが、高リスクのシナリオでは、ユーザーは必要であれば、実行を停止することができるようになります。将来のアップデートリリースでは、安全でない挙動(未署名や自己署名アプリケーション)を制限する追加の変更が入る可能性があります。

コード署名はデスクトップユーザーにとってどういう意味がありますか?

信頼された証明書を用いるコードの署名により、よりよいユーザー体験を提供し、攻撃者から攻撃を防ぐために役立つより多くの情報を提供します。

コード署名はアプリケーションの作者やベンダーにとってどういう意味がありますか?

最高のユーザー体験を提供するため、JavaアプレットやJava Web Startテクノロジーを使って展開しているJavaアプリケーションの作者やベンダーは、4月のJava SE 7u21のCPUリリース前にコードの署名をしておくことをお薦めします。さらに、全てのソフトウェアコードを最新バージョンのJavaに対応させておくべきです。Javaはセキュリティベースラインの下に動作しているため、ユーザーがJavaの最新リリースにアップグレードしたがらなくなると、ユーザー体験が変わります。すべてのユーザはシステムのセキュリティを確保するため、最新のJavaバージョンにアップグレードすることを強くお勧めします。

アプリケーションの作者やベンダーはどんな準備をすればいいでしょうか?

一般に、全てのJavaアプレットやWeb Startアプリケーションの推奨されるデプロイ手順は以下のようです。
  1. アプレット、Web Startアプリケーションとも、JNLPを使ってデプロイする
  2. 権限を昇格する必要がある場合は、デプロイメント・ディスクリプタの"all permissions"を指定する
  3. 信頼された認証局から発行された証明書でアプリケーションを署名する
  4. 常に最新のJavaバージョンでアプリケーションをテストする
  5. ユーザー体験の変更に関して利用者とコミュニケーションする

コード署名の方法は?

コード署名の証明書は数多くの商用認証局から入手したり自己署名ツールを使って入手することができます。"Certificate Authorities"(認証局)や"self signed certificate tools"(自己署名証明ツール)で検索すると、要件にあったソリューションを見つけることができるかと思います。ほとんどの認証局はアプリケーションの署名方法をステップバイステップで説明してくれていますし、自己署名の方法もたくさんサンプルが出回っています。

ブラウザでJavaアプリケーションを実行するシステムのセキュリティを確保するため、どんな追加の手順をとることができますか?

Javaユーザー、システム管理者、開発者に対し、システムで利用するJavaのバージョンを最新にすることを強く推奨します。Javaの自動アップデートメカニズムはJavaユーザーが最新のセキュリティ修正に対応したJavaを使えるように設計されています。以前自動アップデートを無効にされたのであれば、自動アップデートを有効に戻し、最新かつ最もセキュアなJavaがシステムに配置されるようにしておくことをお薦めします。
その他の詳細情報は、以下の自動更新に関するFAQをご覧下さい。
Java 6 Auto-Update to Java 7 - General Information and FAQ
http://www.oracle.com/technetwork/java/javase/documentation/autoupdate-1667051.html
企業の場合、デスクトップを企業ポリシーに従いアップデートすべきです。企業はプラグインアプリケーションのインベントリを作成し、それらのアプリケーションを信頼された証明書を使って署名すべきです。

Java Security - 参考資料

開発者向け Java SE Security
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html
Secure Coding Guidelines for the Java Programming Language, Version 4.0
http://www.oracle.com/technetwork/java/seccodeguide-139067.html
Java SE 7 Security Documentation
http://docs.oracle.com/javase/7/docs/technotes/guides/security/
企業向け Oracle Java SE Support
http://www.oracle.com/us/technologies/java/standard-edition/support/overview/index.html
ミッションクリティカルなアプリケーションを24時間×7日、メールや電話でサポートしています。
Oracle Java SE Advanced and Oracle Java SE Suite
http://www.oracle.com/us/technologies/java/standard-edition/advanced-suite/overview/index.html
Oracle Java SE AdvancedとOracle Java SE Suiteは、JavaベースのIT環境を展開、監視、メンテナンスするコストを最小化する企業向け機能を提供しています。
システム管理者向け Deployment Best Practices
http://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/bestPractices.html
Java Plug-in Guide for System Administrators
http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/faq/developer.html
Tutorial: Security Features in Java SE
http://docs.oracle.com/javase/tutorial/security/
エンドユーザー向け Javaヘルプ・センター
http://www.java.com/ja/download/help/
Java Help Center(英語)
http://www.java.com/en/download/help/
信頼できないアプレットやアプリケーションがWebブラウザでいつ実行されるかを制御するにはどうすればよいですか。
http://www.java.com/ja/download/help/jcp_security.xml
How do I control when an untrusted applet or application runs in my web browser?
http://www.java.com/en/download/help/jcp_security.xml

[Java] IMP: Your Java Applets and Web Start Applications Should Be Signed

原文はこちら。
https://blogs.oracle.com/java/entry/imp_your_applets_and_web

2013年4月のJava SE 7 Update 21から、全てのJava AppletおよびWeb Startアプリケーションを信頼された証明書で署名しなければなりません。

certificate2013年4月16日リリース(予定)のCritical Patch Update for Java SE (7u21)から、Java AppletやWeb Startアプリケーション実行に関係する起動時の挙動が変わります。実行の継続もしくは終了を選択できるユーザーに対し、追加の情報を表示するための画面が現れます。最高のユーザー体験のために、AppletとWeb Startアプリケーションを署名しておかなければなりません。
どういうことでしょうか。Java SE 7u21ではJavaブラウザプラグインの挙動を変更し、アプリケーションの著者とベンダーに対し、認証局(Certificate Authority)からの証明書を使ってコードに署名することを奨励しています。開発者として、このリリースならびに将来のリリースに向け、今コードに署名することを強く推奨します。
詳細情報は、OTNにUpされている以下の記事をご覧下さい。
Java Applet & Web Start - Code Signing
http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

2013年3月28日

[Hardware] Benchmark-Results of new SPARC servers (T5 & M5)

原文はこちら。
https://blogs.oracle.com/eSTEP/entry/benchmarkresults_of_new_sparc_servers

先頃発表したSPARCサーバーT5、M5のわくわくするようなベンチマーク結果の概要をまとめました。

Recent Benchmark Results -- TPC and SPEC
Recent Benchmark Results -- Applications
その他のベンチマーク結果や上記ベンチマークの詳細は以下のエントリをご覧下さい。
BestPerf
https://blogs.oracle.com/BestPerf/
しびれる数値が出てますよ。
ところで、T5とM5のコア係数はコア係数表の記載通り、0.5です。

2013年3月27日

[EM] Ports used to talk to Agents

原文はこちら。
https://blogs.oracle.com/opscenter/entry/ports_used_to_talk_to

Ops Centerで使っているポートに関する質問を受けました。
「Proxy Controllerと管理対象アセット間の通信に必要なポート番号ってどんなの?」
セキュリティガイドの表に、Ops Centerが使うポート番号およびプロトコルがまとめられています(Proxy Controllerがアセットに到達するために使うものも含みます)。
Oracle® Enterprise Manager Ops Center Security Guide 12c Release 1 (12.1.2.0.0)
Required Ports and Protocols
http://docs.oracle.com/cd/E27363_01/doc.121/e35102/chap_overview.htm#BABFDFCI
Oracle® Enterprise Manager Ops Center Security Guide 12c Release 1 (12.1.2.0.0)
http://docs.oracle.com/cd/E27363_01/doc.121/e35102/toc.htm
 [訳注]
Enterprise Managerで利用するポート番号は、インストールガイドに記載がありますので、チェックして下さい。
例えば、インストール時に利用するポートは…
Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース2 (12.1.0.2)
インストールに使用されるポート
http://docs.oracle.com/cd/E26854_01/install.121/b65085/getstrtd_things_to_know.htm#BACEEJEH
デフォルトで割り当てられているポート番号やその範囲は…
Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース2 (12.1.0.2)
Enterprise Managerコンポーネントのデフォルト・ポートおよびポート範囲
http://docs.oracle.com/cd/E26854_01/install.121/b65085/firewalls.htm#BEIEIGEA

2013年3月26日

[SOA] How to Describe SOA to Your Grandparents

原文はこちら。
https://blogs.oracle.com/SOA/entry/how_to_describe_soa_to

Quoteことわざにもあるように、本当にテクノロジーを理解していることを確認する最善の方法は、祖父母が理解できるようにテクノロジーを説明できるようになることです…ってそんなこと聞いたことないですけどね。でももっともらしく聞こえますね。




そして、SOAと何らかの関係があるならば、いつかSOAの価値を上層部のビジネスマネージャーやシニアプロジェクトマネージャー、もしかすると貴社のCEOに説明するよう依頼される可能性があります。その場合、「疎結合」やら「サービスの再利用」やら「エンタープライズ・サービス・バス」なんてぶつぶつ言ってその後に「うーん、いえ、乗るバスじゃあないんです」なんて続けるべきではありません。
たまたまDERELCAROの動画を見つけたのですが、このDERELCAROは非常にすばらしい仕事をしてくれています。まずSOAの技術的な定義に始まり、その後すぐに平易な英語でSOAについて説明しています。ちょっと古いですが、そんなことは些細なことです。

[訳注]
動画の1:55までで説明しています。それ以後はSOA Suiteの説明です。

たぶん将来、孫にSOAについて説明する必要が出てくるでしょう。SOAとは、リアルタイムアセンブリと統合されたサービス思考(real time assembly and orchestrated service thinking, RTAAOST)のために、無線でマイクロ思考サービス(micro thought services, MTS)をローカルの側頭葉レシーバー(local temporal lobe receivers, LTLR)にダウンロードできる機能の先駆けであった、と…ええ、将来は3文字の略語を使い果たしているんですよ。

この動画をご覧になって準備ができたら、"Oracle SOA Suite in the Customers' Words"を読んでみて下さい。次のステップにお客様の言葉でSOA eBookを読んでみて下さい。次の一歩によいかと思いますよ。
Interactive E-Book
Oracle SOA Suite - In the Customers' Words
http://www.oracle.com/webapps/dialogue/dlgpage.jsp?p_dlg_id=12631082&src=7319922&act=92

[Java] Getting Started with JSON-P

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/getting_started_with_json_p

Java EE 7のリリース日が近づくにつれ、新機能を取り上げるブログや記事が出てきています。Java EEコミュニティの主要な独立メンバーであるMarkus EiseleがJSON-P入門に関してブログエントリにまとめています。
Test driving Java API for Processing JSON with GlassFish 4.0 (Enterprise Software Development with Java)
http://blog.eisele.net/2013/02/test-driving-java-api-for-processing.html
ご存知のように、JSON-P(もっと正確に言うと、Java API for JSON Processingですが)はJava EE 7に追加された主要な新APIです。JSON-Pは、特に次世代HTML5アプリケーションで使われるJAX-RSやWebSocketで、JSONをパース、生成、変換およびクエリに利用可能な基礎となるAPIです。開発者はJava EE 7でハイレベルの宣言型JSONバインディングAPI(JAXB vs. JAXPと同様)を期待できます。現在のところ標準ではありませんが、MOXyやJacksonのようなオプションがあります。Markusはこのブログエントリの中で、JSON-PとJAX-RSの統合、JSONコンテンツの作成やJSONのパースについて説明しています。
ご存知ない方のために申し上げると、JSON-Pは現在提案の最終ドラフトステージの段階にあります。ドラフト仕様をダウンロードして是非ご一読下さい。
JSR-000353 Java(tm) API for JSON Processing 1.0 Proposed Final Draft
http://download.oracle.com/otndocs/jcp/json-1_0-pfd-spec/index.html

2013年3月25日

[SOA] Community Management: The Next Wave of SOA Governance and API Management

原文はこちら。
https://blogs.oracle.com/SOA/entry/community_management_the_next_wave

長年にわたって規律としてのSOAガバナンスが存在しましたが、SOAの導入に乗り出しているすべての企業が、SOAガバナンスを受け入れることを決定してきたわけではありませんでした。いくつかの事例では、サービスのランタイム管理は実装されているものの、設計時の管理はそうではありません。

さて、クラウドコンピューティングの導入とモバイルデバイスの普及に伴い、API管理の"新しい"規律が浮上しています。このセッションでは、API管理が出現してきた理由やSOAガバナンスとの関係を説明しつつ、これらの両分野が、最終的にB2Bの世界の先例に倣って、"Community Management"と呼ばれる新しい規律へと進化する理由を説明します。

OracleのProduct Managementを担当するVPであるTim Hallが、SOAガバナンスとAPI管理を比較・対比しながら、"Community Management"と呼ばれる新しい規律に進化していくと彼が信じている理由を説明しています。
動画やスライドは以下のリンクからどうぞ。
Community Management: The Next Wave of SOA Governance and API Management (InfoQ)
http://www.infoq.com/presentations/Community-Management
スライド(PDF)
http://www.servicetechsymposium.com/dl/presentations/community_management.pdf

[Java] Network Monitor for REST and WebSockets communication

原文はこちら。
https://blogs.oracle.com/netbeanswebclient/entry/network_monitor_for_rest_and

NetBeans 7.3の未完成機能の一つにNetwork Monitorがありました。サーバーと通信するアプリケーションを開発する際に様々な問題が発生する可能性があります。例えば…
  • サーバーが応答せず通信が中断する
  • サーバーが期待しているものとは異なるデータを送信する
  • アプリケーションがサーバーに送信したをサーバーが期待通りに処理してくれなかった
などです。
こういった場合にどんなデータがアプリケーションとサーバー間でやりとりされているのかを分析できるのは非常に有益なことです。
  • アプリケーションが正しいURLを使ったか?
  • 正しいリクエスト・ヘッダーを設定していたか?
  • 実際に送信されたデータはどういうものだったのか?
  • サーバーの応答にはどんなデータが含まれていたのか?
  • データのフォーマットは?
こうした類の疑問をNetwork Monitorを使うと解き明かすことができます。この機能が次期NetBeansリリースのNightly Buildに組み込まれました。まだ完全ではなく、UIを洗練する必要があるのですが、レビュー第1弾として使う上では十分かと考えています。
NewAndNoteworthyNB74
http://wiki.netbeans.org/NewAndNoteworthyNB74
では見ていきましょうか。"Chrome with NetBeans Integration"ブラウザもしくは"Embedded WebKit"ブラウザでプロジェクトを実行すると、Browser Logウィンドウやセッションデバッグ・ウィンドウと同じように、NetWork Monitor監視ウィンドウが自動的に開きます。

前述の通り、UIはまだまだです。アプリケーションでのRESTもしくはWebSocket通信を始めると、ネットワークリクエストがNetwork Monitor UIに現れ始めることに気付くでしょう。先ほどのスクリーンショットでわかるように、全てのネットワークリクエストが監視されるわけではありません。NetBeansのネットワーク監視機能は、RESTやWebSocketを使って通信するアプリケーションの開発時に起こる、よくある問題を解決するのに役立つものです。静的なリソース(イメージやCSSなど)のロードのようなネットワークリクエストは自動的にフィルタされます。これらのネットワークリクエストを確認する必要がある場合には、例えばChrome Developer Toolsのようなブラウザツールを使って直接分析することができます。しかし、失敗した任意のネットワークリクエストは、RESTやWebSocket、その他シンプルな静的リソースリクエストにかかわらず、ログを採取し、注意を向けさせます。
どのようにネットワークリクエストが表示されるか見てみましょう。

上のスクリーンショットでは、3件のネットワークリクエストが記録されています。1つ目は失敗しているため赤で表示されています。最後のリクエストはTwitter Search REST APIを呼び出しており、リクエストヘッダーならびにレスポンスヘッダーを表示しています。Responseタブに切り替えるとサービスから受信したデータを確認できます。

サーバーからのレスポンスはここではJSONP(前のスクリーンショットにあったレスポンスヘッダー中のcontent-typeが"application/javascript"であることに注意して下さい)であり、IDEは自動的にJSONデータをjavascriptレスポンスから展開し、一つのJSONストリームを可読性の高いフォーマットに変えています。
サービスからデータが到着するとデータを確認したい場合には、右下の隅にある"Raw Data Response"のチェックボックスにチェックを入れましょう。この例では、出力は以下のようです。

最後のタブではこのネットワークリクエストを呼び出しているコール・スタックを表示します。リンクをクリックすると迅速にアプリケーションコードに到達することができます。

WebSocket通信の監視用のUIはにていますが、レスポンスデータの代わりに時系列でテキストデータのリストにて確認できます。

青字はWebSocketリクエストがまだオープンの状態でまだデータフレームが到着/送信される可能性があることを示しています。
ネットワークリクエストが失敗すると、Network MonitorはサーバーステータスコードをHeadersパネルに表示します。例えば、"404 - Not Found"といった具合です。ネットワークモニタが区別して詳しいヘルプを提供しようとしている一つのエラーケースがあります。お使いのブラウザが同一生成元ポリシー(Same Origin Policy)が原因で中止したRESTサービス呼び出しの場合は次のとおりです。

例えばこの事象は次のような場合に発生することがあります。開発中のRESTサービスをGlassFishサーバー(デフォルトでは8080/tcp上で動作します)にデプロイすると同時に、NetBeansの軽量Webサーバー(デフォルトでは8383/tcpで動作します)で実行するHTML5プロジェクトからこのRESTサービスにアクセスしようとしている場合です。このシナリオでは、ブラウザの同一生成元ポリシーにより、JavaScriptコードを停止して、RESTサービスへのアクセスができません。それはこのポリシーがJavaScriptが同一ポート、同一プロトコルを使って、同一サーバーにあるリソースにのみアクセスできるように規定しているからです。
これを解決するオプションはほとんどありませんが、両プロジェクトを一つのサーバで実行したり、RESTサービスでJSONPをサポートするように書き換え、JavaScriptからJSONPを使って同一生成元ポリシーを回避するということぐらいでしょう。しかし、RESTサービスをパブリックアクセス可能にすることを考えているならば、最善の方策はCross-Origin Resource Sharing(CORS)を利用し、RESTサービスを修正してブラウザに異なるドメインから呼ぶことができるようにすることです。
Cross-Origin Resource Sharing(CORS)
http://www.w3.org/TR/cors/
NetBeansでJerseyを使って開発されたRESTサービスの場合、(Webサービスカテゴリ中の)"Jersey Cross-Origin Resource Sharing Filter"ウィザードを使って簡単にJerseyのContainerResponseFilter SPIのサブクラスを作成し、必要なCORSヘッダーをすべて提供してくれます。
public class NewCrossOriginResourceSharingFilter
              implements ContainerResponseFilter {
    @Override
    public ContainerResponse filter(ContainerRequest request, 
                                    ContainerResponse response) {
        response.getHttpHeaders().putSingle(
            "Access-Control-Allow-Origin", "*");
        response.getHttpHeaders().putSingle(
            "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        response.getHttpHeaders().putSingle(
            "Access-Control-Allow-Headers", "content-type");
        return response;
    }
}
ウィザードが自動的にフィルタをweb.xmlに登録してくれます。
この機能がお役に立てばと思っています。フィードバックやご提案をお待ちしています。

2013年3月24日

[EM, Cloud, FMW] Cookbook : Middleware as a Service using Oracle Enterprise Manager 12c

原文はこちら。
https://blogs.oracle.com/oem/entry/cookbook_middleware_as_a_service

エンタープライズプライベートクラウド向けのMiddleware as a Service (MWaaS) ソリューションは完全なアプリケーション開発・展開環境を提供します。このソリューションには、エンタープライズクラスのアプリケーションをデプロイおよび実行するために必要な全てのサービスからなる完全なランタイム環境がふくまれています。この中にはアプリケーションホスティングや永続ストア、アプリケーション統合、アプリケーションが必要とする可能性がある追加のコンピューティングサービスにプログラマティックにアクセスできるAPIなどのサービスが含まれています。アイデンティティ・サービスは、PaaSの環境内で利用可能なAPIの例です。MWaaSにより、開発者は、コストをかけずに速くアプリケーションを展開することができます。基盤となるハードウェアおよびソフトウェア·コンポーネントの複雑さに対処する必要はありません。

Oracleは先頃、Oracle Enterprise Manager 12cを用いるMiddleware as a ServiceのためのCookbookを発行しました。
Middleware as a Service using Oracle Enterprise Manager 12c Cookbook
http://www.oracle.com/technetwork/oem/cloud-mgmt/mwaascookbook-em12c-1921948.pdf
このドキュメントではOracle Enterprise Manager 12cを使ってWebLogicドメインをプロビジョニングする手順を一つ一つ説明しています。この手順とは、以下のようなものを含んでいます。
  • クラウド管理のための名前付き資格証明、ロールおよびアカウントのセキュリティ設定
  • Oracle Enterprise Manager 12c R2標準機能のWebLogicプロファイルの利用
  • 環境や業務要件に合わせてWebLogicドメイン作成プロシージャをカスタマイズする
  • Middleware Zonesのセットアップ
  • 各クラウド管理ロールに対するクォータの設定
  • ミドルウェアドメイン作成のために利用するサービス・テンプレートの定義
  • ミドルウェアクラウド・インフラストラクチャ用のチャージバック・ポリシーの構成

Cookbook : Middleware as a Service using Oracle Enterprise Manager 12c from Oracle Enterprise Manager

[訳注]
OTNの以下のページからもアクセスできます。
Cloud Management
http://www.oracle.com/technetwork/oem/cloud-mgmt/index.html

2013年3月23日

[Database] Are you a Type I or Type II Data Scientist?

原文はこちら。
https://blogs.oracle.com/R/entry/are_you_a_type_i

Data Scientistという役割が最近注目を浴びるようになりました。Brendan Tierneyのブログエントリ「Type I and Type II Data Scientists」では、2種類のタイプのData Scientistを定義、特徴付けて、どちらも組織に必要とされる、との興味深い見方を寄せています。
Type I and Type II Data Scientists (Brendan Tierney - Oracle & Data Mining Blog)
http://brendantierneydatamining.blogspot.ie/2013/03/type-i-and-type-ii-data-scientists.html
TierneyはType I Data Scientistについて以下のように書いています。
"Data Scienceに関連するテクニックやテクノロジーについて豊富な知識があり、非常に得意とする人がいます。こうした話題の深い知識を持ち、指定された領域のデータを探索するのに最善の方法についてたくさんの詳しい情報を提供することができます。"
対して、Type II Data Scientistsについては、以下のように書いています。
"組織が直面しているビジネス目標およびビジネス上の問題に集中しています。これらをもとに、Data Scientistのプロジェクトが目指すものを識別し、測定可能な成果とビジネス目標があることを確認します。"
また、Type IIを良いコミュニケーターにしてストーリーテラーとも見なしています。
Data Scientistの役割が進化するにつれ、構造や定義が役割に付加され続けながら、組織が最も先進的な分析やデータサイエンスプロジェクトの実行を手助けすることでしょう。

[Applications] Apple iPads Certified with Oracle E-Business Suite 12.1

原文はこちら。
https://blogs.oracle.com/stevenChan/entry/safari_apple_ipads_certified_with

E-Business Suite 12.1はApple iPadで動作保証されました。
この動作保証はE-Business SuiteのOAフレームワークベースのHTMLアプリケーションのSafariでの動作保証も含んでいます。これらは時として"Self Service Web Applications" (SSWA) と呼ばれるものです。
この動作保証はApple Mailアプリを利用してE-Business Suite Workflow通知メールを承認することも対象としています。
iOSデバイス上でJavaベースのアプリケーションを実行することはできませんので、Java Runtime Environment (JRE) プラグインが必要なOracle Formベースの製品はiPad上で動作しません。

要件
  • Oracle E-Business Suite 12.1.3以降
  • iOS 6.0以降
iPhoneでは使える?
E-Business SuiteのOAフレームワークベースの製品は現在デスクトップサイズの画面を持つクライアントデバイスを想定して設計されています(例: 1024×768)。iPhone上のSafariでも動作しますが、画面サイズが小さいため、理想的なユーザー体験を提供しません。最適なユーザー体験のため、OAフレームワークベースのE-Business Suite製品にアクセスする場合はiPadをお使いになることを推奨します。
Apple Mailアプリケーションを利用してE-Business Suite Workflowの通知メールを承認する場合は、iPadでもiPhoneのどちらも動作保証されています。

標準準拠のメールクライアントを使ってワークフロー通知を承認するには
Oracle WorkflowはE-Business Suiteのテクノロジースタックの主要な構成要素です。承認待ちのE-Business SuiteのトランザクションをE-Business Suiteのユーザーに通知するメールをSMTP経由で送信するよう構成することができます。E-Business Suiteのエンドユーザーはこうした通知メールに対し、メール中のリンクをクリックするか、返信メールに特定のキーワードを含めて送信することで、通知メールに対応できます。

Windowsデスクトップベースのメールクライアント(Microsoft Outlookなど)を使い、WorkflowやE-Business Suiteの通知機能をテストしています。Apple MailアプリケーションをiOSの動作保証の一環でテストしました。現在のところその他のモバイルデバイス(Android、BlackBerry Emailなど)でのWorkflow通知メールのテストは実行していません。

標準準拠のメールクライアント(モバイルデバイスを含むメールクライアント)はWorkflow通知メールを適切に処理できると想定しています。一部のモバイルメールクライアントでは標準ベースのメールを取り扱うことが出来ず、他のメールクライアントでは長いWorkflow通知メールを切り捨てることがあります。こうした問題のために、モバイルデバイスの特定のメールクライアントは適切にWorkflow通知を取り扱うことができない可能性があります。

スマートフォンやモバイルデバイスでのWorkflowメール通知にて、標準準拠のメールクライアントでは再現できない問題が発生した場合は、後でWorkflow通知を処理することを推奨します。

[参考]技術的に詳しい読者の場合、少なくとも一つのWebベースのメールクライアントが、mailto URLエンコーディングにおける新しい行文字の処理でRFC2368に準拠していないことを知っていることに対し、その内容を聞いてみたいという関心があるかもしれません。こうした問題を抱えるWebベースのメールクライアントはWorkflow通知を適切に処理できないでしょう。一般的なWindowsデスクトップベースのメールクライアントで再現できない、Webベースのメールクライアントで発生する問題に出くわした場合、後でWorkflow通知を処理することを推奨します。

他のモバイルデバイスはどうなの?
他のモバイルデバイスは現時点ではまだ動作保証していません。E-Business SuiteクライアントとしてAndroidベースのデバイスを展開するプランが貴組織にある場合には、詳細をお知らせ下さい。現在Androidのfragmentationまわりの複雑性に取り組んでいますので、皆様の要求を検討することは参考になると考えています。

参考
関連エントリ

[Cloud] Oracle Cloud Development with NetBeans and Eclipse (OEPE)

原文はこちら。
https://blogs.oracle.com/javatraining/entry/oracle_cloud_development_with_netbeans

Oracle Cloud開発シリーズを続けてきて、新たに5個のチュートリアルを作成しました。これらのチュートリアルは、Oracle CloudにNetBeansやOracle Enterprise Pack for Eclipse (OEPE) を使ってJava EEアプリケーションを開発、デプロイする方法を説明するものです。チュートリアルでは、Oracle Java Cloud ServiceやOracle Database Cloud Serviceと、これらのすばらしいIDEのうちの一つを使ったアプリケーション開発を説明しています。
Oracle Java Cloud Service
https://cloud.oracle.com/mycloud/f?p=service:java:0
Oracle Database Cloud Service
https://cloud.oracle.com/mycloud/f?p=service:database:0
NetBeansシリーズでは、NetBeansを構成しプラグインからOracle Cloudを使い、JSF/JPAアプリケーションやアプリケーションで使うデータを作成し、Oracle Cloudにデプロイする方法を学んで頂けます。
Developing Applications for Oracle Cloud Using NetBeans Series
http://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:6945,2
OEPEシリーズでは、OEPE(Eclipse Junoとextensionを使用)を構成し、OEPEで作成したADFアプリケーションを修正の上、Oracle Cloudにデプロイする方法を学んで頂けます。
Developing Applications for Oracle Cloud Using OEPE (Eclipse) Series
http://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:7026,2
是非、Oracle Learning Libraryにある、Oracle Cloud用の無料のチュートリアルやリソースをチェックして下さい!
Oracle Learning Library
https://apex.oracle.com/pls/apex/f?p=44785:2:0:::2:P2_TAGS:Cloud

2013年3月22日

[Coherence] Oracle Coherence Special Interest Group Presentations Published

原文はこちら。
https://blogs.oracle.com/OracleCoherence/entry/oracle_coherence_special_interest_group1

2012年11月15日、ロンドンのCoherence Special Interest Group(CSIG)で数多くのすばらしいプレゼンテーションがあり、これらを録画することができました。そしてこのたび、YouTube Channelに動画をUpし、新しいCSIGプレイリストに追加しました。
November 15th 2012, London, UK -  Coherence Special Interest Group
http://coherence.oracle.com/display/CSIG/15+November+2012+-+London%2C+UK
Oracle Coherence YouTube Channel
http://www.youtube.com/oraclecoherence
Coherence Special Interest Group
http://www.youtube.com/playlist?list=PLxqhEJ4CA3JubAjL-KCkdKmAPiKdNsBYt
以下のコンテンツが含まれています。
  • Oracle Event Processing and Oracle Coherence (Phil Aston, Technical Director, Oracle)

  • Evolving the Evolvable in Coherence (Aleksander Seović, Solutions for Human Capital)
  • Oracle Coherence Pivot Tables (Jonathan Knight, TheGridMan)
  • Oracle Coherence MessageBus (Rob Lee, Coherence Architect, Oracle)
CSIGに参加すると、Coherenceや製品をとりまく活発なコミュニティで起こっていることを知ることができます。Coherenceのエンジニアやアーキテクトに出会ったり、他のCoherenceユーザーやお客様ととつながったりしましょう。近日開催のイベントはWikiをご覧下さい。
Coherence Special Interest Group (Coherence Wiki)
http://coherence.oracle.com/display/CSIG/Home

[Java] Java Magazine March/April: Java Is Community

原文はこちら。
https://blogs.oracle.com/java/entry/java_magazine_march_april_2013

Java Magazineの3/4月号はコミュニティを特集しています。
Java Magazine 3/4月号
http://www.oraclejavamagazine-digital.com/javamagazine/20130304#pg1
[訳注]
もしご覧いただけない場合は、以下のURLから最新刊をご覧下さい。
http://www.oracle.com/technetwork/java/javamagazine/index.html
活発なコミュニティがJavaテクノロジーとJava言語に不可欠です。コミュニティへの参加の第1歩から、指導者の地位をとったり、イベントを開催したりするに至るまでの、Javaシチズンシップへの実践ガイドを提供します。Hackathonをホストする方法やJava Championになる方法、JUGを復活させる方法などを学んで下さい。
mag cover
3/4月号では、"by and for the Java community"というタグラインを喜んで受け入れました。今号では、史上初のゲストエディターであるAgnes Crepetという、Lyon JUGのリーダーでありDuchessのリーダーを特集しています。Agnesは偉大な人材であり、Java Magazineの3/4月号の編集を手伝ってくれました。彼女がストーリーのアイデアを提案しJUGの再活性化に関する記事を書き、プロセスを通じてガイドしてくれました。彼女が熱狂的にゲスト·エディターになることに同意したのは、現在活動中のJavaコミュニティの別の好例でもあります。多くの他のコミュニティメンバーは、この号を成功させるために協力してくれました。非常に感謝しております。

またこの号では、以下の内容も取り扱っています。
  • Java In Robotics — Meet Java pioneer Paul Perrone and some of his robots.
  • Using Java 8 Lambda Expressions — We continue our series on exploring lambda expressions.
  • Responsive Interportlet Communication with Ajax — Build portlets that communicate with each other and update dynically on the client.
  • JavaFX in Spring — Stephen Chin uses Spring to build out data screens in a JavaFX application.
Java Magazineは無料の隔月刊でオンラインでご覧いただけます。Java Magazineでは、Java言語やプラットフォームの技術記事、Javaの進化ならびにイノベーター、JUGやJCPのニュース、Javaのイベント、オンラインのJavaコミュニティへのリンク、動画やマルチメディアデモなどの情報を掲載しています。購読は無料ですが、登録が必要です。
Get Java Magazine!(登録もできます)
http://www.oracle.com/technetwork/java/javamagazine/index.html
Java Magazineに対するフィードバックがあれば、是非 @oraclejavamag にTweetしてください。

[Linux, Education] Harness Oracle Linux Performance with System Administration Training

原文はこちら。
https://blogs.oracle.com/linux/entry/harness_oracle_linux_performance_with

Oracle Linuxシステム管理のトレーニングコースを受講して、Oracle Linuxのパフォーマンスや拡張性、信頼性を生かしましょう。
Oracle Linux System Administration
http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=609&p_org_id=1001&lang=WW&get_params=dc:D74508GC10,p_preview:N
この5日間のコースでは、以下のことを身につけることができます。
  • Kspliceを使い、実行中のシステムのカーネルを更新する
  • Oracle Database用にOracle Linuxを準備する
  • Oracle Linuxをインストール、実行し、Unbreakable Enterprise Kernelを構成する
  • Unbreakable Linux Networkや他のリポジトリからソフトウェアパッケージをインストールする
  • システム・ログを構成する
  • カーネルモジュールをロードし、カーネルモジュール・パラメータを構成する
  • ユーザーやグループの管理を行う
  • ファイルシステムを作成する
  • スワップ領域をメンテナンスする
  • 論理ボリュームマネージャ(LVM)を使う
  • RAIDデバイスを構成する
  • ネットワークやネットワークサービス(DHCP、DNS)を構成する
  • ファイル共有サービス(NFS、Samba、FTP、OpenSSH)を構成する
  • ディレクトリや認証サービス(NIS、LDAP、Winbind、Kerberos)を構成する
  • セキュリティ管理を行う(SELinux、iptables、chroot、TCP wrappers)
このインストラクターによるトレーニングは、以下の形態で提供します。
  • Live-Virtual Event: このコースにみなさんの机から参加します(旅費は不要です)。上記リンクからスケジュールをご覧になり、様々な時間帯にあうスケジュールから選択してください。
  • In-Class event: 教育センターでの集合研修です。すでに予定が決まっているのは以下の通りです。
場所
日付
言語
 Vienna, Austria
 2013/6/24
 German
 London, England
 2013/5/20
 English
 Dortmund, Germany
 2013/4/8
 German
 Hamburg, Germany
 2013/5/13
 German
 Munich, Germany
 2013/1/24
 German
 Utrecht, Netherlands
 2013/5/27
 English
 Warsaw, Poland
 2013/5/13
 Polish
 Bucharest, Romania
 2013/5/27
 Romanian
 Istanbul, Turkey
 2013/5/27
 Turkish
 Tokyo, Japan
 2013/7/1
 Japanese
 Petaling Jaya, Malaysia
 2013/5/27
 English
 Makati City, Philippines
 2013/4/8
 English
 Singapore
 2013/4/15
 English
 Gabarone, Botswana
 2013/4/24
 English
 Nairobi, Kenya
 2013/4/15
 English
 Canberra, Australia
 2013/5/20
 English
 Melbourne, Australia
 2013/6/24
 English
 Sydney, Australia
 2013/5/20
 English
 Mississauga, Canada
 2013/4/29
 English
 Beaverton, IL, United States
 2013/8/12
 English
 Chicago, IL, United States
 2013/5/13
 English
 New York, NY, United States 
 2013/6/17
 English
 Reston, VA, United States 
 2013/4/15
 English
 Roseville, MN, United States
 2013/4/8
 English
 San Antonio, TX, United States
 2013/7/15
 English
 San Francisco, CA, United States
 2013/7/15
 English
 Schamburg, IL, United States
 2013/8/26
 English
 Southfield, MI, United States
 2013/4/22
 English

このコースや他のLinuxのコースに関する詳細は以下のリンクからどうぞ。
Linux Administration (Oracle University)
http://oracle.com/education/linux.

2013年3月21日

[BPM] New BPM Papers: Transforming Customer Experience & Cooking up successful business process management & BPM in Utility

原文はこちら。
https://blogs.oracle.com/soacommunity/entry/new_bpm_papers_transforming_customer

(新しいとは言いづらいのですが)BPMに関する以下の3種類のホワイトペーパーをご紹介します。

[misc.] UPK Player Optimized for Apple iPad

原文はこちら。
https://blogs.oracle.com/UPK/entry/upk_player_optimized_for_ipad

UPK PlayerがApple iPadに最適化されたビューを持っていること、ご存知でしたか?この機能はUPK 11.1. ESP 1(11.1.0.1)で導入されました。一番いいところは、コンテンツの変更や、iPadユーザーに別のリンクを知らせる必要がない、ということです。単にUPK 11.1 ESP1でコンテンツを作成し、iPadでコンテンツにアクセスすれば、iPadに最適化された目次が確認できます。
UPK Player on iPad
iPadに最適化された目次から、タップしてコンセプトを呼び出して、"See It!"モードでご覧頂いたり、"Try It!"モードで操作したり、"Print It!"でドキュメントを開いたりできます。
iPadでPlayerを動作させる方法に関する追加情報は、以下のリンクからご覧頂けます。
Player Content on iPad (UPK 11.1.0.1 Documentation Library)
http://docs.oracle.com/cd/E36145_01/PlayerPackage/data/tpc/b3cf1414-1384-4aba-b6f6-21fa90f25685/lmstart.html?dhtml
UPKをモバイルデバイスで使う上ためのわくわくするようなプランをたくさん考えていますが、モバイルデバイスでUPKコンテンツをどのように利用したり、配信したりしたいか、是非聞かせて下さい。是非コメント欄からお知らせ下さい。
[訳注]
是非原文にコメントお願いします。

[Hardware] More on the March 26 Webcast: "New SPARC Servers with the World's Fastest Microprocessor"

原文はこちら。
https://blogs.oracle.com/solaris/entry/more_on_the_march_26

もし、 2010年3月にOracleが「世界最速のマイクロプロセッサー」について発表していたら、頭をかきむしっていたことでしょう。
SPARC T3がその年の後半に出てきたことがわかり、これまでのUltraSPARC T2の性能を大きく上回っていました。「前世代のSPARC Tシリーズに比べて性能が2倍に増加」していましたが、誰も業界最速とは言いませんでした。
Oracle Unveils SPARC T3 Processor and SPARC T3 Systems (2010年9月20日のNews Release)
http://www.oracle.com/us/corporate/press/173536
しかし注目すべきことは、Sun買収の際に発表されたSPARCのロードマップにリリース日と性能が一致していた、ということです。こういうことは現実にはあまりあり得ないことです。

もし、2011年3月にOracleが「世界最速のマイクロプロセッサー」を発表していたら、それでも懐疑的だったかもしれません。
しかしさらにもう一度、数ヶ月後にSPARC T4を発表しました。これはJavaのパフォーマンスで世界記録を樹立しました。そして、2010年のSPARCのロードマップに一致していただけでなく。T3のすばらしい性能レベルを上回っていたのです。
Oracle Launches Next Generation SPARC T4 Servers(2011年9月26日のPress Release)
http://www.oracle.com/us/corporate/press/497230
で、2013年3月です。しかもイベントのタイトルは、「Announcing New SPARC Servers with the World’s Fastest Microprocessor」です。
かなり大胆ですね、でも最近のSPARCの歴史で起こったことを考えると、3年前のように耳を疑うようなことでしょうか?
是非イベントに参加して知って下さい。

Oracle Live Event: Announcing New SPARC Servers with the World's Fastest Microprocessor
2013年3月26日13時(PDT) / 16時 (EDT)

(訳注)日本時間では2013年3月27日5時から
参加登録は以下のリンクからどうぞ。
[Webcastの登録]
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=165654&src=7618691&src=7618691&Act=915
[訳注]
Oracle Conference Centerで開催されるイベントもあります。
日時:2013年3月26日12時(PDT) / 15時 (EDT)
こちらに参加される方は以下のリンクからどうぞ。
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=165644&src=7662982&src=7662982&Act=71

[AIA, SOA, FMW] New Oracle Foundation Pack pages on OTN

原文はこちら。
https://blogs.oracle.com/aia/entry/new_advanced_oracle_foundation_pack

OTNに新しいOracle Foundation PackのWebページがUpされました。これらの新しいページには、ホワイトペーパーやプレゼンテーション資料、記事、ブログエントリなどの有用な情報が含まれています。
主要な2個のWebページをご紹介します。

2013年3月19日

[SOA] OASIS SOA reference architecture

原文はこちら。
https://blogs.oracle.com/soacommunity/entry/oasis_soa_reference_architecture

このドキュメントはOASIS Reference Architecture Foundation for Service Oriented Architecture (SOA-RAF)を規定しています。OASIS Reference Model for Service Oriented Architectureで定義されているコンセプトや関連だけでなく、他の組織で実施された成果から導かれたものです。概念的ではありますが、現在の文書では、特定のSOAの具体的なアーキテクチャを構築するための基盤を説明しています。
SOA-RAFは、サポートに必要な情報技術とビジネスを統合するアプローチに主眼に置いています。これらの問題は常に存在しますが、ビジネスの統合がオーナーシップの境界を越える場合に特に重要なものになります。すべてのSOAアーキテクト必読の書ですね。
OASIS Reference Architecture Foundation for Service Oriented Architecture Version 1.0
http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra.pdf

2013年3月17日

[Database, Security] Finding Oracle Database Security Information

原文はこちら。
https://blogs.oracle.com/securityinsideout/entry/resources_to_help_address_your

セキュリティのプロが直面する多くの問題の一つは、特定のセキュリティの問題に対する情報を見つけ出すことです。Oracleには総合的なデータベースセキュリティの多重防御ソリューションに関連するリソースがたくさんあります。簡単に言うと、探索中の特定の情報を見つけ出すのは難しいことがあるので、ここに主要なリソースをまとめておきます。

製品情報

顧客事例

イベント、トレーニング

アナリストレポート、ニュース、ソーシャルメディア

関連資料

[Java] EJB 3.2 Proposed Final Draft is available for review

原文はこちら。
https://blogs.oracle.com/marina/entry/ejb_3_2_proposed_final

EJB 3.2のリリースに向け、最後の直線を走っています。PDFドキュメントやJavadocはJCPのページやJava.netのプロジェクトのページからダウンロードできます。
JSR-000345 Enterprise JavaBeansTM 3.2 (Proposed Final Draft)
http://jcp.org/aboutJava/communityprocess/pfd/jsr345/index.html
ENTERPRISE JAVABEANS 3.2 Downloads (ejb-spec)
java.net/projects/ejb-spec/downloads
大きな変更点は以下の通りです。
  • EJB APIグループ(詳細は16.1をご覧下さい)
  • メソッドを持たないメッセージリスナーインタフェースを持つMDBのサポート(詳細は5.4.3をご覧下さい)
  • セキュリティロール"**"が定義されたコンテナ(詳細は12.3.1をご覧下さい)
以下は変更履歴に記載されている通り、パブリックドラフトからの仕様変更です

[訳注]
変更履歴に記載があるため、以下の日本語化は省略しています。

2013年3月16日

[Java] AutoCloseable JMS 2 Resources

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/autocloseable_jms_2_resources

Java EE 7のリリース日が近づくにつれ、新機能を扱うブログや記事が出てき始めています。以下のエントリでは、John Amentという、JMS 2.0専門家グループの主要な独立メンバーが、自動的にリソースをクローズ(AutoCloseable)するJMS 2.0リソースについて説明しています。
What's New in JMS 2 (Part 1)
http://john-ament.blogspot.se/2013/03/whats-new-in-jms-2-part-1.html
この機能はJava SE 7のtry-with-resourcesを利用しており、JMSリソース(接続、セッション、メッセージコンシューマやメッセージプロデューサ)のクリーンナップが非常に簡単になっています。
The try-with-resources Statement
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
@Injectを使って新しいJMS Context APIを利用していない非Java EE環境ではこの機能は特に重要です。先ほどのエントリにはJMS 2.0のコードサンプルも含まれています。JohnはJMS 2.0に関するブログエントリを今後たくさん書く予定なので、期待してお待ち下さい。
JMS 2.0って何?という方のために、JMS 2.0は現時点でhは最終ドラフトが提示された段階にあります。ドラフト仕様を自由にダウンロードしてご覧頂くことができます。ドキュメントの最初の部分で「What is new in JMS 2.0?」というセクションがあり、そこで非常に簡潔にJMS 2.0についてまとめられています。
JSR-000343 Java(tm) Message Service 2.0 Proposed Final Draft
http://download.oracle.com/otndocs/jcp/jms-2_0-pfd-spec/index.html

2013年3月15日

[Java] JavaSE 7 Try-with-Resources Refactoring Hints

原文はこちら。
https://blogs.oracle.com/binkyscave/entry/javase_7_try_with_resources

最近、Oracle Technical Network Java Developer Daysで実施するJava SE 7のHands-onコンテンツのアップグレードを完了しました。このHands-onの目的の一つとして、Project CoinとNIO2といったJava SE 7の新機能を参加者に伝えることがあります。その他の目的は(これはちょっと微妙な目的ではありますが)、NetBeans IDEとそのリファクタリング機能をお伝えするというものです。さらに、アップデートの発表の最近のJavaSE 6のアップデート終了の発表に伴い、Java SE 7にアップグレードするのに併せてご自身のコードをアップグレードすることを考えてらっしゃる方に対し、リファクタリングのヒントをご案内するよい機会というのもあります。

まずはじめに

Java SE 7以前のHands-onの元々の課題は以下のようでした。
private static void tryWithResource6c() {
        System.out.println("TESTING TRY WITH RESOURCES 6c");
        UglyCloser closer1 =  new UglyCloser("First closer");
        UglyCloser closer2 =  new UglyCloser("Second closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
            closer1.close();
            closer2.close();
        } catch (Exception ex) {
            // quietly ignore
        }
        fakeAssert(closer1.isClosed(), "Closer1 should be closed");
        fakeAssert(closer2.isClosed(), "Closer1 should be closed");
    }
「try-with-resourcesの形式に変換」する候補であることを示すリファクタリングのヒント(黄色の三角形”!”のアイコンを持つ小さな電球)が、コードの行番号の隣に出てくるものと思っていましたが、そのようなアイコンが現れませんでした。リファクタリングが推奨されるコードの種々のパターンを試す必要があるようなので、上記コードのいくつかのバリエーションでリファクタリングする方法の○と×を確認してみました。

例1:
以下のコードでは、リファクタリングのヒントが現れます。
private static void tryWithResource2a() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
         } catch (Exception ex) {
             // quietly ignore
         } finally {
             closer1.close();
         }

      }
期待通りに、以下のようにリファクタリングされます。
private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        try (UglyCloser closer1 = new UglyCloser("First closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }

    }
例2:
しかし、try-finallyブロック外でオブジェクト参照している場合はリファクタリングされません。まぁ、わからなくもないです。
private static void tryWithResource2() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
         } catch (Exception ex) {
             // quietly ignore
         } finally {
             closer1.close();
         }
         fakeAssert(closer1.isClosed(), "Closer1 should be closed");
      }
ここで重要なのは、現在のtry-with-resourceの形式では新しいリソース変数を使うということです。try-finallyの外部で変数への参照がある場合、こうした参照はスコープ外になります。この例は、実世界のコードで存在する可能性は低いのですが、コード変換時にスコープ外のリソース変数を探すことを考慮すべきでしょう。

例3:
奇妙なことに、finally節を削除するとリファクタリングされません。closer1を永久に閉じていないので、これはおそらくまずいコードだと思うのですが…
private static void tryWithResource2b() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
         } catch (Exception ex) {
             // quietly ignore
         }
      }
この例ではfinally節にcloseがなく、実際にコード・セマンティクスの変更があります。Java SE 6以前では、自動クローズ機能がないということを忘れないで下さい。おそらく、オリジナルコードのプログラマーは間違えてcloseを呼び出さなかったか、もしくは意図的にcloseを使わずに脱出していたのでしょう。いずれの場合においても、さらなる分析が必要です。

例4:
同様に、try文でオブジェクトをcloseすると、closeされません。
private static void tryWithResource2b() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
             closer1.close();
         } catch (Exception ex) {
             // quietly ignore
         }
      }
この例では、プログラマが何を考えているのかわかりません。プログラマー側でcloseを呼び出そうとして失敗したのかもしれないし、tryの中にcloseがあることが重要なのかもしれません。この時点では選択の余地がありませんが、リファクタリングの際には、プログラマがどうしたかったのかを考慮する必要があります。

例5:
最後に、try-catchブロック内で複数のオブジェクトを取り扱う場合、一つだけがリファクタリングされますが、これはおそらくNetBeansのバグでしょう。もちろん、上記のすべての単一バリアントの中断も適用されます。
private static void tryWithResource1a() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         UglyCloser closer2 =  new UglyCloser("Second closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
             fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
         } catch (Exception ex) {
             // quietly ignore
         } finally {
             closer1.close();
             closer2.close();
         }
     }
以下のようにリファクタリングします。
private static void tryWithResource6b() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6a");
        UglyCloser closer1 =  new UglyCloser("First closer");
        try (UglyCloser closer2 = new UglyCloser("Second closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
        } catch (Exception ex) {
            // quietly ignore
        } finally {
            closer1.close();
        }
    }
これはcloser1がリファクタリングされておらず、部分的なリファクタリングです。おそらくNetBeansのバグではないかと思いますが、もしtry-with-resourcesを最大限に活用したい場合には、手作業でのリファクタリングを追加する必要があります。

新しいHands-onでは…

Hands-onのコンテンツのために、try-catchブロックのリファクタリングで予想される3種類のリファクタリング体験をご紹介しましょう。

1. 完全なリファクタリング
private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        UglyCloser closer1 =  new UglyCloser("First closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        } finally {
            closer1.close();
        }
     } 
以下のようにリファクタリングされます。
private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        try (UglyCloser closer1 = new UglyCloser("First closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
    }
2. 部分的なリファクタリング
private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        UglyCloser closer1 =  new UglyCloser("First closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        } finally {
            closer1.close();
        }
     } 
以下のような不完全なリファクタリングではなく
private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        try (UglyCloser closer1 = new UglyCloser("First closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
     } 
手作業で以下のように変更する必要があります。
private static void tryWithResource6b() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6b");
        try (UglyCloser closer1 = new UglyCloser("First closer");
                UglyCloser closer2 = new UglyCloser("Second closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
    }
3. リファクタリングしない
private static void tryWithResource6c() {
        System.out.println("TESTING TRY WITH RESOURCES 6c");
        UglyCloser closer1 =  new UglyCloser("First closer");
        UglyCloser closer2 =  new UglyCloser("Second closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
            closer1.close();
            closer2.close();
        } catch (Exception ex) {
            // quietly ignore
        }
        fakeAssert(closer1.isClosed(), "Closer1 should be closed");
        fakeAssert(closer2.isClosed(), "Closer1 should be closed");
    }
手作業で以下のようにリファクタリングする必要があります。
private static void tryWithResource6b() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6b");
        try (UglyCloser closer1 = new UglyCloser("First closer");
                UglyCloser closer2 = new UglyCloser("Second closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
    }

まとめ

このHands-onで使われない部分ですが、ご自身のコードのtry-catchブロックをJava SE 7用にリファクタリングする必要が出てきた場合、結果を確認する必要があります。あなたは幸運にも完全なリファクタリングを実施しているかもしれません。リソースを1個だけ使用している場合は一般的に正しくリファクタリングされているでしょうが、複数のリソースを使用している場合、ツールによるリファクタリングに対し、手作業の追加が必要になるでしょう。try-catchブロックのスコープ外のリソースの場合は、手作業でのリファクタリングが必要になるでしょう。