ボーランドの.NET戦略

聞き手、文責：デジタルアドバンテージ
2003/12/25

藤井：モデルといってもいくつかのレベルがあります。具体的にはプラットフォームに依存した部分と、依存しない部分があります。例えばJavaでいえば、Javaプラットフォームに特に依存しない抽象度の高いモデルのレベルと、それを現実のシステムとして実装するためにJavaプラットフォームを駆使するレベルがあります。これはシステム開発で「一汗かく」部分で、現状ではここにさまざまなノウハウが存在します。Togetherはクラス図とソースの自動連携機能を提供しますが、ここで作業しているモデル図は、プラットフォーム非依存の抽象度の高いものではなく、あくまで各プラットフォームを前提としたモデルになります。従って抽象度の高いモデル図から始めるには、プラットフォーム依存のモデルを作るというもうひとつ追加の作業が必要になってしまいます。抽象度の高いモデルを設計するだけで、実際のコード生成に至るまでの一連のプラットフォーム依存の実装を自動化するツールとして、ECO（Enterprise Core Objects）があるのです。

奥村：ECOは、OMGが提唱しているモデル・ドリブン・アーキテクチャ（MDA：Model Driven Architecture）を実装したものです。ECOでは特定のプラットフォームに依存しないモデルを作成可能で、C# Builderが最終的なC#のソースコードを生成し、実行可能プログラムを生成します。クラスのリレーションなど、実装はすべてECO任せにすることができます。このECOの一部はTogetherの技術を用いて開発されています。

藤井：将来的に目指しているのはそこです。プラットフォームに依存しない抽象度の高いモデルから、共通のインターフェイスを通して現在のTogetherが担当する世界をつなぐことができれば、プラットフォーム非依存のMDAが実現されます。そこまで行けば、.NETとJavaが本当に何の違和感もなく1つの選択肢として同じ土台に立つことになるでしょう。

奥村：ECOのクラスですね。顧客や在庫など、ECOのクラス・レベルで抽象化したオブジェクトの関係付けなどを作り、実装部分はすべてECOに任せるスタイルです。開発者の作業は、どういうデータをどのように表現するかということをクラス図のデザイナで定義することです。データベースのスキーマ設計を始めとして、Togetherのところでお話しした「汗をかく」という部分をすべてECO任せにできるわけです。そして最終的には、ユーザー・インターフェイス・デザイナを利用して、ECOによって生成された実体とユーザー・インターフェイスとを結び付けます。

藤井：先にデータベースがあるのに、後からECOが勝手なスキーマを生成してくれても困るということですね。確かに既存のWindowsテクノロジ・ベースのソフトウェア開発では、このような手法は馴染まないかもしれません。しかしJavaプラットフォームには先例があります。EJBには、永続的なストレージ・メカニズムの中でビジネス・オブジェクトを表現するエンティティBeanと呼ばれるものがありますが、ECOによるスキーマ生成はまさにこれにあたります。エンティティBeanを設計して、そのエンティティBeanをどのように永続化するかということは、最終的にデータベースがどのような構成になるかとは関係がありません。ECOは、こうしたエンティティBeanの発想を.NETプラットフォームに持ち込むものです。とはいえ現実には、データベースの構成によってシステムの性能は大きな影響を受けますから、最終的に適用されるデータベースの構成には目を光らせる必要があります。抽象度の高いモデル設計と、最終的なデータベース・チューニングのギャップをいかに埋めるかといった部分が今後のシステム開発のノウハウになっていくでしょう。

藤井：現実のシステム開発で、プラットフォームの統一を迫られる具体的な理由は、異なるプラットフォーム間の相互運用におけるパフォーマンスの低下や、トランザクションの不完全性などです。つまりWebサービスのブリッジ・ソフトウェアによるパフォーマンス低下、トランザクション制御不全などからくる問題です。この問題を解決することが、Javaと.NETを両立させるポイントだろうと思います。このために開発されたミドルウェアがJanevaです。具体的には、.NET Framework対応アプリケーションと、J2EE／CORBA（Common Object Request Broker Architecture）のランタイム環境との完全でシームレスな相互運用を実現します。

藤井：それはよく質問されます。Webサービスの発表以来、一時は「CORBAの時代はこれで終わった」などといわれたものですが、現実にはいままさに脂が乗ってきたところ、といってよいでしょう。この理由の1つは、J2EEがCORBAの仕様を取り込んだことです。これにより、イントラネット内部での軽量なアプリケーション連携用プロトコルとしてCORBAの採用が徐々に進み始めました。もう1つの理由は、通信事業者などでCORBAの採用が定着してきたことです。例えばCisco社は、ルータのリモート・メンテナンス用プロトコルとしてCORBAを採用しています。

藤井：ええ。.NET側から見れば、相手のシステムが何であれ、CORBAのインターフェイスさえ備えていればJanevaで接続可能になるということです。

藤井：アプリケーション連携の方法には、通信するアプリケーションの独立性を高めた疎結合と、独立性よりもパフォーマンスを重視する密結合の2種類があります。このうちWebサービスは疎結合のプロトコルであるのに対し、CORBAは密結合のプロトコルとして位置づけられます。例えていえば、野球で内野手が近距離で素早くボールを回すのが密結合、外野手同士が遠投でボールを回すのが疎結合です。Webサービスの長所は、ファイアウォールを越えてアプリケーション同士が連携できることです。例えばファイアウォールを越えて企業間でのシステム連携を行うならWebサービスを利用するのがよいでしょう。しかしプロトコルとしてのオーバーヘッドは大きく、またトランザクション管理機能などもまだ整備されていません。従ってクライアント・サイドのGUIアプリケーションとサーバとの間で頻繁にデータのやり取りを行ったりする場合にはWebサービスは向きません。またWebアプリケーションのようなもので、セッションを保持しながら、一連の画面遷移の中で処理が完了したかどうかを保証し、処理が途中で失敗した場合にはロールバックするなどのトランザクション管理を実現するにはWebサービスは不向きです。このような用途にはCORBAを採用したほうが有利でしょう。Webサービスでトランザクション管理を行うことも可能ですが、その場合にはそれらの機能を自身で実装する必要があります。

藤井：それは誤解です。オブジェクト指向設計やモデル指向開発を学習したいと思うなら、理屈から始めるより、まずはTogether for VS.NETをインストールして動かしてみてもらいたいと考えています。すでに述べたとおりTogetherは、ソースコードさえあればそこからクラス図を生成することができます。

藤井：そうです。世の中の風潮では、オブジェクト指向設計の入門というと「UMLありき」で始まるものが少なくありません。しかしすでに開発中のソースコードがあるなら、そこからツールを使ってモデル指向開発の第一歩を踏み出せばよいのです。それでコードベース開発での問題点が解決するなら、ツールを使い続けてもらえばよいと思います。やれクラス図だ、ユースケース図だと勉強させて「きっといつかは役に立つ」と教えられるより、よほど楽しく学べるはずです。Together for VS.NETはVS.NETのアドオンですから、インストールしても用がなければ使わなければよい。でもコードベース開発で行き詰って、モデル指向開発が何らかの答えを与えてくれるのではと思ったなら、Togetherを呼び出してクラス図を生成してみればよいのです。

藤井：このようなアプローチはJava開発者にはマッチしないかもしれません。しかしUMLのメリットをこれから知るかもしれないという.NET開発者の方々にUMLツールを紹介する方法としては、このようなアプローチが現実的だろうと考えています。