2014年12月29日

[SOA/BPM] SOA Suite 12c: Topology Suggestions

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

このエントリでは、よく使われ、サポート対象のSOA Suite 12cのトポロジーに関する提案と選択肢をご紹介します。Enterprise Deployment Guide(EDG)トポロジーだけはOracleが徹底的にテストをしてはいますが。
  • トポロジーを決める上で考慮すべきことは、アップグレードは常にドメイン単位である、ということです。ドメインにデプロイされたすべての製品が同じリリースタイミングで公開する必要があり、同時にすべての製品をアップグレードすべきです。
  • 2個の異なる製品を同一ドメインに配置する理由として、管理の集中化は一つの要素ではありますが、それが唯一の理由であってはいけません。管理の集中化に対するソリューションとして、Enterprise Manager Cloud Controlを利用できるからです。
  • 通常、Service BusとSOA SuiteはEnd-to-Endのアーキテクチャにおいて異なる層にあり、そのため異なるドメインに配置します。これはService Busが、複数のSOAドメインや他のサービスへのエンタープライズ規模でのルーティングに利用される場合は正しいのですが、Service Busが主としてドメイン内のSOA SuiteコンポジットへのMediationやルーティングを提供するために使われている場合、同一ドメインに存在する場合があります。しかしながら、最適なパフォーマンスやスケーラビリティのために、通常は別のクラスタに配置します。12cではService BusとSOA Suiteを同一クラスタに配置し始動することができます。この構成を採用するにあたって可能性のある唯一の理由は、メモリ使用量を削減するというものですが、一般的ではありません。
  • Oracle Enterprise Repository(OER)やUDDIなどガバナンス製品は、SOA SuiteやService Busドメインに含めず、別ドメインに配置すべきです。OERはUDDIと異なるドメインに配置すべきです。UDDIは3rdパーティ製品であり、同一ドメインに配置するとアップグレード時に問題が発生する可能性があります。
  • ユーザーが拡張可能なサーバーグループをクラスタ内のサーバに適切に割り当てることにより、複数の製品を同一クラスタに配置することができます。
    1. SOA Suiteの場合、サーバーグループとしてSOA-MGD-SVRSもしくはSOA-MGD-SVRS-ONLYを使います。
    2. Service Busの場合、サーバーグループとしてOSB-MGD-SVRS-COMBINEDもしくはOSB-MGD-SVRS-ONLYを使います。
    3. BAMの場合、サーバーグループとしてBAM12-MGD-SVRSもしくはBAM12-MGD-SVRS-ONLYを使います。
    4. MFTの場合、サーバーグループとしてMFT-MGD-SVRSもしくはMFT-MGD-SVRS-ONLYを使います。
    5. ESSの場合、サーバーグループとしてESS-MGD-SVRSを使います。
  • BAMをSOA Suiteの外部で使う場合、通常はSOA Suiteとは別のドメインにしますが、SOA Suiteインスタンスとともに利用することが主な場合は、SOA Suiteと同一ドメインの異なるクラスタにBAMを配置すべきです。BAM 12cでは、SOA SuiteとBAMの統合が緊密になっており、同一ドメインに配置することが最良です。BAMとSOA Suiteを同じクラスタに共存させるべきではありません。それはHA構成時にはBAMが自動サービス移行するのに対し、SOA Suiteはサーバー全体の移行を使うためです。
  • Oracle Web Services Manager Policy Manager(OWSM PM)はドメインの一つのクラスタにのみデプロイしなければなりません。しかし、SOA Suite、OSB、BAM、MFTテンプレートはデフォルトで各コンポーネント自身のクラスタにOWSM PMをOWSM PMに配置することを前提としています。
    1. このような異なるクラスタを持つドメインの場合、OWSM PMをEDGにあるようにOWSM PM自身のクラスタに配置してください。JRFと2個のOWSM PMに関係するサーバーグループをこのクラスタに指定できます。
    2. サーバーグループとしてデフォルトのSOA-MGD-SVRSを指定した場合、OWSM PMは自動的にSOAクラスタに配置されます。しかし、OWSM PMがすでに別のクラスタに存在する場合、サーバーグループとしてSOA-MGD-SVRS-ONLYを指定し、SOA SuiteをSOAクラスタに配置してください。
    3. サーバーグループとしてデフォルトのBAM12-MGD-SVRSを指定した場合、OWSM PMは自動的にBAMクラスタに配置されます。しかし、OWSM PMがすでに別クラスタに存在する場合、サーバーグループとしてBAM12-MGD-SVRS-ONLYを指定し、BAMをBAMクラスタに配置してください。
    4. サーバーグループとしてデフォルトのOSB-MGD-SVRS-COMBINEDを指定すると、OWSM PMは自動的にService Busクラスタに配置されます。しかしOWSM PMがすでに別のクラスタに存在する場合、サーバーグループとしてOSB-MGD-SVRS-ONLYを指定し、Service BusをService Busクラスタに配置してください。
    5. サーバーグループとしてデフォルトのMFT-MGD-SVRSを指定すると、OWSM PMは自動的にMFTクラスタに配置されます。しかしOWSM PMがすでに別のクラスタに存在する場合、サーバーグループとしてMFT-MGD-SVRS-ONLYを指定し、MFTをMFTクラスタに配置してください。 
    6. ESSはOWSM PMがドメイン上に存在する必要がありますが、ESS自体はOWSM PMをターゲットにしていません。
  • ESSの配置にあたっては以下のガイドラインに従ってください。
    1. Service Busのみのドメインの場合、ESSは通常Service Busクラスタに配置します。
    2. SOA Suiteのみのドメインの場合、ESSは通常SOA Suiteクラスタに配置します。
    3. SOA SuiteとService Busとも異なるクラスタに存在する場合、ベストプラクティスはESSをESS自身のクラスタに配置することです。
    4. MFTは常にMFTクラスタにESSのプライベート・コピーを有しています。これは、SOA SuiteとService Busで利用するために追加でデプロイされるESSとは無関係です。
    5. ESSは現在スタンドアロン・スケジューラとしての位置づけではなく、SOA SuiteやService Busのためのスケジューラとしての位置づけであり、同じドメインに配置すべきです。
  • MFTは通常SOA SuiteやService Busとは別のドメインに配置しますが、同一ドメインの異なるクラスタに配置することができます。
  • ベストプラクティスは、Healthcare IntegrationやB2B用の別のドメイン、SOA SuiteとB2B用の別のドメインを利用することです。これはB2BとHealthcare Integrationのドキュメントに記載があります。

2014年12月28日

[Applications] Siebel theme demo with Alta UI styling

原文はこちら。
https://blogs.oracle.com/SiebelOpenUI/entry/siebel_theme_demo_with_alta

