ObjectSquare [2001 年 8 月号]

［レポート］



JavaOne2001参加報告


（株）オージス総研
藤井　拓


去る6月4日〜8日に渡り、サンフランシスコのMosconeセンターで開催されたJavaOne2001に参加しました。聴取したセッションの中で、興味深かったテクニカルセッション2セッションの内容を紹介したいと思います。



・TS-2218： “Scaling XP to Large Projects for the Java™ 2 Platform, Enterprise Edition(J2EE™)”, Michael R. Lauer(Brokat Technologies)
Mosconeセンター（会場の一部）
Mosconeセンター（会場の一部）

このセッションは、XP(eXtreme Programming)を自己流にアレンジして20人規模の開発チームに適用し、J2EEベースのシステムを開発した事例報告でした。

発表者のLauerさんは、製品販売とSIに関するビジネスを展開しているBrokat Technologiesというベンチャー会社の金融関係のフレームワークを開発している事業部の事業部長(Director)です。この発表者は、かなりの読書家で毎週のように本屋さん通いをして新刊本を漁っているようです。その本屋さん通いの過程でXP本[1]と出会い、　自社の開発にXPを適用してみようと思い立ったそうです。

発表者は、XPのプラクティスにおいてスパイラルな開発モデルを補完すると思われる以下のプラクティスが本質的に重要と考えたようです。
TS-2218のセッションの様子
TS-2218のセッションの様子

最後の項目は、「（開発が進行しても）変更のコストがフラットになり、変更を恐れることがない」というXPの効能を意味しています。ちなみに、この発表者はスパイラルな開発モデルを「使い捨てのプロトタイプを作成しながら、開発を進めていく開発プロセス」と理解しているようでした。従って、これらのプラクティスは使い捨てせずにプロトタイプを発展させるという観点で有効と思われるものが選ばれたようです。

スパイラルな開発モデルを補完し、より良い開発プロセスを構築するために選ばれたプラクティスは以下のとおりです。

これらのプラクティスのうちで、ペアプログラミングについては必要に応じて共同作業を行えば良いという意見でした。週40時間労働のプラクティスが除かれていたことに対しては、会場からはかなりのブーイングが飛んでいました。これらのプラクティスを、発表者はMXP(Modifiable eXtreme Programming)と呼んでいました。

実際には、これらのプラクティスだけではなく、開発プロジェクトで作業分割を行い、並行に開発を行うために「設計のテンプレート化(Templated Design)」というテクニックも併用しています。対象となったプロジェクトでは、J2EE上に銀行業務をサポートするフレームワークを開発することが主目標になっています。そのために、アーキテクト以下数名がチームを組んで、J2EEのシステム階層を3グループに分けて、フレームワークを構成する標準的な要素を特定し、その要素毎に対する標準の設計や実装サンプルを作成したそうです。例えば、ＸＸマスタ−画面とＸＸ詳細画面がこのような標準的な要素の例になります。このような標準的な要素の特定とそれらに対する標準の設計や実装サンプルの準備に2回のリリースを要したという話でした。これらの2回のリリースの最後に、標準の設計や実装サンプルのRefactoringを行ったようです。後続する3回目のリリースでは、システムの機能を分割し、開発プロジェクト内の各チームの開発分担を決め、標準の設計や実装サンプルを参考にして並行開発を行ったようです。

結論としては、MXP、J2EE、「設計のテンプレート化」の3者の組み合わせにより、XPの考え方をより大きな開発チームに適用できたということでした。 　
MXPを実際に実践して、発表者が感じた利点は以下の点のようでした。

このプロジェクトでは開発と並行しながら、採用を行って開発要員を増員したようで、そのような状況で採用者の立ち上がりを非常に早くできたようです。ただし、一方では採用基準はかなり厳格で、Java等の技術に心得があり、こだわりがある人しか採用していないとのことでした。（採用方法も、かなり工夫しているようでした）


筆者の所感

この事例の成功要因は、以下の2点にあったと解釈できるような気がします。

その点で、反復型開発プロセスを実践する際のお手本としては一般的に参考にできる事例だと思います。開発基盤となるフレームワークをいきなり開発しようと力まなかったような現実主義的な考え方も成功要因だと言えるかもしれません。
このプロセスをXPと呼ぶか否かについては、意見が分かれるところであろうと思います。ただ、XPにせよ、RUP[3]にせよ、プロセスのプラクティスは実際に有効と思われる内容を自ら取捨選択する必要があるということをこの事例から学ぶべきではないでしょうか。


