試験管のなかのコード

[JSR] JCP の更新情報を Twitter で確認する

JCP-INTEREST というメーリングリスト で JCP の最新情報を受け取ることができる。 メーリングリストも良いが、Twitterで更新情報を逐次確認できると個人的には非常に便利。 ということで、Twitter に JCP-INTEREST の情報を自動配信してみた。

jcp_unofficial

http://twitter.com/jcp_unofficial

個人的な利用を目的としたものではあるけれど、もし Twitter を利用していて JCP に興味のある方がいたらどうぞ(そんな人居るのか??)。

[JSR] JSR 168 Portlet Specification ダイジェスト

Portlet Specification をざっと眺めたときのメモ。

JSR 168 Portlet Specification

オリジナルの入手はこちら → JSR 168

PLT.1 Preface

JSR 168 に関連する仕様は、

• Java 2 Platform, Enterprise Edigion, v1.3
• Java Servlet, v2.3
• JavaServer Pages, v1.2

PLT.2 Overview

Portal とは

情報システムのプレゼンテーション層に相当する機能で、一般的に personalization、single sign on、content aggregation などを提供する Web アプリケーションのこと。

Portlet とは

Java を利用して構築された Web Component。Portal から呼び出され、リクエストに応じて動的に画面生成を行う。Portlet Container に管理される。

Portlet Container とは

Portlet を管理し、Portlet の実行環境を提供するコンテナ。Portlet のライフサイクル管理、永続情報管理を行う。

PLT.3 Relationship with the Servlet Specification

Servlet と Portlet の違い。

• Portlet は画面の一部のみを生成する。
• Portlet は URL と直接的な関連を持たない
• Web ブラウザは直接 Portlet を呼び出すことはできない。(必ず Portal 経由)
• Portlet は Servlet よりリクエストハンドリングなどに関して細かく定義されている
• Portlet の状態を表す Portlet Mode や Window State などが予め定義されている
• Portlet は Potal ページ内に複数存在することができる

Portlet は Servlet にはない以下の機能がある。

• Portlet 毎の設定情報、ユーザ毎の設定情報にアクセスできる
• ユーザプロファイル情報にアクセスできる
• HTML 内のリンクを Portal に適した形に書き換えることができる
• Portlet Session にアクセスできる。スコープには application-wide, portlet private が選択できる。

Portlet は Servlet が提供している以下の機能を利用できない。

• レスポンスの文字エンコーディングを指定できない
• レスポンスの HTTP ヘッダを変更できない
• リクエストの URL を参照できない

Portlet と Servlet の関係は、

• Portlet は Servlet や JSP を呼び出すことができる。
• Portlet Container は Servlet Container の拡張。

PLT.4 Concepts

Web ブラウザが Portal にアクセスすると、Portal は Portlet Container を呼び出す。 Portlet Container は、内部で管理している Portlet を呼び出す(必要な場合は複数の Portlet を呼び出す)。

┏━━┓　┏━━┓　┏━━━━━━━━━━┓
┃　　┃　┃　　┃　┃　　　　　　　　　　┃
┃　　┃　┃　　┃　┃┌────────┐┃
┃　　┃　┃　　┃→┃│Ｐｏｒｔｌｅｔ１│┃
┃　　┃　┃　　┃　┃└────────┘┃
┃　　┃　┃　　┃　┃┌────────┐┃
┃　　┃→┃　　┃→┃│Ｐｏｒｔｌｅｔ２│┃
┃　　┃　┃　　┃　┃└────────┘┃
┃　　┃　┃　　┃　┃┌────────┐┃
┃　　┃　┃　　┃→┃│Ｐｏｒｔｌｅｔ３│┃
┃　　┃　┃　　┃　┃└────────┘┃
┃　　┃　┃　　┃　┃　　　　　　　　　　┃
┗━━┛　┗━━┛　┗━━━━━━━━━━┛
Brower　　Portal　　　Portlet Container


　　　　　　↓　生成された画面は・・・

　┏━━━━━━━━━━┓
　┃┌────────┐┃
　┃│Ｔｉｔｌｅ　　　│┃
　┃├────────┤┃
　┃│　　　　　　　１│┃
　┃│Ｃｏｎｔｅｎｔ　│┃
　┃│　　　　　　　　│┃
　┃└────────┘┃
　┃┌───┐┌───┐┃
　┃├───┤├───┤┃
　┃│　　２││　　３│┃
　┃└───┘└───┘┃
　┗━━━━━━━━━━┛
  