Siebel Open UIはCRMアプリケーションの新しいユーザー体験を作成するための能力や柔軟性を提供します。Open UIを使うと、CRMアプリケーションも簡単にコーポレートブランディングに整合することができます。Siebelチームの同僚と一緒に、新しいテーマをシンプルな手順でSiebelアプリケーションに簡単に追加できる様子をご紹介する動画を作成しました。
この例では、先日Oracleのクラウドおよびモバイルアプリケーション製品群向けに発表された、新しいクールなOracle Alta UIスタイルをSiebelに適用することにしました。
Alta UI Gallery & Patterns
http://www.oracle.com/webfolder/ux/middleware/alta/gallery/homePages/browser.html
Siebel CRMはOracle Sales Cloudと統合されており、もしかすると両アプリケーションに対しAlta UIスタイルを使って、よりシームレスなユーザー体験を作成したいと思われるかもしれません。
以下の動画をご覧いただくとともに、正確な手順をご紹介しましょう。



ここから、Siebelテーマ、ここでは新しいAlta UIテーマを展開する正しい手順をご紹介します。
  1. カスタムcssを作成する(通常Web開発者が好みのスタイルを作成するために実施する)。
  2. カスタムcssファイルを PUBLIC/<Language>/FILES/custom フォルダにコピー
  3. Manifest Filesビューにて該当するファイルパス(大文字・小文字を区別、ファイルフォルダで始まる)を使ってカスタムcssファイルを登録する。
  4. カスタムテーマをユーザー・プリファレンスで選択し、Manifest ExpressionsビューでカスタムExpressionを登録する(既存のManifest Expressionテーマのレコードをコピーし、それを編集するのが最も簡単)。
  5. マニフェスト管理ビューでアプリケーションテーマに対しカスタムPLATFORM DEPENDENTエントリを登録する(既存のテーマ・レコードをコピーしそれを編集するのが一番簡単)。
    1. Object Expression List Appletで新しいカスタム式を関連付ける
    2. File List Appletでベース(Aurora)のcssファイルを関連付ける
    3. File List Appletで新しいカスタムcssファイルを関連付ける(順序が重要です。順序1、ベース、拡張子、そして順序2)
  6. カスタムテーマ用に新しいLOV(List Of Values)エントリを作成する(既存のテーマのLOVレコードをコピーし、適切なLICエントリを用いて編集するのが一番簡単)。LOVキャッシュをクリアする。
  7. ログオフしてマニフェストシステムのキャッシュをクリアし、再度ログインする
  8. [User Preferences]>[Behavior]へ移動する
  9. カスタムテーマを選択し、設定を保存する
  10. F5を押してページを再読み込みする
新しいテーマをご自身で試してみたいという場合には、Siebel Alta UIテーマをこちらからダウンロードできます。

2014年12月26日

[FMW, MFT] Customizing Oracle MFT File Rename Java Callout

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

Review and Use Case

それでは、このCustomizing MFTシリーズの前回の概要エントリをすべて理解されたことかと思うので、カスタムアクション(コールアウト)というコンポーネントを完全に理解し、Oracle MFTドキュメントの「Processing Transfers with Custom Callouts」の章にある、改行文字の変換サンプルをビルドされ、MFTエンジン内部でファイル名を変更するしくみを実装するという、別の現実世界のシナリオを作成する準備が整っているはずです。
Customizing Oracle MFT with Java Overview
https://blogs.oracle.com/SOA/entry/customizing_oracle_mft
http://orablogs-jp.blogspot.jp/2014/12/customizing-oracle-mft-with-java.html
Oracle® Fusion Middleware Using Oracle Managed File Transfer
Processing Transfers with Custom Callouts
Understanding Custom Callouts
https://docs.oracle.com/middleware/1213/mft/MFTUG/mftug_exts.htm#MFTUG4266
内部と言っているのは、ファイルをファイルシステムに書き出す、もしくはリモートFTPサーバに書き出し、配信後にファイル名を変更するユースケースと区別するためです。このユースケースは、ソースから流入するファイルの名前にタイムスタンプのような余分な文字が含まれている場合に、標準のJavaの正規表現を使って取り除くというものです。つまり、order20151011.xmlをorder.xmlに変更したり、customer12345.csvをcustomer.csvと変更します。

Components

XML Config File

ご存じのように、コールアウト・アクションにはそれぞれインターフェースを定義するXMLの設定ファイルが必要です。以下はこのサンプルの設定ファイルで、アクション名、ライブラリ名、ヘルプテキスト、デザイナで設定されるパラメータなどを定めています。このサンプルをターゲット前処理で使います。2個のパラメータ(SourceExpとReplaceWith)を使います。コールアウト設定ファイルの構成方法の詳細は前回のエントリで説明していますので、理解が不明瞭であれば再読してください。先へ進むため、とりあえずファイルを以下のリンクからダウンロードするか、お気に入りのテキストエディタに以下のXMLをコピー&ペーストして、RenameRegesp.xmlという名前で保存し、そのファイルをRenameRegespというフォルダを新規作成し保存してください。
RenameRegexp.xml
https://blogs.oracle.com/SOA/resource/mftblog/RenameRegexp.xml
<?xml version="1.0" encoding="UTF-8"?>
  <mft:Callouts xmlns:mft="http://xmlns.oracle.com/mft"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.oracle.com/mft callout.xsd ">
    <mft:Callout description="Rename Regexp" 
      helpText="File Rename with Regular Expressions"
      groupName="Target-pre" timeout="300"
      implementationClass="com.oracle.callout.sample.RenameRegexp"
      libraryName="RenameRegexp.jar" name="RenameRegexp">
    <mft:Parameter description="SourceExp" mandatory="true"
      helpText="Source Regular Expression Pattern" 
      name="SourceExp" parameterType="string"/>
    <mft:Parameter description="ReplaceWith" mandatory="true"
      helpText="ReplaceWith Regular Expression Pattern"
      name="ReplaceWith" parameterType="string"/>
   </mft:Callout>
</mft:Callouts>

Java Source Code

ご存じのように、ソース、ターゲットの前処理、後処理コールアウト用の様々なAPIがあります。この例ではターゲット前処理インターフェースを説明しています。これは以前の改行文字変換であったような、ファイルの内容を変更するものではありません。このトピックを確認したい場合には、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Using Oracle Managed File Transfer
Processing Transfers with Custom Callouts
Java Code Requirements and Tips
https://docs.oracle.com/middleware/1213/mft/MFTUG/mftug_exts.htm#MFTUG4270
このJavaクラスは、実行時にデザイナ転送アーティファクトで設定される正規表現を置換するため、2個の文字列を受け取ります。このサンプルで使われる、ファイル名変更のためのこの新しい興味深いコードは、PluginContext.getTransformedInputFileNameとPluginOutput.setNewFileNameというメソッドです。正規表現の置換は、昔からあって信頼できるString.replaceAllを使い、1行のコードで実装しています。以下がコードスニペットです。
PluginOutput out = new PluginOutput();
oldfname = pluginContext.getTransformedInputFileName() ;
newfname = getNewname(oldfname, SourceExp, ReplaceWith);
if (newfname != null && newfname.length() > 0) { 
    out.setNewFileName(newfname);
}
...
public String getNewname(String oldfname, String srcexp, String repexp) {
        return oldfname.replaceAll(srcexp, repexp);
}
RenameRegexp.javaファイルをダウンロードし、RenameRegexpフォルダ内にcom/oracle/callout/sampleという子ディレクトリを新規作成し、その中に配置してください。
RenameRegexp.java
https://blogs.oracle.com/SOA/resource/mftblog/RenameRegexp.java

