N2 ToolBox(跡地)

跡地です。引っ越しました。http://d.hatena.ne.jp/nosen

Mavenのサイト更新

2005-03-30 02:24:00 | オープンソース
最近(3/15ころ)Mavenのサイト
大幅に更新されました。どこに何が書いてあるのかがはっきり分かるように
なって、とてもいい感じです。

ところで、仕事でMavenを使う場合に、やっぱり困るのはドキュメントが
少ないこと、それも日本語のドキュメントが少ないことです。
自分がそのプロジェクトにどっぷり浸かっている場合は、自分が頑張って
ソース読むなり、英語読むなりすればいいだけなのでよいのですが、
問題はスポット的にプロジェクトの支援に入る場合です。
この場合、ビルド環境のメンテを誰かにひきつがなければならないわけですが、
このとき、Mavenというややこしいツールを説明する資料を自分で書くのは
とてもしんどい、というか無理です。

今回、更新されたドキュメントが日本語で読めれば、「ココ見とけ」で
済んで便利なので、是非Ja-Jakartaで翻訳に取り組みたいと考えています。

Java Computing 2005 Spring

2005-03-12 02:03:19 | その他
いやー、なにも役にたつようなことはしてない割りに
疲れましたね、Java Computing 2005 Spring。
わたくしは、ほとんどJa-Jakarta Projectのブースの番を
してたので、ほとんどセッションとか他のブースは見てない
のですが、キーワード的にはJSF他プレゼンテーション層、
SOA、O/Rマッピング、テストツール等が主だった気がします。
各ベンダとも、高い金とるんだったら
もうちょい現場の開発者の心に響く、地に足のついた
ソリューションを提供してくれたらいいのにな、
と思いました。

知ってる顔がぼろぼろその辺をうろついていて、
この業界も狭いな、と実感しました。

打ち上げでは、席がたまたまCraig Mclanahanの前でめっちゃ
緊張しました。Craigはわたくしの拙い英語の質問にも
誠実に回答してくれました。やっぱり英語をもっと
勉強しようと思いました。Seasarプロジェクトの歴史の話も
聞けたし、とても勉強になりました。

JSR-208 Java Business Integration

2005-03-08 01:56:10 | その他
石原さんのBlogによると、J2EE6.0(!)の目玉になる可能性が高い
JSR-208 Java Business IntegrationのPublic Review がリリースされたとのこと。
初耳だったので、一体これは何だ?とちょこっとだけ仕様を読んで
みたところ、どうもSOAの話らしいです。
もう、いろんな所でいろんな人がSOA,SOAと連呼していて、うんざり
してしまうが、まだなお新しいSOA関連の仕様をつくるのか~、と
思いつつも、あまり先入観をもつのも良くないので、なるべく
ニュートラルな心持ちで読んでみました。

結論からいうと、JBIというのはBPEL4WSとかよりも更に
一段抽象度の高いフレームワークで、BPELエンジン自体を
一つのコンポーネントとして扱うということです。
で、BPELエンジンとかと同列のコンポーネントとして
EJBコンテナとかがある、と。

少し詳しく説明すると、JBIというのは以下の3つの部分より
構成されるらしいです。あらかじめ断っておくと、全ての仕様を
精読した訳ではないし、なにより今、安い泡盛をあおって酔っ払ってる
ので、そのへん差し引いてよんでください。
(ああ、つくづくだめだな、僕と言う人間)

--
1. コンポーネントフレームワーク
サービスのコンシューマ、あるいはプロバイダとなるコンポーネント。
コンポーネントには以下の2種類が存在する。

a. サービスエンジン
BPELエンジンやEJBコンテナ、XSLT変換などのサービスを他のコンポーネント
に対して提供すると同時に、自らも他のサービスのコンシューマとなる。
b. バインディングコンポーネント
SOAP over HTTPであるとか、JMSといった外部サービスへの接続を提供する。

サービスエンジンが基本的にJBIフレームワークと同一VMで動作するのに対し、
バインディングコンポーネントで接続される外部サービスは別のVMやマシン上で
動作することが想定されているようです。

2. 正規化されたメッセージのルータ(Normalized Message Router)
各コンポーネントは互いに直接依存しあっている訳ではなく、
Delivery Channelというものを通じて全てこのNormalized Message Router
につながっているということです。
Normalized Message Routerというからにはこの一種のルータを通過できるのは
「正規化されたメッセージ」だけ。「正規化されたメッセージ」とは、
JBIの世界では、WSDL2.0にのっとった構造をもったメッセージ+それらのメッセージ
に関するメタデータであるということです。
コンポーネントがルータに対してできることは、この正規化されたメッセージを
送信したり、受信したりすること。 他のあらゆる種類のメッセージも
コンポーネントは正規化されたメッセージに変換してこのルータに送出する
必要があります。後はルータが適切な他のコンポーネントにこの
メッセージを送り届けてくれるというわけらしい。

