8月ごろの記事ですがSun Developer Network(SDN)でIntroducing Design Patterns in XML Schemasという記事が公開されています。
この元ネタはJavaOne Sanfrancisco 2006のBOFで「BOF-2224 What You Need to Know About Schema Design Patterns and Java Technology」だと思います。 ちょうどこのBOFを聞いていたので内容としては大体知っていることだったんですが、上記の記事で面白いと感じたのはこのBOFで紹介されていたXMLSchemaのデザインパターンが実はすでにNetBeans + Enterprise Packのツールとして実装されているということでした。

まず簡単に上記の記事で紹介されているXMLSchemaデザインパターンを紹介しておきます。デザイン・パターンには次の4つがあります。

Russian Doll(マトリョーシカ) パターン

入れ子人形で知られるマトリョーシカのように、全てのエレメントと複合型が一つのエレメントの中に入れ子になった形で定義されているようなスキーマです。イメージとしてはこんな感じ。

<xsd:element name="Line">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="PointA">
        <xsd:complexType>
          <xsd:attribute name="x" type="xsd:integer"/>
          <xsd:attribute name="y" type="xsd:integer"/>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="PointB">
        <xsd:complexType>
          <xsd:attribute name="x" type="xsd:integer"/>
          <xsd:attribute name="y" type="xsd:integer"/>
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

エレメント、複合型がまとめて入れ子に定義されています。ぜんぶ一まとめでわかりやすいのですが、再利用をしようとするときには全て使うか、すべて使わないかのどちらかしか選べません。

Salami Slice (サラミ・スライス) パターン

すべてのエレメントがグローバルに定義されているようなスキーマです。 イメージとしてはこんな感じ。

<xsd:element name="PointA">
  <xsd:complexType>
    <xsd:attribute name="x" type="xsd:integer"/>
    <xsd:attribute name="y" type="xsd:integer"/>
  </xsd:complexType>
</xsd:element>

<xsd:element name="PointB">
  <xsd:complexType>
    <xsd:attribute name="x" type="xsd:integer"/>
    <xsd:attribute name="y" type="xsd:integer"/>
  </xsd:complexType>
</xsd:element>

<xsd:element name="Line">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element ref="PointA"/>
      <xsd:element ref="PointB"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

すべてのエレメントが再利用しやすい形ですが、どこがルートなのかパッと見ただけでは良くわからないかもしれません。

Venetian Blind (ベネチア風の日よけ) パターン

このパターンはマトリョーシカ・パターンの特徴を受け継いでいます。違いは中に含まれているエレメントの型をグローバルに定義しているところです。イメージとしてはこんな感じ。

<xsd:complexType name="PointType">
  <xsd:attribute name="x" type="xsd:integer"/>
  <xsd:attribute name="y" type="xsd:integer"/>
</xsd:complexType>

<xsd:element name="Line">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="PointA" type="PointType"/>
      <xsd:element name="PointB" type="PointType"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Garden of Eden (エデンの園) パターン

ベネチア風の日よけパターンとサラミスライス・パターンを混ぜたような感じのパターンです。すべてのエレメントと型は別々に定義されます。

<xsd:complexType name="PointType">
  <xsd:attribute name="x" type="xsd:integer"/>
  <xsd:attribute name="y" type="xsd:integer"/>
</xsd:complexType>

<xsd:complexType name="LineType">
  <xsd:sequence>
    <xsd:element ref="PointA"/>
    <xsd:element ref="PointB"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:element name="PointA" type="PointType"/>
<xsd:element name="PointB" type="PointType"/>
<xsd:element name="Line" type="LineType"/>

細かく再利用できそうですが、細かすぎてわかりにくいかもしれません。

NetBeans Enterprise PackのXMLSchemaエディタ

NetBeans Enterprise PackにはXMLSchemaエディタが含まれているのですが、上記で紹介したXMLSchemaデザインパターンを適用する、いわばXMLSchema版のリファクタリング機能がついています。
デザインパターンを適用するには、プロジェクトやファイルのウインドウで目的のXMLSchemaファイルを選択して、右クリック・メニューで「Apply Design Pattern ..」という項目を選びます。 すると次のようなダイアログで、どういう風にしたいのかをチェックしてデザインパターンを選びます。

ここでデザインパターンを適用すれば、その通りにリファクタリングされます。これはマトリョーシカ・パターンを適用した結果をXMLSchemaエディタでグラフィカルに見たところです。

次は、エデンの園パターン。

こういった形でスキーマのデザインをいろいろ手軽に試すことができるので、スキーマを設計しているときに、どの形式が使用目的にあっているか、というのを気軽に試すことができるようになります。

10月13日(金)にサンの用賀本社にて「Sun Java Composite Application Platform Suites活用セミナー」というセミナーを行うそうです。このセミナーは輪島さんによるSOAの概要から順番に紹介されますので、まだSOAについて具体的なイメージがない方でも気軽に参加できると思います。
なおセミナーは無料ですが、事前登録制となっていますのでご興味のある方はお早めに登録されることをお勧めいたします。

SunのシステムというとOSはSolarisで、その上で動作するSun Java System Application Server等のようなミドルウエアも当然、主なターゲットとしてはSolarisを設定しているのですが、Microsoftとの和解の成果なのか、現在のSun Java Enterprise Systemのミドルウエア郡はちゃんとWindowsをサポートしています。
こういったミドルウエア関連のお仕事をする上で、理屈上はOSに関する知識はほとんど必要ないのですが、パフォーマンスチューニングとかトラブルシューティングという仕事をしなければならない場合には、あった方がかなり良い、と思うことがしばしばあります。
そういったことからも最近、細々とWindowsの勉強をしています。 (藤井さんが紹介されているOpen Service Platformのお話を見ると、時代の流れに逆らっている、というか合って無いのかもなーと感じます・・。)

Windowsというと、普通にユーザとしてブラウザを使ったり、インターネットの設定をしたり、という程度＋αぐらいは知識があるつもりですが、実際のところサーバとして運用するようなWindowsについての知識はまったくありません。また会社はSolaris、家はMacという生活のためWindowsに関する知識は Windows 95で止まっています(もう10年前ですね・・)。
そこで最近読んでいるのがMicrosoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (Pro-Developer)という本です(邦訳版はインサイド Microsoft Windows 第4版〈上〉とインサイドMicrosoft Windows第4版〈下〉)。
この本はさすがにInternalsというだけあって、プロセスやスレッドの構造体、スケジューリングの実装あるいはメモリ管理についてモダンなサーバ向けWindowsの各バージョン(Windows 2000, 2003, XP)についてかなり詳細に解説しています。内容が濃いだけあってページ数も相当なものです。

この本の良いところは私のようなWindows初心者にもわかりやすくパフォーマンスモニタの監視項目などを説明している点です。今までSolarisのvmstat相当のことをどうやってモニタすれば良いのか知らず、Windowsといわれた時点でお手上げでしたが、これでなんとかちょっとずつやっていけそうです。

以前、大野さんに登録していただいたバグで、Mac OS X上のNetBeans + Enterprise Pack 5.5の日本語フォントが汚くなってしまうという課題があります。
これはEnterprise Packをインストールする際に、コンフィグファイルの $NETBEANS_HOME/etc/netbeans.config (/Applications/NetBeans5.5.app/Contents/Resources/NetBeans/etc/netbeans.confなど)に -J-Dapple. awt.graphics.UseQuartz=false というオプションが付け加えられることが原因です。
具体的に見栄えはこのようになります。
Enterprise Packインストール前。

インストール後

この問題は上記のとおり UseQuartzというオプションのオン・オフだけで制御されるので修正は簡単です。このUseQuartsをfalseにしている理由は描画速度の違いによるものです。実際のところ、UseQuartzを使用するほうが速いのか、そうでないかは様々なトレードオフがあって試してみないとわからないのですが、話によればNetBeans Enterprise PackではUseQuartz=false(つまり、フォントはアンチエイリアスされない等、見栄えが悪い)の方が高速に描画するようです。
このオプションをNetBeansの標準に取り込むという観点では、課題 83358によれば今は速さ重視だからごめんなさい。という形で却下されてしまいました。
この件に関して何かコメントや良い方法を思いつかれた方は課題 83358にコメントをしていただくか、「nbdiscuss_ja あっと netbeans.org」まで！