Compile, Package and Install

この章では以下の環境変数が設定済みであるとします。
  • $MW_HOME :MFTがインストールされている場所
  • $JAVA_HOME : JDK7がインストールされている場所

Compile

コマンドプロンプトから以下のコマンドを実行します。
$JAVA_HOME/bin/javac -classpath $MW_HOME/mft/modules/oracle.mft_12.1.3.0/core-12.1.1.0.jar com/oracle/callout/sample/RenameRegexp.java

Package

JDKのjarコマンドを使い、javaのjarファイルを以下のように作成します。
$JAVA_HOME/bin/jar cvf RenameRegexp.jar com/oracle/callout/sample/RenameRegexp.class

Install

これは2段階で実施します。まず、jarファイルをMFTサーバのcalloutsフォルダに配置し、続いて設定XMLファイルをインポートします。以下のようにコピーコマンドを使います。ドメイン名は皆さんの環境に合わせて変更してください。
cp RenameRegexp.jar $MW_HOME/user_projects/domains/<Domain_Name>/mft/callouts/
[注意]このコールアウトを使うファイル転送のMFTエクスポートファイルがある場合、これをインポートし、以下のWESTのステップをスキップできます。

続いて、WLSTコマンドを使い、RenameRegesp.xmlファイルをインポートします。
$MW_HOME/mft/common/bin/wlst.sh
WebLogic Serverに対し、ホスト名、ポート番号、管理者の資格証明を使い接続します。
connect("weblogic", "<PASSWORD>, "t3://<host>:<port>")
WLSTのCreateCalloutコマンドで、ファイルの場所を指定します。
  createCallouts('/home/oracle/mft/callouts/RenameRegexp/RenameRegexp.xml')
listCallouts() コマンドを使って正しく設定できたことを確認します。
listCallouts()
exit() コマンドでWLSTを終了します。
exit()

Deploy a Transfer and Test

この章では、Javaの正規表現に関する知識が必要です。この実装はJavaのString.replaceAllメソッドを使用しています。外部ツールを使い、事前に作成された正規表現をテストしておくことをおすすめします。様々なツールが利用可能ですが、MFTデザイナに設定する前に正規表現をテストするためのオンラインツールとして、www.regexplanet.comはなかなかよいと思います。
RegexPlanet - Online Regular Expression (Regex) Testing and Cookbook for: Go, Haskell, Java, JavaScript, .Net, Perl, PHP, Python, Ruby, Tcl & XRegExp
http://www.regexplanet.com/
この例では、以下のパラメータ値を使ってファイルorder20151011.xmlをorder.xmlへと変換するとしましょう。
  SourceExpr:  ([A-z])\d+(.*)
  ReplaceWith: $1$2

Design and Deploy

この時点で、RenameRegexpコールアウト・アクションは転送ターゲット前処理UIに現れており、任意の転送で利用する準備が整っています。デザイナに移動し、"Rename Transfer"という転送を作成します。この転送は、"Rename FTP Source"と"Rename FTP Target"という、ソースとターゲットで構成されています。FTP埋込みソースは"/rename/in"を使い、FTPリモートターゲットは"/rename/out"を使います。転送は以下のようなスクリーンショットになっているはずです。

下のスクリーンショットのように、以下のパラメータを使って、転送の前処理アクションを構成する必要があります。

  SourceExpr:  ([A-z])\d+(.*)
  ReplaceWith: $1$2

保存し、他のOracle MFT転送のようにこの転送をデプロイします。

Test

任意のFTPクライアントを使ってMFT埋込みFTPサーバに接続し、"order20151011.xml"というファイルを"/rename/in"フォルダにコピーします。完了すると、MFT監視コンソールに移動し、以下のような転送レポートを確認します。

おめでとうございます!これで非常に便利かつ設定可能で再利用可能な名前変更のためのカスタム・コールアウトを実装しました。このカスタム・コールアウトは任意の転送ターゲット前処理アクションで利用できますが、たった76行のコードでできています。この転送の完全なエクスポートファイルはこちらからダウンロードいただけます。

2014年12月25日

[FMW, MFT] Customizing Oracle MFT with Java Overview

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

Overview

Oracle MFTは、標準でよく使われるほとんどの機能を提供するよう設計されましたが、十分ではない場合には、ちょっとしたカスタマイズ可能なコードスニペットを使って簡単に拡張できるようになっています。自分で試したいということであれば、Oracle MFTのドキュメントの「Processing Transfers with Custom Callouts」という章に、カスタマイズを始めるにあたって必要なものがすべて用意してあります。
Oracle® Fusion Middleware Using Oracle Managed File Transfer
Processing Transfers with Custom Callouts
Understanding Custom Callouts
https://docs.oracle.com/middleware/1213/mft/MFTUG/mftug_exts.htm#MFTUG4266

このトピックに関する詳細情報が必要であれば、このままお読みください。簡単に言うと、すべてのカスタム・コールアウトは完全に再利用可能であり、パラメータ化されるため、すべての開発投資は概して1回のコストですみます。

Terminology

カスタム・コールアウトには多くのユースケースや種類があります。コールアウトができること、そしてコールアウトを呼び出すタイミングならびに方法を含めご紹介しますが、まずは少々背景と用語についてご紹介します。コールアウトは一般的な用語で、MFTデザイナーページでMFT転送の設定時に使用できるカスタムJavaコードを説明するためために使用される用語です。圧縮・展開、暗号化・復号化のような[アクション]が標準で利用可能であり、カスタム・コールアウトも同様に、[処理アクションの追加]ボタンをクリックすることで添付できます。

ここから先、この記事ではアクションという用語を使いますが、これは標準提供されるアクションとカスタム・コールアウトの両方に適用します。

Types

アクションには一般的に2種類あります。一つはペイロードを変更する必要があるものと、他方はそうでないもの、というものです。ドキュメント内の「改行変換」の例では、ファイルを変更して改行文字をDOSとUnix間で変更する方法を説明しています。このようなアクションは、コンテンツの変更を必要とするため、出力ストリームを提供するPluginOutputを返すメソッドを実装する必要があります。
public PluginOutput process(PluginContext context, InputStream input,
            OutputStream out, Map<String, String> calloutParams) {
ファイルコンテンツの変更が不要なアクションの場合、以下のように、出力ストリームにアクセスしないPuginOutputを返すメソッドで異なるバージョンを実装します。
public PluginOutput process(PluginContext context, InputStream input,
            Map<String, String> calloutParams) {

Invocation Order

アクションは転送の以下のポイントで呼び出されます。それぞれのポイントでのアクションのメリットについて以下でご紹介します。
  1. Source
  2. Pre-Target(前処理)
  3. Post Target(後処理)

Source(ソース)

ソース・アクションをソースアーティファクトページに添付し、そのチャネルですべての流入してくるファイルに対して紐付けられています。チャネルに対する要件が常にPGP暗号化ファイルのみであれば、これはソース側の処理にアクションを追加するよい理由にります。しかしながら、異なるファイルタイプがこのチャネルやフォルダに配信されるのであれば、異なるフォルダを使うか、もしくはターゲットアクションを利用すべきでしょう。

Pre-Target(前処理)

転送フローページでターゲット・アクションを構成しますが、これは任意のソースアクションが完了した後に実行されます。上記の例のように、複数のファイルタイプで単一のフォルダを共有するような場合、fan-outシナリオを別のターゲットで実装して、同じソースを異なる転送でコンテント・フィルタを使って再利用し、異なるファイルタイプを別のターゲットへルーティングすることができます。この例では、一つの転送にはターゲット復号化アクションがあるのに対し、他の転送にはアクションがないため、ファイルを別のターゲットにそのままルーティングします。これは処理済みのファイルを後続の処理のために最終のターゲットに送信しつつ、元のファイルのアーカイブを維持する一方法です。

Post Target(後処理)

前処理と同様に、後処理を転送内で構成します。ターゲットに対するファイル転送が成功した場合に、後処理アクションが呼び出されます。そのため、後処理アクションは通常ファイルの中身に手を入れません。通知は、複数のファイルにzipファイルを展開するのと同様に、後処理アクションに適しています。

Summary

アクションやカスタム・コールアウトには多数のユースケースがあります。圧縮、暗号化、通知、ファイルペイロードの改行文字変換、検証などといった内容に関し、これから取り上げていきます。この概要で、Oracle MFTドキュメントのProcessing Transfers with Custom Calloutsという章にしっかり記載されている、81行の最初のEnd-to-Endのサンプルをなんとかやっていく準備が整ったはずです。

2014年12月22日

[FMW, BPM] BPM 12cのPAMに関すること

昨日に続いて、BPM 12cについてよく頂戴する質問への回答をご紹介します。

Q1) Process Asset Manager (PAM) って何?
A1) Process ComposerとJDeveloperで作成したアセットを管理するための中央リポジトリです。

PAMとは、 12cで新たに導入されたコンポーネントで、11gまではMDS(Metadata Services)と呼ばれたものに近いものですが、かなり違いがあります。

MDS
(11g)
MDS
(12c)
PAM
データを保持する場所 データベース
(*_MDS)
データベース
(*_MDS)
ファイルシステム
設計時の情報を保持できるか ×
バージョン管理の可否 ×
バージョン管理の方法 スナップショット ×Subversion
BPMプロジェクト以外の成果物(ADF Formなど)も管理できるか × ×
クラスタ構成が可能か ×
MDSは12cでも存在するのですが、12cでは設計情報は持たず、ランタイム情報の共有のために利用するようになりました。とはいえ、Process ComposerやJDeveloperで作成した開発成果物を保持するための領域が必要なので、12cでPAMが導入されました。

(こっそり)リリース直前に名前がBAC(Business Asset Catalog)からPAMに変わったため、ExceptionやPackage名には、PAMではなく、まだBACが使われている箇所が多く見られます。今後整理されることでしょう。

PAMのアーキテクチャ概略は以下のようになっています。BPM Studio(=JDeveloper)からもComposerからもアクセスできるようになっていますが、背後にいるのはSubversionなので、NetBeansやEclipse、Visual Studioであっても、Subversionクライアントの機能があれば、直接Subversionにアクセスできます。



Q2) 開発環境で、物理ノード(マシン)を複数使うクラスタ構成にしたんだけど、PAMってファイルシステムに情報を保持するんだよねぇ。その場合、どうやればクラスタ構成に対応させればいいの?
A2) デフォルトのリポジトリ保持場所の変更が必要です。全てのクラスタメンバからアクセスできるファイルシステムにリポジトリを作成する必要があります。

