Mar 08, 2009

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

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

jcp_unofficial
http://twitter.com/jcp_unofficial

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

    follow me on Twitter

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

    Oct 26, 2005

    [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 を呼び出す)。

    ┏━━┓ ┏━━┓ ┏━━━━━━━━━━┓
    ┃  ┃ ┃  ┃ ┃          ┃
    ┃  ┃ ┃  ┃ ┃┌────────┐┃
    ┃  ┃ ┃  ┃→┃│Portlet1│┃
    ┃  ┃ ┃  ┃ ┃└────────┘┃
    ┃  ┃ ┃  ┃ ┃┌────────┐┃
    ┃  ┃→┃  ┃→┃│Portlet2│┃
    ┃  ┃ ┃  ┃ ┃└────────┘┃
    ┃  ┃ ┃  ┃ ┃┌────────┐┃
    ┃  ┃ ┃  ┃→┃│Portlet3│┃
    ┃  ┃ ┃  ┃ ┃└────────┘┃
    ┃  ┃ ┃  ┃ ┃          ┃
    ┗━━┛ ┗━━┛ ┗━━━━━━━━━━┛
    Brower  Portal   Portlet Container
    
    
          ↓ 生成された画面は・・・
    
     ┏━━━━━━━━━━┓
     ┃┌────────┐┃
     ┃│Title   │┃
     ┃├────────┤┃
     ┃│       1│┃
     ┃│Content │┃
     ┃│        │┃
     ┃└────────┘┃
     ┃┌───┐┌───┐┃
     ┃├───┤├───┤┃
     ┃│  2││  3│┃
     ┃└───┘└───┘┃
     ┗━━━━━━━━━━┛
      
    Portlet はそれぞれ画面の一部分となる HTML を返すので、Web ブラウザには複数の子ウィンドウが開いたような画面が表示される。

    PLT.5 The Portlet Interface

    ┌─────────────┐
    │<<interface>>│
    │   Portlet   │
    ├─────────────┤
    ├─────────────┤
    └─────────────┘
          △
          |
    ┌──────────────┐
    │ <<abstract>> │
    │GenericPortlet│
    ├──────────────┤  ← 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

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

    Oct 25, 2005

    [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 にアクセス

    [PLUTO の TOP 画面] [テストドライバの TOP 画面] [テストドライバ画面(1)] [テストドライバ画面(2)] [テストドライバ画面(3)] [PLUTO の管理画面]

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

    Oct 14, 2005

    [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。

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

    Sep 10, 2005

    [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

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

    Aug 18, 2005

    [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 94 クラス図]

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

    Aug 14, 2005

    [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

    Posted in JSR | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |