JCA 入門記 Chapter 2 Overview

Java JCA
「JCA」って、
http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html
と名称が被ってるんですよね...

なんですと？

The first release of Security API in JDK 1.1 introduced the "Java Cryptography Architecture" (JCA), a framework for accessing and developing cryptographic functionality for the Java platform. In JDK 1.1, the JCA included APIs for digital signatures and message digests.

ぐはぁっ，こっちが本家 JCA ？
なんてこった，連載 入門記始めたばかりでタイトル変更か？
まいっか．
とりあえず，公式に「JCA とは呼ぶな」みたいなのを目にするまでこのままでいっちゃお．
そんなわけで (どんなわけで？)，始めませう．


2. Overview
本章では，コネクタ・アーキテクチャを理解するために必要な，キーとなる概念を紹介します．だそうです．


2.1 Definitions


2.1.1 Enterprise Information System (EIS)
EIS は組織の基盤となる情報を提供するもので，次のようなものがあります．

そして，EIS (とのインタフェース) には，二つの側面があるのだとか．

  • システムレベルのサービス．接続とか？
  • アプリケーション固有のインタフェース．DBMS におけるテーブルやストアド，TP モニタにおける特定のトランザクションプログラムの呼び出しとか．

ふむ．前者の標準 API が SPI，後者のが CCI ってことなんでしょうね，きっと．


2.1.2 Connector Architecture
コネクタ・アーキテクチャは，J2EE サーバと EIS とを統合するためのアーキテクチャで，二つの部分からなります．

これらの規約により，アプリケーションサーバと EIS は，双方向に通信を行うことが可能になりとのことです．
ふむふむ．JDBC や JMS にはリソースアダプタ的なものはありますが (Driver や ConnectionFactory)，後者の部分はありません．そんなわけで (どんなわけで？)，JDBC や JMS も JCA のリソースアダプタとして扱う方向みたいですね．
これからは JDBC ドライバも RAR だ！ みたいな．


2.1.3 EIS Resource
EIS は固有のリソースをクライアントに提供します．その例．

だそうです．で，なんだ？
そうか，「Definitions」だから単に言葉を定義しているだけか．


2.1.4 Resource Manager (RM)
リソースマネージャは，EIS のリソースを管理するものだそうです．
トランザクショナルなりソースマネージャは，トランザクションマネージャが制御するトランザクションに参加することが出来ます．っていうか，この仕様書では，トランザクショナルなものだけをリソースマネージャと呼ぶみたい．JTA でいうところのリソースマネージャと同じってことですね．
で，なんだ？
そうか，「Definitions」だから単に言葉を定義しているだけか (こぴぺ)．


2.1.5 Managed Environment
管理された環境とは，J2EE を基盤としたコンテナから EIS にアクセスするような環境のことです．
管理された環境では，アプリケーションはいくつかのコンポーネントとして構成され，次のコンテナに配備されます．

  • Web コンテナ
  • EJB コンテナ
  • アプリケーションクライアントコンテナ

ふむふむ．ってことは，S2JCA (仮称) ができればスタンドアロンな S2 アプリも管理された環境になるわけですね．


2.1.6 Non-Managed Environment
管理されない環境は，コンテナのいない環境ですね．この場合は，リソースアダプタを直接使って EIS にアクセスすることになります．
今スタンドアロンな S2 アプリで Coherence みたいなリソースアダプタを使おうとするとこれになるわけですね．


2.1.7 Connection
コネクションはリソースマネージャへの接続を提供します．そのまんまやね．
コネクションはトランザクショナル・非トランザクショナルどちらでもいいらしいです．
コネクションが双方向の通信に使われるかどうかはリソースマネージャ次第とのこと．双方向はオプションなんですね．


2.1.8 Application Component
アプリケーションコンポーネントは，EJB や サーブレット，JSP として配備・管理・実行できるとのことです．
だからどうした．
そうか，「Definitions」だから単に言葉を定義しているだけか (こぴぺ)．


2.1.9 Container
コンテナはアプリケーションサーバの一部であり，アプリケーションコンポーネントを配備して実行できるようにしてくれます．
コンテナは，アプリケーションサーバに対する統合された視点をアプリケーションコンポーネントに提供します．
だからどう (以下略)


2.2 Rationale
ここからは，コネクタ・アーキテクチャの原理について解説してくれるそうな．


2.2.1 System Contracts
様々な EIS とアプリケーションサーバを統合するには，標準となるアーキテクチャが必要です．
なんか，図まで使って説明が長々と続くのですが，要するに標準は大事だよねってことだけっぽい．


2.2.1 Common Client Interface
同じように，クライアントアプリケーションが EIS にアクセスするインタフェースにおいても標準が必要です．それが Common Client Interface (CCI)．


2.3 Goals
コネクタ・アーキテクチャの目標は以下の通り．

  • 様々な EIS を対象としたスケーラブルでセキュアでトランザクショナルなリソースアダプタを簡単に開発できること．
  • 十分に広範囲な EIS をカバーできること．
  • 特定のアプリケーションサーバだけでなく，すべてのアプリケーションサーバに適用可能であること．
  • エンタープライズなツールや EAI のベンダにクライアント API の標準を提供すること．
  • 実装が仕様に準拠しているかどうかを明確に判断できること．
  • すぐに理解できて，特定の EIS のために開発・配備されたアプリケーションコンポーネントが，容易に異なった EIS にアクセスできるようにすること．そのために，ごく少数の概念だけを導入し，実装にわずかな要求しかしないこと．
  • EIS との双方向の接続のために必要な要素について，それぞれの役割と契約・責任を定義する．
  • 管理された環境 (アプリケーションサーバに配備されたりソースアダプタ) から EIS にアクセスするだけでなく，管理されていない環境からでもリソースアダプタを直接使用して EIS にアクセスすることを可能にすること．

以上．

んー，なんか淡々とした学習だな．．． まだ導入部だからしょうがないか．
次回は「Chapter 3 The Connector Architecture」ということなので，そこからが本格的な JCA の解説 (っていうか仕様) になるのでしょう．
次回はいつだ？ 明日金曜日は EbiYuri デー．だったけど，もうハニカミだけなんだよなぁ．うー，気分次第で明日も学習するかも〜．