A1で記載したように、Subversionのリポジトリはファイルシステム上に作成します。そのため、クラスタ構成を採っている環境では、PAMのリポジトリをクラスタメンバ全てからアクセスできる場所に作成する必要があります。

# 開発環境でそこまでやるか、という話はさておき...

具体的には、デフォルトのPAMのリポジトリの在処は
<Domain_Home>/bpm/bac/<server名>/repositories
です。Pathからもわかる通り、サーバ毎に作成されてしまうため、たとえ単一ノード内に複数サーバでクラスタを構成したとしても、リポジトリが複数作成されてしまいます。これを回避するためには、BACNodeとBacConfigurationManagerというMBeanの設定を変更する必要があります。

変更するには
  1. Enterprise Manager Fusion Middleware Controlに管理者としてログイン
  2. WebLogicドメイン>ドメイン名を右クリック>システムMBeanブラウザへ遷移
  3. 検索(双眼鏡アイコン)ボタンを押し、MBean名として上述のMBeanを指定
まず、BacConfigurationManager。

クラスタ構成の場合、Active-Active、Active-Passiveの選択ができます。
必要であれば、Protocol(プレーンもしくはSSH)も変更できます(デフォルトはプレーン)。

続いてBACNode。

この中のRepositoryPath(リポジトリのパス)を、クラスタメンバからアクセスできる場所に設定してください。その他、必要があればAddresses(PAMへアクセスするためのホスト名もしくはIPアドレス)、AdminAddresses(管理用のアドレス)、AdminPort(管理用のポート)、Port(PAMへ接続するためのポート番号)を指定してください。

注意
PAMはSOA Suiteでは利用できません(BPM Suiteのライセンスが必要です)。
BacConfigurationManager、BACNodeに対し変更を加えた場合、設定を反映させるためにはサーバ再起動が必要です。

[Java, JavaScript] Node.js and io.js on Java

原文はこちら。
https://blogs.oracle.com/java-platform-group/entry/node_js_and_io_js

Nashorn(ドイツ語でRhino) JavaScriptエンジンはJDK 8の数多ある機能改善のうちの一つであり、Rhinoとして知られる以前のJavaScriptエンジンに変わるもので、より高速に動作します。また、別の注目すべき機能があります。それは多くのNode.jsやio.jsアプリケーションをJVM上で実行することができる、というものです。これらのアプリケーションは最適化されたJavaライブラリを呼び出したり、JMXを使って監視能力を自動的に受け取ったりすることができます。
まもなく登場するJDK 8 update 40では、Nashorn/JavaScriptのパフォーマンスがOptimistic Typingにより、より一層向上するはずです。
Nashorn Architecture and Performance Improvements in the Upcoming JDK 8u40 Release
https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the
http://orablogs-jp.blogspot.jp/2014/12/nashorn-architecture-and-performance.html

Java Virtual Machine - More than just Java