WSRP ProjectはOASISによるWeb Services for Remote Portletsという仕様の実装で、Sun Java System Portal Server 7の一部がオープンソース化されたプロジェクトです。
WSRP(Web Services for Remote Portlets)はポータル・デスクトップに貼り付けられる部品である小さな窓(=ポートレット)をWebサービスを使って遠隔のポータルに対してサービスを提供したり(このようなサービスの提供者をProviderと言います)、遠隔のポートレットを手元のポータルに組み込んだり(このようなサービスの利用者をConsumerと言います)、というようにポータルとして提供されているサービスを一つのサーバや場所に限定しないための言語や環境に依存しないポータルの仕様です。イメージとしてはThe AquariumのEarly Draft of JSR286 (Portlet 2.0 Spec) Availableにある図がわかりやすいですね。
また、このWSRPは現バージョンは1.0ですが、この次のバージョンである2.0もたしかDraft版が出ています。Javaにおけるポータル仕様はJSR 168 Portlet Specificationですが、WSRP 2.0への対応を謳っているJSR 286: Portlet Specification 2.0も現在Early Draftが出ているという状況です。WSRP 2.0の目玉はなんといってもInter-portlet通信でしょうか。
Inter-portlet通信はSun Java System Portal Server 7にも含まれていますが、ポートレット同士がお互いにイベント通知を行い、表示や動作において協調した動作を提供するというような機能です。これによって、たとえば発注ポートレットと在庫表示ポートレットが連携して発注とともに在庫情報が反映されるというようなポータルの構築が可能になります。

さて、このWSRP Projectですが菅谷さんもすでに紹介されていますが、最近WSRP Consumerのコードが公開されたそうです。 WSRPもいろいろ可能性のある仕様なので、ちゃんと使えるようになったら一度これを使ったなんちゃってアプリを作ってみようかなと思っています。

気づきませんでしたがJ2SE 1.3.1_19がリリースされています。Java SE 6のリリースと同時にEOL(出荷終了)とのことです。もうあまり1.3.xという話は聞かなくなりましたが、まだ使用されている方はそろそろJDK 1.4.2やJDK 5.0へのアップグレードをご検討ください。

つい先日のことですがSolaris 10のDTraceがWall Street Journal Innovation Awardを受賞したそうですね。Dtrace自身はとくにグラフィカルな機能ではないちょっと地味めの機能ですが、一度使ってしまうと、こんなすごいのはなかなか手放せないなぁーと思うほどパワフルな潜在能力を秘めています。
今日はSun Java System Application Server 8.1のパフォーマンスチューニングにDTraceを使う例を紹介します。アプリケーションサーバのチューニングというと、Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Performance Tuning Guideという結構分厚いマニュアルに広範囲にわたって説明されています。このマニュアルはなかなか内容もよく、そもそもどのようにしてパフォーマンスチューニングをしていけば良いのかといった考え方から、実際にどういう風にチューニングするかまでをよく説明しています。(残念なところは日本語版マニュアルがまだないというところでしょうか・・。)
チューニング箇所はこの分厚いマニュアルにいろいろな視点で載っているのですが、実際にチューニングをする箇所はあまり多くありません。 Java VMのGCエルゴノミクスのような自動調整機能や、Java VMやアプリケーションサーバ自身が出荷時点でチューニングされるようになってきたことが影響しているように思います。 もちろん、アプリケーション・アーキテクチャの見直しとか、コーディング上の調整はまだまだ効果絶大ですが、AppServerの設定という意味ではだいたい次の3点が主なチューニング箇所となります。

• Java VMオプション (特にガーベジコレクションなどメモリ管理関係)
• HTTPリスナの設定
• コネクションプーリングの設定