Portlet はそれぞれ画面の一部分となる HTML を返すので、Web ブラウザには複数の子ウィンドウが開いたような画面が表示される。

PLT.5 The Portlet Interface

┌─────────────┐
│＜＜ｉｎｔｅｒｆａｃｅ＞＞│
│　　　Ｐｏｒｔｌｅｔ　　　│
├─────────────┤
├─────────────┤
└─────────────┘
　　　　　　△
　　　　　　｜
┌──────────────┐
│　＜＜ａｂｓｔｒａｃｔ＞＞　│
│ＧｅｎｅｒｉｃＰｏｒｔｌｅｔ│
├──────────────┤　　← Portlet はこのクラスを継承する。
├──────────────┤
└──────────────┘
  

• Portlet のインスタンスは VM 毎に1つずつ(なので、分散環境でない場合は1つ)
• Portlet のライフサイクルは Porlet#init → Porlet#processAction → Porlet#render → Porlet#destroy
• Portlet Container は Servlet Container が Portlet アプリケーションの実行時に利用している ClassLoader と同一の ClassLoader を利用して Portlet をロードしなければならない
• Portlet 実行時(Portlet#processAction) には PortletException, PortletSecurityException, UnavailableException が throw される可能性がある
  • PorletException・・・Porlet 実行中に何らかのエラーが発生した場合
  • PorletSecurityException・・・ユーザが Porlet の利用権限を持っていない場合
  • UnavailableException・・・Portlet が一時的もしくは永続的に利用不可能な場合
• Portlet に渡されるリクエスト/レスポンスのインスタンスは Thread Safe ではない。

PLT.6 Portlet Config

• Portlet Deployment Descriptor には title, short-title, keywords などの情報を記述できる
• PortletConfig のインスタンスが Portlet Deployment Descriptor の情報を保持している

PLT.7 Portlet URLs

• Portlet に指示を行うために、Portlet へのコマンドを含んだ URL を使用する。この URL を Porlet URL と呼ぶ。
• Portlet URL を表す PortletURL インターフェースが定義されている。PortletURL#createActionURL, PorletURL#createRenderURL を使用して PortletURL のオブジェクトを生成できる。
• 特定の Portlet Container 実装が内部情報を URL のクエリに含めている可能性があるので、Porlet を開発する際には HTTP の GET メソッドを使用した Form を利用すべきではない。
• Porlet 毎の情報を PorletURL#setParameter を利用することで Portlet URL 内に組み込むことができる。
• PortletURL#setSecure を使用することで、Portlet URL の転送時に SSL を使用しなければならないか否かを指定することができる。

PLT.8 Portlet Modes

• Portlet Mode は Portlet が現在実行中の機能を表す。
• 標準で定義されている Portlet Mode は、VIEW、EDIT、HELP。
  • VIEW・・・Portlet の現在状態を表示するモード。GenericPortlet#doView が対応する。
  • EDIT・・・Portlet の状態を変更する方法を提供するモード。GenericPortlet#doEdit が対応する。
  • HELP・・・Portlet に関するヘルプ情報を表示するモード。GenericPortlet#doHelp が対応する。
• Deployment Descriptor の custom-portlet-mode を使用することでカスタムの Portlet Mode を定義できる。

PLT.9 Window States

• Window State はレンダリングの際に Portlet がどの程度の情報を出力するかを表す。
• 標準で定義されている Window State は、NORMAL、MAXIMIZED、MINIMIZED。
  • NORMAL・・・Portlet が他の Porlet とページをシェアしている状態を表す。
  • MAXIMIZED・・・Portlet がページ内のスペースを占有できる状態を表す。
  • MINIMIZED・・・Portlet は最小限の情報しか出力できない状態を表す。
• Deployment Descriptor の custom-window-state を使用することでカスタムの Window State を定義できる。

PLT.10 Portlet Context

• PortletContext のインスタンスは Portlet Application 毎に一つ(正確には VM 単位で)。
• PortletContext は、初期化パラメータ、アトリビュート、リソースなどを管理する。
• Portlet は PortletContext から RequestDispatcher を取得することで、Servlet や JSP を呼び出すことができる。
• Portlet は ServletContext にもアクセスできる。この ServletContext は PortletContext と同一のデータを保持している。

PLT.11 Portlet Requests

PLT.12 Portlet Responses

PLT.13 Portal Context

PLT.14 Portlet Preferences

PLT.15 Sessions

PLT.16 Dispatching Requests to Servlets and JSPs

PLT.17 User Information

PLT.18 Caching

PLT.19 Portlet Applications

PLT.20 Security

PLT.21 Packaging and Deployment Descriptor

PLT.22 Portlet Tag Library

PLT.23 Technology Conpatibility Kit Requirements

[JSR] JSR 168 Portlet Specification について調査

関連サイト

JSR 168: Portlet Specification

http://www.jcp.org/en/jsr/detail?id=168

JSR 162: Portlet API

http://www.jcp.org/en/jsr/detail?id=162

JSR 167: Java Portlet Specification

http://www.jcp.org/en/jsr/detail?id=167

Apache Portals Project

http://portals.apache.org/

Apache Pluto

http://portals.apache.org/pluto/

Jetspeed 1

http://portals.apache.org/jetspeed-1/

Jetspeed 2

http://portals.apache.org/jetspeed-2/

JBoss Portal

http://www.jboss.com/products/jbossportal

※JSR 162 と JSR 167 が一つに統合されて JSR 168 となった(なので、JSR 162、JSR 167 は取り下げられた)。

Apache Pluto 1.0.1 インストールメモ

1. Pluto をここからダウンロードする。面倒がないように Tomcat 入りのフルセットを落とす。
2. Pluto をインストールする。適当な場所にアーカイブを解凍
3. <PLUTO のインストール先>\bin\setenv.bat を作成。
   • 環境変数 JAVA_HOME を設定。ここで指定する JAVA_HOME は JDK5.0 のパス
   • 環境変数 PLUTO_HOME を設定。(ex. set PLUTO_HOME=c:\opt\pluto)
   • 環境変数 CATALINA_HOME を設定。PLUTO_HOME と同じパスが CATALINA_HOME になる。(ex. set CATALINA_HOME=%PLUTO_HOME%)
4. Pluto を起動する。%PLUTO_HOME%\bin\startup.bat を実行
5. Pluto の起動確認をする。http://localhost:8080/ にアクセス
6. Pluto Test Driver を実行する。http://localhost:8080/pluto/portal にアクセス

[JSR] JSR 250 Common Annotations for the Java Platform ダイジェスト

Common Annotations for the Java Platform の仕様をざっと眺めたときのメモ。

JSR 250 Common Annotations for the Java Platform

オリジナルの入手はこちら → JSR 250

General Guidelines for Inheritance of Annotations

annotation が付加されたメソッドがサブクラスでオーバーライドされた場合、 どのように扱われるのかが曖昧。そのため、そのような場合におけるガイドラインを 以下の様に定義する。

• クラスレベル annotation は自分自身のメンバー(メソッド、フィールド)のみを対象とする。
• クラスレベル annotation よりメンバーレベル annotation の方が優先される。
• インターフェースは実装されているクラス(メンバーを含む)に影響を与えない。
• オーバーライドもしくは隠蔽されていないメンバーは子クラスにおいても親クラスの annotation を引き継ぐ。
• オーバーライドもしくは隠蔽されているメンバーは子クラスにおいて親クラスの annotation の影響を受けない。

javax.annotation.Generated

自動生成されたコードを表す。 自動生成ツールの名称を必ず指定しなければならない。 自動生成された時刻を記述可能。時刻は ISO 8601 のフォーマットに従わなければならない。 ターゲットは ANNOTATION_TYPE, CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, PARAMETER, TYPE。

javax.annotation.Resource

DataSource などを自動でクラスにインジェクションするために利用される。 JNDI 名を指定することで、コンテナが JNDI から適切なリソースを取得しフィールドインジェクションもしくはメソッドインジェクションで対象オブジェクトに引き渡す。 ターゲットは TYPE, METHOD, Field。

javax.annotation.Resources

複数のリソースを必要とする場合、Resources を利用して複数の Resource をまとめる。 同一 annotation の複数回指定が認められていないため。 ターゲットは TYPE。

javax.annotation.PostConstruct

インジェクション終了直後に実行されるメソッドを表す。 オブジェクト生成→インジェクション→PostConstruct指定されたメソッド実行、というライフサイクルになる。 ターゲットは METHOD。 この annotation を付加されるメソッドには以下の制限がある。

• パラメータは指定できない(但し、EJB interceptor における InvocationContext のみ可能)
• 戻り値は void のみ。
• チェック例外は throw できない。
• アクセス識別子は public, protected, package private, private を指定可能。
• static にできない。
• final を指定可能。
• 非チェック例外を throw した場合は、そのオブジェクトを利用してはいけない。

javax.annotation.PreDestroy

コンテナがオブジェクトを破棄する際に実行されるメソッドを表す。 ターゲットは METHOD。 この annotation を付加されるメソッドには以下の制限がある。

• パラメータは指定できない(但し、EJB interceptor における InvocationContext のみ可能)
• 戻り値は void のみ。
• チェック例外は throw できない。
• アクセス識別子は public, protected, package private, private を指定可能。
• static にできない。
• final を指定可能。
• 非チェック例外を throw した場合、その例外は無視される。

javax.annotation.security.RunAs

クラスのロールを表す。 Java EE コンテナでクラスが実行される際、RunAs でクラスのロールを割り当てることができる。 ターゲットは TYPE。

javax.annotation.security.RolesAllowed

クラス、メソッドの実行権限を持つロールを指定する。 ターゲットは TYPE, METHOD。

javax.annotation.security.PermitAll

全てのロールが実行権限を持つことを表す。 PermitAll が指定されたクラス、メソッドは権限に関して未チェックで実行される。 ターゲットは TYPE, METHOD。

javax.annotation.security.DenyAll

全てのロールが実行権限を持たないことを表す。 DenyAll が指定されたクラス、メソッドは Java EE コンテナ上では実行できない。 ターゲットは METHOD。

PermitAll, DenyAll and RolesAllowed interactions

• PermitAll, DenyAll, RolesAllowed は特定のクラスもしくはメソッドに同時に指定することはできない。
• DenyAll がクラスレベルで指定されている場合、メソッドに PermitAll, RolesAllowed が指定されると PermitAll, RolesAllowed が優先される。
• RolesAllowed がクラスレベルで指定されている場合、メソッドに DenyAll, PermitAll が指定されると DenyAll, PermitAll が優先される。

謎) DenyAll のターゲットは METHOD のみなのに、ここではクラスレベルで指定できると書かれている。どちらが正しいの??