Java Platformは、異なるタイプのアプリケーションを実行する方法を提供しています。たとえアプリケーションがJavaプログラミング言語で書かれていないとしてもです。その結果、開発者はJVMの最適化機能や安定性を活用できるとともに、システム管理者はデプロイメントの管理・監視が向上します。
JVMで動作する他の言語の例として、JavaScript(Nashorn)、Ruby(JRuby)、Python(Jython)、Scala、Groovyなど、様々なものがあります。

Project Avatar – A JavaScript services layer on the JVM

Avatar.jsはNodeプログラミングモデル、APIやモジュール・エコシステムをJavaプラットフォームにもたらすプロジェクトです。
Avatar.js
https://avatar-js.java.net/
JavaScriptで記述されていますが、これらのアプリケーションはJavaプラットフォームの拡張性、管理性、ツールや拡張可能なJavaライブラリやミドルウェアのコレクションを活用することができます。Avatar.jsバイナリをダウンロードすると、開発者はアプリケーションを実行できます。例えば、Tim Caswellの記事である "Hello Node!" には、hello-console.js と hello-http.js という基本的なサンプルが含まれており、これを使ってAvatar(訳注:厳密にはAvatar.jsです)のテストのために利用することができます。
Hello Node!
http://howtonode.org/hello-node
「Nashorn, The Hidden Weapon of JDK 8」というプレゼンテーションが2014年12月のSilicon Valley Java User Groupの会合で発表されました。このスライドではNetflixでのNashornとAvatarの利用に関して説明しています。さらに別のNashornのデモを紹介しています。
Nashorn, The Hidden Weapon of JDK8
http://www.meetup.com/sv-jug/events/218752724/
Nashorn @ Netflix
https://docs.google.com/file/d/0B1_6_iTSwCcjVlc0d1JQLTFTUUU/edit
nashorn at netflix (スライドとデモコード)
https://drive.google.com/folderview?id=0B1_6_iTSwCcjcFRUTjRQRWV2bkk&usp=drive_web#

Avoid rewrites and re-use libraries

サーバーサイドJavaScriptアプリケーションをJVMで実行する主要なメリットに、Javaライブラリへアクセスできる、というものがあります。開発者は主要なライブラリ、SQLやNoSQLドライバ、Hadoopクライアント、エンコーディングライブラリなどの機能を書き直す必要はありません。以前の「Nashorn, the rhino in the room」というエントリで別のサンプルがありますが、これはNode.jsに固有のものではありません。
Nashorn, the rhino in the room
https://blogs.oracle.com/java-platform-group/entry/nashorn_the_rhino_in_the
Niko Köbler(@dasniko)がAvatar 2.0とそのModel Store APIに関する2部構成の記事を出しています。このモデルストアAPIを使用することで、開発者はより簡単に、SQLやNoSQLと対話することができ、そして多くの既存の最適化されたものから便益を享受することができます。

Monitoring Applications on the JVM

すべてのJavaプロセスをJMXと呼ばれるメカニズムで監視することができます。システム管理者はリモートの認証済みJMX接続を有効にして、こうした実行中のアプリケーションを外部から監視するのではなく、内部から監視することができます。JMX監視(ローカル、リモートとも)に関する詳細情報は、以前のエントリからどうぞ。
Deep Monitoring with JMX
https://blogs.oracle.com/java-platform-group/entry/deep_monitoring_with_jmx

Monitoring applications with Mission Control / Flight Recorder

Java Flight Recorderを使うとJVMアプリケーションを本番環境で効果的に監視することができます。標準的な(NetBeansプロファイラのような)開発プロファイラとは異なり、Flight Recorderは性能への影響が軽微でほぼ無視できます。
Mission Controlのダッシュボード・ビューには、CPUやメモリリソースの基本情報が表示されます。開発者はThreadタブを使ってシステムのスループットや、アプリケーションが特定のリソースでブロックしているかどうかをより詳細に把握できます。
Mission Controlを立ち上げるには、jmcコマンドを実行し、Avatarアプリケーションに接続します。以下のスクリーンショットは、com.oracle.avatar.Serverとして識別されているNode.jsアプリケーションをMission Controlで監視している様子です。

Node.jsアプリケーションをJavaScriptで記述していますが、Flight RecorderはCPUのスパイクのようなイベントに関するトリガーベースの記録も可能です。システム管理者や開発者が記録を見返して、何がそのイベントの原因だったのかを知ることができます。
詳細情報は、Mission Controlの製品情報ページやユーザーガイドからどうぞ。
Java Mission Control
http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html
Java Mission Control (JMC) and Java Flight Recorder (JFR)
http://docs.oracle.com/javacomponents/jmc.htm

Additional ways of running Node.js on the JVM

Avatar.jsはNode.jsアプリケーションをJVMで実行するための方法の一つです。
Oracle Java上で動作させる場合、どちらのプロジェクトも上述のようにFlight Recorder/Mission Controlで監視することができます。この監視をOracle JVM自身が直接提供しているため、コードの変更や追加の監視パッケージの適用は不要です。

2014年12月21日

[FMW, BPM] ADF FormをBPM Process ComposerのPlayerで使ってみたり、タスクを取り下げてみたり

JPOUG Advent Calendar 2014 の12月21日分のエントリです。昨日は @mutatsu さんのエントリでした。
本当はNashornについて書きたいところですが、そこは耐え難きを耐え、Oracle Business Process Management Suite(以下、Oracle BPM)について今年よくお尋ねいただいた質問とその回答をご紹介します。なお、「Oracle BPMって何?」という方はこちらをどうぞ。
Oracle Business Process Management Suite
http://www.oracle.com/technetwork/jp/middleware/bpm/overview/index.html

Q1) BPM Process Composerで利用可能なProcess Player機能って、ADF Formでも使えるの?
A1) はい、使えます。
まず、Process Composerとは、Web画面でプロセスの設計・開発ができるツールです。
Process Composer (画面は12cの例)
そのComposerに含まれているProcess Playerとは、作成したプロセスが想定通りに動作するかを入力フォームや作業するロールを含めて確認するための機能です。簡単に言えばテストのための機能です。
Process Playerの実行例
Process Composerでは、Web Formと呼ばれる画面を使って、簡単に入力フォームを作成できますし、
Web Formの例
もっと凝った、リッチな画面が必要であれば、ADF Formと呼ばれるADF(Application Development Framework、アプリケーション開発のためのOracleが提供しているフレームワーク)を使った画面をJDeveloperで開発し、プロセスの入力・表示画面として利用することができます。
ADF Formの例
で、Web Formを使うか、ADF Formを使うかは、Composerのヒューマンタスク機能で設定するのですが、下図の通り、その設定内容がわかりづらいために、上記質問をいただいた、というわけです。
Web Formの場合
ADF Formの場合
では、本題。ADF Formをタスクフォームウィザードを使って、BPMプロセスと一緒にJDeveloperからデプロイした場合、プレゼンテーションの設定は、「何もする必要がない」というのがが答えです。実際にProcess Playerを実行すると...