この3つのうち、目に見えて違うのは最後のコネクションプーリングの設定であるようなケースをよく経験しますので今回はその点についてDtraceでデータを取りながらチューニングをする方法を紹介します。

Java VMとDTraceの準備

実は、現在のJava VMでは標準的にDtraceを使うことはできませんので、別途Java VMのDtraceエージェントを入手します。エージェントはhttps://solaris10-dtrace-vm-agents.dev.java.net/から入手することができます。 次に準備の手順を紹介します。

1. Solaris 10を用意します :-)
2. DTraceのJava VMエージェントの配布ファイルdvm.zipをダウンロードします。
3. dvm.zipを適当な場所に展開します。
4. 次のような環境変数の設定シェルスクリプトを作ります。

   #!/bin/sh
   
   DVM_ROOT=<dvm.zipを展開したディレクトリ>
   JAVA_TOOL_OPTIONS="-Xrundvmti:all"
   
   if [ "`uname -p`" = sparc ] ; then
      LD_LIBRARY_PATH_64=$DVM_ROOT/build/sparcv9/lib
      LD_LIBRARY_PATH_32=$DVM_ROOT/build/sparc/lib
   else
      LD_LIBRARY_PATH_64=$DVM_ROOT/build/amd64/lib
      LD_LIBRARY_PATH_32=$DVM_ROOT/build/i386/lib
   fi
   
   export JAVA_TOOL_OPTIONS
   export LD_LIBRARY_PATH_32
   export LD_LIBRARY_PATH_64
   

5. このシェルスクリプトを実行して環境変数を設定します。
6. 次に、今回の計測ターゲットであるSun Java System Application Serverを再起動します。

これで準備完了です。

DTraceで計測

次にいよいよDtraceで計測を行ってみます。なお、現在のSolaris 10では計測対象となるアプリケーションはローカルゾーンで動作させていてもかまわないのですが、Dtraceはグローバルゾーンで実行する必要があります。
今回はコネクションプールからコネクションを取得する際に同期処理が行われるのですが、コネクションを取得するのに待たされている時間、を計測することによってコネクションプールのサイズと待ち時間の関係を調べてみました。
今回使ったdtraceスクリプトは次のような感じです。
monitor.d

#!/usr/sbin/dtrace -s

dvm$1:::monitor-contended-enter
{
    self->mc[tid, copyinstr(arg0)] = timestamp;
}

dvm$1:::monitor-contended-entered
{
    @mc[tid, copyinstr(arg0)] = sum(timestamp - self->mc[tid, copyinstr(arg0)]);}

dvm$1:::monitor-wait
{
    self->mw[tid, copyinstr(arg0)] = timestamp;
}

dvm$1:::monitor-waited
{
    @mw[tid, copyinstr(arg0)] = sum(timestamp - self->mw[tid, copyinstr(arg0)]);}


pid$1::exit:entry {
   printf("\nMonitor Contended:\n");
   printa(@mc);

   printf("\nMonitor Wait:\n");
   printa(@mw);
   exit(0);
}

ここではmonitor-waitとmonitor-contended-enterというプローブを使って、それぞれのスレッドが同期処理でどの程度待たされているのかを計測しています。(なお、このスクリプトはかなり簡略化しているので、アプリケーション自体が同期処理を行う時間も含まれています。必要に応じて条件を追加してフィルタリングをしてください。)
このスクリプトに実行権を与えて、引数にアプリケーションサーバのインスタンスのPIDを引数として渡します。

 # chmod 755 monitor.d
 # ./monitor.d <AppServerのPID>

これでモニタリングが開始します。この後に負荷試験を行って特性を計測します。 負荷試験が終わったらアプリケーションサーバを停止します。すると、次のように結果が得られます。

CPU     ID                    FUNCTION:NAME
  0  47931                       exit:entry 

       40  ContainerBackgroundProcessor[StandardEngine[com.sun.appserv]]           111876
      113  Timer-4                                                   141871141
      176  service-j2ee                                           142310303401
      168  service-j2ee                                           142381032157
      124  service-j2ee                                           142968651607