javax.annotation.security.DeclareRoles

テスト等で使用するためのロールを定義する。 ターゲットは TYPE。

[JSR] JSR 181 Web Services Metadata for the Java Platform ダイジェスト

Web Services Metadata for the Java Platform の仕様をざっと眺めたときのメモ。

JSR 181 Web Services Metadata for the Java Platform

オリジナルの入手はこちら → JSR 181

Concepts

Server Programming Model

Web Services Metadata

Annotation: javax.jws.WebService

Annotation: javax.jws.WebMethod

Annotation: javax.jws.Oneway

Annotation: javax.jws.WebParam

Annotation: javax.jws.WebResult

Annotation: javax.jws.HandlerChain

Annotation: javax.jws.soap.SOAPBinding

Annotation: javax.jws.soap.SOAPMessageHandlers

Java Mapping To XML/WSDL

SOAP Binding

Mapping JSR-181 to the J2EE 1.4 Runtime Environment

Using JSR-181 annotations to affect the shape of the WSDL

[JSR] JSR 94 Java Rule Engine API ダイジェスト

Java Rule Engine API をざっと眺めたときのメモ。

JSR 94 Java Rule Engine API

オリジナルの入手はこちら → JSR 94

6. Definitions

Rule Engine

高機能な if/then statement インタプリタの様なもの。ビジネスロジックをシステムの外部に出すことで宣言的プログラミング(declarative programming)を促進する。