という感じで、正しくADF Formが表示されます。
ただし、何も設定しないで動作させるためには、以下の前提条件を満たしていることが必要です。

  • PAM(Process Asset Manager)にBPMプロジェクトをチェックインしており、Process Composerからプロジェクトにアクセスできること
  • BPMエンジンの稼働するサーバ(たいていの場合はSOAサーバ)にADF Formがデプロイされていること

APIを使って画面を作成している場合や、外部JNDI経由でADF Formを作成している場合には、ADF Formの設定をProcess Composerで実施する必要があります。

Q2) ワークフローの取下げ(ワークフローの起票をなかったことにする)ってできるの?できるタイミングは?
A2)取下げはプロセスが完了していないかぎり、任意のタイミングで可能です。
ヒューマンタスクの定義で、「取下げ」はタスク作成者、タスク所有者、管理者が実施できるようになっています。

例えば、先ほどのプロセスで、James Cooper(jcooper)というアカウントの人が起票した経費精算レポートのタスクを、すでに上長であるJohn Stein(jstein)が取得しているとします。James CooperとしてBPM Workspaceにログインし、その状況を確認してみましょう。

右下のペインに[アクション]がありますが、これを開くと、[取下げ]が選択できます。

これを選択すると、当該インスタンスは終了します。タスク履歴上は取下げ済になっています。


BPMについてはいろいろお伝えしたいことがありますが、今回はこのあたりで。
明日は吉川和宏さんのエントリです。お楽しみに。
Happy holidays!

2014年12月18日

[Java, JavaScript] Nashorn Architecture and Performance Improvements in the Upcoming JDK 8u40 Release

原文はこちら。
https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the

[訳注]
原文はMarcus Lagergren (動的言語のパフォーマンス・アーキテクト)からのメール形式になっていますが、訳文では少々編集しています。

ここしばらくブログ投稿をご無沙汰して申し訳ありませんでした。ちょうどコードフリーズしたOpenJDK 8u40について、そしてNashornにどのような機能拡張を施したのかをこのタイミングで説明するのがよいと考えました。

8u40ではNashornコードジェネレータを書き換え、Optimistic type systemが搭載されています。

JavaScript、もっとはっきり言うと、任意の動的言語は、パフォーマンスの高いコードを簡単に生成するためのコンパイル時の情報を提供しません。これが、8u40のために、Nashorn Type Systemを再設計し、より良い、高速なコードを生成するようにした理由です。Nashornコンパイラの出力である、Javaバイトコードは、意図的に強く型付けされていますが、JavaScriptはそうではありません。ここに動的言語のASTを最適なバイトコードへ変換する重大な問題があります。Attila Szegedi、Hannes Wallnöfer、と共に、昨年来、この問題を解決するために膨大な時間を研究や実装に費やしてきました。

背景
伝統的に、JavaでJavaScriptランタイムを実装する際、数字と言われるものをJavaでdoubleとして表現でき、それ以外のものは全てObjectとして表現できます。これには、数字、int型、long型や、その他の静的に証明可能ではないプリミティブ型が含まれています。言うまでもなく、このアプローチは、内部で多くのボクシングをもたらすため、JVM上での動的言語の実行速度の面でかなりのボトルネックになります。JVMは、Javaのようなバイトコードの最適化が得意ですが、これは、Javaのようなバイトコードではありません。
Type transitions in the optimistic type system
Nashornは実際に大規模な静的型解析を実施するため、生成されたコードは、上記の保守的なシナリオに比べてはるかに優れたものになる、というのが、もう一つの8u40の新しい点です。とはいえ、まだ全ての型で証明できているわけではないため、そこでOptimistic Type Systemが出てきます。今回のOptimistic Type Systemは、任意の静的に証明できない型がintという、全てのデータ型でもっとも制限の厳しいデータ型と仮定します。実行時にこの仮定が間違っていることが判明した場合には、例えばObject型やdouble型であることがわかったフィールドをメモリやスコープからロードします。また、オーバーフローする32ビットの加算を実施する場合には、実行中のコードをより保守的なバージョンで置き換えます。つまり実行中に再生成します。Nashornは実行時のコード置換を容易にするためのsimple continuationをサポートしています。これは将来、例えば、仮想的なインタプリタ層とコンパイル済みバイトコード間で行き来するといった、様々な用途に使われる可能性がある機能です。

また、将来のこうした変更に対する保護のため、リンク時にCallsiteに渡した引数によって、バイトコードがどのように見えるのかを詳細に調べ、推測しています。
Octane benchmark scores, normalized on JDK 8. 
これにより、(静的な場合には)生成されたバイトコードが実行速度において最適なJava型を含むようになっています。このコスト(全てにはコストがかかります)は、コード生成に時間を要する、というところに現れます。具体的には、わずかにウォームアップでマイナスの影響があります。ウォームアップはJDK9における主要なR&D分野であり、この件を解決でき、またワークロードを改善し、HotSpotによりうまくコンパイルさせて、もっと最適化されたサイクルにすることができる、と自信をもっています。

NashornをJVMの動的言語のための一般的なプラットフォーム/ランタイムとする取り組みで、Optimistic Type SystemはNashornに対しコード生成を指示しているどんなASTともうまく統合されています。将来のJavaのリリースのためにこれらの計画をもっと固め、最終的にNashornが「JVM上の動的言語のためのLLVM」のようなものになることを願っています。楽観的な型付けの問題がすべての動的言語に戻ってきます。このことを証明するために、当社の優れた論文学生であるAndreas Gabrielssonが、TypeScriptをNashornで実行するために必要なほとんど全てのものを実装することに成功しました。これを書いている時点で、唯一の大規模な機能のモジュールが不足しています。中間レベルのコンパイラ層でJavaScriptを生成せずに、NashornはTypeScriptからバイトコードに直接到達します。これは非常に素晴らしいことであり、Nashornが既に拡張性が高いことを示しています。類似の環境でRubyやGroovyが実行されていることについて考えてきました。Nashorn TypeScriptはまだオープンソース化されていませんが、まもなくそうなることを期待しています。

optimistic typeを使って8u40のNashornを実行するには、 以下の引数を使う必要があります。
--optimistic-types=true
まだウォームアップの問題に対する解決策を入れる時間がなかった(それはすべてのものに影響するわけではないですが、問題が残っていることで迷惑を掛ける可能性があります)ため、Optimistic Type SystemはまだNashornのデフォルト設定・動作とはなっていません。これは過度に保守的のように思われるかもしれませんが、不必要に皆さんのウォームアップを壊したくなかったためにそのようにしました。

以前のリリースに比べると、Octane benchmarks suiteのようなもので、数桁のオーダーでの性能向上をお知らせできます。また、Avatarプロジェクト向けのREST、HTTPベンチマークにおけるネイティブまたはネイティブに近いパフォーマンスを報告することができます。このことについてかなり好感を持っています。いくつかのケースでは、Nashorn上のJavaScriptアプリケーションは、SpiderMonkeyやV8のようなネイティブランタイム上で実行した同じアプリケーションと同じくらい速く動作します。言うまでもなく、自分たちの仕事をかなり誇りに思っています。