この結果は左から、スレッドID、スレッド名、待ち時間(ナノ秒)として表示されます。このようにしてスレッドプールのサイズを変えながら待ち時間を計測し、あとはStarSuiteなどでグラフ化するとその特性を調べることができるようになります。

このグラフは左奥方向にコネクションプールのサイズ(8〜128)、右奥方向にスレッドがコネクションを占有する時間(コネクションの使用時間)と条件を変えたときのそれぞれの平均待ち時間をグラフ化したものです。このように、占有する時間が長い(=重い処理をしている)場合にはコネクション数はそれ相応でなければならないことが一目瞭然です。
すこし説明が長くなってしまいましたが、このようにDtraceはアプリケーションやアプリケーションサーバの特性を知るのにとても有益な情報を与えてくれます。
もちろん、NetBeans Profilerのようなプロファイラはもっと多くの情報を与えてくれます。しかし、どちらかというとプロファイラはアプリケーション・サーバのチューニングという観点では情報が多すぎるのと、オーバーヘッドが大きすぎます。
このため、アプリケーションの構築がほぼ終わり、あとはテスト環境でアプリケーションサーバのテストを！という時にはこのようなDTraceによる計測は真価を発揮してくれます(もちろん、開発中に使っても便利です)。

今日も引き続きなんちゃってブラウザ編です。今回紹介するのはjava.awt.RobotというAPIです。
このAPIはJ2SE 1.3から導入されたAPIでかなり歴史があります。このAPIはもともと自動テストやデモ向けの、まさにロボットにアプリケーションを操作させることを目的としたクラスでキーボードやマウスのエミュレーションのほか、その途中経過の画面をキャプチャすることのできるようなAPIです。
これを使って今回はなんちゃってブラウザにブックマーク機能をつけてみました。

タブブラウザなのは前回までと同じですが、ブックマークボタンを押すと、そのときのスクリーンショットとともにブックマークに追加できます。ちなみにスクリーンショットは

  Rect rect = .. // スクリーンショットとして取り込む範囲
  BufferedImage capture = new Robot().captureScreenCapture(rect);

というように簡単に取り込むことができます。

結構、ブラウザのブックマーク機能って昔から同じような感じですが、パソコンも性能が上がってきたことですし、そろそろこういう感じでブックマークをよりわかりやすくしてくれるようなものがあってもいいのになあと思ったり・・。

JDIC(JDesktop Integration Components)というプロジェクトのコンポーネントの一つにWebブラウザコンポーネントというのがあります。なんだ、JavaでWebブラウザならしょぼいけどSwingでもJEditorPaneとか使えばできるでしょ。とか思われるかもしれませんが、JDICはネイティブ実装と組み合わせて動作するので、Run Anywhereでなくなる場合がありますが、たとえばInternet Explorerの画面をSwingアプリに貼り付けて、しかもURL指定とか、ダウンロードが終わったイベントとかを取れたりするちょっと力技のすごいAPIなのです。
今日はこのAPIを使ってInternet Explorerのレンダラを使ったタブブラウザをつくってみました。とても簡単です。ちなみに出来上がりはこんな感じです。

ちゃんとエラー表示の下のほうをみると「Internet Explorer」と出ていますね。さて、早速作り方です。

まずは、JDICのライブラリをダウンロードしてきます。今日時点での最新版は0.9.1です。今回はWindows版のjdic-0.9.1-bin-windows.zipを使用します。

アーカイブを展開したら jdic.jarをNetBeansプロジェクトのライブラリに追加します。

次に実行時のライブラリを追加します。拡張子がdllとかexeのものです。NetBeansのライブラリの追加は.jarとかしか反応してくれませんので、ディレクトリを選択してからファイル名の欄に「*.*」などを入力して全ファイル表示してから追加すると楽チンです。

ではさっそくブラウザのデザインです。なんちゃって感を出すためにデザインには懲りません(笑)。追加したのはJTabbedPaneとJTextFieldです。