・TS-1978：“Developing a Complex Application for the Java™ 2 Platform, Etnerprise Edition(J2EE™), for Continuous Availability and High Performance”, Torbjörn Keisu(Ericsson), Vlada Matena(Sun Microsystems)

このセッションは、J2EEのEJBのCMP(Container Managed Persistence)モデルを用いて、通信分野でのシステムに要求される99.9999%の高可用性（年間で累計30秒のダウンしか許容されない）が実現できるかどうかプロトタイプを設計、実装し、評価した結果を報告したものでした。

評価対象となったシステムは、RNS(Radio Network Server)というもので携帯電話の通話管理、基地局のリソース管理、携帯電話の通話のセル間でのハンドオーバーを行う機能を担っています。RNSは、休止しないので高可用性とともにソフトやハードのオンラインアップグレード、障害の分離／普及、ロードバランシング、運転状態でのスケールアップを要求されるとともに、サービス時間の上限が50msに設定されているソフトなリアルタイムシステムです。
展示会場の入り口付近
展示会場の入り口付近

RNSを構成するソフトの中核をなすのが、Cell Managerと呼ばれる機能です。このCell Managerは、Cell内の携帯電話、基地局、携帯電話用交換機の間のコネクションを確立し、そのコネクションの状態を監視する役割を担っています。また、セル間を跨ったコネクションのハンドオーバー等をサポートすることも求められるようです。

求められる高可用性を実現するためには、Cell Managerが管理するコネクションの割り当てやコネクションの状態がソフトウエアやハードウエアの障害によって失われないようなアーキテクチャを考える必要があります。通常、各セルを管理するCell Managerは各々独立したCPUで実行されます。そのため、障害発生時には実行時に各セル毎に存在するチャンネルとコネクション間の割り当て関係やコネクションの状態をCPU間で受け渡しする必要があります。

今回講演で言及されたアーキテクチャは、割り当て関係やコネクションの状態を保持するためにEntity Beans が用いられています。これらのEntity BeansはCell Managerが実行されるスレッド上で存在するとともに、そのレプリカが別ノードのCPU上で動作しているReplicated State Managerというコンポーネントにより保持されています。また、RNS全体のCell Managerの実行状態を監視し、障害発生時にはCell ManagerのCPUへの割り当てを動的に変更する役割を担うControl Managerというコンポーネントも使用されています。結局、これらCell Manager, Replicated State Manager, Control Managerが連携することにより、ソフトウエアやハードウエア障害の発生時やソフトウエアのオンラインアップグレード時に割り当て関係やコネクションの状態がノード間で受け渡しできるようになっています。
Mosconeセンターの入り口付近
Mosconeセンターの入り口付近

このように異なるノード間でEntity Beansを共有するために、J2EEのEJBのCMP(Container Managed Persistence)モデルが用いられたとのことです。ちなみに、このシステムで用いられたアプリケーションサーバはEricsson社のオリジナル実装に基づくものだそうです。

また、基地局や携帯電話用の交換機等のリソースとCell Manager間の相互作用は、Resource AdaptorとMDB(Message Driven Beans)という非同期通信をサポートするJava Beansを利用して実装されているようです。Cell ManagerのCPUへの割り当て変更が起こった場合には、非同期通信のメッセージ経路を切り替えれば良いので、利にかなったアーキテクチャであると思います。

評価結果としては、可用性や時間的な制約等々の面でEJBのCMPモデルを用いた今回のプロトタイプで既存のシステムと同等の性能が実現できたそうです。


筆者の所感

「システムのアーキテクチャとは、何を指すのか」と質問されることが時としてありますが、この講演内容はそのような疑問に答える具体例だといえます。すなわち、アーキテクチャとして検討すべき内容と解決策を丁寧に説明した良い講演だったと思います。


参考文献

[1] ケント・ベック：　XPエクストリーム・プログラミング入門、ピアソン・エデュケーション
[2] マーチン・ファウラー：　リファクタリング：プログラミングの体質改善テクニック、ピアソン・エデュケーション
[3] フィリップ・クルーシュテン：　ラショナル統一プロセス入門（第2版）、ピアソン・エデュケーション



アンケートにご協力お願いいたします
記事の内容を５点満点で評価してください。
1点 2点 3点 4点 5点
© 2001 OGIS-RI Co., Ltd.
HOME HOME TOP　オブジェクトの広場 TOP