しかも・・・
JDK 8u40のNashornは生成されたコードと、推測された型情報を実行時にディスクへキャッシュします。
これは、長いウォームアップを伴う大きめアプリケーションにおける最初のイテレーションだけが問題になることを意味します。同じコードを連続実行する場合には非常に素早く安定し、等しく良好なパフォーマンスで実行されるでしょう。


是非お試し頂き、気付いたことをお知らせください。何かご質問があれば、ドキュメントを読み、メーリングリスト nashorn-dev [at] openjdk.java.net に参加してお知らせください。TwitterでNashornチームをフォローすることもできます。
  • Jim Laskey: @wickund 
  • Sundararajan Athijegannathan: @sundararajan_a
  • Marcus Lagergren: @lagergren
  • Attila Szegedi: @asz
  • Hannes Wallnöfer: @hannesw 

近い将来、より多くのエントリをUpすることになるはずですので、ご期待下さい。ブログ執筆活動を休止していることに対し、申し訳なく思っております。

追伸
多言語ランタイムとしてのJVMや、そうした多言語ランタイムを促進するフレームワークとしてのNashornに関する情報に関心がある場合には、以下のプレゼンテーションが知的好奇心を満たすかもしれませんのでご紹介しておきましょう。

2014年12月17日

[Java] USB Device Access for Java SE and OSGi

原文はこちら。
https://blogs.oracle.com/jtc/entry/simplifying_usb_access_for_java

JavaOne 2014でのハンズオン「Java SE Embedded Internet of Things Hands-on-Lab」を作成するにあたっての課題の一つが、JavaとOSGiを使った、USB温度センサーとの通信でした。
Java SE Embedded Internet of Things Hands-on Lab [HOL2097]
https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=2097
残念ながら、USB通信APIは(2014年のハロウィン時期の段階で)Java SE標準には含まれておりません。そのため、この問題はどうすればJava/USB通信を確立できるのか、そしてさらに、どうやればOSGiフレームワークで動作するのか、ということに相当します。
今回は、この接続のベースとしてjavahidapiを選択しました。
JavaHIDAPI - Java API for working with Human Interface USB Devices (HID)
http://code.google.com/p/javahidapi/
HID API for Linux, Mac OS X, and WindowsのJava/JNIラッパーとしてのこのAPIの魅力は、このAPIを使うと、各プラットフォームの各デバイス用カスタムドライバが不要になる、という点にあります。
HID API for Linux, Mac OS X, and Windows
http://www.signal11.us/oss/hidapi/
OSGiフレームワーク内で操作するために(今回の場合、Apache Felix 4.4)、javahidapiのオープンソースコードを少々修正・機能拡張しました。その結果、最終的にOSGiバンドルを標準のOSGiフレームワークに適用し、HIDデバイスのUSB通信をサポートすることができます。このバンドルにはネイティブコンポーネントを含みまた、単純化のために、別のjarファイルをサポート対象のアーキテクチャ用にそれぞれ用意することにしました。OSGi愛好家向けに、Linux/armhf(Raspberry Pi向け)アーキテクチャ用の生成された MANIFEST.MF がどのようなものかご覧いただきましょう。
Manifest-Version: 1.0
Bnd-LastModified: 1414694971263
Build-Jdk: 1.7.0_51
Built-By: jtconnor
Bundle-Activator: com.codeminders.hidapi.Activator
Bundle-ManifestVersion: 2
Bundle-Name: hidapi OSGi Bundle for Linux/armhf
Bundle-NativeCode: native/linux/armv6l/libhidapi-jni-32.so; osname=Linux; processor=armv6l
Bundle-SymbolicName: com.codeminders.com.codeminders.hidapi-armhf
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: com.codeminders.hidapi;uses:="org.osgi.framework";version="1.0.0"
Import-Package: org.osgi.framework;version="[1.6,2)"
Tool: Bnd-1.50.0
以下は事前ビルド済みの人気のあるLinuxプラットフォーム用hidapi OSGiバンドルです。
元のソースに対し、以下のような変更を加えました。
  1. MavenカテゴリのOSGiバンドルを使い、NetBeansプロジェクトを作成
  2. javahidapi のJavaソースコードをプロジェクトの src/main/java/com/codeminders/hidapi ディレクトリに配置
  3. アーキテクチャ固有のネイティブライブラリをプロジェクトの src/main/resources/native/linux/architecture ディレクトリに配置。具体的には、Linux/x86版の場合、 libhidapi-jni-32.so ファイルを src/main/resources/native/linux/x86 ディレクトリに配置。
  4. Activator.java クラスをプロジェクトの src/main/java/com/codeminders/hidapi ディレクトリに追加。OSGiでは、このバンドルがアクティベートされた際にこのクラスの start() メソッドが呼び出される。これはバンドルの MANIFEST.MF ファイルに指定する。
  5. 元の ClassPathLibraryLoader.java ファイルを簡素化。現時点ではLinuxにのみ対応。
  6. これはMavenベースのプロジェクトなので、ビルド時に上記で紹介したものと類似のMANIFEST.MFファイルを生成するよう、プロジェクトの pom.xml ファイルを編集した(x86版はこんな感じ)。
また、以下は関連するNetBeansプロジェクトです。上記4個のバンドルをビルドする際に使用しました。
このテンプレートを拡張しこれら以外のアーキテクチャ用のOSGiバンドルを含めたい場合、上記プロジェクトのうち一つを使って作業を始め、複製し、新しい環境のための適切な変更を施すことができます。新プラットフォーム用のネイティブのjavahidapiコンポーネントが使えない場合には、hidapiのソースをダウンロードしてビルドし、プロジェクトに含める必要があるでしょう。
signal11/hidapi
https://github.com/signal11/hidapi/downloads
この作業に興味がある方は、ここ(原文のコメント)に成果をお知らせ頂けると幸甚です。

2014年12月9日

[Java] Project Jigsaw: Modular run-time images

原文はこちら。
http://mreinhold.org/blog/jigsaw-modular-images