次にJTextFieldにアクションを追加します。プロパティの「イベント」タブをクリックして、actionPerformedというアクションのところの「<なし>」と書かれているところをクリックすると新しいアクションが追加されます。

では早速コーディングです。jTextFieldのアクションのところに次のようなコードを書きます。(jTextField1やjTabbledPane1などの変数名は適当に読み替えてください)

    private void jTextField1ActionPerformed(java.awt.event.ActionEvent evt) {
        final WebBrowser browser = new WebBrowser();
        browser.addWebBrowserListener(new WebBrowserListener() {
            public void titleChange(WebBrowserEvent webBrowserEvent) {
                jTabbedPane1.setTitleAt(jTabbedPane1.indexOfComponent(browser), webBrowserEvent.getData());
            }
            public void statusTextChange(WebBrowserEvent webBrowserEvent) {}
            public void downloadStarted(WebBrowserEvent webBrowserEvent) {}
            public void downloadProgress(WebBrowserEvent webBrowserEvent) {}
            public void downloadError(WebBrowserEvent webBrowserEvent) {}
            public void downloadCompleted(WebBrowserEvent webBrowserEvent) {}
            public void documentCompleted(WebBrowserEvent webBrowserEvent) {}
        });
        try {
            browser.setURL(new URL(jTextField1.getText()));
        } catch (MalformedURLException ex) {
            ex.printStackTrace();
        }
        jTabbedPane1.add("(タイトルなし)", browser);

これで出来上がりです。簡単ですね！

今日もまた気になるツールの紹介です。今日はOpenGrokです。これはOpenSolarisプロジェクトで使用されているソースコードブラウザで、WebインタフェースとSwingによるリッチクライアント・インタフェースの両方を備えるソースコードブラウザです。
この手のツールとしてはLXRが有名ですが、OpenGrokを教えていただいた方曰く、LXRより設定が簡単(CTagsを用意して、TomcatかGlassfishにデプロイするだけ)、速い、C/C++/Java等々対応、キーワード検索もイケてる。等など大絶賛でした。こういうツールが活躍するのはOpenSolarisやGlassfishのような大規模オープンソースプロジェクトのソースをちょこっと参照したい、というときもそうですが、突然トラブルシューティングという話で20万行ぐらいのソースを見なければならなくなった場合(涙)などにものすごい効果を発揮します。
20万行ぐらいであれば、NetBeansなどに取り込んでもまあ、問題ないのですがいろいろソースをブラウズしているとNetBeansエディタウインドウがたちまちいっぱいになってクローズするのが面倒だったりするのでWebブラウザで見るほうが便利だったりするのです。
こちらもまだちゃんと試していませんが、面白い使い方などあればまた紹介していこうとおもいます。

前から気になっているんですがなかなか使う機会がないツールに Hudsonというツールがあります。これはアプリケーションのビルドを自動化するツールで、アプリケーションのビルドをスケジュールしておいて自動的にビルドしてくれるというものです(当然、ビルドだけではなくJUnitのテスト等も実行してくれます)。
このツールは単に、ナイトリービルドを自動化するというだけのスケジューラではなくて、いままでローカルの開発用PCでビルドしていた作業をサーバ上でやってしまおうというものです。GUIもなんとなく洒落ているので、ぜひ使ってみたいところですが、なにぶん私のような下々の者がすぐに使えるサーバが社内には無い・・・。ということで前からぜんぜん試せていません。 ご興味がある方はぜひ。

この二つの製品。じつは片方、おかしなところがあります。さて、どこでしょうか？

実は、Sun Java Enterprise Systemのスプラッシュスクリーンの背景画像の "S"カーブが左右対称になっていて、"S"カーブではなく、なんとなくカーブになっています。なぜだか良くわかりませんが一時期この逆S現象がSunの製品にはいくつか見られました。
最近、ようやくいろいろな人が気づき始めたのかBetaプログラムが始まったJava Enterprise System のリリース5ではちゃんとした"S"カーブになっています。気になる方はチェックしてみてください。