Rule

Rule は condition と action とから成る。この JSR では Rule の構造は規定されない。

Rule Execution Set

Rule の集合。この JSR では Rule Execution Set の構造は規定されない。

Rule Session

Rule Engine とクライアント間の実行時コネクション。Rule Session は単一の Rule Execution Set と関連付けられる。

Stateful Rule Session

Stateful な Rule Session。

Stateless Rule Session

Stateless な Rule Session。Stateful Rule Session よりシンプルでパフォーマンスが良い。

10. Architecture

• javax.rules, javax.rules.admin とい 2 つのパッケージで構成される。
• javax.rules は、Rule Engine のランタイムクライアントを表す。既に用意された Rule Execution Set 用の Rule Session の生成や Rule Session を用いた各種処理を提供する。
• javax.rules.admin は、管理用 API を表す。外部リソース (URI, InputStream, XML, Binary tree, Reader) から Rule Execution Set を読み込む機能を提供する。

10.1. Runtime API

RuleServieProviderManager

RuleServiceProvider を提供する。ベンダー毎の RuleServiceProvider を返す。

RuleServiceProvider

RuleRuntime, RuleAdministrator を提供する。

RuleRuntime

RuleSession, 登録済みの RuleExecutionSet の URI リストを提供する。

RuleExecutionSetMetadata