以前投稿したように、Project Jigsawがいくつかのステップを踏んでJDK 9に組み入れられています。
Project Jigsaw: Phase Two
http://mreinhold.org/blog/jigsaw-phase-two
Project Jigsaw
http://openjdk.java.net/projects/jigsaw/
JDK 9
http://openjdk.java.net/projects/jdk9/
JEP 200ではJDKのモジュラー構造を定義し、JEP 201ではJDKのソースコードをモジュラー型に再編成し、そしてJEP 220ではモジュールをサポートするようにJDKおよびJREランタイムイメージを再構成します。実際のモジュールシステムはJSR 376(現在作業中)で定義し、対応するJEP(まだ発行されていません)によって実装される予定です。
JEP 200: The Modular JDK
http://openjdk.java.net/jeps/200
JEP 201: Modular Source Code
http://openjdk.java.net/jeps/201
JEP 220: Modular Run-Time Images
http://openjdk.java.net/jeps/220
Java Platform Module System JSR (376)
http://openjdk.java.net/projects/jigsaw/spec/
ソースコードの再編成(JEP 201)は今年の8月に実施しました。このステップは計画的なものであって、開発者やエンドユーザーには影響はありませんでした。モジュラーランタイムイメージ(JEP 220)に対するほとんどの変更が先週後半に統合され、JDK 9早期アクセス版ビルド41でご利用頂けるようになっています。
JDK™ 9 Early Access Releases
9 Build b41
https://jdk9.java.net/download/
このステップはソースコードの再編成とは対照的に、開発者やエンドユーザーにとって大きな影響が及ぶことが想定されます。この作業の詳細はJEP(JEP 220)に記載されていますが、以下に主要な点を書き出しておきます。
  • JREとJDKイメージには現在、理想的な構造が存在します。以前はJDKイメージはJREをjreサブディレクトリに埋め込んでいましたが、現在はJDKイメージは、はからずも開発ツールや以前からJDKにあったその他のアイテムの完全なセットを含むシンプルなランタイムイメージです。
  • ユーザーが編集可能な構成ファイルは以前libディレクトリにありましたが、これは今後は新たなconfディレクトリにうつります。libディレクトリに残るファイルはランタイムシステムのプライベートな実装の詳細であり、開いたり、変更したりするべきではありません。
  • エンドースド・オーバーライド機能(Endorsed Standards Override Mechanism)は削除されました。
    Java Endorsed Standards Override Mechanism
    http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html
    この機能を利用しているアプリケーションは、java.endorsed.dirsシステムプロパティを設定するか、もしくはjarファイルをJREのlib/endorsedディレクトリに配置しなければ動作しません。同様の機能をJDK 9の後期でupgradable modulesとして提供する予定にしています。
    Upgradeable modules
    http://openjdk.java.net/projects/jigsaw/goals-reqs/03#upgradeable-modules
  • 拡張機能メカニズム(extension mechanism)は削除されました。
    The Extension Mechanism
    http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/index.html
    この機能を使っているアプリケーションは、java.ext.dirsシステムプロパティを設定するか、もしくは以前拡張としてインストールしたjarファイルをJREのlib/extディレクトリに配置しなければ動作しません。ほとんどの場合、jarファイルは拡張として以前インストールされているので、それらをクラスパスの前に単に結構です。
  • rt.jartools.jardt.jarという内部ファイルは削除されました。これらのファイルの中身は現在より効率良い形式でlibディレクトリのimplementation-privateファイルに格納されています。以前tools.jardt.jarに入っていたクラスやリソースファイルは、JDKイメージにブートストラップ・クラスローダやアプリケーション・クラスローダを使うと、現在もなお確認することができます。
  • 新しい、組み込みNIOファイルシステムプロバイダを使って、ランタイムイメージに格納されているクラスやリソースファイルにアクセスすることができます。以前rt.jarやその他の内部jarファイルを読んでいたツールは直接このファイルシステムを使うようにアップデートすべきです。
これらの変更の結果、アプリケーション、特にJDKの内部構造に依拠しているIDEやその他の開発ツールが壊れる可能性があることを認識していますが、パフォーマンスやセキュリティ、メンテナンス性の向上を実現するこうした変更がより大きな価値を生み出すと考えています。既に主要なIDEのメンテナンス担当者に対し、こうした変更があること、必要に応じて支援する準備が整っていることを伝えました。
既存のアプリケーションをJDK 9 build 41以後で実行したときに障害が発生し、それがこの再編成によるもので、JEP 220にや上記の変更内容にあるものが原因でない、と考える場合には、是非jigsaw-devメーリングリストへ知らせる(まだ購読していない場合には、まず購読してください)か、bugs.java.comからバグレポートを上げてください。どうぞよろしくお願いいたします。
jigsaw-dev -- Technical discussion about Project Jigsaw
http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev
Java Bug Database
http://bugs.java.com/

2014年12月8日

[Database] Parallel Execution Fundamentals White Paper

原文はこちら。
https://blogs.oracle.com/datawarehousing/entry/parallel_execution_fundamentals_white_paper

Parallel Execution(多くの人にはParallel Queryとして知られているものです)のプロダクトマネージャとしての最初の投稿で、Oracle Databaseにおけるパラレル実行の基本原理に関する新しいホワイトペーパーをお知らせしたいと思います。以下のリンクよりダウンロードいただけます。
Parallel Execution with Oracle Database 12c Fundamentals
http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-parallel-execution-fundamentals-133639.pdf
Database Resource Managerを利用し、パラレル実行でコンカレントワークロードを管理する方法をまとめたホワイトペーパーも現在用意していますのでしばらくお待ちください。まもなく発行の予定です。

ホワイトペーパーに対するコメント、質問やフィードバック、Oracle Databaseにおけるパラレル実行に関する一般的な質問などは、yasin.baskan at oracle.comにおよせください。以下のコメントセクションを使用していただいても結構です。

2014年12月5日

[Java] The Java 7 EE Tutorial - free eBook!

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

Java EE 7のドキュメントページが見やすいわかりやすいレイアウトに変更されました。
Java Platform, Enterprise Edition (Java EE) 7
http://docs.oracle.com/javaee/7/
これまでよりもJava EE APIやJava EE SDKの各ドキュメント、Java EEチュートリアルをご覧いただきやすくなったはずです。
そのJava EEチュートリアルという有用なリソースが、しかも無料で利用できる、というのはいつか役に立つことでしょう。
Java Platform, Enterprise Edition: The Java EE Tutorial
https://docs.oracle.com/javaee/7/tutorial/index.html
Java EEチュートリアルは見逃されがちですが、貴重なものの一つです。チュートリアルはJava EE 7を取り扱っているので、Java EEを学習したい人たちだけでなく、既にJava EEを熟知されている方にとっても貴重なコンテンツです。しかも、JCAといったJava EEプラットフォームでもあまり知られていない部分も取り扱っています。
Java EE 7入門者向けには、Java EEプラットフォームのわかりやすい入門編があります。
Java Platform, Enterprise Edition: Your First Cup: An Introduction to the Java EE Platform
https://docs.oracle.com/javaee/7/firstcup/index.html
このJava EE 7チュートリアルは無料でご利用いただけ、オンライン版とPDF版があります。さらに、Java EEチュートリアルはePub、Mobi形式でもご利用いただけます(ヒント:オンライン版の右上部をチェックしてください)ので、タブレット、iBook、Kindleなどのお気に入りのeBookリーダーにダウンロードし、ご覧頂けます。オンライン版の右上部をチェックするだけです。もう一度言います。こうしたすばらしいリソースが無料なんです!
最後に、電子書籍はちょっと、という方には、有料ですが、書籍版としてもJava EE 7チュートリアルを入手いただけます。以下はAmazonの例です。
Amazon (US)
http://www.amazon.com/Java-EE-Tutorial-5th/dp/0321994922/
Amazon (JP)
http://www.amazon.co.jp/Java-EE-Tutorial-5th/dp/0321994922/