3.マネジメント
JMXベースの管理フレームワークが定義されており、コンポーネントの
インストール、ライフサイクル管理、各種設定など、標準的なツールを
使って可能になるらしいです。
--

この仕様のミソは、細かい「ビジネスロジック」的な部分を「サービスエンジン」
というコンポーネントに隔離してしまっているところだと思います。
BPEL4WSとかWSCIのような仕様が難しいところは、複数のサービスを繋合わせる
ときに、必須となるデータ変換やさまざまなロジックをその仕様のなかに内包
してしまっている点かと思います。JBIはそうしたややこしい部分を、それらの
仕様に任せて、自分は「メッセージのルーティング」に徹することで
自らのシンプルさを保つ、という思想にもとづいているとみました。
仕様書もそんなにボリュームがなくて、たぶん全部読破するのは
そんなに大変じゃないです。

酔っ払っているので、全然自信ありません。間違ってたらだれか突っ込んで
ください!

それにしても、SOAというもの、流行っているんだか、なんだか
よくわからないですね。僕のなかでは、SOAというものが、
EAIとどう違うのかというと、「サービス」というもののインターフェース
が"WSDL"という形で拡張性を保ちつつ標準化されている点かと思います。

そういう意味ではSOAというのは新しい概念ではなくて、WSDLによって
理想に近付いたEAI、程度に僕は理解してます。
それをマーケティングだかなんだかのために大げさにいう
人がいるから訳のわからない事態に落ちいってしまうのではないかと、
そんなことを考えております。

ネットワーク科学!?

2005-03-03 18:46:10 | その他
Cafe Babeにて風間さんが「ネットワーク科学」というジャンルの学問について紹介しておられました。
ネットワーク科学というのはノードとリンクから構成されるネットワーク構造
に関する研究なのだそうです。最近私は「ノードとリンクからなるデータ構造」
をプログラム的に簡単に扱いたいと思うことが多々あったので、とても興味を
惹かれました。人間の認識の枠組みがそのようにつくられているのか、
確かに、経験的にネットワーク構造というのはよく目にする一般的な構造です。
システム開発とかプログラムの世界に限っていっても、ライブラリの依存関係
や、よく考えてみるとオブジェクト指向におけるクラスモデルも一種のネットワーク
構造と見ることができます。
ネットワーク構造とは少し違うかもしれませんが、
Maven2で使われているplexusというDIコンテナではユーティリティとしてDAG(Directed
Acyclic Graph=非循環有向グラフ)というライブラリが用意されていて、Maven2では
ライブラリ間の依存関係の表現やGoal間の依存関係の表現など、様々な用途にこれを
使いまわしています。実は私はこのグラフ構造を永続化できて、かつトランザクション
にも対応したライブラリが欲しいのですが。Googleで"非循環 有向 グラフ"で検索すると
結構な数のなにやら学術的なページがヒットするので、いかにもありそうな雰囲気
なんですけどね。文系人間の私には少し敷居が高いです("ネットワーク構造"と
"グラフ構造"ってすごく似た雰囲気がするんですが、同じようなものと考えてしまって
よいんでしょうか?)。

ちょっと気合入れて勉強してみようかと思います。

ブックレビュー:知識創造企業

2005-03-01 01:27:02 | ブックレビュー
書名:知識創造企業
著者:野中郁次郎+竹内弘高
訳:梅本勝博
発行所:東洋経済新報社
ISBN4-492-52081-3 2,000円

いわずと知れた、ナレッジマネジメントの基礎理論
を打ちたてた本です。やっと読みました。
本書でいわれている知識創造理論に関してはすでに
様々なところで語られ過ぎるほど語られているので、
ここで私がまたその概要を示すまでもないでしょう。
@ITの記事などが、良くまとまった紹介になっています。

読後感としては、やはり概要レベルの解説を読んだだけの
レベルとは、「形式知」「暗黙知」「共同化」「表出化」
「内面化」「連結化」と言った基礎的な用語の厚みが全く
違ったものに感じられます。「知識として知っている」だけの
レベルとは違い、これらの言葉が自分の内部で生き生きと
躍動し、物を考えるためのいわば概念装置として作動するように
なるのを感じます。

システム開発の世界も、知識創造の観点からみるとまた違った
捉え方が出来そうです。

マネジメントに関わる全ての人は、本書を読むべきです。
まだ読んでない人はいますぐ読んで下さい。必ず読んで下さい。

ITプロジェクトサバイバルで今村さんも取り上げている通り、効率最優先の経営は最善ではありません。
では「効率」にとって変わる価値とはなにか?
すくなくとも私は、本書からそれを見付けるための重要な示唆を受けました。
あとは、実践あるのみです。
私は本書からまた一つ、戦う力を手にいれました。