RuleExecutionSet に関するメタデータを提供する。

RuleSession

StatefulRuleSession, StatelessRuleSession の共通インターフェース。

StatelessRuleSession

クライアントは StatelessRuleSession に Objet のリストを渡して RuleExecutionSet の実行を指示する。その後、処理の結果生成された Object を受け取ることができる。処理結果の Object は ObjectFilter を利用することで必要なもののみ受け取るようにフィルタリングすることができる。

StatefulRuleSession

RuleExecutionSet に渡される Object の受け渡しなどを行うインターフェース(addObject, getObject, removeObject, updateObject, containsObject)を提供する。

ObjectFilter Interface

RuleSession 実行結果 Object リストから必要なもの/不必要なものを選別するフィルタ。

Handle Interface

StatefulRuleSession 内で独自の方法で Object を識別する。異なる ClassLoader でロードされた Object 同士でも正確に一致/不一致を判断するために利用される。

10.2. Administrator API

RuleAdministrator

RuleExecutionSetProvider を提供する。

RuleExecutionSetProvider

RuleExecutionSet を生成する。

LocalRuleExecutionSetProvider

RuleExecutionSet を生成する。LocalRuleExecutionSetProvider はシリアライズされていないデータ (InputStream, Reader) から RuleExecutionSet を生成する。

Rule

Rule の名称や説明情報などを提供するインターフェースを持つ。

RuleExecutionSet

RuleExecutionSet の名称や説明情報などを提供するインターフェースを持つ。

クラス図

[JSR] JSR 73 Data Mining API ダイジェスト

Data Mining API の仕様をざっと眺めたときのメモ。

JSR 73 Data Mining API

オリジナルの入手はこちら → JSR 73

1. Overview

• JDM は Pure Java のデータマイニング用 API。 データマイニングツールベンダが提供する実装に対する共通の API を定義する。
• 類似の JSR に JSR-69 JOLAP があるが、JSR-73 は JSR-69 と調整をしながら策定されている。
• JDM は、API(application programming interface)、DME(data mining engine)、MOR(mining object repository) の 3 つのコンポーネントで構成される。

2. Use cases

3. Concepts

Data mining Functions

データマイニングの主だったサブドメイン。以下の 5 つから構成される。

• Classification・・・予め決められた分類に従ってデータを分類する。ex) customer segmentation, business modeling, credit analysis
• Regression・・・時間を考慮したClassification。ex) financial forecasting, biomedical and drug response modeling
• Attribute Importance・・・モデルの構築の際にどの属性が最も重要であるかを決定する。
• Clustering・・・データ内のクラスタを見つける。
• Association・・・データ内に頻発する値の関連を見つける。ex) market basket analysis

Data mining Tasks

• Building a model
• Testing a model
• Applying a model
• Object import and export
• Computing statistics on data
• Verifying task correctness

Principal Objects

• Connection
• Task
• Execution handle and status
• Physical data set
• Physical data record
• Build settings
• Algorithm
• Algorithm settings
• Model
• Model signature
• Model detail
• Logical attribute
• Logical data
• Attribute statistics set
• Apply settings
• Confusion matrix
• Lift
• Cost matrix
• Prior probabilities
• Category sets
• Taxonomy
• Rules
• Verification report

Physical data representations

• Individual record
• Single record case table
• Multi-record case table
• Data preparation

Attribute mapping

• Direct mapping
• Pivot mapping

Creating physical data objects

Persistence

Object references

Reflection/introspection

4. Packages

5. Code examples

6. Conformance statement